From nobody Fri Aug 1 01:13:28 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B0B1A045B for ; Fri, 1 Aug 2014 01:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.693 X-Spam-Level: ** X-Spam-Status: No, score=2.693 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 VPjQViMDzLPv for ; Fri, 1 Aug 2014 01:13:23 -0700 (PDT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181271A036F for ; Fri, 1 Aug 2014 01:13:22 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube3.xs4all.net [194.109.20.199]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id s718DB7W018376; Fri, 1 Aug 2014 10:13:12 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 01 Aug 2014 10:13:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 01 Aug 2014 10:13:11 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <3398D003-F294-455D-A036-AB7C92CDB1E8@cs.stanford.edu> References: <067.f0fd62a4161a1ac153a9b089b2780010@trac.tools.ietf.org> <538302CC.9020904@toshiba.co.jp> <3398D003-F294-455D-A036-AB7C92CDB1E8@cs.stanford.edu> Message-ID: <01206ae54ce5202d5afdc5225bb5653d@xs4all.nl> X-Sender: stokcons@xs4all.nl (Pi7IaY9fn0RyWGcpSYkR/bhMQJS5NGgv) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/roll/o6wX3DFzf01jIXYoFrwuoTBMZMI Cc: draft-doi-roll-mpl-parameter-configuration@tools.ietf.org Subject: Re: [Roll] [roll] #157 (draft-doi-roll-mpl-parameter-configuration): mpl-parameter-configuration-00 - Effect of inconsistent parameter set among nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 08:13:25 -0000 > Depending on K, a difference in Imax can do more than just > increase/reduce responsibility. It could actually lead to complete > suppression. Is it not better to consider the relation between K and the number of 1-hop MPL neighbours? Supposing M is the number of 1-hop neighbours of a node, one can reason about: K > M, where no suppression occurs K < M there is an increased probability of suppression that increases with increasing Imax Greetings, Peter Philip Levis schreef op 2014-07-29 19:25: > On May 26, 2014, at 2:01 AM, Yusuke DOI > wrote: > >> Hi, >> >> Thank you for summarizing issues on my draft. >> On #157, my understanding is as follows. If there are any issues you >> know, please let me know. >> >> Inconsistent but valid parameter does not harm the network much (it >> may harm battery-powered nodes). > > Given the L in RPL/MPL includes the term "low power", harming > battery-powered nodes is kind of important. It's easy to try to ignore > them because they're so challenging, but I'd strongly recommend > against it. > >> >> Reason: >> >> 1) If a node have smaller Imin/Imax, it takes more responsibility to >> repeat messages than surrounding nodes. The node will consume more >> power and the area will have higher traffic than expected until MPL >> parameters of the node is updated. > > It's worth noting that transmission (in most link layers MPL/RPL care > about) does not consume significantly more energy than reception. > Therefore, one node that has a smaller Imin or Imax introduces an > energy cost on *all* of the nodes around it. > > A smaller Imin can double the latency of propagation over a single > hop, as nodes, on receiving an update, receive multiple Trickle > messages and so suppress for their first interval. > > Depending on K, a difference in Imax can do more than just > increase/reduce responsibility. It could actually lead to complete > suppression. Consider the case where three nodes have Imax=t and one > node has Imax=t+2 (so the actual time interval is 4 times greater). > K<=3. The three nodes will almost always completely suppress the > fourth node with the longer interval. > >> 2) If a node have larger Imin/Imax, it takes less responsibility to >> send messages than surrounding nodes. As other nodes will send the >> message instead of the node with old parameters, effect for traffic >> load and e2e delay is negligible on dense mesh clusters. If the node >> with old parameters is on sparse area of a mesh network, larger >> Imin/Imax will cause larger e2e delay than new parameter's expectation >> untilthe node is updated. > > You should disambiguate the effects of Imin and Imax. > >> 3) If a node have smaller K, it takes less responsibility to repeat >> messages than surrounding nodes. On dense network, the effect is >> negligible. On sparse network, messages pass through the node will >> have less reliability until the node is updated. > > It also introduces uneven transmission load. A node with a higher K > will transmit with a much higher probability that those with the lower > K (within the logarithmic bounds introduced by packet loss). > > I'd suggest re-reading 6206 (Section 6), which goes into greater > detail than the bullet points above and is much more specific. > >> 4) If a node have larger K, it will repeat almost all the messages. >> The area will have excessive traffic untile the node is updated. >> > > This is not true. Note that packet loss/imperfect duplicate > suppression/uneven topologies often cause some nodes to receive more > than K packets. Again, I'd suggest re-reading 6206. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Fri Aug 1 02:38:59 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 A3B9F1A030D; Fri, 1 Aug 2014 01:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAfW_WCWya9J; Fri, 1 Aug 2014 01:50:16 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087061A010D; Fri, 1 Aug 2014 01:50:15 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn18so1161385igb.3 for ; Fri, 01 Aug 2014 01:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hsGlE5ethnUo51DLtSkziO+xogSTV0FnomfyTMbLajE=; b=jTcPiZYbUAqvecNGsWM/XrjkulibrsBz8W0Yit1stWEvEMrJzmt3v7rTrhVGZ4990f g9hyttpjmr9tH0F1oJ93AccnGhZFqm1OH49OovanVvrwWQcmPqkH/LYRVg7OraoMOT0b bWQK6HJUF46bRjfErrpe85Bn/LP7XLDiZIgUJYSR3ke+KQ+IdRD5JXVgbC1lL9QbMM3h 2EDsPhBfohw7OPSnrwYy8MNfSOhuU/pUkgFhGSESq+d9wcABhtEPQrcNYd/uE8Xd7w9c zh37vNEM8a/dWfwXvIMYtbTAlMOILr+/szurtzdvL+pu6tGfLadPlSADJFtckvC3Ulxu F4ew== MIME-Version: 1.0 X-Received: by 10.42.109.79 with SMTP id k15mr5287828icp.42.1406883015394; Fri, 01 Aug 2014 01:50:15 -0700 (PDT) Sender: xvilajosana@gmail.com Received: by 10.64.129.198 with HTTP; Fri, 1 Aug 2014 01:50:15 -0700 (PDT) In-Reply-To: <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> Date: Fri, 1 Aug 2014 10:50:15 +0200 X-Google-Sender-Auth: _k70OTDGsaT1OR1GClrs1hWOAWo Message-ID: From: Xavier Vilajosana To: Philip Levis Content-Type: multipart/alternative; boundary=20cf303dd3b05f8a8f04ff8d7a46 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/jtNBTMICUy8H4RhMYCmvLqCiBh0 X-Mailman-Approved-At: Fri, 01 Aug 2014 02:38:58 -0700 Cc: Brian Haberman , "ipv6@ietf.org" , Michael Richardson , roll , Ines Robles , Bob Hinden , Ole Troan , Brian E Carpenter Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 01 Aug 2014 08:50:18 -0000 --20cf303dd3b05f8a8f04ff8d7a46 Content-Type: text/plain; charset=UTF-8 Dear Phil, all, I do not completely agree :) Let's look at what IPHC does at the LBR when a flow label is elided and has to be inflated to be forwarded to the IPv6 network, this standardized behaviour is somehow interfering the end to end notion of the flow label as the content is being populated at the border of the LLN. For me this is not different than changing the scope of the flow label inside the LLN to transport RPL information and resetting it at the LBR once data moves outside of the network considering that inside the LLN the flow label has no meaning. Looking into an article we wrote some time back, "A Realistic Energy Consumption Model for TSCH Networks". published in IEEE Sensors we know that the charge used by a mote (something similar to telosb) to send 127bytes is around 69uC and to receive them is 72uC (considering the optimal case where receiver has a guard time of 1ms and the network is synchronized). By using the flow label instead of the RPL extension header we save 5bytes which give us a gain 2,71uC per data packet per hop when sent and something similar when received (i.e ~5uC in total), this is a 8% saving (accounting TX and RX side) considering that motes are always using 127bytes packets. If we go to a more realistic case where motes send ~50bytes packets, the charge needed to send/receive them is something around 27.5uC and being able to save 5 bytes represents a 10% saving for the sender and 10% for the receiver (~20% saving if we look it overall per hop). If we use batteries that power the mote for 5 years, a 20% saving gives us ~1 more year which I think is pretty significant. regards, Xavi 2014-08-01 0:11 GMT+02:00 Philip Levis : > > On Jul 29, 2014, at 6:36 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > On 30/07/2014 12:02, Philip Levis wrote: > > ... > >> "This specification suggests that energy-saving is another > >> compelling reason for a violation to the aforementioned > >> rule." > >> > >> makes the assumption that the energy saving is significant. > >> Breaking the end-to-end nature of the flow label for some > >> tiny saving seems like a mistake. > > > > I can't evaluate whether the energy saving is significant. > > However, I don't have any deep faith in the e2e-ness of the > > flow label. The reality (as RFC 6437 tries to recognise) > > is that it's a mutable field, and is therefore untrustworthy > > for e2e use. It has value for load balancing if all packets > > of a given flow have the same label, whether the label is > > set by the source or by a border device. For that reason, > > I think the usage proposed in this draft is OK. > > > > However, I do agree that at least a hand-waving estimate of > > the % energy saving would be useful. > > > > Brian Carpenter > > *shrug* My thoughts are pretty simple. I'm sure you know all this (as one > of the authors!) but I'll revisit for everyone else's sake. 6437 states > > "A forwarding node MUST either leave a non-zero flow label value unchanged > or change it only for compelling operational security reasons as described > in Section 6.1." > > So, this is a MUST. Either the RPL flow label draft contradicts 6437 (and > should say so explicitly), or there should be an explicit update to 6437. > In fact, the current draft is misleading and incorrect. It says > > "but the RFC also indicates a violation to the rule can be accepted for > compelling reasons, and that security is a case justifying such a > violation. This specification suggests that energy-saving is another > compelling reason for a violation to the aforementioned rule." > > This is *not* what 6437 says. It says for compelling operational security > reasons, not compelling reasons, of which one case is security. > > Having been researching, implementing, and deploying low-power protocols > for over a decade, I've become exceedingly skeptical when someone proposes > a protocol with energy as a motivation without quantifying it. For example, > there are tons of protocols in the research literature which talk about > using transmission power control to save energy (trading off range for > power). But almost all of these papers ignore the fact that (unlike > mobile/cellular systems, which the authors have been publishing in for > years) RF is a tiny sliver of power in low-power networks. So reducing your > transmission (RF) power by 99% only reduces your radio power by 50%. > Generally a losing proposition. This is the same reason why power saving in > WiFi involves synchronization on AP beacons and not adjusting transmit > power. If someone doesn't quantify the potential benefit based on real > hardware and protocols, then it could be based on mistaken assumptions. > > I mean, it doesn't take much here. Start with a working low-power RPL > network. Send packets with sizes following a reasonable distribution based > on an actual application. In one experiment send just those packets. In > another add the 8 bytes. In a third add 8 + the IP-in-IP encapsulation. > Measure the energy cost. > > And, generally speaking, if you can't demonstrate the problem very easily, > then perhaps it isn't a real problem at all. > > All that being said, I think using the flow label in this way is a good > idea, and definitely valuable. But as it is now, doing so violates 6437, > and so the assumptions implementers make when reading 6437. I think the bar > for doing so should be high, higher than vague suggestions and hand waving > which might not be correct. > > Phil > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --20cf303dd3b05f8a8f04ff8d7a46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Phil, all,

I do not com= pletely agree :)

Let's look at what IPHC does = at the LBR when a flow label is elided and has to be inflated to be forward= ed to the IPv6 network, this standardized behaviour is somehow interfering = the end to end notion of the flow label as the content is being populated a= t the border of the LLN. For me this is not different than changing the sco= pe of the flow label inside the LLN to transport RPL information and resett= ing =C2=A0it at the LBR once data moves outside of the network considering = that inside the LLN the flow label has no meaning.=C2=A0

Looking into an article we wrote some time back, "= A Realistic Energy Consumption Model for TSCH Networks". published in = IEEE Sensors=C2=A0

we know that the charge used by= a mote (something similar to telosb) to send 127bytes is around 69uC and t= o receive them is 72uC (considering the optimal case where receiver has a g= uard time of 1ms and the network is synchronized). =C2=A0By using the flow = label instead of the RPL extension header we save 5bytes which give us a ga= in 2,71uC per data packet per hop when sent and something similar when rece= ived (i.e ~5uC in total), this is a 8% saving (accounting TX and RX side) c= onsidering that motes are always using 127bytes packets.

If we go to a more realistic case where motes send ~50b= ytes packets, the charge needed to send/receive them is something around 27= .5uC and being able to save 5 bytes represents a 10% saving for the sender = and 10% for the receiver (~20% saving if we look it overall per hop).=C2=A0=
If we use batteries that power the mote for 5 years, a 20% saving give= s us ~1 more year which I think is pretty significant.

=
regards,=C2=A0
Xavi



2014-08-01 0:11 GMT+02:00 Philip Levis <= span dir=3D"ltr"><pal@cs.stanford.edu>:

On Jul 29, 2014, at 6:36 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> On 30/07/2014 12:02, Philip Levis wrote:
> ...
>> "This specification suggests that energy-saving is another >> compelling reason for a violation to the aforementioned
>> rule."
>>
>> makes the assumption that the energy saving is significant.
>> Breaking the end-to-end nature of the flow label for some
>> tiny saving seems like a mistake.
>
> I can't evaluate whether the energy saving is significant.
> However, I don't have any deep faith in the e2e-ness of the
> flow label. The reality (as RFC 6437 tries to recognise)
> is that it's a mutable field, and is therefore untrustworthy
> for e2e use. It has value for load balancing if all packets
> of a given flow have the same label, whether the label is
> set by the source or by a border device. For that reason,
> I think the usage proposed in this draft is OK.
>
> However, I do agree that at least a hand-waving estimate of
> the % energy saving would be useful.
>
> =C2=A0 =C2=A0Brian Carpenter

*shrug* My thoughts are pretty simple. I'm sure you know all this= (as one of the authors!) but I'll revisit for everyone else's sake= . 6437 states

"A forwarding node MUST either leave a non-zero flow label value uncha= nged or change it only for compelling operational security reasons as descr= ibed in Section 6.1."

So, this is a MUST. Either the RPL flow label draft contradicts 6437 (and s= hould say so explicitly), or there should be an explicit update to 6437. In= fact, the current draft is misleading and incorrect. It says

"but the RFC also indicates a violation to the rule can be accepted fo= r compelling reasons, and that security is a case justifying such a violati= on. =C2=A0This specification suggests that energy-saving is another compell= ing =C2=A0 =C2=A0reason for a violation to the aforementioned rule."
This is *not* what 6437 says. It says for compelling operational security r= easons, not compelling reasons, of which one case is security.

Having been researching, implementing, and deploying low-power protocols fo= r over a decade, I've become exceedingly skeptical when someone propose= s a protocol with energy as a motivation without quantifying it. For exampl= e, there are tons of protocols in the research literature which talk about = using transmission power control to save energy (trading off range for powe= r). But almost all of these papers ignore the fact that (unlike mobile/cell= ular systems, which the authors have been publishing in for years) RF is a = tiny sliver of power in low-power networks. So reducing your transmission (= RF) power by 99% only reduces your radio power by 50%. Generally a losing p= roposition. This is the same reason why power saving in WiFi involves synch= ronization on AP beacons and not adjusting transmit power. If someone doesn= 't quantify the potential benefit based on real hardware and protocols,= then it could be based on mistaken assumptions.

I mean, it doesn't take much here. Start with a working low-power RPL n= etwork. Send packets with sizes following a reasonable distribution based o= n an actual application. In one experiment send just those packets. In anot= her add the 8 bytes. In a third add 8 + the IP-in-IP encapsulation. Measure= the energy cost.

And, generally speaking, if you can't demonstrate the problem very easi= ly, then perhaps it isn't a real problem at all.

All that being said, I think using the flow label in this way is a good ide= a, and definitely valuable. But as it is now, doing so violates 6437, and s= o the assumptions implementers make when reading 6437. I think the bar for = doing so should be high, higher than vague suggestions and hand waving whic= h might not be correct.

Phil

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

--20cf303dd3b05f8a8f04ff8d7a46-- From nobody Fri Aug 1 04:24:09 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E871A0A99; Fri, 1 Aug 2014 04:24:06 -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 8JlMv16c09kM; Fri, 1 Aug 2014 04:24:04 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D3A1ABB18; Fri, 1 Aug 2014 04:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s71BNliK010532; Fri, 1 Aug 2014 13:23:47 +0200 (CEST) Received: from [192.168.217.106] (p5489377C.dip0.t-ipconnect.de [84.137.55.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D3147F2E; Fri, 1 Aug 2014 13:23:46 +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: Fri, 1 Aug 2014 13:23:44 +0200 X-Mao-Original-Outgoing-Id: 428585024.77831-f8a90d73a64f26af62a888953db75812 Content-Transfer-Encoding: quoted-printable Message-Id: <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> To: Xavier Vilajosana X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/L-bTu_3NaiSEZUWDUqZdEwgomF4 Cc: roll , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 01 Aug 2014 11:24:06 -0000 On 01 Aug 2014, at 10:50, Xavier Vilajosana = wrote: >=20 > Let's look at what IPHC does at the LBR when a flow label is elided = and has to be inflated to be forwarded to the IPv6 network, this = standardized behaviour is somehow interfering the end to end notion of = the flow label as the content is being populated at the border of the = LLN.=20 No. With IPHC, the flow label has always been there, it just was = transmitted in a very compressed form. I think the visceral reaction that most of us have in using the flow = label as a mesh routing header is that this blurs the layer boundaries. = So much for O, R, F, and rank. Putting the VLAN (=93instance ID=94) = into the packet is a significantly larger change, because it essentially = extends the IP service interface by a VLAN ID. We normally try to hide = IDs of this kind below IP. Now, I=92m not saying any of this new architecture is wrong. I just = think what we need to do is discuss this as the architectural change = that it is, not as a simple optimization. (The need for some kind of = optimization of IP-in-IP mesh routing for small-packet IoT applications = is pretty obvious to me.) The other story is that we are retracting RFC 6437 and turning the flow = label into the =93field you may trample on in your lower layers if you = have a good reason=94. Cynically, one could say this is proper payback = for designing this field without a compelling purpose and no protocol = evolution story attached to it. So the evolution just eats it. = Teachable moment. Gr=FC=DFe, Carsten From nobody Fri Aug 1 05:47: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 243141A0B00; Fri, 1 Aug 2014 05:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 kyycVQksyiF0; Fri, 1 Aug 2014 05:44:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9046C1A0B04; Fri, 1 Aug 2014 05:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6467; q=dns/txt; s=iport; t=1406897086; x=1408106686; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c/WKTYA/5UNVR/gnH9rZnEDWWLXiE++Vy3iLXfbKTpw=; b=PTFlutIxvO6jK7cT5hc8aq9wUsqp9+Ij+AqOeSaAjkNO5BBzV+tFHm2e 4bBHSPP6KUV75M1Yl95w//lfLb/VH7UV0C4KvDGTduaN0CTF87Cs9Wj8P AQ9VNPIDA+3RwfzAGnkhGMdVWcXLO0ZVocAdwktLon7AGk4SJyQd83O2N w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFADeL21OtJV2T/2dsb2JhbABPDA6Cf4EpBNNTAYEIFneEAwEBAQQdShIMBAIBCA4DBAEBAQodByERFAkIAgQBDQUIiCYDEcJrDYcPF40fgUYBGB0xBwaDKYEcBYpMjyKQOoYlgwdCbAGBRA X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208";a="344417706" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 01 Aug 2014 12:44:42 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s71CigDg001383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 12:44:42 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 07:44:42 -0500 From: "Pascal Thubert (pthubert)" To: Philip Levis , Brian E Carpenter Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPq3MQL9UY5QNEnE6ScMk7SCjlQJu4D/iAgAAaYwCAAutIgIAAk91g Date: Fri, 1 Aug 2014 12:44:41 +0000 Deferred-Delivery: Fri, 1 Aug 2014 12:44:00 +0000 Message-ID: References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> In-Reply-To: <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.197.62] 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/4H5QZdZ-vKr4iJJkcCp04ktOtZc X-Mailman-Approved-At: Fri, 01 Aug 2014 05:47:39 -0700 Cc: Brian Haberman , "ipv6@ietf.org" , Michael Richardson , roll , Ines Robles , Bob Hinden , "Ole Troan \(otroan\)" , Pat Kinney Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 01 Aug 2014 12:44:52 -0000 Hello Phil: The end-to-end principle will not break in pieces if we reuse the flow labe= l field within the LLN.=20 FYI, it will break nothing since there is no assumption in the Internet tha= t the flow label will be carried unchanged. Consistently, there is no nativ= e way to secure the flow label to make sure it was not tempered with (IOW i= t is not protected by ULP checksums, IPSec AH or ESP transport mode).=20 The last call at 6MAN is where I expect problems with the use of the flow l= abel field in this draft to be pointed at. I'm happy to report that there w= as no trace of bigotry there, all the contrary. 6MAN will confirm whether t= his draft conforms the spirit of the existing RFCs and so far I gathered, f= rom all but you, that it does. About SDOs: To be very clear, ISA100.11a made a clear condition to acceptan= ce of 6LoWPAN that we compress the UDP checksum - 2 bytes. And we made that= happen. As the standard is now considering what new work may be taken in, RPL will = not be considered if we waste those 5 bytes, simple as that. Sorry that you= missed the ROLL meeting, but Pat Kinney was very clear on that both as vic= e chair of 802.15, and as chair of ISA100.11a where he "fought over every = byte". " Both hats say that this is what we need this". We'll also note that each additional octet in a frame is an increased chanc= e of loss and retry. This is an argument that I hear frequently at IEEE and= the people there as well as at ISA100 are very sensitive to frame size in = general. The distribution of the frame size and the cost of security depend on the a= pplication and the app layer. With high levels of security, if the distribu= tion includes NLPDU around 80-90 octets then the extra bytes will cause fra= gmentation, which will add all sorts of new problems to the picture. The benefits are quite clear, both on actual numbers (thanks Xavi!) and on = the political arena where such a waste of bytes is just not defendable. Please reconsider where you are placing your efforts and what you are tryin= g to achieve... Pascal > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: vendredi 1 ao=FBt 2014 00:11 > To: Brian E Carpenter > Cc: Ines Robles; Brian Haberman; ipv6@ietf.org; Michael Richardson; roll; > Bob Hinden; Ole Troan (otroan); Pascal Thubert (pthubert); Adrian Farrel > Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03 >=20 >=20 > On Jul 29, 2014, at 6:36 PM, Brian E Carpenter > wrote: >=20 > > On 30/07/2014 12:02, Philip Levis wrote: > > ... > >> "This specification suggests that energy-saving is another compelling > >> reason for a violation to the aforementioned rule." > >> > >> makes the assumption that the energy saving is significant. > >> Breaking the end-to-end nature of the flow label for some tiny saving > >> seems like a mistake. > > > > I can't evaluate whether the energy saving is significant. > > However, I don't have any deep faith in the e2e-ness of the flow > > label. The reality (as RFC 6437 tries to recognise) is that it's a > > mutable field, and is therefore untrustworthy for e2e use. It has > > value for load balancing if all packets of a given flow have the same > > label, whether the label is set by the source or by a border device. > > For that reason, I think the usage proposed in this draft is OK. > > > > However, I do agree that at least a hand-waving estimate of the % > > energy saving would be useful. > > > > Brian Carpenter >=20 > *shrug* My thoughts are pretty simple. I'm sure you know all this (as one= of > the authors!) but I'll revisit for everyone else's sake. 6437 states >=20 > "A forwarding node MUST either leave a non-zero flow label value > unchanged or change it only for compelling operational security reasons a= s > described in Section 6.1." >=20 > So, this is a MUST. Either the RPL flow label draft contradicts 6437 (and > should say so explicitly), or there should be an explicit update to 6437.= In > fact, the current draft is misleading and incorrect. It says >=20 > "but the RFC also indicates a violation to the rule can be accepted for > compelling reasons, and that security is a case justifying such a violati= on. > This specification suggests that energy-saving is another compelling r= eason > for a violation to the aforementioned rule." >=20 > This is *not* what 6437 says. It says for compelling operational security > reasons, not compelling reasons, of which one case is security. >=20 > Having been researching, implementing, and deploying low-power protocols > for over a decade, I've become exceedingly skeptical when someone > proposes a protocol with energy as a motivation without quantifying it. F= or > example, there are tons of protocols in the research literature which tal= k > about using transmission power control to save energy (trading off range = for > power). But almost all of these papers ignore the fact that (unlike > mobile/cellular systems, which the authors have been publishing in for > years) RF is a tiny sliver of power in low-power networks. So reducing yo= ur > transmission (RF) power by 99% only reduces your radio power by 50%. > Generally a losing proposition. This is the same reason why power saving = in > WiFi involves synchronization on AP beacons and not adjusting transmit > power. If someone doesn't quantify the potential benefit based on real > hardware and protocols, then it could be based on mistaken assumptions. >=20 > I mean, it doesn't take much here. Start with a working low-power RPL > network. Send packets with sizes following a reasonable distribution base= d > on an actual application. In one experiment send just those packets. In > another add the 8 bytes. In a third add 8 + the IP-in-IP encapsulation. > Measure the energy cost. >=20 > And, generally speaking, if you can't demonstrate the problem very easily= , > then perhaps it isn't a real problem at all. >=20 > All that being said, I think using the flow label in this way is a good i= dea, and > definitely valuable. But as it is now, doing so violates 6437, and so the > assumptions implementers make when reading 6437. I think the bar for > doing so should be high, higher than vague suggestions and hand waving > which might not be correct. >=20 > Phil From nobody Fri Aug 1 05:56:52 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19921A854B; Fri, 1 Aug 2014 05:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 qVTfW_Gq8kUU; Fri, 1 Aug 2014 05:56:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CEB81A0B14; Fri, 1 Aug 2014 05:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3352; q=dns/txt; s=iport; t=1406897802; x=1408107402; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tVR2wH25GCFpDfqHL4WDRHLF1o52CijN/QbyRyKzFY0=; b=RzeHxqv549lxjCMRTokONjKPSTKl0WPxOAWC01AVTQ7ItpecEaSnC3Wt x5pToU1Jnth+sYJUOcGh70rz5NX0VTnONQb5tl9gi1OTDRKH5M4Vx90Q4 cvzkd2nZtJy/BQSrw54Qk6nmoHcxbIAG5sf2tiCef6OMHA3WCGfHfQWK/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAHyN21OtJA2D/2dsb2JhbABbDoJ/UlcEy38Kh0wBgQgWd4QDAQEBAwEBAQFrCwwEAgEIDgMBAwEBAQodBycLFAMGCAIEAQ0FCIgyCA3JeBMEjn4dMQcGgymBHAWGBoRIpgaDB0JsgUU X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208";a="344416242" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP; 01 Aug 2014 12:56:41 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s71CufmE019179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 12:56:41 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 07:55:51 -0500 From: "Pascal Thubert (pthubert)" To: Carsten Bormann , Xavier Vilajosana Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPrXsN1MAnFsPEm0SwuR6qTQA6spu7svGw Date: Fri, 1 Aug 2014 12:56:40 +0000 Deferred-Delivery: Fri, 1 Aug 2014 12:56:00 +0000 Message-ID: References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> In-Reply-To: <47417131-2393-4083-B904-E1983D6AAAA6@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.197.62] 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/6K7SWiHy905t-l8DpjM2osw_8Fw Cc: roll , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 01 Aug 2014 12:56:48 -0000 > > Let's look at what IPHC does at the LBR when a flow label is elided and= has > to be inflated to be forwarded to the IPv6 network, this standardized > behaviour is somehow interfering the end to end notion of the flow label = as > the content is being populated at the border of the LLN. >=20 > No. With IPHC, the flow label has always been there, it just was transmi= tted > in a very compressed form. My take is that you are both providing angles on a same thing. It does not = make sense for a LLN node to waste compute power and bandwidth to get a ran= dom through that is of use only in the core of the internet, should the pac= ket ever get there. So the flow label is effectively zero - or something lo= cally significant in specific standards, which is not design to serve the p= urpose of load balancing in the core. So in either case, we need the root t= o 'inflate' the zero flow label, or replace it by something that fits the c= ore of the Internet. That behavior was not specified so far and it should b= e. This document is covering this particular gap. Cheers, Pascal > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: vendredi 1 ao=FBt 2014 13:24 > To: Xavier Vilajosana > Cc: roll; ipv6@ietf.org > Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03 >=20 > On 01 Aug 2014, at 10:50, Xavier Vilajosana > wrote: >=20 > > > > Let's look at what IPHC does at the LBR when a flow label is elided and= has > to be inflated to be forwarded to the IPv6 network, this standardized > behaviour is somehow interfering the end to end notion of the flow label = as > the content is being populated at the border of the LLN. >=20 > No. With IPHC, the flow label has always been there, it just was transmi= tted > in a very compressed form. >=20 > I think the visceral reaction that most of us have in using the flow labe= l as a > mesh routing header is that this blurs the layer boundaries. So much for= O, > R, F, and rank. Putting the VLAN ("instance ID") into the packet is a > significantly larger change, because it essentially extends the IP servic= e > interface by a VLAN ID. We normally try to hide IDs of this kind below I= P. >=20 > Now, I'm not saying any of this new architecture is wrong. I just think = what > we need to do is discuss this as the architectural change that it is, not= as a > simple optimization. (The need for some kind of optimization of IP-in-IP > mesh routing for small-packet IoT applications is pretty obvious to me.) >=20 > The other story is that we are retracting RFC 6437 and turning the flow l= abel > into the "field you may trample on in your lower layers if you have a goo= d > reason". Cynically, one could say this is proper payback for designing t= his > field without a compelling purpose and no protocol evolution story attach= ed > to it. So the evolution just eats it. Teachable moment. >=20 > Gr=FC=DFe, Carsten >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Aug 1 06:25: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 C9E4F1A0B13; Fri, 1 Aug 2014 06:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 QlWDk0sQR-t1; Fri, 1 Aug 2014 06:25:08 -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 237361A0B06; Fri, 1 Aug 2014 06:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1573; q=dns/txt; s=iport; t=1406899508; x=1408109108; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QhAjaCNubhiAAMcAlhI5fiNV4z2CCx9hEgOCeJUHzfs=; b=VEn9Ebw5lNX2IXqLQNR7yKrIVEPqG/dRyhpsTbYsRsgTkt2WZfSc6QEe E86LmeO48C/K3Z9OBZ6iL89ISeCoXdvKA7lMGkBQPohCuYiL08PZkffWA C+dVmay4WxEgUUNdC5Xl6gSJGrBJERa6hK/u1JIeuGnBR0RiBSSkpl18G w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAA+U21OtJV2b/2dsb2JhbABbgw2BLdNVAYEIFneEBAEBAwE6PwULAgEIDgQQFBAyFw4CBA4NiDIIyXwXjxsxB4MvgRwBBLBUg0mCMQ X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208";a="341312469" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 01 Aug 2014 13:25:07 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s71DP7a6016088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 13:25:07 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 08:25:06 -0500 From: "Pascal Thubert (pthubert)" To: Carsten Bormann Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPrXsN1MAnFsPEm0SwuR6qTQA6spu7tLlA Date: Fri, 1 Aug 2014 13:25:06 +0000 Deferred-Delivery: Fri, 1 Aug 2014 13:25:00 +0000 Message-ID: References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> In-Reply-To: <47417131-2393-4083-B904-E1983D6AAAA6@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.197.62] 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/SBjEcEFGoWdkFIm0XSMdESGFJJ8 Cc: roll , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 01 Aug 2014 13:25:10 -0000 > I think the visceral reaction that most of us have in using the flow labe= l as a > mesh routing header is that this blurs the layer boundaries. So much for= O, > R, F, and rank. Putting the VLAN ("instance ID") into the packet is a > significantly larger change, because it essentially extends the IP servic= e > interface by a VLAN ID. We normally try to hide IDs of this kind below I= P. >=20 > Now, I'm not saying any of this new architecture is wrong. I just think = what > we need to do is discuss this as the architectural change that it is, not= as a > simple optimization. (The need for some kind of optimization of IP-in-IP > mesh routing for small-packet IoT applications is pretty obvious to me.) >=20 >=20 I agree, Carsten. An angle is that we allow for localized usage of the flow label as opposed = to end-to-end. Another is that we allow for different semantics within a local domain, as = long as the packet that leaves the local domain fits the requirements in RF= C 6437. As you point out, it is worth noting that we include information about flow= isolation and rules by which a flow will be routed, which is akin to Multi= -Topology Routing though MTR is based on TOS bits. It would be good to design an architecture that encompasses such capabiliti= es. We'll note that ISA100.11a is shipping with a flow label that contains an i= ndex to a state (so-called a contract) that is installed on the nodes on th= e way and by and large extends the notion of PHB on a per flow basis. Cheers, Pascal From nobody Fri Aug 1 11:46: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 8782A1A00E2; Fri, 1 Aug 2014 09:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppxLHhoWdeuz; Fri, 1 Aug 2014 09:50:28 -0700 (PDT) Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU [171.64.64.26]) (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 C7C881A00B5; Fri, 1 Aug 2014 09:50:28 -0700 (PDT) Received: from gates-ap-275.stanford.edu ([171.64.70.25]:53072 helo=[10.171.216.192]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XDG2E-000594-7j; Fri, 01 Aug 2014 09:50:26 -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: Date: Fri, 1 Aug 2014 09:21:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 5c460fe7d3aaafaf78d72307c0bc7e10 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Zh6pHpwFRQNdYs03h9cKO_V4wjk X-Mailman-Approved-At: Fri, 01 Aug 2014 11:46:10 -0700 Cc: Brian Haberman , "ipv6@ietf.org" , Michael Richardson , roll , Ines Robles , Bob Hinden , "Ole Troan \(otroan\)" , Pat Kinney , Brian E Carpenter Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 01 Aug 2014 16:50:36 -0000 On Aug 1, 2014, at 5:44 AM, Pascal Thubert (pthubert) = wrote: >=20 > FYI, it will break nothing since there is no assumption in the = Internet that the flow label will be carried unchanged. Consistently, = there is no native way to secure the flow label to make sure it was not = tempered with (IOW it is not protected by ULP checksums, IPSec AH or ESP = transport mode).=20 >=20 > The last call at 6MAN is where I expect problems with the use of the = flow label field in this draft to be pointed at. I'm happy to report = that there was no trace of bigotry there, all the contrary. 6MAN will = confirm whether this draft conforms the spirit of the existing RFCs and = so far I gathered, from all but you, that it does Pascal, I don't think this is a question of spirit or anything. I mean, = I'll repeat, 6437 states "A forwarding node MUST either leave a non-zero flow label value = unchanged or change it only for compelling operational security reasons = as described in Section 6.1." If the point is that experience and use and the spirit of the flow label = has changed from this MUST, then we should explicitly state so. I'm not = arguing that the above prescription is right; but it's what's written. = What worries me is the idea of directly contradicting the text of a = prior RFC (the one explicitly on flow labels, no less), without = correspondingly obsoleting that RFC. This isn't a SHOULD. It's a MUST! I've always thought that using the flow label in this way within an LLN = is a good idea. The problem is that you can't do so without violating a = MUST in the RFC that specifies how flow labels are used. It sounds like = the letter of that document doesn't match the spirit of it -- so let's = fix the letter, so it says what was intended! Why is there such = recalcitrance to do so? Or provide any quantitative basis for the claims = of battery power? You've been proposing this for nearly 4 years now... I personally see two reasonable ways forward: 1) (As Carsten mentioned) Update 6437 to embrace these new and valuable = uses of the flow label. 2) Provide evidence that using the flow label in this way would provide = significant enough gains that violating a MUST in the RFC specifying the = flow label is worth it. It seems like you're advocating a third: 3) Violate a MUST in the RFC specifying how the flow label is used = without any evidence that the actual energy savings are significant. As for what I'm trying to achieve, that's pretty simple. I think it's a = terrible mistake for a standards body as important as the IETF to rely = on the spirit of the standard rather than the letter of the standard, = especially when they contradict. If you are one of the hundreds of = thousands of network engineers and software developers who work in the = Internet, you can't know that a bunch of people in a meeting decided = that the spirit of a specification differs from its text. All you have = to go on is the text. When the founder of the next YouTube or Instagram = or Google or Nicira takes my class and I ask them to write their code to = follow an RFC (which I currently do), what should I tell them MUST = means? Phil= From nobody Fri Aug 1 12:58: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 31E911B28B3; Fri, 1 Aug 2014 12:58:41 -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 dzWyXlpn-ouQ; Fri, 1 Aug 2014 12:58:39 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E901A0467; Fri, 1 Aug 2014 12:58:39 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id lj1so6345450pab.33 for ; Fri, 01 Aug 2014 12:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=65VqK3L8Io+gxTbGcPhMlmRHYmei9ukzebgwZ3yvwoI=; b=jquQukMkQbEMWA1wYLcREps6MPMwYgN8hMeyFkFYiK4jRKOoj6DCIPPomEo/6iva6J oQHip2j2ZjBIJ6l55QcRraJr8c5PDRFf4XIMscdXZO8nP5uKb2fOovNim3PTlwbN6bTA BijuqBgD15sbzePy8LYqAHKfSZJl5NFz9eT2rvNzHVxhbNi6zLfI3unbvyiUi9fEXVKN dmXMY3GzLJ7tUpBgNg2OQitfT1CK24nY52WLCanN1MCoXwqkEjcMFCEbMrIH0bUtz08Q hh4XkWoMCt49W/XFSwOQDIEmXcIFNuRBZREhWhaoxSPTSzTHYhR4n7ngsgzUe3nTEVff xrag== X-Received: by 10.68.245.9 with SMTP id xk9mr8745410pbc.123.1406923118839; Fri, 01 Aug 2014 12:58:38 -0700 (PDT) Received: from [192.168.178.23] (48.195.69.111.dynamic.snap.net.nz. [111.69.195.48]) by mx.google.com with ESMTPSA id xq3sm33503484pab.0.2014.08.01.12.58.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 12:58:38 -0700 (PDT) Message-ID: <53DBF16F.2090202@gmail.com> Date: Sat, 02 Aug 2014 07:58:39 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Carsten Bormann References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> In-Reply-To: <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/roll/pOlbL1SlIuFLC89C2kjmcvbcnkQ Cc: roll , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 01 Aug 2014 19:58:41 -0000 On 01/08/2014 23:23, Carsten Bormann wrote: =2E.. > The other story is that we are retracting RFC 6437 and turning the flow= label into the =E2=80=9Cfield you may trample on in your lower layers if= you have a good reason=E2=80=9D. Cynically, one could say this is prope= r payback for designing this field without a compelling purpose and no pr= otocol evolution story attached to it. So the evolution just eats it. T= eachable moment. RFC 6437 co-author hat on (but only speaking for myself, of course): My opinion is that the draft doesn't retract RFC 6437. As I already said,= 6437 attempts to recognise the reality that middleboxes can mess with the= flow label, and to set conditions for that messing such that remote syste= ms can still use it for load balancing. Since it's unprotected by checksum o= r crypto, there is a strict limit to how much it can be trusted anyway. As the RFC says: There is no way to verify whether a flow label has been modified en route or whether it belongs to a uniform distribution. Therefore, no Internet-wide mechanism can depend mathematically on unmodified and uniformly distributed flow labels; they have a "best effort" quality. Implementers should be aware that the flow label is an unprotected field that could have been accidentally or intentionally changed en route (see Section 6). It is true that the RFC also says A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons... There is a case for arguing that flow-label-for-rpl should carry the legend "Updates: 6437 (if approved)" because it adds another exception to this sentence. There is also a case for arguing that flow-label-for-rp= l is a stateful mechanism, out of scope for RFC 6437 according to Section 4 of that RFC. Either way, I don't see a problem. Regards Brian From nobody Fri Aug 1 13:30:24 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3BB1B28B3; Fri, 1 Aug 2014 13:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.502 X-Spam-Level: X-Spam-Status: No, score=-16.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 b7JjwIfE-vrn; Fri, 1 Aug 2014 13:27:42 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2290B1A0137; Fri, 1 Aug 2014 13:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3995; q=dns/txt; s=iport; t=1406924862; x=1408134462; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lk8u0FO2bB5hKVS6eu4FnolzVYn48Q5NItL1v2QSvcI=; b=XEhdVBsZ60U0bJR+R/MT8F8Fxai4Zg6301vORpnqr7oCjIhmTxYq58Vh u3DhW0dfxAhzZ57OblN6Yj3JEgJz6c6b4bRx06HbExs0DpSyITGoGeaaV 5usBtbLsjwjsrhiTEw8LfrXA9ija1JckK4zG2SoBL8b9DYKw66VE3IQXv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFALT321OtJV2U/2dsb2JhbABPDA6Cf4Ep02EBgQsWd4QDAQEBAwEdSgUNBQsCAQgOCi4yJQIEDgWIOgjIZxeOZAEBGBszB4MvgRwFhH0ChU+RLJRagwdCbA X-IronPort-AV: E=Sophos;i="5.01,782,1400025600"; d="scan'208";a="344523903" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP; 01 Aug 2014 20:27:41 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s71KRfgG028932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 20:27:41 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 15:27:41 -0500 From: "Pascal Thubert (pthubert)" To: Philip Levis Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPrai33Dn9icet106HlaTIaH7gh5u8MoZe Date: Fri, 1 Aug 2014 20:27:40 +0000 Message-ID: References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> , <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu> In-Reply-To: <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HHFwTlLbkrFSVPLbr1dh9PSqxTU X-Mailman-Approved-At: Fri, 01 Aug 2014 13:30:23 -0700 Cc: Brian Haberman , "ipv6@ietf.org" , Michael Richardson , roll , Ines Robles , Bob Hinden , "Ole Troan \(otroan\)" , Pat Kinney , Brian E Carpenter Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 01 Aug 2014 20:27:44 -0000 Phil, Though I attended the discussions and have a clear reading of this work I'l= l certainly defer to Brian on whether there is a violation or not.=20 OTOH you need to understand that there is no need for a bis to update a MUS= T in an RFC. We recognize the imperfection in our work and are always ready= to revise and amend after due consideration. This process takes is another RFC and best judgement from the original grou= p that the new text is indeed valuable and not breaking the original object= ives. We are going through that process. Pascal > Le 1 ao=FBt 2014 =E0 18:50, "Philip Levis" a =E9cri= t : >=20 >> On Aug 1, 2014, at 5:44 AM, Pascal Thubert (pthubert) wrote: >>=20 >>=20 >> FYI, it will break nothing since there is no assumption in the Internet = that the flow label will be carried unchanged. Consistently, there is no na= tive way to secure the flow label to make sure it was not tempered with (IO= W it is not protected by ULP checksums, IPSec AH or ESP transport mode).=20 >>=20 >> The last call at 6MAN is where I expect problems with the use of the flo= w label field in this draft to be pointed at. I'm happy to report that ther= e was no trace of bigotry there, all the contrary. 6MAN will confirm whethe= r this draft conforms the spirit of the existing RFCs and so far I gathered= , from all but you, that it does >=20 > Pascal, I don't think this is a question of spirit or anything. I mean, I= 'll repeat, 6437 states >=20 > "A forwarding node MUST either leave a non-zero flow label value unchange= d or change it only for compelling operational security reasons as describe= d in Section 6.1." >=20 > If the point is that experience and use and the spirit of the flow label = has changed from this MUST, then we should explicitly state so. I'm not arg= uing that the above prescription is right; but it's what's written. What wo= rries me is the idea of directly contradicting the text of a prior RFC (the= one explicitly on flow labels, no less), without correspondingly obsoletin= g that RFC. This isn't a SHOULD. It's a MUST! >=20 > I've always thought that using the flow label in this way within an LLN i= s a good idea. The problem is that you can't do so without violating a MUST= in the RFC that specifies how flow labels are used. It sounds like the let= ter of that document doesn't match the spirit of it -- so let's fix the let= ter, so it says what was intended! Why is there such recalcitrance to do so= ? Or provide any quantitative basis for the claims of battery power? You've= been proposing this for nearly 4 years now... >=20 > I personally see two reasonable ways forward: >=20 > 1) (As Carsten mentioned) Update 6437 to embrace these new and valuable u= ses of the flow label. >=20 > 2) Provide evidence that using the flow label in this way would provide s= ignificant enough gains that violating a MUST in the RFC specifying the flo= w label is worth it. >=20 > It seems like you're advocating a third: >=20 > 3) Violate a MUST in the RFC specifying how the flow label is used withou= t any evidence that the actual energy savings are significant. >=20 > As for what I'm trying to achieve, that's pretty simple. I think it's a t= errible mistake for a standards body as important as the IETF to rely on th= e spirit of the standard rather than the letter of the standard, especially= when they contradict. If you are one of the hundreds of thousands of netwo= rk engineers and software developers who work in the Internet, you can't kn= ow that a bunch of people in a meeting decided that the spirit of a specifi= cation differs from its text. All you have to go on is the text. When the f= ounder of the next YouTube or Instagram or Google or Nicira takes my class = and I ask them to write their code to follow an RFC (which I currently do),= what should I tell them MUST means? >=20 > Phil From nobody Fri Aug 1 13:37: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 8E5D71A005C; Fri, 1 Aug 2014 13:37:05 -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 Ft--fYggFmJS; Fri, 1 Aug 2014 13:37:01 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B5E1A0028; Fri, 1 Aug 2014 13:37:01 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id im17so7604481vcb.17 for ; Fri, 01 Aug 2014 13:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=mS5cBKwyPzvnfM1m53sFXtiYDNrGFiYmkNowMUXXvnc=; b=VxzlSkMc9F/i17Lahjx5/UfY2BrGha9fESl2tvlIwCUGdT2src2Gzs9TBpzPrw8usp Ty4j8nC7H/cVW1mpd8Ljl104r9FaKnjBpCUlEybwZDw9LIccOZtSxI9eCSyQG+uEj5jm QzcLuGUBjdYlbS5xGNmB3eM4WdPddL81QrzpQrm9I6ES1SRgUulOCjKLDSJ81P5GCmLV 2Sj4g8bfBFn08hMMNlUULA+NqZdLbsawX8QoPiwKung3CQHxISicLTghFT893h7iW75/ yHlEG+K41LcF8i5GZ6g98DjiMZgH1izxr0dkKWolG1AhDEunAskPqmxhqkQrC+QwLb7g YboA== MIME-Version: 1.0 X-Received: by 10.52.246.198 with SMTP id xy6mr8111493vdc.7.1406925420517; Fri, 01 Aug 2014 13:37:00 -0700 (PDT) Received: by 10.220.58.69 with HTTP; Fri, 1 Aug 2014 13:37:00 -0700 (PDT) Date: Fri, 1 Aug 2014 23:37:00 +0300 Message-ID: From: Ines Robles To: ietf Content-Type: multipart/alternative; boundary=001a1133b890ea5f4f04ff975981 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/zjBVFVQ-6yUhkCveLLZczx1Z4uc Cc: "6tisch@ietf.org" <6tisch@ietf.org>, roll , 6lo@ietf.org Subject: [Roll] Pictures, Slides and Results for LLN PlugFest IETF 90 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, 01 Aug 2014 20:37:05 -0000 --001a1133b890ea5f4f04ff975981 Content-Type: text/plain; charset=UTF-8 Dear all, Thank you very much for your participation at the PlugFest. You can find more information (Pictures, Slides and Results) of this event in the wiki: https://bitbucket.org/6tisch/meetings/wiki/140720a_ietf90_toronto_plugfest We hope to see you again in future Plugfests :-). Best Regards, Xavier and Ines. --001a1133b890ea5f4f04ff975981 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Than= k you very much for your participation at the PlugFest.

You can find more information (Pictures, Slides and Res= ults) of this event in the wiki:=C2=A0https:/= /bitbucket.org/6tisch/meetings/wiki/140720a_ietf90_toronto_plugfest

We hope to see you again in future Plugfests :-).

Best Regards,

Xavier and I= nes.
--001a1133b890ea5f4f04ff975981-- From nobody Fri Aug 1 23:02:29 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 179C91B2901; Fri, 1 Aug 2014 23:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kyjw9tq6FDD0; Fri, 1 Aug 2014 23:02:22 -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 979831B28FC; Fri, 1 Aug 2014 23:02:19 -0700 (PDT) Received: from [76.14.66.110] (port=58043 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XDSOY-0003Nm-NU; Fri, 01 Aug 2014 23:02:19 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: Date: Fri, 1 Aug 2014 23:02:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2A7F73B7-FCDC-44C6-99A5-FBA0EBFBC27D@cs.stanford.edu> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> , <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/lW37ZjpQRLKnxFUkzFxrwXIisL0 Cc: roll Lossy networks , ipv6@ietf.org Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 06:02:26 -0000 On Aug 1, 2014, at 1:27 PM, Pascal Thubert (pthubert) = wrote: > Phil, >=20 > Though I attended the discussions and have a clear reading of this = work I'll certainly defer to Brian on whether there is a violation or = not.=20 >=20 > OTOH you need to understand that there is no need for a bis to update = a MUST in an RFC. We recognize the imperfection in our work and are = always ready to revise and amend after due consideration. >=20 > This process takes is another RFC and best judgement from the original = group that the new text is indeed valuable and not breaking the original = objectives. >=20 > We are going through that process. If the proposal is to have an Updates: 6437 (such that someone looking = up 6437 will see a forward reference and know there's an update), I'm = all in favor! That seems entirely reasonable. In that way, as I've = always said, I think using the flow label is an excellent solution. I = just also think doing so is significant in the context of 6437 and so = should correctly acknowledge so. Someone reading 6437 should be able to = easily learn there's another exception. It seems like an Updates: would = do that well.=20 That being said, I don't think the energy claims in the current document = will hold up to much experimental scrutiny or actual network = measurements. Xavier's back-of-the-envelope calculations don't include = preambles, slot padding, or idle listening. TSCH is nice in that it has = much lower idle listening costs than ad-hoc algorithms, but they are far = from zero. Reducing overhead is valuable due to the corresponding = increase in MSS and reduced memory pressure: the energy argument is a = red herring. Phil From nobody Sat Aug 2 08:05:07 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB65B1A0B05; Sat, 2 Aug 2014 08:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 HeVIssTB7smL; Sat, 2 Aug 2014 08:05:00 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB6C1A0AF6; Sat, 2 Aug 2014 08:04:59 -0700 (PDT) Received: from ([24.40.56.121]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.108902679; Sat, 02 Aug 2014 11:04:55 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.153]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.03.0181.006; Sat, 2 Aug 2014 11:04:55 -0400 From: "Roscoe, Alexander" To: Routing Over Low power and Lossy networks , ietf Thread-Topic: [Roll] Pictures, Slides and Results for LLN PlugFest IETF 90 Thread-Index: AQHPrciFEbsaH0akR0SqvDxHKcsYO5u9aqoA Date: Sat, 2 Aug 2014 15:06:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.249] Content-Type: multipart/alternative; boundary="_000_D002758C11C0EAlexanderRoscoecablecomcastcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/GmKLHMlA24z0L-fxIbWn1-etsBs Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] Pictures, Slides and Results for LLN PlugFest IETF 90 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 15:05:04 -0000 --_000_D002758C11C0EAlexanderRoscoecablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Very cool plugfest. Thanks for the write up as I was really interested in t= he 6TiSH wireshark tool but I couldn=92t remember details. -- Alexander Roscoe Comcast - Wireless Engineer Phone =96 215.286.7283 Cell =96 215.609.2691 From: Ines Robles > Reply-To: Routing Over Low power and Lossy networks > Date: Friday, August 1, 2014 at 4:37 PM To: ietf > Cc: "6tisch@ietf.org" <6tisch@ietf.org>, roll >, "6lo@ietf.org" <6lo@ietf.org> Subject: [Roll] Pictures, Slides and Results for LLN PlugFest IETF 90 Dear all, Thank you very much for your participation at the PlugFest. You can find more information (Pictures, Slides and Results) of this event = in the wiki: https://bitbucket.org/6tisch/meetings/wiki/140720a_ietf90_toro= nto_plugfest We hope to see you again in future Plugfests :-). Best Regards, Xavier and Ines. --_000_D002758C11C0EAlexanderRoscoecablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Very cool plugfest. Thanks for the write up as I was really interested= in the 6TiSH wireshark tool but I couldn=92t remember details.
-- 
Alexander Roscoe
Comcast - Wireless Engineer
Phone =96 215.286.7283
Cell =96 215.609.2691

From: Ines Robles <mariainesrobles@googlemail.com>=
Reply-To: Routing Over Low power an= d Lossy networks <roll@ietf.org>=
Date: Friday, August 1, 2014 at 4:3= 7 PM
To: ietf <ietf@ietf.org>
Cc: "6tisch@ietf.org" <= 6tisch@ietf.org>, roll <roll@iet= f.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: [Roll] Pictures, Slides an= d Results for LLN PlugFest IETF 90

Dear all,

Thank you very m= uch for your participation at the PlugFest.

You can find more information (Pictures, Slides and Results) of this e= vent in the wiki: https://bitbucket.org/= 6tisch/meetings/wiki/140720a_ietf90_toronto_plugfest

We hope to see you again in future Plugfests :-).

Best Regards,

Xavier and Ines.
 --_000_D002758C11C0EAlexanderRoscoecablecomcastcom_-- From nobody Sat Aug 2 12:09:13 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 9D97F1B28B2; Sat, 2 Aug 2014 12:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 2HS6w4SB__gq; Sat, 2 Aug 2014 12:09:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA751B28CE; Sat, 2 Aug 2014 12:08:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A6B3D20012; Sat, 2 Aug 2014 15:11:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5FCEA638D9; Sat, 2 Aug 2014 15:08:55 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 46F1D638D7; Sat, 2 Aug 2014 15:08:55 -0400 (EDT) From: Michael Richardson To: "ipv6\@ietf.org" , roll In-Reply-To: References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> , <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu> 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/oj3Cs2fsbFZvwmXNp1luHJzPCfo Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 19:09:09 -0000 --=-=-= Pascal Thubert (pthubert) wrote: > OTOH you need to understand that there is no need for a bis to update a > MUST in an RFC. We recognize the imperfection in our work and are > always ready to revise and amend after due consideration. Perhaps this document UPDATES 6437 then? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU903QoCLcPvd0N1lAQJAzwgAuxOtt18r18lpLJhN5hF6VUbQ3nlCWu7I hssUIKYU/RCBzAAoAwd2/jIZXydsgknyRMmvucJKJC8XN6hRBgTfRXOg+70qF8y0 3H8/c0QMLSSmGEoh1C/bAw3uaTemX4POOdras3jXyTJpsNgCROAlA7VOiu9KRdNQ /UgY38nKKze/YDgadtFzD5Ch4a20OfNY0HnlM14Keaz26AywClxOXW77xJGnvtb3 rY+B06c0TILvmzvf3tHezy6tSCN7pp6nmfaIiU/uINTXjvFqTnD83F1ImHyf0Mq7 1sWxg2M8cTRfRlRJYsdEXmr6VfMzmmAN+jbuTS1CUsDM8fm8rgfYXw== =ojCE -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 2 12:23:19 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1861B295C; Sat, 2 Aug 2014 12:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 tMgDFGlzeZyy; Sat, 2 Aug 2014 12:23:15 -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 D44A31B295A; Sat, 2 Aug 2014 12:23:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D86A520012; Sat, 2 Aug 2014 15:25:29 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6B5CD638D9; Sat, 2 Aug 2014 15:23:13 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 521E7638D7; Sat, 2 Aug 2014 15:23:13 -0400 (EDT) From: Michael Richardson To: "ipv6\@ietf.org" , roll@ietf.org In-Reply-To: References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <53DB675C.9000502@tm.uka.de> <53DB88B7.80205@tm.uka.de> 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/CJu2uJ3rASgRutNawSQoljtOcfg Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 19:23:16 -0000 --=-=-= Philip Levis wrote: > The paper is very helpful, thanks! Can you comment on what is a typical > idle slot configuration in a TiSCH network? Can you provide some > insight on what fraction of energy is spent in data communication > versus control and idle listening? Here is a recent post with some real numbers: https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY it concerns diet-ESP, but the numbers are correct. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU906nYCLcPvd0N1lAQIfjgf/e5tNGcSKP2vG6y3yCVtQ/3N6VRfQ92/j 6la/iEomMdjJH7ncdMcvx3b++YrfaIQCb3Wh7JURecOghW9zy4nzvzltfDAb59CQ nFFM+wcM7YqtpmbVHbjrgDmBlJQVvcqUHuZcXy+xbwWKYcr5yaepS+smQBFKtjzE sliyGkFjH51iFkduGli+/jr9Hmh4DGSXwVd9MwpKQbYOq3QGQJ42p9/je75tRZyT N5I+6QHpi/tIWgx+6MmFQ7bYYzUPxKCyLRS0K6cxfxu1CQoNdMysUysEqR9Dt6WB b4YEO0Fnf3r/5u2J/Z9ZuCD61uE1JA/GgWiWaa30/RwaEzxNqqt2gw== =F9ZH -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 2 13:48:58 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D231B2997; Sat, 2 Aug 2014 13:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 tE6lGiINojd1; Sat, 2 Aug 2014 13:48:52 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5921B2996; Sat, 2 Aug 2014 13:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1019; q=dns/txt; s=iport; t=1407012532; x=1408222132; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TQKh1eu/EmtaeFSuCylW2b+tPv5W3oh+yBYq/wS723w=; b=lcxbc6/3j369RbCCHXYoIh7lJnumi//u9r2vTFng0Geebif6eCVurQ/y g7sqHCcHoEculFxQbHXPcXsrmHwhtJTJbmejZ72pa0e5+Q/lziKvNS9Ni 4dcKJEWrMKdpE4QYmDpWcueXf9PYwGUBofhKpjzT82U/CwAXGQG5jVEm8 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAKVN3VOtJA2F/2dsb2JhbABagmojUlfMDwqHTAGBBRZ3hAMBAQEDAQEBAWsLBQsCAQgYLicLJQIEDgWIOggBDMZWEwSPGTMHgy+BHAWKVZExlF+DTWw X-IronPort-AV: E=Sophos;i="5.01,787,1400025600"; d="scan'208";a="66067890" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 02 Aug 2014 20:48:50 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s72KmoM2029355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Aug 2014 20:48:50 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Sat, 2 Aug 2014 15:48:49 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPrai33Dn9icet106HlaTIaH7gh5u8MoZegAHQY4D//8gYNw== Date: Sat, 2 Aug 2014 20:48:49 +0000 Message-ID: References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> , <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu> , <3211.1407006535@sandelman.ca> In-Reply-To: <3211.1407006535@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/gAoVk6V8ZfA4Fo83CKEiPJ36hBY Cc: roll , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 20:48:57 -0000 That sounds right, Michael, though slightly on the overkill side. And this= is consistent with what Brian suggested. This can be added during the rfc = editor process I expect? Pascal > Le 2 ao=FBt 2014 =E0 21:09, "Michael Richardson" = a =E9crit : >=20 >=20 > Pascal Thubert (pthubert) wrote: >> OTOH you need to understand that there is no need for a bis to update a >> MUST in an RFC. We recognize the imperfection in our work and are >> always ready to revise and amend after due consideration. >=20 > Perhaps this document UPDATES 6437 then? >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Aug 2 13:56: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 7F5201B29A7; Sat, 2 Aug 2014 13:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 9GNeIqg_xcUc; Sat, 2 Aug 2014 13:56:40 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A421B29A2; Sat, 2 Aug 2014 13:56:40 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id v10so5352479qac.5 for ; Sat, 02 Aug 2014 13:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6dmX27P7oPeXR3Xuakm7AqBZBpkaDo0yg55z08VUPOc=; b=xOvohFOZQb+4iB7MOnoItGsHZuc/WrBlYtqGi0PFF/ZVGUPw72RjtOr4XvN2gU3seJ glJVBw00+RMiMt3Drrj6BcIgpreMdU38En8zMKkTfXbjZ4Wia5A5UJaFQKK6ngzRDLcC BVgHhOV8dLVCEfYa6KaA75r5ma994SQf0Aponkr8V8/mT5kTI8xPa/bCx2nCko+ymazc LB5DwIsOswB/OGavHT18aSRmSu1mLxXsnh0SR2tDQXbey+wvOxdduGsjdTAaioo/LvMI 1apsqC7Zbk9By8m4VikBGZW1AnnSlFY/EmEUEZL/eXFt+hvwTIgYu+ikYFxFB3vEL7oC jaZA== X-Received: by 10.140.94.70 with SMTP id f64mr21051974qge.64.1407012998981; Sat, 02 Aug 2014 13:56:38 -0700 (PDT) Received: from ?IPv6:2601:6:6780:636:f96f:9ecd:5aaa:13b2? ([2601:6:6780:636:f96f:9ecd:5aaa:13b2]) by mx.google.com with ESMTPSA id o89sm13796116qgo.1.2014.08.02.13.56.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Aug 2014 13:56:37 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B614815F-7F8B-43E7-995E-AC221C0662B2 Mime-Version: 1.0 (1.0) From: Ralph Droms X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Sat, 2 Aug 2014 16:56:36 -0400 Content-Transfer-Encoding: 7bit Message-Id: <2F2D5FEA-51E0-4F04-8A54-2493ECB73757@gmail.com> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu> <3211.1407006535@sandelman.ca> To: Routing Over Low power and Lossy networks Archived-At: http://mailarchive.ietf.org/arch/msg/roll/szD8JaChI_kRow-TXcInZmRTV2s Cc: Michael Richardson , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 20:56:42 -0000 --Apple-Mail-B614815F-7F8B-43E7-995E-AC221C0662B2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)" wrote: >=20 > That sounds right, Michael, I agree that "updates 6437" is a right thing to do. > though slightly on the overkill side. I disagree that it is overkill. In my opinion, draft-thubert-6man-flow-labe= l-for-RPL pretty clearly contradicts RFC 6437, so "updates 6437" is an appro= priate action. > And this is consistent with what Brian suggested. This can be added durin= g the rfc editor process I expect? It should be added as soon as possible, certainly before it goes to the IESG= . In my opinion, the change might warrant a new or extended WGLC; that acti= on is up to the chairs, of course. - Ralph >=20 > Pascal >=20 >> Le 2 ao=C3=BBt 2014 =C3=A0 21:09, "Michael Richardson" a =C3=A9crit : >>=20 >>=20 >> Pascal Thubert (pthubert) wrote: >>> OTOH you need to understand that there is no need for a bis to update a >>> MUST in an RFC. We recognize the imperfection in our work and are >>> always ready to revise and amend after due consideration. >>=20 >> Perhaps this document UPDATES 6437 then? >>=20 >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >>=20 >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-B614815F-7F8B-43E7-995E-AC221C0662B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Aug 2, 2014, at 4= :48 PM, "Pascal Thubert (pthubert)" <pthubert@cisco.com> wrote:

<= div>That sounds right, Michael,

I agree that "updates 6437" is a right thing to do.

though slightly on the overkill side.
<= /blockquote>

I disagree that it is overkill.  In my opini= on, draft-thub= ert-6man-flow-label-for-RPL pretty clearly contradicts RFC 6437, so "updates 6437" is an appropriate action.

 And this is consistent with what Brian suggested. Th= is can be added during the rfc editor process I expect?

It should be added as soon as possible, certainly be= fore it goes to the IESG.  In my opinion, the change might warrant a ne= w or extended WGLC; that action is up to the chairs, of course.
- Ralph


Pascal

Le 2 ao=C3=BBt 2014 =C3=A0 21:09, "Michael Richardson" <mcr+ietf@sandelman.ca> a =C3=A9crit :

<= blockquote type=3D"cite">
Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
OTOH you need to understand that t= here is no need for a bis to update a
MUST in an RFC. We r= ecognize the imperfection in our work and are
always ready= to revise and amend after due consideration.

Perhaps this document UPDATES 6437 then?

--
= Michael Richardson <mcr+IETF@san= delman.ca>, Sandelman Software Works
-=3D IPv6 IoT consulting =3D-
=


<= br>
----------------------------= ----------------------------------------
IETF IPv6 working group mailing list
ipv6@iet= f.org
Administrat= ive Requests: https:/= /www.ietf.org/mailman/listinfo/ipv6
---------------------------------------------------------= -----------

__________________= _____________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailm= an/listinfo/roll
= --Apple-Mail-B614815F-7F8B-43E7-995E-AC221C0662B2-- From nobody Sat Aug 2 14:41: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 6BF6C1B29CB; Sat, 2 Aug 2014 14:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 99jRnVlc69u2; Sat, 2 Aug 2014 14:41:14 -0700 (PDT) Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU [171.64.64.26]) (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 15F0A1B29DB; Sat, 2 Aug 2014 14:41:14 -0700 (PDT) Received: from [76.14.66.110] (port=61141 helo=[192.168.0.103]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XDh3A-0007pH-7T; Sat, 02 Aug 2014 14:41:14 -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: <6439.1407007393@sandelman.ca> Date: Sat, 2 Aug 2014 14:41:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <53DB675C.9000502@tm.uka.de> <53DB88B7.80205@tm.uka.de> <6439.1407007393@sandelman.ca> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 127ff6e1eac6b45a32dc112250ed777d Archived-At: http://mailarchive.ietf.org/arch/msg/roll/rPYaT5s72xqNpKE9QJoK2RupJJc Cc: "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 21:41:15 -0000 On Aug 2, 2014, at 12:23 PM, Michael Richardson = wrote: >=20 > Philip Levis wrote: >> The paper is very helpful, thanks! Can you comment on what is a = typical >> idle slot configuration in a TiSCH network? Can you provide some >> insight on what fraction of energy is spent in data communication >> versus control and idle listening? >=20 > Here is a recent post with some real numbers: > = https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY > it concerns diet-ESP, but the numbers are correct. Michael, I'm confused on what this email message is supposed to be providing: the = energy cost of sending a bit? That's pretty simple to calculate. The = tradeoff between CPU and network is also very well known, going back to = Pottie's "Every bit transmitted brings a sensor node one moment closer = to death." If you look at the behavior of most micro controller based = devices, the MCU is insignificant -- and 95% of its energy is spent = handling interrupts (per-byte, over an SPI bus) for the radio. Yes, = unless you're doing something quite silly, the CPU cost of compression = is almost always absolutely worth the benefit in terms of reduced = transmission energy. My question related to the fraction of radio energy in TSCH that is = consumed by data transmission/reception versus everything else (idle = listening, guard periods, control frames, etc. To give you a data point -- early low-power link layers continually = transmitted a packet (or wakeup frame) until receiving an = acknowledgement from the intended receiver. Receivers periodically wake = up, listen if there's energy on the channel, and if so, stay awake for 2 = packet times (in case they woke up just after the preamble of a packet). = If there's no coordination between receiver and sender, this means a = sender must send on average for 1/2 of a wakeup interval to deliver a = packet. E.g., 0.5s. Clearly in such a protocol a few extra bytes doesn't = matter in terms of energy. Of course, TSCH is much, much better than = this, I only mention this protocol as a simple explanatory example -- = but what's the actual number? Phil From nobody Sat Aug 2 20:37: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 3C94D1A00ED; Sat, 2 Aug 2014 20:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.622 X-Spam-Level: ** X-Spam-Status: No, score=2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FB_CIALIS_LEO3=3.899, 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 pP8hnxkJxyPs; Sat, 2 Aug 2014 20:37:05 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA80D1A00EA; Sat, 2 Aug 2014 20:37:04 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id w10so7695384pde.4 for ; Sat, 02 Aug 2014 20:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cswJ6EWhfSEatvVaLn4TLLDysFyCRVAS/unDHT5MEYk=; b=E/mBRPsg/frVzFmhSFOXlb0QE3hsfCRpy+keeGAwOZ7k1TJOrcBI+C6Z4CmW2BTQOF DOVwLuFHJEhmlTnB3QG3lqHNrKtC7NmL69EqwvLjmUmW3PIneTQsGKOiiwrNMBl4OOHG 29kbNfnt7WOCWnOhAuom0Qo3tl3nOh+GVgLzT22i+DI+34spFJC2uJB0PCGZKPkZqwEP upUDRF32jV6jYxNDJLuaSS97ufwAk7jbwolZlYOzaZUM5lJybCzuzlXD8LwrRog1kTh5 ABvxDispjuC/HlsSyQOzH/JbT5t1rfEJmubRN0wRUStzQduUsSrrzGzFejf6PX3+03bJ w9Xw== X-Received: by 10.68.68.207 with SMTP id y15mr16122177pbt.25.1407037024445; Sat, 02 Aug 2014 20:37:04 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.144.1 with HTTP; Sat, 2 Aug 2014 20:36:44 -0700 (PDT) In-Reply-To: <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <53DB675C.9000502@tm.uka.de> <53DB88B7.80205@tm.uka.de> <6439.1407007393@sandelman.ca> <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu> From: Thomas Watteyne Date: Sat, 2 Aug 2014 20:36:44 -0700 X-Google-Sender-Auth: odZ7zxR-YZSv4h907uuVZUeYPCo Message-ID: To: Philip Levis Content-Type: multipart/alternative; boundary=001a11381772072a7504ffb156ea Archived-At: http://mailarchive.ietf.org/arch/msg/roll/RvxgnfFAY268qG_zFw5stVFcPvs Cc: Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 03:37:07 -0000 --001a11381772072a7504ffb156ea Content-Type: text/plain; charset=UTF-8 Phil, There are two parts in answering your question. Let me describe both, I will then justify why the answer is "it depends". *a single slot* Let's consider for starters only a single TSCH slot: mote A sends a packet to mote B, which replies with an ACK. This timeslot is depicted below (borrowed from [1]) /------------------- Time Slot duration --------------------/ | /tsShortGT/ | | | | | | | |------------+-----------------+--------------+------+------| TX | | TX-Packet | |RX Ack| | |------------+-----------------+--------------+------+------| |/tsTxOffset/| | | | | | | | | | | |------------+-----------------+--------------+------+------| RX | | | | RX-Packet | |TX Ack| | |---------+--+--+--------------+--------------+------+------| | | | | | | | | | /tsLongGT/ |/TsTxAckDelay/| | | Start End of of Slot Slot Let's assume that the IEEE802.15.4 frame is 127B long, i.e. full length. Let's assume, finally, that you are using the default 10ms timeslot template from the IEEE802.15.4e-2012 standard [2] (Table 52e), no CCA. This is the radio-on time on both A and B: - mote A - transmitting the data packet: 4256us - listening for ACK during the guard time (i.e. idle listening): 200us - receiving the ACK (~15B long): 480us - mote B: - listening for data during the guard time (i.e. idle listening): 1000us - receiving data: 4256us - transmitting the ACK: 480us >From an energy point of view, you also need to account for the time is takes to switch the radio on/off and for the possible energy consumed between the data and ack, in case the radio is kept in a state allowing it to TX/RX fast. Good embedded engineers will reduce this overhead through firmware and hardware wizardry. Considering only time, the radio on-time budget can hence be cut into: - total: 10672us - transmission of data: 8512us (~80%) - desynchronization overhead (i.e. idle listening during guard time): 1200us (~10%) - ACK overhead: 960us (~10%) >From these numbers, you see that the actual data transmission accounts for ~80% of the radio-on time budget. Of course, this timeslot template is the default one. If you are very good at keeping synchronized, you might be able to shorten the guard times and reduce the desynchronization overhead. *full network* Now the fun part. In a TSCH network, the communication schedule indicates to every mote what to do: transmit, listen or sleep. You can tune the TSCH communication schedule any way you want. In fact, the 6TiSCH WG was created to define mechanisms for centralized and distributed managements of this schedule. Your goal should be to match the amount of bandwidth in your schedule (i.e. the cells used for transmission and reception) to what is needed by the network. If every cell you schedule is used, the single slot results from above carry over to a full network. If, however, you schedule has too many cells, some might be unused. In that case, the transmitter will keep its radio off (i.e. consume no energy), while the receiver will have to listen for a full guard time, or 2ms when using the default timeslot template. So there you go: it depends. In the best possible case, the portion of radio on-time spent of exchanging actual useful data can be very high (80%+), but it's easy to mess things up, resulting in a large number of over-provisioned cells. For a (hopefully clear) overview of IEEE802.15.4e TSCH, take a look at http://tools.ietf.org/html/draft-ietf-6tisch-tsch-01. Thomas [1] http://tools.ietf.org/html/draft-ietf-6tisch-minimal-02 [2] http://standards.ieee.org/getieee802/download/802.15.4e-2012.pdf On Sat, Aug 2, 2014 at 2:41 PM, Philip Levis wrote: > On Aug 2, 2014, at 12:23 PM, Michael Richardson > wrote: > > > > > Philip Levis wrote: > >> The paper is very helpful, thanks! Can you comment on what is a typical > >> idle slot configuration in a TiSCH network? Can you provide some > >> insight on what fraction of energy is spent in data communication > >> versus control and idle listening? > > > > Here is a recent post with some real numbers: > > https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY > > it concerns diet-ESP, but the numbers are correct. > > Michael, > > I'm confused on what this email message is supposed to be providing: the > energy cost of sending a bit? That's pretty simple to calculate. The > tradeoff between CPU and network is also very well known, going back to > Pottie's "Every bit transmitted brings a sensor node one moment closer to > death." If you look at the behavior of most micro controller based devices, > the MCU is insignificant -- and 95% of its energy is spent handling > interrupts (per-byte, over an SPI bus) for the radio. Yes, unless you're > doing something quite silly, the CPU cost of compression is almost always > absolutely worth the benefit in terms of reduced transmission energy. > > My question related to the fraction of radio energy in TSCH that is > consumed by data transmission/reception versus everything else (idle > listening, guard periods, control frames, etc. > > To give you a data point -- early low-power link layers continually > transmitted a packet (or wakeup frame) until receiving an acknowledgement > from the intended receiver. Receivers periodically wake up, listen if > there's energy on the channel, and if so, stay awake for 2 packet times (in > case they woke up just after the preamble of a packet). If there's no > coordination between receiver and sender, this means a sender must send on > average for 1/2 of a wakeup interval to deliver a packet. E.g., 0.5s. > Clearly in such a protocol a few extra bytes doesn't matter in terms of > energy. Of course, TSCH is much, much better than this, I only mention this > protocol as a simple explanatory example -- but what's the actual number? > > Phil > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11381772072a7504ffb156ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Phil,

There are two parts in answering = your question. Let me describe both, I will then justify why the answer is = "it depends".

a single slot

Let's consider for starters only a single TSCH slot= : mote A sends a packet to mote B, which replies with an ACK. This timeslot= is depicted below (borrowed from [1])


      /------------------- Time Slot duration --------------------/
      |                                        /tsShortGT/        |
      |            |                              | | |           |
      |------------+-----------------+--------------+------+------|
   TX |            |    TX-Packet    |              |RX Ack|      |
      |------------+-----------------+--------------+------+------|
      |/tsTxOffset/|                 |              |      |      |
      |            |                 |              |      |      |
      |------------+-----------------+--------------+------+------|
   RX |         |  |  | RX-Packet    |              |TX Ack|      |
      |---------+--+--+--------------+--------------+------+------|
      |         |  |  |              |              |      |      |
      |        /tsLongGT/            |/TsTxAckDelay/|      |      |
     Start                                                       End
      of                                                          of
     Slot                                                        Slot
=

Let's assume that the IEEE802.15.4 frame is 1= 27B long, i.e. full length. Let's assume, finally, that you are using t= he default 10ms timeslot template from the IEEE802.15.4e-2012 standard [2] = (Table 52e), no CCA. This is the radio-on time on both A and B:
  • mote A
    • transmitting the data packet: 4256us
    • listening for ACK during the guard time (i.e. idle listening): 200us<= /li>
    • receiving the ACK (~15B long): 480us
  • mote B:
    • listening for data during the guard time (i.e. idle listening): 1000us<= /li>
    • receiving data:=C2=A04256us
    • transmitting the ACK: 480us
From an energy point of view, you also need to accoun= t for the time is takes to switch the radio on/off and for the possible ene= rgy consumed between the data and ack, in case the radio is kept in a state= allowing it to TX/RX fast. Good embedded engineers will reduce this overhe= ad through firmware and hardware wizardry.

Considering only time, the radio on-time budget can hen= ce be cut into:
  • total: 10672us
  • transmission of da= ta: 8512us (~80%)
  • desynchronization overhead (i.e. idle listening d= uring guard time): 1200us (~10%)
  • ACK overhead: 960us=C2=A0(~10%)
From these numbers, you s= ee that the actual data transmission accounts for ~80% of the radio-on time= budget.

Of course, this timeslot template is the = default one. If you are very good at keeping synchronized, you might be abl= e to shorten the guard times and reduce the desynchronization overhead.

full network

Now the fun part.

In a TSCH network, the commun= ication schedule indicates to every mote what to do: transmit, listen or sl= eep. You can tune the TSCH communication schedule any way you want. In fact= , the 6TiSCH WG was created to define mechanisms for centralized and distri= buted managements of this schedule.

Your goal should be to match the amount of bandwidth in= your schedule (i.e. the cells used for transmission and reception) to what= is needed by the network. If every cell you schedule is used, the single s= lot results from above carry over to a full network. If, however, you sched= ule has too many cells, some might be unused. In that case, the transmitter= will keep its radio off (i.e. consume no energy), while the receiver will = have to listen for a full guard time, or 2ms when using the default timeslo= t template.

So there you go: it depends. In the best possible case,= the portion of radio on-time spent of exchanging actual useful data can be= very high (80%+), but it's easy to mess things up, resulting in a larg= e number of over-provisioned cells.

For a (hopefully clear) overview of IEEE802.15.4e TSCH,= take a look at=C2=A0http://tools.ietf.org/html/draft-ietf-6tisch-tsch-01.
<= div>
Thomas



On Sat,= Aug 2, 2014 at 2:41 PM, Philip Levis <pal@cs.stanford.edu> wrote:
On Aug 2, 2014, at 12:23 PM,= Michael Richardson <mcr+ietf= @sandelman.ca> wrote:

>
> Philip Levis <pal@cs.stanfor= d.edu> wrote:
>> The paper is very helpful, thanks! Can you comment on what is a ty= pical
>> idle slot configuration in a TiSCH network? Can you provide some >> insight on what fraction of energy is spent in data communication<= br> >> versus control and idle listening?
>
> Here is a recent post with some real numbers:
> =C2=A0https://mailarchive.ietf.org/arch/msg= /ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY
> it concerns diet-ESP, but the numbers are correct.

Michael,

I'm confused on what this email message is supposed to be providing: th= e energy cost of sending a bit? That's pretty simple to calculate. The = tradeoff between CPU and network is also very well known, going back to Pot= tie's "Every bit transmitted brings a sensor node one moment close= r to death." If you look at the behavior of most micro controller base= d devices, the MCU is insignificant -- and 95% of its energy is spent handl= ing interrupts (per-byte, over an SPI bus) for the radio. Yes, unless you&#= 39;re doing something quite silly, the CPU cost of compression is almost al= ways absolutely worth the benefit in terms of reduced transmission energy.<= br>
My question related to the fraction of radio energy in TSCH that is consume= d by data transmission/reception versus everything else (idle listening, gu= ard periods, control frames, etc.

To give you a data point -- early low-power link layers continually transmi= tted a packet (or wakeup frame) until receiving an acknowledgement from the= intended receiver. Receivers periodically wake up, listen if there's e= nergy on the channel, and if so, stay awake for 2 packet times (in case the= y woke up just after the preamble of a packet). If there's no coordinat= ion between receiver and sender, this means a sender must send on average f= or 1/2 of a wakeup interval to deliver a packet. E.g., 0.5s. Clearly in suc= h a protocol a few extra bytes doesn't matter in terms of energy. Of co= urse, TSCH is much, much better than this, I only mention this protocol as = a simple explanatory example -- but what's the actual number?

Phil




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

--001a11381772072a7504ffb156ea-- From nobody Sun Aug 3 10:28:43 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 0EAA91A0AF7; Sun, 3 Aug 2014 10:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 HnbD7IcV_Kj5; Sun, 3 Aug 2014 10:28:38 -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 4B6531A0AF6; Sun, 3 Aug 2014 10:28:38 -0700 (PDT) Received: from [76.14.66.110] (port=62544 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XDzaG-00057V-MZ; Sun, 03 Aug 2014 10:28:38 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: Date: Sun, 3 Aug 2014 10:28:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9A525A33-FC53-4574-86F9-0FC4E8E5EC43@cs.stanford.edu> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <53DB675C.9000502@tm.uka.de> <53DB88B7.80205@tm.uka.de> <6439.1407007393@sandelman.ca> <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu> To: Thomas Watteyne X-Mailer: Apple Mail (2.1510) X-Scan-Signature: e2fb03075b2557fb7882065b4eb34aa8 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/zndKI9Saf24zenoIxL2ibjvwvvc Cc: Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 17:28:40 -0000 Thomas, This is great, thank you! Precise, technical statements. What I conclude = from your text (correct me if I'm wrong): 1) If 802.15.4e uses maximum sized frames (127 bytes), the data = communication time (reception or transmission) within a transmit slot is = 80% of the total radio-on time. I appreciate that you separate the costs = of the two sides (e.g., idle listening guard period on receive). 2) Following Xavier's analysis, using 127-byte frames means the RPL = option increases data communication time by 4%. This means, from 1), = that it will increase energy consumption by ~3.5%. Or, supposing his 8% = number is correct (I still don't understand how he reached it), the = energy consumption is increased by ~6.5%. 3) For smaller frames (e.g., the 50 bytes Xavier suggested), the idle = listening on the receiver takes a larger fraction of the radio-on time, = so his 10% number is too high. 4) None of these calculations consider the control overhead or, as you = point out, inefficiencies in slot assignment. E.g., if you have a = low-bandwidth, low-delay network, then you will allocate slots (for low = latency) that you do not use (low bandwidth). For networks that are = perfectly tuned, as you suggest, you can approach the transmission slot = gains in 1) and 2). But they do not consider the costs and time of = beacons or management time slots. Or radio wakeup overhead (dead time): = my understanding is that on modern chips this is about 300us? I think = your ACK timing considers RX/TX turnaround time. So in that way, 1) and = 2) represent the absolute *best* savings this might give you.=20 So my conclusion from this data is that, in the absolute best case -- = assuming the radio is all of the system energy, you have a perfectly = tuned TSCH schedule, etc., etc., using the flow label will save <10%, = and often on the order of 5%. For simpler, less efficient and tuned MAC = layers, the savings will be less. 5% or 10% isn't huge, but it is significant and valuable. I've just been = a bit confused as to why this proposal has been trotted around for 4 = years and yet no-one had yet even done this simple calculation, so WG = members could make an informed engineering decision. IMO, a 5-10% = savings in already highly tuned networks is above the bar and worth it. = In most networks, the savings will be much less, but the benefits of = reduced memory pressure and larger application payloads without = fragmentation are more than sufficient motivation and justification of = the value of the approach. Phil On Aug 2, 2014, at 8:36 PM, Thomas Watteyne = wrote: > Phil, >=20 > There are two parts in answering your question. Let me describe both, = I will then justify why the answer is "it depends". >=20 > a single slot >=20 > Let's consider for starters only a single TSCH slot: mote A sends a = packet to mote B, which replies with an ACK. This timeslot is depicted = below (borrowed from [1]) >=20 >=20 > /------------------- Time Slot duration --------------------/ > | /tsShortGT/ | > | | | | | | > |------------+-----------------+--------------+------+------| > TX | | TX-Packet | |RX Ack| | > |------------+-----------------+--------------+------+------| > |/tsTxOffset/| | | | | > | | | | | | > |------------+-----------------+--------------+------+------| > RX | | | | RX-Packet | |TX Ack| | > |---------+--+--+--------------+--------------+------+------| > | | | | | | | | > | /tsLongGT/ |/TsTxAckDelay/| | | > Start End > of of > Slot Slot >=20 >=20 > Let's assume that the IEEE802.15.4 frame is 127B long, i.e. full = length. Let's assume, finally, that you are using the default 10ms = timeslot template from the IEEE802.15.4e-2012 standard [2] (Table 52e), = no CCA. This is the radio-on time on both A and B: > =95 mote A > =95 transmitting the data packet: 4256us > =95 listening for ACK during the guard time (i.e. idle = listening): 200us > =95 receiving the ACK (~15B long): 480us > =95 mote B: > =95 listening for data during the guard time (i.e. idle = listening): 1000us > =95 receiving data: 4256us > =95 transmitting the ACK: 480us > =46rom an energy point of view, you also need to account for the time = is takes to switch the radio on/off and for the possible energy consumed = between the data and ack, in case the radio is kept in a state allowing = it to TX/RX fast. Good embedded engineers will reduce this overhead = through firmware and hardware wizardry. >=20 > Considering only time, the radio on-time budget can hence be cut into: > =95 total: 10672us > =95 transmission of data: 8512us (~80%) > =95 desynchronization overhead (i.e. idle listening during guard = time): 1200us (~10%) > =95 ACK overhead: 960us (~10%) > =46rom these numbers, you see that the actual data transmission = accounts for ~80% of the radio-on time budget. >=20 > Of course, this timeslot template is the default one. If you are very = good at keeping synchronized, you might be able to shorten the guard = times and reduce the desynchronization overhead. >=20 > full network >=20 > Now the fun part. >=20 > In a TSCH network, the communication schedule indicates to every mote = what to do: transmit, listen or sleep. You can tune the TSCH = communication schedule any way you want. In fact, the 6TiSCH WG was = created to define mechanisms for centralized and distributed managements = of this schedule. >=20 > Your goal should be to match the amount of bandwidth in your schedule = (i.e. the cells used for transmission and reception) to what is needed = by the network. If every cell you schedule is used, the single slot = results from above carry over to a full network. If, however, you = schedule has too many cells, some might be unused. In that case, the = transmitter will keep its radio off (i.e. consume no energy), while the = receiver will have to listen for a full guard time, or 2ms when using = the default timeslot template. >=20 > So there you go: it depends. In the best possible case, the portion of = radio on-time spent of exchanging actual useful data can be very high = (80%+), but it's easy to mess things up, resulting in a large number of = over-provisioned cells. >=20 > For a (hopefully clear) overview of IEEE802.15.4e TSCH, take a look at = http://tools.ietf.org/html/draft-ietf-6tisch-tsch-01. >=20 > Thomas >=20 > [1] http://tools.ietf.org/html/draft-ietf-6tisch-minimal-02 > [2] http://standards.ieee.org/getieee802/download/802.15.4e-2012.pdf >=20 >=20 > On Sat, Aug 2, 2014 at 2:41 PM, Philip Levis = wrote: > On Aug 2, 2014, at 12:23 PM, Michael Richardson = wrote: >=20 > > > > Philip Levis wrote: > >> The paper is very helpful, thanks! Can you comment on what is a = typical > >> idle slot configuration in a TiSCH network? Can you provide some > >> insight on what fraction of energy is spent in data communication > >> versus control and idle listening? > > > > Here is a recent post with some real numbers: > > = https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY > > it concerns diet-ESP, but the numbers are correct. >=20 > Michael, >=20 > I'm confused on what this email message is supposed to be providing: = the energy cost of sending a bit? That's pretty simple to calculate. The = tradeoff between CPU and network is also very well known, going back to = Pottie's "Every bit transmitted brings a sensor node one moment closer = to death." If you look at the behavior of most micro controller based = devices, the MCU is insignificant -- and 95% of its energy is spent = handling interrupts (per-byte, over an SPI bus) for the radio. Yes, = unless you're doing something quite silly, the CPU cost of compression = is almost always absolutely worth the benefit in terms of reduced = transmission energy. >=20 > My question related to the fraction of radio energy in TSCH that is = consumed by data transmission/reception versus everything else (idle = listening, guard periods, control frames, etc. >=20 > To give you a data point -- early low-power link layers continually = transmitted a packet (or wakeup frame) until receiving an = acknowledgement from the intended receiver. Receivers periodically wake = up, listen if there's energy on the channel, and if so, stay awake for 2 = packet times (in case they woke up just after the preamble of a packet). = If there's no coordination between receiver and sender, this means a = sender must send on average for 1/2 of a wakeup interval to deliver a = packet. E.g., 0.5s. Clearly in such a protocol a few extra bytes doesn't = matter in terms of energy. Of course, TSCH is much, much better than = this, I only mention this protocol as a simple explanatory example -- = but what's the actual number? >=20 > Phil >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Mon Aug 4 02:52: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 D91D21B298A; Mon, 4 Aug 2014 02:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 pkfDDUwHcbEt; Mon, 4 Aug 2014 02:51:02 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B501B298C; Mon, 4 Aug 2014 02:51:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEGAKJW31OtJssW/2dsb2JhbABbhDaCeNB2BAIBgS53hAMBAQQBI1YFCwsYAgImAgIhNgYTiC4DCQitZI9sDYcAF4Esi3OBViQzB4J5NoEcAQSZf5A+hiiDTzsvAYEE X-IronPort-AV: E=Sophos;i="5.01,797,1400025600"; d="scan'208";a="132591672" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 04 Aug 2014 09:50:59 +0000 Received: from dhcp-10-61-106-70.cisco.com (dhcp-10-61-106-70.cisco.com [10.61.106.70]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s749ovhq019970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2014 09:50:58 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\)) From: Ole Troan In-Reply-To: <53DBF16F.2090202@gmail.com> Date: Mon, 4 Aug 2014 11:50:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53DBF16F.2090202@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1971.5) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/CoviHxmzzLhbva3_Cp4EIkc6_d8 X-Mailman-Approved-At: Mon, 04 Aug 2014 02:52:09 -0700 Cc: 6man WG , roll Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 04 Aug 2014 09:51:04 -0000 > On 01 Aug 2014, at 21:58 , Brian E Carpenter = wrote: >=20 > On 01/08/2014 23:23, Carsten Bormann wrote: > ... >> The other story is that we are retracting RFC 6437 and turning the = flow label into the =E2=80=9Cfield you may trample on in your lower = layers if you have a good reason=E2=80=9D. Cynically, one could say = this is proper payback for designing this field without a compelling = purpose and no protocol evolution story attached to it. So the = evolution just eats it. Teachable moment. >=20 > RFC 6437 co-author hat on (but only speaking for myself, of course): >=20 > My opinion is that the draft doesn't retract RFC 6437. As I already = said, > 6437 attempts to recognise the reality that middleboxes can mess with = the > flow label, and to set conditions for that messing such that remote = systems > can still use it for load balancing. Since it's unprotected by = checksum or > crypto, there is a strict limit to how much it can be trusted anyway. = As > the RFC says: >=20 > There is no way to verify whether a flow label has been modified en > route or whether it belongs to a uniform distribution. Therefore, = no > Internet-wide mechanism can depend mathematically on unmodified and > uniformly distributed flow labels; they have a "best effort" = quality. > Implementers should be aware that the flow label is an unprotected > field that could have been accidentally or intentionally changed en > route (see Section 6). >=20 > It is true that the RFC also says >=20 > A forwarding node > MUST either leave a non-zero flow label value unchanged or change it > only for compelling operational security reasons... >=20 > There is a case for arguing that flow-label-for-rpl should carry the > legend "Updates: 6437 (if approved)" because it adds another exception > to this sentence. There is also a case for arguing that = flow-label-for-rpl > is a stateful mechanism, out of scope for RFC 6437 according to > Section 4 of that RFC. >=20 > Either way, I don't see a problem. I see the principles in these two documents as mutually exclusive: RFC6437: middleboxes can mess with the flow label -flow-label-for-rpl: networks uses flow label field as an immutable = protocol field you can't both use the flow label as an immutable protocol field and = have middleboxes rewriting it. cheers, Ole From nobody Mon Aug 4 07:02: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 67BA81B2B10; Mon, 4 Aug 2014 07:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 l4lO3PNrG7zK; Mon, 4 Aug 2014 07:02:32 -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 262FB1B2B0F; Mon, 4 Aug 2014 07:02:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 71D0320029; Mon, 4 Aug 2014 10:04:50 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F279363AC9; Mon, 4 Aug 2014 10:02:27 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DC1D8638D6; Mon, 4 Aug 2014 10:02:27 -0400 (EDT) From: Michael Richardson To: Philip Levis In-Reply-To: <9A525A33-FC53-4574-86F9-0FC4E8E5EC43@cs.stanford.edu> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <53DB675C.9000502@tm.uka.de> <53DB88B7.80205@tm.uka.de> <6439.1407007393@sandelman.ca> <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu> <9A525A33-FC53-4574-86F9-0FC4E8E5EC43@cs.stanford.edu> 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/BZb5MDa6kYHJZ81NC5OKeneer5o Cc: Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 04 Aug 2014 14:02:34 -0000 --=-=-= Philip Levis wrote: > 5% or 10% isn't huge, but it is significant and valuable. I've just > been a bit confused as to why this proposal has been trotted around for > 4 years and yet no-one had yet even done this simple calculation, so WG > members could make an informed engineering decision. IMO, a 5-10% my opinion: 1) the exact calculation was hard to really do until 6tisch made it clearer what the duty cycle was going to be. 2) it took awhile to come back to figuring out how to deal with the flow label issue. 3) it is now clear exactly how close many of our packets are to the 127 byte limit, and how much the HbH header hurts if it is the reason we go into two fraglets. 4) we had other things to worry about! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU9+ScYCLcPvd0N1lAQKSrQgAj0jM9dgzgL8ZP78Ey5/OcRv9kKCkqVjp InGMXvpZCpBuUY0yZyxiIIGYUDh02v41QbATGgyCUmVIM6aUfQ3lhlpbu4CSUR7l C5l/Z6ZlT97u6DMHQvzhgtSlY7frGk1Nlf4H+4I2jRvAYVOz/LB5WsEhm+imYYKL dY6WXvUVxguG9G8cvgmeJS0rRlx9zs4chWNqI5lC4MMn4XXfRwTp90Wl+2eQZYjG 3kNzzgz5gRA60umoZq8JWSSc9R+XohPEOt2vB+U9oxp5DR/v3WkcjsWP2uAmoZiY Qd55MnA4qBZtXKcUmhVzT1ULPWxRNRFM77XsKOF1QnTvNNDc2TGBkw== =6iHG -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 4 07:15:26 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA6D1B2B16; Mon, 4 Aug 2014 07:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 EHmOtWcFVU5V; Mon, 4 Aug 2014 07:15:17 -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 0AA5D1B2B11; Mon, 4 Aug 2014 07:15:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6309620029; Mon, 4 Aug 2014 10:17:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E5E0F63AC9; Mon, 4 Aug 2014 10:15:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D3FF6638D6; Mon, 4 Aug 2014 10:15:15 -0400 (EDT) From: Michael Richardson To: Ole Troan In-Reply-To: References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53DBF16F.2090202@gmail.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/tjXlOevvMxrnikPDqPf7JJLyc28 Cc: roll , 6man WG , Brian E Carpenter Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 04 Aug 2014 14:15:20 -0000 --=-=-= On 01 Aug 2014, at 21:58 , Brian E Carpenter wrote: >> It is true that the RFC also says >> >> A forwarding node MUST either leave a non-zero flow label value >> unchanged or change it only for compelling operational security >> reasons... >> >> There is a case for arguing that flow-label-for-rpl should carry the >> legend "Updates: 6437 (if approved)" because it adds another exception >> to this sentence. There is also a case for arguing that >> flow-label-for-rpl is a stateful mechanism, out of scope for RFC 6437 >> according to Section 4 of that RFC. >> >> Either way, I don't see a problem. Ole Troan wrote: > I see the principles in these two documents as mutually exclusive: > RFC6437: middleboxes can mess with the flow label -flow-label-for-rpl: > networks uses flow label field as an immutable protocol field > you can't both use the flow label as an immutable protocol field and > have middleboxes rewriting it. This is my take. Case 1: packet is within the LLN. No issue; the sender sets the flow label, and we know (by design) that there aren't any (non-RPL) middle boxes that need to rewrite it. Case 2: the packet has to leave the LLN, travel across the Internet, and enter another LLN. Here the arguments about the LLN being a kind of virtual host from the document are relevant. The flow label, when it crosses the Internet, would be immutable. Prior to this document, the flow label would have been compressed out, been zero, and the DODAG root ought to have set it in some consistent fashion anyway. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU9+VcYCLcPvd0N1lAQKI8wgAlset3iLkNvBTxf7b910wO9yiu1ZaXXyF mKtFTL5OeAT/oyO2hDu3ph+NgvJo5+x9HruzyCsEG/lqqJgTs2GipU3XeP9m9Opt ZhzukyIVhRXxVFToFrIx34v/WNJQxojtOcc9UEdiWnx9tMqrTZU9GZ8n7LGEUbhp 9lrQQ5JqZBifDwu6I+u7mSlh47G5+jDiMe26HhdSfyB0fKvtM/I91Iv0DwpV8pkz mxPZIHSWyixyIMfkTWVKmdpr0Hi7jpTpaPd0cK4qlwZDCO5+UDW05U2UBCUj7XAS IKoML9yAni1Tg4fXEExefidhFEP/OR4h4eTL+pP85HaFdIyb/c0tbQ== =PD8O -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 4 08:42: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 028711B2B85; Mon, 4 Aug 2014 08:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 i2uzP1eyA2Ne; Mon, 4 Aug 2014 08:42:04 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9471B2B87; Mon, 4 Aug 2014 08:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2791; q=dns/txt; s=iport; t=1407166925; x=1408376525; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xw3B3o2JPOVlwtt1J2/28xsD7wSNskWemkGFgIbJPoA=; b=Q+xk0i1hPwJMQZzZMdTIebNY51L7W4uI19HfoNNFmwhc+L67v3yCzcui xjCV3bvnHxbl/C37RXIBqQKDwii+vcfMpynp/Sm470vWity1aM/pr11i9 ReoandSFkk5X7Fx76XJwDgYXSSfZxtS2zLLGD82qO4S60q5DFaI/hoWIR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAJup31OtJV2a/2dsb2JhbABagw2BKQTTewGBEBZ3hAMBAQEEeQwEAgEIEQQBAQEKHQchERQJCAIEAQ0FCIgmAxG+Jw2HABeNH4F8MQcGgymBHAWKVY8qkD6GKINNbAGBRQ X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="scan'208";a="344977142" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 04 Aug 2014 15:41:57 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s74FfuAB031725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 15:41:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 10:41:56 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson , Ole Troan Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPrcL83Dn9icet106HlaTIaH7gh5vAi3mAgABJ2ID//8HXoA== Date: Mon, 4 Aug 2014 15:41:55 +0000 Deferred-Delivery: Mon, 4 Aug 2014 15:41:00 +0000 Message-ID: References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53DBF16F.2090202@gmail.com> <26363.1407161715@sandelman.ca> In-Reply-To: <26363.1407161715@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.74.174] 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/FMHYkuruIeMYGmvVfnmY57ym9OM Cc: roll , 6man WG Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 04 Aug 2014 15:42:06 -0000 Exactly; It can be argued that the LLN is a single something that is a more complex = form of the classical host-router link from the L3 perspective. RFC6437 understands that the host can leave the flow label to all zeroes an= d allows the first router to set it in a recommended fashion.=20 The draft pushes that role to the RPL root that is effectively the gateway = from the LLN onto the Internet. Upon the WLLC discussion I have added " Updates: 6437 (if approved) " and p= osted an update with no other change in the text. Cheers, Pascal > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: lundi 4 ao=FBt 2014 16:15 > To: Ole Troan > Cc: roll; 6man WG > Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03 >=20 >=20 > On 01 Aug 2014, at 21:58 , Brian E Carpenter > wrote: > >> It is true that the RFC also says > >> > >> A forwarding node MUST either leave a non-zero flow label value > >> unchanged or change it only for compelling operational security > >> reasons... > >> > >> There is a case for arguing that flow-label-for-rpl should carry t= he > >> legend "Updates: 6437 (if approved)" because it adds another > exception > >> to this sentence. There is also a case for arguing that > >> flow-label-for-rpl is a stateful mechanism, out of scope for RFC 6= 437 > >> according to Section 4 of that RFC. > >> > >> Either way, I don't see a problem. >=20 > Ole Troan wrote: > > I see the principles in these two documents as mutually exclusive: > > RFC6437: middleboxes can mess with the flow label -flow-label-for-r= pl: > > networks uses flow label field as an immutable protocol field >=20 > > you can't both use the flow label as an immutable protocol field an= d > > have middleboxes rewriting it. >=20 > This is my take. > Case 1: packet is within the LLN. No issue; the sender sets the flow la= bel, > and we know (by design) that there aren't any (non-RPL) middle boxes > that need to rewrite it. >=20 > Case 2: the packet has to leave the LLN, travel across the Internet, and > enter another LLN. > Here the arguments about the LLN being a kind of virtual host from > the document are relevant. The flow label, when it crosses the > Internet, would be immutable. Prior to this document, the flow labe= l > would have been compressed out, been zero, and the DODAG root ought > to > have set it in some consistent fashion anyway. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Mon Aug 4 11:01:19 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA81E1A008B; Mon, 4 Aug 2014 11:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 YWFPeGHQGJtp; Mon, 4 Aug 2014 11:01:14 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58B61A00B2; Mon, 4 Aug 2014 11:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2834; q=dns/txt; s=iport; t=1407175274; x=1408384874; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=SguRyPk9qyZJA4pK5gAZKGObnA9g9cKVnhnwi5fPhJ4=; b=hObilLyKDC4OjRWS6c/YGl3husDQk7cSU765r0bm/pxB3l9q3KmTCCmU kBOw2ziY5Gi8NfygORybxMpUldWUgcepghybAujHdgdV/xEU0auX4YYOy UwSP/n1T3yt/yVhIHx0DiuMHvW+e9209M0VXu5q+l/FKOtqn6cRT9za97 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAEfJ31OtJV2Z/2dsb2JhbABagw1SVwSCdMk6CodKARl4FneEAwEBAQQBAQEgEToLEgEIDgMEAQEDAgYdAwIEJQsUAQgJAQQOBQiIOg2uG5cJEwSBLI1SHTGDADaBHAWGCapcg01sgUY X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="scan'208";a="66416238" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 04 Aug 2014 18:01:13 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s74I1CCT014433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 18:01:12 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 13:01:12 -0500 From: "Pascal Thubert (pthubert)" To: Ralph Droms , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoA== Date: Mon, 4 Aug 2014 18:01:11 +0000 Deferred-Delivery: Mon, 4 Aug 2014 18:01:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.74.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/V0r1PkXc133mpDYwKihevvNE-bE Cc: Michael Richardson , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 04 Aug 2014 18:01:17 -0000 VGhlIGNoYW5nZSBpcyBub3cgZG9uZSwgUmFscGguDQoNClRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0 d2VlbiBkcmFmdC10aHViZXJ0LTZtYW4tZmxvdy1sYWJlbC1mb3ItcnBsLTAzIGFuZCBkcmFmdC10 aHViZXJ0LTZtYW4tZmxvdy1sYWJlbC1mb3ItcnBsLTA0IGlzIA0KDQpVcGRhdGVzOiA2NDM3IChp ZiBhcHByb3ZlZCkNCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KRnJvbTogaXB2NiBbbWFpbHRvOmlw djYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJhbHBoIERyb21zDQpTZW50OiBzYW1l ZGkgMiBhb8O7dCAyMDE0IDIyOjU3DQpUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9z c3kgbmV0d29ya3MNCkNjOiBNaWNoYWVsIFJpY2hhcmRzb247IGlwdjZAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbUm9sbF0gV0dMQyBmb3IgZHJhZnQtdGh1YmVydC02bWFuLWZsb3ctbGFiZWwtZm9y LXJwbC0wMw0KDQoNCg0KT24gQXVnIDIsIDIwMTQsIGF0IDQ6NDggUE0sICJQYXNjYWwgVGh1YmVy dCAocHRodWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPiB3cm90ZToNClRoYXQgc291bmRzIHJp Z2h0LCBNaWNoYWVsLCANCg0KSSBhZ3JlZSB0aGF0ICJ1cGRhdGVzIDY0MzciIGlzIGEgcmlnaHQg dGhpbmcgdG8gZG8uDQoNCnRob3VnaCBzbGlnaHRseSBvbiB0aGUgb3ZlcmtpbGwgc2lkZS4gDQoN CkkgZGlzYWdyZWUgdGhhdCBpdCBpcyBvdmVya2lsbC4gwqBJbiBteSBvcGluaW9uLMKgZHJhZnQt dGh1YmVydC02bWFuLWZsb3ctbGFiZWwtZm9yLVJQTCBwcmV0dHkgY2xlYXJseSBjb250cmFkaWN0 cyBSRkMgNjQzNywgc2/CoCJ1cGRhdGVzIDY0MzciIGlzIGFuIGFwcHJvcHJpYXRlIGFjdGlvbi4N Cg0KwqBBbmQgdGhpcyBpcyBjb25zaXN0ZW50IHdpdGggd2hhdCBCcmlhbiBzdWdnZXN0ZWQuIFRo aXMgY2FuIGJlIGFkZGVkIGR1cmluZyB0aGUgcmZjIGVkaXRvciBwcm9jZXNzIEkgZXhwZWN0Pw0K DQpJdCBzaG91bGQgYmUgYWRkZWQgYXMgc29vbiBhcyBwb3NzaWJsZSwgY2VydGFpbmx5IGJlZm9y ZSBpdCBnb2VzIHRvIHRoZSBJRVNHLiDCoEluIG15IG9waW5pb24sIHRoZSBjaGFuZ2UgbWlnaHQg d2FycmFudCBhIG5ldyBvciBleHRlbmRlZCBXR0xDOyB0aGF0IGFjdGlvbiBpcyB1cCB0byB0aGUg Y2hhaXJzLCBvZiBjb3Vyc2UuDQoNCi0gUmFscGgNCg0KDQpQYXNjYWwNCg0KTGUgMiBhb8O7dCAy MDE0IMOgIDIxOjA5LCAiTWljaGFlbCBSaWNoYXJkc29uIiA8bWNyK2lldGZAc2FuZGVsbWFuLmNh PiBhIMOpY3JpdCA6DQoNCg0KUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lz Y28uY29tPiB3cm90ZToNCk9UT0ggeW91IG5lZWQgdG8gdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGlz IG5vIG5lZWQgZm9yIGEgYmlzIHRvIHVwZGF0ZSBhDQpNVVNUIGluIGFuIFJGQy4gV2UgcmVjb2du aXplIHRoZSBpbXBlcmZlY3Rpb24gaW4gb3VyIHdvcmsgYW5kIGFyZQ0KYWx3YXlzIHJlYWR5IHRv IHJldmlzZSBhbmQgYW1lbmQgYWZ0ZXIgZHVlIGNvbnNpZGVyYXRpb24uDQoNClBlcmhhcHMgdGhp cyBkb2N1bWVudCBVUERBVEVTIDY0MzcgdGhlbj8NCg0KLS0NCk1pY2hhZWwgUmljaGFyZHNvbiA8 bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzDQotPSBJUHY2 IElvVCBjb25zdWx0aW5nID0tDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcg Z3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3JnDQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0 czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9s bCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcm9sbA0K From nobody Mon Aug 4 11:10:59 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 71F4B1A00D7; Mon, 4 Aug 2014 11:10:53 -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 lpBM8bC73jLx; Mon, 4 Aug 2014 11:10:50 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85F51A00E6; Mon, 4 Aug 2014 11:10:43 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id j5so9434151qga.1 for ; Mon, 04 Aug 2014 11:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3Q5zBVkMJA3QW5n+26VXwUczY9lgy1b3mn+s2DlhXQk=; b=sAWn4Wq+L6o7vtbE0tRDVR2oka/4pEdr0kkN3Cg5Xa1F00xTnvhuB1tCLA3D9pv7SY JD/lK3n2qM9irU+cvsn5OLjHwAEgIF1oNCdAWCoE8YhasaveFep8jastxhIEejEQd43D nk8yiGIc3H09fNAwJjswaYdNHVRvJ37yWoron6M+bYWVZ16Q53qnwHDsa0FASORWtsmc qgkAzzoQcD4aWvx+UdM3zOnpZXb2NgNe7PWTCqqEHxlPhHHGKxO+WC2snA9zMkt0eOPp huf6HqYPxCKBdIpz1hOgUPYukQFAz8M1x7Xly++U5VmMPVv3v0TcREIGkLmXM5NlvgKm DKzw== X-Received: by 10.224.11.9 with SMTP id r9mr23103790qar.43.1407175843072; Mon, 04 Aug 2014 11:10:43 -0700 (PDT) Received: from [10.82.101.21] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id s7sm8832174qgd.20.2014.08.04.11.10.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 11:10:42 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: Date: Mon, 4 Aug 2014 14:10:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> References: To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/lHTN2xrlbdcBkkRQt2Qcw0W7_CU Cc: Michael Richardson , Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 04 Aug 2014 18:10:53 -0000 On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) = wrote: > The change is now done, Ralph. >=20 > The only difference between draft-thubert-6man-flow-label-for-rpl-03 = and draft-thubert-6man-flow-label-for-rpl-04 is=20 >=20 > Updates: 6437 (if approved) I suggest adding a section to your doc that explains exactly what is = being updated in RFC 6437. - Ralph >=20 > Cheers, >=20 > Pascal >=20 > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ralph Droms > Sent: samedi 2 ao=FBt 2014 22:57 > To: Routing Over Low power and Lossy networks > Cc: Michael Richardson; ipv6@ietf.org > Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 >=20 >=20 >=20 > On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)" = wrote: > That sounds right, Michael,=20 >=20 > I agree that "updates 6437" is a right thing to do. >=20 > though slightly on the overkill side.=20 >=20 > I disagree that it is overkill. In my opinion, = draft-thubert-6man-flow-label-for-RPL pretty clearly contradicts RFC = 6437, so "updates 6437" is an appropriate action. >=20 > And this is consistent with what Brian suggested. This can be added = during the rfc editor process I expect? >=20 > It should be added as soon as possible, certainly before it goes to = the IESG. In my opinion, the change might warrant a new or extended = WGLC; that action is up to the chairs, of course. >=20 > - Ralph >=20 >=20 > Pascal >=20 > Le 2 ao=FBt 2014 =E0 21:09, "Michael Richardson" = a =E9crit : >=20 >=20 > Pascal Thubert (pthubert) wrote: > OTOH you need to understand that there is no need for a bis to update = a > MUST in an RFC. We recognize the imperfection in our work and are > always ready to revise and amend after due consideration. >=20 > Perhaps this document UPDATES 6437 then? >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Aug 4 11:23: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 154121A00D7; Mon, 4 Aug 2014 11:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkpsltyXDc-z; Mon, 4 Aug 2014 11:23:09 -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 7D0351A005C; Mon, 4 Aug 2014 11:23:09 -0700 (PDT) Received: from 108-192-17-194.lightspeed.sntcca.sbcglobal.net ([108.192.17.194]:49954 helo=phoenix.att.net) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XEMuW-0001Mu-Mf; Mon, 04 Aug 2014 11:23:08 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> Date: Mon, 4 Aug 2014 11:23:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1510) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Archived-At: http://mailarchive.ietf.org/arch/msg/roll/RYYOPPsLpsIQrvPKmHjkrPWT-aI Cc: Michael Richardson , "ipv6@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 04 Aug 2014 18:23:11 -0000 On Aug 4, 2014, at 11:10 AM, Ralph Droms wrote: >=20 > On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) = wrote: >=20 >> The change is now done, Ralph. >>=20 >> The only difference between draft-thubert-6man-flow-label-for-rpl-03 = and draft-thubert-6man-flow-label-for-rpl-04 is=20 >>=20 >> Updates: 6437 (if approved) >=20 > I suggest adding a section to your doc that explains exactly what is = being updated in RFC 6437. >=20 > - Ralph I agree. I think some of the text in 1.3 can be re-used for this = purpose. Phil= From nobody Mon Aug 4 11:24:52 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4216E1A005C; Mon, 4 Aug 2014 11:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYjxXJv1vA51; Mon, 4 Aug 2014 11:24:48 -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 6AB211A00E5; Mon, 4 Aug 2014 11:24:35 -0700 (PDT) Received: from 108-192-17-194.lightspeed.sntcca.sbcglobal.net ([108.192.17.194]:49959 helo=phoenix.att.net) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XEMvy-0001V9-Lr; Mon, 04 Aug 2014 11:24:35 -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: <23675.1407160947@sandelman.ca> Date: Mon, 4 Aug 2014 11:24:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7FA35615-C9A0-4591-B60B-874B95E87D1E@cs.stanford.edu> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <53DB675C.9000502@tm.uka.de> <53DB88B7.80205@tm.uka.de> <6439.1407007393@sandelman.ca> <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu> <9A525A33-FC53-4574-86F9-0FC4E8E5EC43@cs.stanford.edu> <23675.1407160947@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 2c21b60125577a2cbf52524016395bed Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ixcKipQ7-vI_8vJMbbj1Y4OYQ80 Cc: Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 04 Aug 2014 18:24:50 -0000 On Aug 4, 2014, at 7:02 AM, Michael Richardson = wrote: >=20 > Philip Levis wrote: >> 5% or 10% isn't huge, but it is significant and valuable. I've just >> been a bit confused as to why this proposal has been trotted around = for >> 4 years and yet no-one had yet even done this simple calculation, so = WG >> members could make an informed engineering decision. IMO, a 5-10% >=20 > my opinion: >=20 > 1) the exact calculation was hard to really do until 6tisch made it = clearer > what the duty cycle was going to be. >=20 > 2) it took awhile to come back to figuring out how to deal with the = flow > label issue. >=20 > 3) it is now clear exactly how close many of our packets are to the = 127 byte > limit, and how much the HbH header hurts if it is the reason we go = into > two fraglets. >=20 > 4) we had other things to worry about! Michael, 1) doesn't depend on 6tisch, it's based on 15.4e timing, and could have = been calculated for any other low power link layer. Years ago. 2) The proposal isn't substantively different -- in terms of bytes = sent/saved -- from the first version of the proposal suggested in 2010. 3) The analysis so far hasn't even touched this issue. 4) The entire introduction/motivation for the proposal is saving energy! = But no-one thought it important enough to actually estimate how much = energy it would save (in a best case, typical case) before a last call? Here's my worry -- the tradeoffs of low-power networks are very = different than the kinds of networks the IETF typically deals with. = It'll lead to protocol decisions a bit different than always-on = networks. But that doesn't mean it should be used as a blanket = justification or motivation. Otherwise it's just smoke and mirrors = (energy is critical! battery is critical! we therefore need less = CPU-intensive compression schemes! here's a new one. we need less = CPU-intensive cryptographic schemes! here's a new one.). If energy is so = important, and this would be such a big savings, then why the = recalcitrance to estimate it? It doesn't help my confidence in the = engineering when some of the back-of-the-envelope analyses (Xavier's) = have basic arithmetic errors that seem incognizant of how to measure = energy.=20 Phil From nobody Mon Aug 4 11:52:54 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F111A0107; Mon, 4 Aug 2014 11:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 cgxAY2FzZbv5; Mon, 4 Aug 2014 11:52:47 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE74D1A00F2; Mon, 4 Aug 2014 11:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3099; q=dns/txt; s=iport; t=1407178366; x=1408387966; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Uz8edhBF+3tpo4HTxDhKvQFo8Z/z1KuwSSxDOr+TLGM=; b=ZybPunGFvYsIOLz08LZAvAsMdppw+lM/Z8Obx8Y2UgTxpA6+DLNm1HCI zu9zCwtzN9B/cxGU6oY2YC/m3rXO6vDhD3KzfYNkpu/fzo5tfcytjR/3O DgGTOPX7Zg6qKa6/1hzwVKlBOB34Q9k3e0I5jGhQVtUV62lQ6ndGN1px0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAH/V31OtJA2E/2dsb2JhbABbgw1SVwTMMAqHSgGBERZ3hAMBAQEEAQEBawsMBAIBCA4DBAEBAQodByEGCxQJCAEBBA4FCIgmAxENvgQNhmMTBI0fgV8dMQcGgymBHAWKVY8qkD6GKINNbIFG X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="scan'208";a="66440083" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP; 04 Aug 2014 18:52:45 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s74IqjqQ000673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 18:52:45 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 13:52:45 -0500 From: "Pascal Thubert (pthubert)" To: Ralph Droms Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAAK2YQAAAkecMA= Date: Mon, 4 Aug 2014 18:52:44 +0000 Deferred-Delivery: Mon, 4 Aug 2014 18:52:00 +0000 Message-ID: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> In-Reply-To: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.74.174] 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/1ZduVtigiBR6EiHXqc1zFscltD8 Cc: Michael Richardson , Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 04 Aug 2014 18:52:52 -0000 Hi Ralph: This is exactly section 3.=20 The section provides a scope of applicability (the RPL domain) and the chan= ges from RFC 6437 that become acceptable within that scope. Cheers, Pascal > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: lundi 4 ao=FBt 2014 20:11 > To: Pascal Thubert (pthubert) > Cc: Routing Over Low power and Lossy networks; Michael Richardson; > ipv6@ietf.org > Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 >=20 >=20 > On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) > wrote: >=20 > > The change is now done, Ralph. > > > > The only difference between draft-thubert-6man-flow-label-for-rpl-03 > > and draft-thubert-6man-flow-label-for-rpl-04 is > > > > Updates: 6437 (if approved) >=20 > I suggest adding a section to your doc that explains exactly what is bein= g > updated in RFC 6437. >=20 > - Ralph >=20 > > > > Cheers, > > > > Pascal > > > > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ralph Droms > > Sent: samedi 2 ao=FBt 2014 22:57 > > To: Routing Over Low power and Lossy networks > > Cc: Michael Richardson; ipv6@ietf.org > > Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 > > > > > > > > On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)" > wrote: > > That sounds right, Michael, > > > > I agree that "updates 6437" is a right thing to do. > > > > though slightly on the overkill side. > > > > I disagree that it is overkill. In my opinion, draft-thubert-6man-flow= -label- > for-RPL pretty clearly contradicts RFC 6437, so "updates 6437" is an > appropriate action. > > > > And this is consistent with what Brian suggested. This can be added du= ring > the rfc editor process I expect? > > > > It should be added as soon as possible, certainly before it goes to the= IESG. > In my opinion, the change might warrant a new or extended WGLC; that > action is up to the chairs, of course. > > > > - Ralph > > > > > > Pascal > > > > Le 2 ao=FBt 2014 =E0 21:09, "Michael Richardson" a > =E9crit : > > > > > > Pascal Thubert (pthubert) wrote: > > OTOH you need to understand that there is no need for a bis to update > > a MUST in an RFC. We recognize the imperfection in our work and are > > always ready to revise and amend after due consideration. > > > > Perhaps this document UPDATES 6437 then? > > > > -- > > Michael Richardson , Sandelman Software > Works > > -=3D IPv6 IoT consulting =3D- > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Aug 4 12:44:19 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5FF1A0305; Mon, 4 Aug 2014 12:44:17 -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 XdxeDzmfmnbA; Mon, 4 Aug 2014 12:44:14 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651581A0301; Mon, 4 Aug 2014 12:44:14 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id m5so7281111qaj.21 for ; Mon, 04 Aug 2014 12:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5Ltqlyh35MTWx9l+txl8Yu3tfNwVBN+BV3dzh9maHCg=; b=bmWTi+UGjnODlRNMhXtkYOYqayx3PK3zs5Pcpvy7lF09rHct8jTxt8Aw/hl+3Aa3jj HHCFAgXiQvuy67AEKWzFupReHjfYwCWGmlUMNcr9wo3ooYW9YnV5UxyIJHsiF1LQNmtv +ywjeM+lvjsRSLlu1rxRGNUUvhaen1/ICfealo1Xj3MXVuwa53NTH0CiWnVQpYmrnPiQ GEMavom8EJnzogXOc/K//o6cqanQBX035y5K0Ksrxt6LO7E8W9S6Idux06xYb07MgtvH uqYr9eoGFF+IjIMjdJ/v0ty232i3qiIr/mEj5nPGDbKHIET/xZHdxLSasBX7BGsTBCOh VH4Q== X-Received: by 10.140.17.81 with SMTP id 75mr37557788qgc.36.1407181453580; Mon, 04 Aug 2014 12:44:13 -0700 (PDT) Received: from [10.82.101.21] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id f92sm20246655qgd.44.2014.08.04.12.44.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 12:44:12 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: Date: Mon, 4 Aug 2014 15:44:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <00DFB20D-0A21-4AB7-B56B-F0E0F6DC01B3@gmail.com> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/CosD1xgIJFb2-08vSETBFmtMfQg Cc: Michael Richardson , Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 04 Aug 2014 19:44:17 -0000 On Aug 4, 2014, at 2:52 PM 8/4/14, Pascal Thubert (pthubert) = wrote: > Hi Ralph: >=20 > This is exactly section 3.=20 >=20 > The section provides a scope of applicability (the RPL domain) and the = changes from RFC 6437 that become acceptable within that scope. I disagree. Section 3 explains how = draft-thubert-6man-flow-label-for-rpl can be interpreted as following = RFC 6437 rather than describing the specific ways in which it updates = RFC 6437. For example, as Philip wrote: > "but the RFC also indicates a violation to the rule can be accepted = for compelling reasons, and that security is a case justifying such a = violation. This specification suggests that energy-saving is another = compelling reason for a violation to the aforementioned rule." >=20 > This is *not* what 6437 says. It says for compelling operational = security reasons, not compelling reasons, of which one case is security. - Ralph >=20 > Cheers, >=20 > Pascal >=20 >> -----Original Message----- >> From: Ralph Droms [mailto:rdroms.ietf@gmail.com] >> Sent: lundi 4 ao=FBt 2014 20:11 >> To: Pascal Thubert (pthubert) >> Cc: Routing Over Low power and Lossy networks; Michael Richardson; >> ipv6@ietf.org >> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 >>=20 >>=20 >> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) >> wrote: >>=20 >>> The change is now done, Ralph. >>>=20 >>> The only difference between draft-thubert-6man-flow-label-for-rpl-03 >>> and draft-thubert-6man-flow-label-for-rpl-04 is >>>=20 >>> Updates: 6437 (if approved) >>=20 >> I suggest adding a section to your doc that explains exactly what is = being >> updated in RFC 6437. >>=20 >> - Ralph >>=20 >>>=20 >>> Cheers, >>>=20 >>> Pascal >>>=20 >>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ralph Droms >>> Sent: samedi 2 ao=FBt 2014 22:57 >>> To: Routing Over Low power and Lossy networks >>> Cc: Michael Richardson; ipv6@ietf.org >>> Subject: Re: [Roll] WGLC for = draft-thubert-6man-flow-label-for-rpl-03 >>>=20 >>>=20 >>>=20 >>> On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)" >> wrote: >>> That sounds right, Michael, >>>=20 >>> I agree that "updates 6437" is a right thing to do. >>>=20 >>> though slightly on the overkill side. >>>=20 >>> I disagree that it is overkill. In my opinion, = draft-thubert-6man-flow-label- >> for-RPL pretty clearly contradicts RFC 6437, so "updates 6437" is an >> appropriate action. >>>=20 >>> And this is consistent with what Brian suggested. This can be added = during >> the rfc editor process I expect? >>>=20 >>> It should be added as soon as possible, certainly before it goes to = the IESG. >> In my opinion, the change might warrant a new or extended WGLC; that >> action is up to the chairs, of course. >>>=20 >>> - Ralph >>>=20 >>>=20 >>> Pascal >>>=20 >>> Le 2 ao=FBt 2014 =E0 21:09, "Michael Richardson" = a >> =E9crit : >>>=20 >>>=20 >>> Pascal Thubert (pthubert) wrote: >>> OTOH you need to understand that there is no need for a bis to = update >>> a MUST in an RFC. We recognize the imperfection in our work and are >>> always ready to revise and amend after due consideration. >>>=20 >>> Perhaps this document UPDATES 6437 then? >>>=20 >>> -- >>> Michael Richardson , Sandelman Software >> Works >>> -=3D IPv6 IoT consulting =3D- >>>=20 >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >=20 From nobody Mon Aug 4 13:44:50 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4790F1A032A; Mon, 4 Aug 2014 13:44:49 -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 RHdXrnJcAgx1; Mon, 4 Aug 2014 13:44:47 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FA01A0326; Mon, 4 Aug 2014 13:44:47 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so10604096pab.15 for ; Mon, 04 Aug 2014 13:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wPBLSy2C94IbG6D+WAf+DkWtT1LLKVBzAuHod1qqHUU=; b=UkEY0hcw3FfJWPBkkdJ1PbbnoJfaqg7rd5zht4lw8K80bkP7nageMF4idhC3HAc91T RSjVEqLBCiLUKBehCVQcCB6Ba2rAyIUjfXPwWpJASk8XoQ/pqbhnhONdDExYYM7tEc+f ijwYtrV3Rxc/gs1tPhl2vUhZcGgwJKgol7cmVY0VnAvopsJhVEa30gNTjTPIvGPVs9sx qkgssKlsIydvY3YREZ6zPfidTGXqqfRVs84VsBPmwAnJNvLG/Sz3TMRElrgiJQJzGAJ6 LvT8jmRzWY7RS+FSEvTWlW5F07Eyq2EHOH6vRIZ1dSRAf0wNaHrYwB8uUK07Uzj0yDiv sY5w== X-Received: by 10.66.66.101 with SMTP id e5mr6021587pat.100.1407185086836; Mon, 04 Aug 2014 13:44:46 -0700 (PDT) Received: from [192.168.178.23] (202.195.69.111.dynamic.snap.net.nz. [111.69.195.202]) by mx.google.com with ESMTPSA id ya1sm1352974pbb.91.2014.08.04.13.44.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 13:44:46 -0700 (PDT) Message-ID: <53DFF0BD.8020409@gmail.com> Date: Tue, 05 Aug 2014 08:44:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ralph Droms References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <00DFB20D-0A21-4AB7-B56B-F0E0F6DC01B3@gmail.com> In-Reply-To: <00DFB20D-0A21-4AB7-B56B-F0E0F6DC01B3@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/roll/TKdkEWq5vRNa3WXzkAWgOBSeYwY Cc: Michael Richardson , "ipv6@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 04 Aug 2014 20:44:49 -0000 Ralph, On 05/08/2014 07:44, Ralph Droms wrote: > On Aug 4, 2014, at 2:52 PM 8/4/14, Pascal Thubert (pthubert) wrote: >=20 >> Hi Ralph: >> >> This is exactly section 3.=20 >> >> The section provides a scope of applicability (the RPL domain) and the= changes from RFC 6437 that become acceptable within that scope. >=20 > I disagree. Section 3 explains how draft-thubert-6man-flow-label-for-r= pl can be interpreted as following RFC 6437 rather than describing the sp= ecific ways in which it updates RFC 6437. >=20 > For example, as Philip wrote: >=20 >> "but the RFC also indicates a violation to the rule can be accepted fo= r compelling reasons, and that security is a case justifying such a viola= tion. This specification suggests that energy-saving is another compelli= ng reason for a violation to the aforementioned rule." >> > This is *not* what 6437 says. It says for compelling operational securi= ty reasons, not compelling reasons, of which one case is security. It also says that there may be stateful ways of using the flow label. It's almost a matter of taste whether the RPL usage is a change to the phrase that you quote, or a stateful usage within an RPL domain (reverting to stateless use when leaving RPL). I agree that the draft could usefully be explicit about this. Brian >=20 > - Ralph >=20 >=20 >> Cheers, >> >> Pascal >> >>> -----Original Message----- >>> From: Ralph Droms [mailto:rdroms.ietf@gmail.com] >>> Sent: lundi 4 ao=C3=BBt 2014 20:11 >>> To: Pascal Thubert (pthubert) >>> Cc: Routing Over Low power and Lossy networks; Michael Richardson; >>> ipv6@ietf.org >>> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03= >>> >>> >>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) >>> wrote: >>> >>>> The change is now done, Ralph. >>>> >>>> The only difference between draft-thubert-6man-flow-label-for-rpl-03= >>>> and draft-thubert-6man-flow-label-for-rpl-04 is >>>> >>>> Updates: 6437 (if approved) >>> I suggest adding a section to your doc that explains exactly what is = being >>> updated in RFC 6437. >>> >>> - Ralph >>> >>>> Cheers, >>>> >>>> Pascal >>>> >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ralph Droms >>>> Sent: samedi 2 ao=C3=BBt 2014 22:57 >>>> To: Routing Over Low power and Lossy networks >>>> Cc: Michael Richardson; ipv6@ietf.org >>>> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-0= 3 >>>> >>>> >>>> >>>> On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)" >>> wrote: >>>> That sounds right, Michael, >>>> >>>> I agree that "updates 6437" is a right thing to do. >>>> >>>> though slightly on the overkill side. >>>> >>>> I disagree that it is overkill. In my opinion, draft-thubert-6man-f= low-label- >>> for-RPL pretty clearly contradicts RFC 6437, so "updates 6437" is an >>> appropriate action. >>>> And this is consistent with what Brian suggested. This can be added = during >>> the rfc editor process I expect? >>>> It should be added as soon as possible, certainly before it goes to = the IESG. >>> In my opinion, the change might warrant a new or extended WGLC; that >>> action is up to the chairs, of course. >>>> - Ralph >>>> >>>> >>>> Pascal >>>> >>>> Le 2 ao=C3=BBt 2014 =C3=A0 21:09, "Michael Richardson" a >>> =C3=A9crit : >>>> >>>> Pascal Thubert (pthubert) wrote: >>>> OTOH you need to understand that there is no need for a bis to updat= e >>>> a MUST in an RFC. We recognize the imperfection in our work and are >>>> always ready to revise and amend after due consideration. >>>> >>>> Perhaps this document UPDATES 6437 then? >>>> >>>> -- >>>> Michael Richardson , Sandelman Software >>> Works >>>> -=3D IPv6 IoT consulting =3D- >>>> >>>> >>>> >>>> --------------------------------------------------------------------= >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> --------------------------------------------------------------------= >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Mon Aug 4 15:53:03 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BF71A03D0 for ; Mon, 4 Aug 2014 15:53:00 -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 MegwYOVhpdjl for ; Mon, 4 Aug 2014 15:52:59 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0101A03CD for ; Mon, 4 Aug 2014 15:52:58 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id le20so202466vcb.14 for ; Mon, 04 Aug 2014 15:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=nCb5Jk3WMN8pfjcCcE76bGKTW0eSkRdfLN0H5Ec9nlI=; b=zoYAa6qylaT0cWyqTwlCgllPoM97Sv1YNNNEVbbwxCvjVQZrjPSD4FmBEceNE9UbrD GRXm/naRUq9igDdqWgG+RBqiS448wZgh62MLo7k3m+DaqmyZK6ZFt57B4g6nMsmiCvy5 FszYMdSPSC7BCSaif8PPIvXFwbkrjkry0A4jFK1dRveMYKX6mQ/gSL+/4O9ZHxy2pyh5 el9i109X37sBMl3SWNKqjHUyiHmcK1bdSaP2kXysVFGHVRBZA69yPywFK9sL41g841tZ /spYxpDj/rDYnC/QCSLgBA+g+22lcyPYZlR65lLARTwQLiyRbr5DZfaHfAQT2ddTZv/9 qUxA== MIME-Version: 1.0 X-Received: by 10.220.175.194 with SMTP id bb2mr21113233vcb.40.1407192777935; Mon, 04 Aug 2014 15:52:57 -0700 (PDT) Received: by 10.220.58.69 with HTTP; Mon, 4 Aug 2014 15:52:57 -0700 (PDT) Date: Tue, 5 Aug 2014 01:52:57 +0300 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=089e015386e4a8d60604ffd599d4 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HFisU_DSKdvkxZLTuEilu4bHI4Y Cc: Michael Richardson Subject: [Roll] Minutes - IETF 90 - ROLL- 08-23-2014 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, 04 Aug 2014 22:53:00 -0000 --089e015386e4a8d60604ffd599d4 Content-Type: text/plain; charset=UTF-8 Dear all, Please find the minutes of the IETF 90 meeting here http://www.ietf.org/proceedings/90/minutes/minutes-90-roll Please any comments are very welcome. The final version of the minutes are due 2014-09-05. Thank you in advance, Michael and Ines --089e015386e4a8d60604ffd599d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Please find the minutes of th= e IETF 90 meeting here


Please any comments are very welcome.=C2=A0The fi= nal version of the minutes are due 2014-09-05.

Tha= nk you in advance,

Michael and Ines
--089e015386e4a8d60604ffd599d4-- From nobody Mon Aug 4 17:19:02 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 3FED81A0AB5; Mon, 4 Aug 2014 17:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Vakddq1MdTs; Mon, 4 Aug 2014 17:18:58 -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 AC76C1A0010; Mon, 4 Aug 2014 17:18:58 -0700 (PDT) Received: from [76.14.66.110] (port=52151 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XESSv-00019f-5Q; Mon, 04 Aug 2014 17:18:57 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: <53DFF0BD.8020409@gmail.com> Date: Mon, 4 Aug 2014 17:18:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0DC174C1-1D60-4A4B-97E0-064B7971CB7F@cs.stanford.edu> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <00DFB20D-0A21-4AB7-B56B-F0E0F6DC01B3@gmail.com> <53DFF0BD.8020409@gmail.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae Archived-At: http://mailarchive.ietf.org/arch/msg/roll/akI8C62fbhPvpG5K1EYrZXdRSOg Cc: Michael Richardson , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 05 Aug 2014 00:19:00 -0000 On Aug 4, 2014, at 1:44 PM, Brian E Carpenter = wrote: > It also says that there may be stateful ways of using the flow label. > It's almost a matter of taste whether the RPL usage is a change to > the phrase that you quote, or a stateful usage within an RPL domain > (reverting to stateless use when leaving RPL). I agree that the draft > could usefully be explicit about this. I'm a bit confused -- the MUST statement is in Section 2, entitled "IPv6 = Flow Label Specification". There doesn't seem to be any text that = suggests this restriction is dependent on stateless operation. My = interpretation, based on the title and its placement in the document, is = that the text in this section applies to any and all uses of the flow = label. How am I reading this wrong? Should I be reading the final MUST = ("=85 MUST choose labels that conform to Section 3 of this = specification") in Section 4 to implicitly mean that Section 2 doesn't = necessarily apply? Or is it optional for stateless as well? My (admittedly naive) reading is that Sections 3 and 4 related to how = source nodes choose a flow label. (S2: "To enable Flow-Label-based = classification, source nodes SHOULD assign each unrelated transport = connection and application data stream to a new flow.") This is = distinct from what forwarding nodes do to flow labels, which Section 2 = covers.=20 Phil From nobody Mon Aug 4 18:06:55 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E251A0ACC; Mon, 4 Aug 2014 18:06:50 -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 76Wz-vSjlwEk; Mon, 4 Aug 2014 18:06:48 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBC01A0ACB; Mon, 4 Aug 2014 18:06:48 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so321625pab.16 for ; Mon, 04 Aug 2014 18:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=q3omwt7IwTjZ2G84U2AQvkDRX6XjIWAp8WbO3+0v+Pw=; b=yG8rrpJHwVj/2VilCTgFCElebPRdky9FV3pqiOYxzQtUTIceIDFE1F7/HAOBG9BKrP cNBhAchk+n/97fuILhXrcV15bsca4dvy4b0DQqcPTUO28gAyutT+3n3AAS3ILs516BzF 0EdCZW6GgOE34xE6I1HvRMFwzAEC0NMd5ozCG4ig9uwFMUm191eOUHk/9oRT6jcsY3s2 TQf1p+41jovPHqb4EZSeEbtTYQtv4q31g8FEDA1DdICkQZ4LBjx18/WCIs35NNyk28TQ QA491yO4U8yZ/J22ypYmWHrfBfEW05Vg8Sj8R8GVJiZQKTTeNOpbdzY4Z+XTyaVL5iAY Q2qg== X-Received: by 10.68.87.101 with SMTP id w5mr418371pbz.130.1407200807284; Mon, 04 Aug 2014 18:06:47 -0700 (PDT) Received: from [192.168.178.23] (202.195.69.111.dynamic.snap.net.nz. [111.69.195.202]) by mx.google.com with ESMTPSA id up2sm115836pbc.21.2014.08.04.18.06.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 18:06:46 -0700 (PDT) Message-ID: <53E02E25.2030701@gmail.com> Date: Tue, 05 Aug 2014 13:06:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Levis References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <00DFB20D-0A21-4AB7-B56B-F0E0F6DC01B3@gmail.com> <53DFF0BD.8020409@gmail.com> <0DC174C1-1D60-4A4B-97E0-064B7971CB7F@cs.stanford.edu> In-Reply-To: <0DC174C1-1D60-4A4B-97E0-064B7971CB7F@cs.stanford.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/roll/0R6UtaWOUpsMgs9dimIE8MJxXGI Cc: Michael Richardson , Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 05 Aug 2014 01:06:50 -0000 Philip, On 05/08/2014 12:18, Philip Levis wrote: > On Aug 4, 2014, at 1:44 PM, Brian E Carpenter wrote: >=20 >> It also says that there may be stateful ways of using the flow label. >> It's almost a matter of taste whether the RPL usage is a change to >> the phrase that you quote, or a stateful usage within an RPL domain >> (reverting to stateless use when leaving RPL). I agree that the draft >> could usefully be explicit about this. >=20 > I'm a bit confused -- the MUST statement is in Section 2, entitled "IPv= 6 Flow Label Specification". There doesn't seem to be any text that sugge= sts this restriction is dependent on stateless operation. My interpretati= on, based on the title and its placement in the document, is that the tex= t in this section applies to any and all uses of the flow label. How am I= reading this wrong? Should I be reading the final MUST ("=E2=80=A6 MUST = choose labels that conform to Section 3 of this specification") in Sectio= n 4 to implicitly mean that Section 2 doesn't necessarily apply? Or is it= optional for stateless as well? I think you're right that it could have been worded more precisely. My personal mental model has always included something like the RPL application (i.e. a specific usage of the flow label within a closed domain) *and* generic stateless use by default, but I don't think that model has ever been the general consensus, so what is supposed to happen at the boundary between such a closed domain and the rest of the Internet has never been written down. Brian > My (admittedly naive) reading is that Sections 3 and 4 related to how s= ource nodes choose a flow label. (S2: "To enable Flow-Label-based classif= ication, source nodes SHOULD assign each unrelated transport connection a= nd application data stream to a new flow.") This is distinct from what f= orwarding nodes do to flow labels, which Section 2 covers.=20 >=20 > Phil >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue Aug 5 01:11: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 B88891B292D; Tue, 5 Aug 2014 01:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 x63rRy_OJ2NG; Tue, 5 Aug 2014 01:11:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133E21B292C; Tue, 5 Aug 2014 01:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2141; q=dns/txt; s=iport; t=1407226293; x=1408435893; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GLhN0aA6RY2A+DdFY9yxHXOiL44gy6konrHxwjuhaSg=; b=EygSvjm/f5tPINH9WztVp5NR1Gmo2KC6JFIlRtUSgAT2usQI7fUkb/dz WJOzGUkv9ngm6YxARBuSwgyJVWlsRb+9XQPP+vVRI5emRaH6lXG3BXjVo sxxEOSGoH18dErKRuLvL5/FlnJa0y0me77vXcItdQjdip56axtPZo+O+4 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAICQ4FOtJA2D/2dsb2JhbABbDoJ/gSkE0zABgRUWd4QDAQEBBHkMBAIBCA4DBAEBAQodByERFAkIAQEEAQ0FCIgmAxG8OQ2GYxeNH4FWCR0xBwaDKYEcAQSKVY8tkD6GKIMLQmyBBUE X-IronPort-AV: E=Sophos;i="5.01,804,1400025600"; d="scan'208";a="345162482" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 05 Aug 2014 08:11:32 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s758BVx3005452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 08:11:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 5 Aug 2014 03:11:31 -0500 From: "Pascal Thubert (pthubert)" To: Philip Levis , Ralph Droms Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAAAz3YlABynPRA= Date: Tue, 5 Aug 2014 08:11:30 +0000 Deferred-Delivery: Tue, 5 Aug 2014 08:11:00 +0000 Message-ID: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> In-Reply-To: <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.75.33] 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/l-XPu3-dVkfi7yTqckZetL8pdlg Cc: Michael Richardson , Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 05 Aug 2014 08:11:40 -0000 I think I see what you are saying, Phil. I can split 1.3 to isolate the deviations to 6437. I also need to move the following text from section 3 in that new section=20 This may seem contradictory with the IPv6 Flow Label Specification [RFC6437] which stipulates that once it is set, the Flow Label is left unchanged; but the RFC also indicates a violation to the rule can be accepted for compelling reasons, and that security is a case justifying such a violation. This specification suggests that energy-saving is another compelling reason for a violation to the aforementioned rule. Proposed update for that text: This specification updates the IPv6 Flow Label Specification [RFC6437], which stipulates that once it is set, the Flow Label is left unchanged. [RFC6437] also indicates that=20 a violation to the rule can be accepted for compelling reasons,=20 but limit those compelling reasons to security related issues. This specification indicates that energy-saving is another compelling reason that justifies a violation to the aforementioned rule. What do you think? Cheers, Pascal > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: lundi 4 ao=FBt 2014 20:23 > To: Ralph Droms > Cc: Pascal Thubert (pthubert); Michael Richardson; Routing Over Low power > and Lossy networks; ipv6@ietf.org > Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 >=20 >=20 > On Aug 4, 2014, at 11:10 AM, Ralph Droms wrote: >=20 > > > > On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) > wrote: > > > >> The change is now done, Ralph. > >> > >> The only difference between draft-thubert-6man-flow-label-for-rpl-03 a= nd > draft-thubert-6man-flow-label-for-rpl-04 is > >> > >> Updates: 6437 (if approved) > > > > I suggest adding a section to your doc that explains exactly what is be= ing > updated in RFC 6437. > > > > - Ralph >=20 >=20 > I agree. I think some of the text in 1.3 can be re-used for this purpose. >=20 > Phil From nobody Tue Aug 5 10:18:51 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90EA1A0453; Tue, 5 Aug 2014 10:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, 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 xcWHVeKYF15p; Tue, 5 Aug 2014 10:18:47 -0700 (PDT) Received: from relay.iisc.ernet.in (relay.iisc.ernet.in [203.200.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id 929B01A0439; Tue, 5 Aug 2014 10:18:44 -0700 (PDT) Received: from ece.iisc.ernet.in (mail.ece.iisc.ernet.in [10.32.1.10]) by relay.iisc.ernet.in (8.14.4/8.14.4) with ESMTP id s75HIRT0031589; Tue, 5 Aug 2014 22:48:27 +0530 Received: from [10.3.1.91] ([10.3.1.91]) by ece.iisc.ernet.in (8.13.6/8.13.6/SuSE Linux 0.8) with ESMTP id s75HHGBM032391; Tue, 5 Aug 2014 22:47:16 +0530 References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1E250FB9-1BBD-4074-9296-C269D6C409D7@ece.iisc.ernet.in> X-Mailer: iPad Mail (11B651) From: Anand SVR Date: Tue, 5 Aug 2014 22:48:25 +0530 To: Routing Over Low power and Lossy networks X-IISc-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: s75HIRT0031589 X-IISc-MailScanner: Found to be clean X-IISc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.899, required 6.5, autolearn=not spam, BAYES_00 -1.90, MIME_QP_LONG_LINE 0.00) X-IISc-MailScanner-From: anand@ece.iisc.ernet.in Archived-At: http://mailarchive.ietf.org/arch/msg/roll/syb_7Ve0mVTjHX5oK9CN_66XQc8 Cc: Michael Richardson , Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 05 Aug 2014 17:18:51 -0000 Hi, The discussion has been very interesting, more so because it is bordering o= n the legality of the usage of the word MUST. I agree with Philip's take on= this. But after reading the RFC, I got this impression that the RFC meant = to be a facility or a feature with certain usage guidelines. The MUST usage= is more to imply stronger than SHOULD so as to discourage people from modi= fying it. I suppose at the time of writing, the authors might not have fore= seen that in some point in future the value can be changed for other reason= s. Therefore the use of MUST MUST be taken with the right spirit it is mean= t to be taken rather than literally :)=20 Anand > On 05-Aug-2014, at 1:41 pm, "Pascal Thubert (pthubert)" wrote: >=20 > I think I see what you are saying, Phil. >=20 > I can split 1.3 to isolate the deviations to 6437. >=20 > I also need to move the following text from section 3 in that new section= =20 >=20 > This may seem contradictory with the IPv6 > Flow Label Specification [RFC6437] which stipulates that once it is > set, the Flow Label is left unchanged; but the RFC also indicates a > violation to the rule can be accepted for compelling reasons, and > that security is a case justifying such a violation. This > specification suggests that energy-saving is another compelling > reason for a violation to the aforementioned rule. >=20 > Proposed update for that text: >=20 > This specification updates the IPv6 > Flow Label Specification [RFC6437], which stipulates that once it is > set, the Flow Label is left unchanged. [RFC6437] also indicates that=20 > a violation to the rule can be accepted for compelling reasons,=20 > but limit those compelling reasons to security related issues. This > specification indicates that energy-saving is another compelling > reason that justifies a violation to the aforementioned rule. >=20 > What do you think? >=20 > Cheers, >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> Sent: lundi 4 ao=C3=BBt 2014 20:23 >> To: Ralph Droms >> Cc: Pascal Thubert (pthubert); Michael Richardson; Routing Over Low power >> and Lossy networks; ipv6@ietf.org >> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 >>=20 >>=20 >>> On Aug 4, 2014, at 11:10 AM, Ralph Droms wrote: >>>=20 >>>=20 >>>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) >>> wrote: >>>=20 >>>> The change is now done, Ralph. >>>>=20 >>>> The only difference between draft-thubert-6man-flow-label-for-rpl-03 a= nd >> draft-thubert-6man-flow-label-for-rpl-04 is >>>>=20 >>>> Updates: 6437 (if approved) >>>=20 >>> I suggest adding a section to your doc that explains exactly what is be= ing >> updated in RFC 6437. >>>=20 >>> - Ralph >>=20 >>=20 >> I agree. I think some of the text in 1.3 can be re-used for this purpose. >>=20 >> Phil >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > --=20 > 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. From nobody Tue Aug 5 21:57:48 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA3E1B280C; Tue, 5 Aug 2014 21:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRdRm7y9aNfl; Tue, 5 Aug 2014 21:57:38 -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 1CF681B280E; Tue, 5 Aug 2014 21:57:35 -0700 (PDT) Received: from [76.14.66.110] (port=57734 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XEtI3-0005Zz-MS; Tue, 05 Aug 2014 21:57:34 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: <1E250FB9-1BBD-4074-9296-C269D6C409D7@ece.iisc.ernet.in> Date: Tue, 5 Aug 2014 21:57:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <1E250FB9-1BBD-4074-9296-C269D6C409D7@ece.iisc.ernet.in> To: Anand SVR X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 5d5bd4b8133540f30bea22ef470d169d Archived-At: http://mailarchive.ietf.org/arch/msg/roll/pXsrpZQXU64uDAb2tV2Z8ItTwLg Cc: Michael Richardson , Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 04:57:43 -0000 I totally agree that the document leaves the question open of whether = there could be future uses. The use of the flow label in that way = doesn't go against the spirit of the document and so we shouldn't reject = the idea out of principle. But it does go against the letter of the = document -- hence the need for an Updates: or other explicit note that = this is the case. Phil On Aug 5, 2014, at 10:18 AM, Anand SVR wrote: > Hi, >=20 > The discussion has been very interesting, more so because it is = bordering on the legality of the usage of the word MUST. I agree with = Philip's take on this. But after reading the RFC, I got this impression = that the RFC meant to be a facility or a feature with certain usage = guidelines. The MUST usage is more to imply stronger than SHOULD so as = to discourage people from modifying it. I suppose at the time of = writing, the authors might not have foreseen that in some point in = future the value can be changed for other reasons. Therefore the use of = MUST MUST be taken with the right spirit it is meant to be taken rather = than literally :)=20 >=20 > Anand >=20 >=20 >> On 05-Aug-2014, at 1:41 pm, "Pascal Thubert (pthubert)" = wrote: >>=20 >> I think I see what you are saying, Phil. >>=20 >> I can split 1.3 to isolate the deviations to 6437. >>=20 >> I also need to move the following text from section 3 in that new = section=20 >>=20 >> This may seem contradictory with the IPv6 >> Flow Label Specification [RFC6437] which stipulates that once it is >> set, the Flow Label is left unchanged; but the RFC also indicates a >> violation to the rule can be accepted for compelling reasons, and >> that security is a case justifying such a violation. This >> specification suggests that energy-saving is another compelling >> reason for a violation to the aforementioned rule. >>=20 >> Proposed update for that text: >>=20 >> This specification updates the IPv6 >> Flow Label Specification [RFC6437], which stipulates that once it is >> set, the Flow Label is left unchanged. [RFC6437] also indicates that=20= >> a violation to the rule can be accepted for compelling reasons,=20 >> but limit those compelling reasons to security related issues. This >> specification indicates that energy-saving is another compelling >> reason that justifies a violation to the aforementioned rule. >>=20 >> What do you think? >>=20 >> Cheers, >>=20 >> Pascal >>=20 >>=20 >>> -----Original Message----- >>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>> Sent: lundi 4 ao=FBt 2014 20:23 >>> To: Ralph Droms >>> Cc: Pascal Thubert (pthubert); Michael Richardson; Routing Over Low = power >>> and Lossy networks; ipv6@ietf.org >>> Subject: Re: [Roll] WGLC for = draft-thubert-6man-flow-label-for-rpl-03 >>>=20 >>>=20 >>>> On Aug 4, 2014, at 11:10 AM, Ralph Droms = wrote: >>>>=20 >>>>=20 >>>>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) >>>> wrote: >>>>=20 >>>>> The change is now done, Ralph. >>>>>=20 >>>>> The only difference between = draft-thubert-6man-flow-label-for-rpl-03 and >>> draft-thubert-6man-flow-label-for-rpl-04 is >>>>>=20 >>>>> Updates: 6437 (if approved) >>>>=20 >>>> I suggest adding a section to your doc that explains exactly what = is being >>> updated in RFC 6437. >>>>=20 >>>> - Ralph >>>=20 >>>=20 >>> I agree. I think some of the text in 1.3 can be re-used for this = purpose. >>>=20 >>> Phil >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >> --=20 >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >>=20 >=20 > --=20 > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. >=20 From nobody Thu Aug 7 02:18:54 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DACE1B2A1E; Thu, 7 Aug 2014 02:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 FSINBby3URKa; Thu, 7 Aug 2014 02:18:50 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87DC1B2966; Thu, 7 Aug 2014 02:18:49 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s779Ik24022668; Thu, 7 Aug 2014 10:18:47 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s779Ie7b022554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 10:18:40 +0100 From: "Adrian Farrel" To: , , Date: Thu, 7 Aug 2014 10:18:44 +0100 Message-ID: <00e501cfb220$96ec9b60$c4c5d220$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+yIJXnSb9CvN3lQke+XTLssv1IYg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20864.006 X-TM-AS-Result: No--40.121-10.0-31-10 X-imss-scan-details: No--40.121-10.0-31-10 X-TMASE-MatchedRID: D2G27ZgZra/YMEqhScrQBUhEDfw/93BuH181YDtIVapF+YXPIqAdvrMj 3GAElQGEHWONFZT/prr3YiuFkZiOxGResrHRY7dK8eSmTJSmEv2S3G9UxpYxsMoNup+2nV/XmkL u0+871bV2HZRu5knIkaCQCfo/jPYbVd/GARVyJ51GypC5CVFOH978NWlYojkr2viB/Jr4D1TNCc A6Zdzj70jpvQu/TgjHcP8NoorbT3V1KobyH4zskSe1T5r1VA3IyeUl7aCTy8jczkKO5k4APhZZd YKgpK9DdxS9fNW9kSZLqpudr4MRIM/BlZO+W2WhtNMyJ72jQd22awxxVfk3ByWy0DEOFuGQ3ogi kAEqSiqRLq2ylp66OeDz4wU7tmbcvXtlm87JVdowiJTf3kjwfaGuPOIOnqBBS5TspQkQ8sGOytA lmFixKqYoxrZu+cZeaw6jvnhkER4dSjum6JPhtyZm6wdY+F8KguwtqyXlE6EhvFjBsLEZNEJb3b 5D8E1yCs950MJfLPLBdLgSSOxM9wnW8iiCcRSGiFoorQjboWkZYA38gj3BxOVs8DNq02hCeIJ7x 1WhBehKW3Ex8kbLqbLDlVGk98URY+SEAY1Jo3eJQ9k+Ypk5CcLiFiL0BG1uEd+K6O5Nt53zb5km gp405bfqHaErmu92kZOl7WKIImq0P2qkGU0XylZ0V5tYhzdWxEHRux+uk8jpP8tMOyYmaA== Archived-At: http://mailarchive.ietf.org/arch/msg/roll/izbWuWbR5QKRzibIRUgE9x7-ZAY Subject: [Roll] FW: [Anima] ANIMA draft charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 09:18:52 -0000 Please excuse the spam. There is a discussion about forming a working group for autonomic networking that may be of interest to a number of you. Please continue the discussion on the ANIMA mailing list (i.e., not here!) Thanks, Adrian > -------- Original Message -------- > Subject: [Anima] ANIMA draft charter > Date: Tue, 5 Aug 2014 08:19:15 +0000 > From: Michael Behringer (mbehring) > To: anima@ietf.org > > At the BoF in Toronto there was rough consensus to continue the work on an > autonomic infrastructure. Brian, Sheng, Toerless, > Laurent and I have now drafted a potential WG charter with the input of our ADs. > Note that this is not yet a formal charter > proposal, it's for discussion only so far. > > The assumption is that more general aspects of autonomics will continue to be > discussed in the NMRG group. > > If we were to go ahead with a WG, the goal would be to focus on realistic > deliverables. So the plan is to start with a small, > achievable set of deliverables, and, if successful and useful, expand after re- > chartering. > > Please comment here on this draft charter proposal. > > Thanks, > Michael > > > Autonomic Networking Integrated Model and Approach (ANIMA) WG > > Description of Working Group > > Autonomic Networking focuses on self-management of network elements. An > autonomic function works in a distributed way across > various network elements, allowing however central guidance and reporting. > Autonomic functions already exist today, for example > IGP routing protocols such as OSPF. However, all such functions have their own > discovery, transport, messaging and security > mechanisms. > > To transform the somewhat abstract Autonomic Networking concept into > concrete, realisable requirements, the first stage, > undertaken in the Network Management Research Group (NMRG) of the IRTF, > was to define terminology and design goals, and to > derive a high-level gap analysis. The definitions and design goals, as well as a > simple architecture model are defined in > draft-irtf-nmrg-autonomic-network-definitions; the gap analysis for AN is > described in draft-irtf-nmrg-an-gap-analysis. The UCAN > BoF at IETF 90 discussed use cases and some existing solutions. All the above > work serves as a baseline for this working group. > > This working group defines solutions for an initial set of components of an > autonomic networking infrastructure, based on the > simple architecture and design goals defined in draft-irtf-nmrg-autonomic- > network-definitions. Future work may include a more > detailed systems architecture to support the development of autonomic service > agents. The Anima working group will initially > focus on enterprise, ISP networks and IoT. > > The solutions target to cover the following areas: > o identity of nodes > o common security model > o discovery model > o negotiation model > o a secure and logically separated communications channel > o an example for an autonomic management model > > The goals of this working group are: > > o Definition of a generic discovery and negotiation protocol for autonomic > functions > Starting point: draft-jiang-config-negotiation-protocol > o Definition of a mechanism to bootstrap a trust infrastructure > Starting point: draft-pritikin-bootstrapping-keyinfrastructures > o Definition of an logically separated Autonomic Control Plane > Starting point: draft-behringer-autonomic-control-plane > > In addition, autonomic service agents will need to be defined for specific use > cases. The working group will initially consider > one simple example as a test case for further work. > > o Definition of > Starting point: draft-use-case-tbd > > The initial set of work items is limited to the above list to stay focused and avoid > "boiling the ocean". Additional documents > concerning policy intent, other autonomic infrastructure components, use cases > or autonomic service agents are strongly > encouraged, as individual submissions, but are not planned as working group > deliverables for now. No additional work items will > be accepted in the working group without re-chartering. > > Milestones > > Nov 2014 - WG formation and adoption of drafts > - Mar IETF - > Jun 2015 - WGLC for draft-generic-discovery-negotiation-protocol > - Jul IETF - > Aug 2015 - submit draft-generic-discovery-negotiation-protocol to IESG > (standards track) > Oct 2015 - WGLC draft-keyinfrastructure-bootstrap > Oct 2015 - WGLC draft-use-case-tbd > - Nov IETF - > Dec 2015 - submit draft-keyinfrastructure-bootstrap to IESG (standards track) > Dec 2015 - submit draft-use-case-tbd to IESG (standards track) > Jan 2016 - WGLC draft-autonomic-common-control-plane > - Mar IETF - > Apr 2016 - submit draft-autonomic-common-control-plane to IESG (standards > track) > Jul 2016 - recharter if needed, or close > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Aug 7 04:32: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 8DD911B27E5; Thu, 7 Aug 2014 03:35:00 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eUFQTN2Ft5t; Thu, 7 Aug 2014 03:34:57 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1B81A00EA; Thu, 7 Aug 2014 03:34:57 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 4777EA6B5A27B; Thu, 7 Aug 2014 10:34:53 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s77AYpF4019688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 12:34:54 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 7 Aug 2014 12:34:51 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "adrian@olddog.co.uk" , "routing-discussion@ietf.org" , "manet@ietf.org" , "roll@ietf.org" Thread-Topic: [Anima] ANIMA draft charter Thread-Index: Ac+yIJXnSb9CvN3lQke+XTLssv1IYgAA85og Date: Thu, 7 Aug 2014 10:34:50 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF83234331DF@FR711WXCHMBA07.zeu.alcatel-lucent.com> References: <00e501cfb220$96ec9b60$c4c5d220$@olddog.co.uk> In-Reply-To: <00e501cfb220$96ec9b60$c4c5d220$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] 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/il-hvy6HlZyr3xJ3DCdIMYEDP5k X-Mailman-Approved-At: Thu, 07 Aug 2014 04:32:31 -0700 Subject: Re: [Roll] [Anima] ANIMA draft charter 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, 07 Aug 2014 10:35:00 -0000 Hi Adrian, all Thanks for sharing. Reading this charter, the following statement escapes m= e "Autonomic functions already exist today, for example IGP routing protocols= such as OSPF." I would have said OSPF like any other IGP is adaptive (and from the current= state only -not previous states-) but it is not autonomous: the same input= leads to the same output (decision), i.e., there is no improvement of qual= ity of the decision process over time and on the other hand there is no mea= n by which OSPF can by itself overcome degradation of performance (at best = mitigate if pre-configured to execute fixed sequences for a sub-set of pre-= determined conditions, cf.RFC 4222, so again driven by open control loops). Setting of configurable constants is mainly driven by open control loops. M= oreover individual routers can't make autonomous decisions in terms of area= parameters configuration as all routers belonging to an area must agree on= that area's configuration). Thanks, -dimitri. > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On > Behalf Of Adrian Farrel > Sent: Thursday, August 07, 2014 11:19 AM > To: routing-discussion@ietf.org; manet@ietf.org; roll@ietf.org > Subject: FW: [Anima] ANIMA draft charter >=20 > Please excuse the spam. >=20 > There is a discussion about forming a working group for autonomic > networking that may be of interest to a number of you. >=20 > Please continue the discussion on the ANIMA mailing list (i.e., not here!= ) >=20 > Thanks, > Adrian >=20 > > -------- Original Message -------- > > Subject: [Anima] ANIMA draft charter > > Date: Tue, 5 Aug 2014 08:19:15 +0000 > > From: Michael Behringer (mbehring) > > To: anima@ietf.org > > > > At the BoF in Toronto there was rough consensus to continue the work > > on an autonomic infrastructure. Brian, Sheng, Toerless, Laurent and I > > have now drafted a potential WG charter with the input of our > ADs. > > Note that this is not yet a formal charter proposal, it's for > > discussion only so far. > > > > The assumption is that more general aspects of autonomics will > > continue to be discussed in the NMRG group. > > > > If we were to go ahead with a WG, the goal would be to focus on > > realistic deliverables. So the plan is to start with a small, > > achievable set of deliverables, and, if successful and useful, expand > > after > re- > > chartering. > > > > Please comment here on this draft charter proposal. > > > > Thanks, > > Michael > > > > > > Autonomic Networking Integrated Model and Approach (ANIMA) WG > > > > Description of Working Group > > > > Autonomic Networking focuses on self-management of network elements. > > An autonomic function works in a distributed way across various > > network elements, allowing however central guidance and reporting. > > Autonomic functions already exist today, for example IGP routing > > protocols such as OSPF. However, all such functions have their own > > discovery, transport, messaging and security mechanisms. > > > > To transform the somewhat abstract Autonomic Networking concept into > > concrete, realisable requirements, the first stage, undertaken in the > > Network Management Research Group (NMRG) of the IRTF, was to define > > terminology and design goals, and to derive a high-level gap analysis. > > The definitions and design goals, as well as > a > > simple architecture model are defined in > > draft-irtf-nmrg-autonomic-network-definitions; the gap analysis for AN > > is described in draft-irtf-nmrg-an-gap-analysis. The UCAN BoF at IETF > > 90 discussed use cases and some existing solutions. All the above work > > serves as a baseline for this working group. > > > > This working group defines solutions for an initial set of components > > of an autonomic networking infrastructure, based on the simple > > architecture and design goals defined in draft-irtf-nmrg-autonomic- > > network-definitions. Future work may include a more detailed systems > > architecture to support the development of autonomic service agents. > > The Anima working group will initially focus on enterprise, ISP > > networks and IoT. > > > > The solutions target to cover the following areas: > > o identity of nodes > > o common security model > > o discovery model > > o negotiation model > > o a secure and logically separated communications channel o an example > > for an autonomic management model > > > > The goals of this working group are: > > > > o Definition of a generic discovery and negotiation protocol for > > autonomic functions > > Starting point: draft-jiang-config-negotiation-protocol > > o Definition of a mechanism to bootstrap a trust infrastructure > > Starting point: draft-pritikin-bootstrapping-keyinfrastructures > > o Definition of an logically separated Autonomic Control Plane > > Starting point: draft-behringer-autonomic-control-plane > > > > In addition, autonomic service agents will need to be defined for > > specific use cases. The working group will initially consider one > > simple example as a test case for further work. > > > > o Definition of > > Starting point: draft-use-case-tbd > > > > The initial set of work items is limited to the above list to stay > > focused and > avoid > > "boiling the ocean". Additional documents concerning policy intent, > > other autonomic infrastructure components, use cases or autonomic > > service agents are strongly encouraged, as individual submissions, but > > are not planned as working group deliverables for now. No additional > > work items will be accepted in the working group without > > re-chartering. > > > > Milestones > > > > Nov 2014 - WG formation and adoption of drafts > > - Mar IETF - > > Jun 2015 - WGLC for draft-generic-discovery-negotiation-protocol > > - Jul IETF - > > Aug 2015 - submit draft-generic-discovery-negotiation-protocol to IESG > > (standards track) Oct 2015 - WGLC draft-keyinfrastructure-bootstrap > > Oct 2015 - WGLC draft-use-case-tbd > > - Nov IETF - > > Dec 2015 - submit draft-keyinfrastructure-bootstrap to IESG > > (standards track) Dec 2015 - submit draft-use-case-tbd to IESG > > (standards track) Jan 2016 - WGLC draft-autonomic-common-control-plane > > - Mar IETF - > > Apr 2016 - submit draft-autonomic-common-control-plane to IESG > > (standards > > track) > > Jul 2016 - recharter if needed, or close > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Aug 7 10:35:06 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 06D0C1A00BB; Thu, 7 Aug 2014 10:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEk2slCS8zdO; Thu, 7 Aug 2014 10:35:01 -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 3769D1A00B9; Thu, 7 Aug 2014 10:35:01 -0700 (PDT) Received: from [76.14.66.110] (port=52176 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XFRad-00064l-I7; Thu, 07 Aug 2014 10:35:00 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: Date: Thu, 7 Aug 2014 10:35:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <23EA0E40-A503-4F7E-A4A9-7A33D43A215D@cs.stanford.edu> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 37a9e86f2e4d2511d38563a73d487f50 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Mn0jqIVgiQYsdiqUcRvB7Kwf0E8 Cc: Michael Richardson , Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 07 Aug 2014 17:35:03 -0000 Seems reasonable to me, although a bit cumbersome. I'd suggest This document updates the IPv6 Flow Label Specification [RFC6437], which stipulates that once the = Flow Label is set, forwarding nodes do not update it unless there are = compelling security reasons to do so. This document argues that saving energy in = LLNs=20 is another sufficiently compelling reason to modify the Flow Label. Phil On Aug 5, 2014, at 1:11 AM, Pascal Thubert (pthubert) = wrote: > I think I see what you are saying, Phil. >=20 > I can split 1.3 to isolate the deviations to 6437. >=20 > I also need to move the following text from section 3 in that new = section=20 >=20 > This may seem contradictory with the IPv6 > Flow Label Specification [RFC6437] which stipulates that once it is > set, the Flow Label is left unchanged; but the RFC also indicates a > violation to the rule can be accepted for compelling reasons, and > that security is a case justifying such a violation. This > specification suggests that energy-saving is another compelling > reason for a violation to the aforementioned rule. >=20 > Proposed update for that text: >=20 > This specification updates the IPv6 > Flow Label Specification [RFC6437], which stipulates that once it is > set, the Flow Label is left unchanged. [RFC6437] also indicates that=20= > a violation to the rule can be accepted for compelling reasons,=20 > but limit those compelling reasons to security related issues. This > specification indicates that energy-saving is another compelling > reason that justifies a violation to the aforementioned rule. >=20 > What do you think? >=20 > Cheers, >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> Sent: lundi 4 ao=FBt 2014 20:23 >> To: Ralph Droms >> Cc: Pascal Thubert (pthubert); Michael Richardson; Routing Over Low = power >> and Lossy networks; ipv6@ietf.org >> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 >>=20 >>=20 >> On Aug 4, 2014, at 11:10 AM, Ralph Droms = wrote: >>=20 >>>=20 >>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) >> wrote: >>>=20 >>>> The change is now done, Ralph. >>>>=20 >>>> The only difference between = draft-thubert-6man-flow-label-for-rpl-03 and >> draft-thubert-6man-flow-label-for-rpl-04 is >>>>=20 >>>> Updates: 6437 (if approved) >>>=20 >>> I suggest adding a section to your doc that explains exactly what is = being >> updated in RFC 6437. >>>=20 >>> - Ralph >>=20 >>=20 >> I agree. I think some of the text in 1.3 can be re-used for this = purpose. >>=20 >> Phil From nobody Thu Aug 7 11:48: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 3784B1B2CF3; Thu, 7 Aug 2014 08:33:14 -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 KtOrTu_tlLI8; Thu, 7 Aug 2014 08:33:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C58F71B2C5F; Thu, 7 Aug 2014 08:33:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: abr@sdesigns.dk, Emmanuel.Baccelli@inria.fr, robert.cragie@gridmerge.com, consultancy@vanderstok.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807153312.24864.44919.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 08:33:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/sjx5V3N9EK6ccUqxG72ehlgWT9A X-Mailman-Approved-At: Thu, 07 Aug 2014 11:48:14 -0700 Cc: mcr+ietf@sandelman.ca, roll@ietf.org, akatlas@gmail.com, maria.ines.robles@ericsson.com, ipr-announce@ietf.org Subject: [Roll] IPR Disclosure: Philips' Statement of IPR related to draft-ietf-roll-applicability-home-building-03 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: Thu, 07 Aug 2014 15:33:14 -0000 Dear Anders Brandt, Emmanuel Baccelli, Robert Cragie, Peter Van der Stok: An IPR disclosure that pertains to your Internet-Draft entitled "Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control" (draft-ietf-roll-applicability-home-building) was submitted to the IETF Secretariat on 2014-05-13 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2413/). The title of the IPR disclosure is "Philips' Statement of IPR related to draft-ietf-roll- applicability-home-building-03.""); The IETF Secretariat From nobody Fri Aug 8 10:00: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 5A3331A045D for ; Fri, 8 Aug 2014 10:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 BpIj-ayOUxRa for ; Fri, 8 Aug 2014 10:00:35 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967471A0407 for ; Fri, 8 Aug 2014 10:00:35 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s78H0Xht019353; Fri, 8 Aug 2014 18:00:33 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s78H0WHH019345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Aug 2014 18:00:32 +0100 From: "Adrian Farrel" To: Date: Fri, 8 Aug 2014 18:00:31 +0100 Message-ID: <039901cfb32a$4396fa40$cac4eec0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+zKjbjWAt8/OXPR76hTX4S1nHWDg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20868.000 X-TM-AS-Result: No--10.129-10.0-31-10 X-imss-scan-details: No--10.129-10.0-31-10 X-TMASE-MatchedRID: uM/FAQ+OoQfLLefpbEkxkJmug812qIbzbv16+gil4jc3Z3efQH+wj0j8 AtVpDcmg30nY8d71auJnI/RGosR8EpVSBURTFYjQoMo9pWsaF6VlrsuS5tC+P/W2znIlYDjDRiX 6fzbAQPUvK5dSZworPLHR1wcQzR2o06P6nK44odAItCy6ZX/lLx852jgffnmI+yNYYwngrxbvv/ IA2HPk+OByqm2JX7QD3Fu/vVUHOxojc2rIhESDRt35+5/2Rxqmbb9qvlMXO4Kyd65qZFFPk2mCt i+JzZB1MzGNNFA7dQEbZLZQawUR5v3oDYuWRaGYEhGH3CRdKUUHZg6HZbmAcfgnJH5vm2+g1BoO 0FXL0sgf8ff5tbWyxfcKXYM536/nF0rpaZ47th8SuhBXNJb1dEyQ5fRSh265BMjYv8ffQVVnKwn YEuaPmLjObRk3pjhHg8SU+T+Au5YzjsQsSbMmptcd9O3aJYmbRtu4vtjjtzQJW4Re2U2py2Rkbo 3bzUFsYu0aFyYZk872vyDIp/5VLuVHGbcDbAq6OX/V8P8ail3Yr6U3ZlQkdsRB0bsfrpPIfiAqr jYtFiQXY+x/7KhI2QdJb2/QOA/yhaNhoUTlUMsjarW1v8ENY37cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Fkopu0WsY70RxuYKB5geKUyeb4g Cc: roll@ietf.org Subject: [Roll] AD review of draft-ietf-roll-security-threats X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:00:38 -0000 Hi authors, I have conducted my usual AD review of your document having received a publication request. The purpose of the review is to make sure that the document is in the best possible shape to go through IETF last call and IESG evaluation. Thank you for taking the time and investing the effort on this important document. I find the content readable and easy to understand (thank you). I'm not a security expert, but what you have written is clear and credible. Good job! There is just a small set of editorial issues that I would like you to clean up before I run the IETF last call. I'll put the document into "Revised I-D Needed" state and wait for you to post a revision. Thanks for the work, Adrian ===- The references are a mess as indicated by idnits and the Shepherd write-up. http://www.ietf.org/tools/idnits?url=http://www.ietf.org/archive/id/draft-ietf-r oll-security-threats-08.txt The point here is that you can't just include something in the references section because you think it is a fine document or you are friends with the author :-) If a document is worth reading in the context of this I-D, then there should be a mention of it somewhere (appropriate) in the text. If there is nowhere that you find it appropriate to mention the reference, then remove it from the references section. [I-D.ietf-roll-terminology] is now RFC 7102. --- A few abbreviations are used without expansion. I found MPLS, ESSID/PAN, CCM, PANA, EAP-TLS, DODAG. --- Your one use of RFC 2119 language outside Section 8 is unnecessary. RPL uses multicast as part of it's protocol, and therefore mechanisms which RPL uses to secure this traffic MAY be applicable to MPL control traffic as well: the important part is that the threats are similiar. s/it's/its/ s/MAY/might also/ s/similiar/similar/ Furthermore, while your use of 2119 in Section 8 is fine with me, it is not in harmony with the boilerplate you have included after the Abstract. I suggest you move it to Section 3, and have it read... Although this is not a protocol specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] in order to clarify and emphasize the guidance and directions to implementers and deployers of LLN nodes that utilize RPL. --- 4.3 is a helpful way to present things. I think that "Limited energy, memory, and processing node resources" also needs to highlight the increased susceptibility of LLN nodes to denial of service attacks since it is not only easier o swamp such nodes, but they can be exhausted to the extent that they are never able to function again! Such an attack may be mounted through the routing plane (and impact both routing and data forwarding) or through the data plane (to impact both forwarding and routing). Thus, there is also an interdependency between the two planes that may be tighter in LLNs than in other networks. From nobody Fri Aug 8 13:19:18 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375011A854D; Fri, 8 Aug 2014 13:19:14 -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 OTAOQlL_zmXU; Fri, 8 Aug 2014 13:19:11 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E5F1B2A18; Fri, 8 Aug 2014 13:19:11 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id hz1so7747279pad.22 for ; Fri, 08 Aug 2014 13:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N5Rshfp2LvAE3j8XyNOFpQrIQaNzsw9XRKZvIjwbBxI=; b=d0Yi0x23Ko20GJoMY3M+3vt7k4iJWKByXF5s5uL4Mn+0U7zRDez2o6953pCqfRGxPT XVrSrfATsrOPtFvyACH+zH0E8hVop9NtxLzCkz6g5wMlUSbLbVyIU3dvcynzeb1+BFH8 BQ8/eAKiYljwC8oEnK3xO4wEq1tiPqHHYjRwzrOXwyUT3PD1wiRE3NVDgcSuSCbMTJZc T2xTdQMTy8joWtljTl6/iKpJYrmTNa5EfCkaE8x888pzky26nMI+qRa5elPRsIzyEO5s 9ZtFue4u9pw/HgEAVDKQ/Ep6HEZdkBwEYOTkjBzwqNyLm9jWCXX2xjuDLqj84ftBYoMz ne/Q== X-Received: by 10.66.123.75 with SMTP id ly11mr20247823pab.82.1407529150895; Fri, 08 Aug 2014 13:19:10 -0700 (PDT) Received: from [10.82.101.34] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id cb8sm28710727pad.8.2014.08.08.13.19.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 13:19:09 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: Date: Fri, 8 Aug 2014 16:19:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/75dTdfi3ZZtOVSD6VN4avSsY_w4 Cc: Michael Richardson , Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 08 Aug 2014 20:19:14 -0000 On Aug 5, 2014, at 4:11 AM 8/5/14, Pascal Thubert (pthubert) = wrote: > I think I see what you are saying, Phil. >=20 > I can split 1.3 to isolate the deviations to 6437. >=20 > I also need to move the following text from section 3 in that new = section=20 >=20 > This may seem contradictory with the IPv6 > Flow Label Specification [RFC6437] which stipulates that once it is > set, the Flow Label is left unchanged; but the RFC also indicates a > violation to the rule can be accepted for compelling reasons, and > that security is a case justifying such a violation. This > specification suggests that energy-saving is another compelling > reason for a violation to the aforementioned rule. >=20 > Proposed update for that text: >=20 > This specification updates the IPv6 > Flow Label Specification [RFC6437], which stipulates that once it is > set, the Flow Label is left unchanged. [RFC6437] also indicates that=20= > a violation to the rule can be accepted for compelling reasons,=20 > but limit those compelling reasons to security related issues. This > specification indicates that energy-saving is another compelling > reason that justifies a violation to the aforementioned rule. Well, I personally don't read the text in RFC 6437 as saying "a = violation to the rule can be accepted for compelling reasons". To avoid = arguments with difficult individuals like me, you might take a more = neutral approach: This document updates the following text from RFC 6437, "IPv6 Flow Label Specification": OLD: Once set to a non-zero value, the Flow Label is expected to be delivered unchanged to the destination node(s). A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1. NEW: Once set to a non-zero value, the Flow Label is expected to be delivered unchanged to the destination node(s). A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for (1) compelling operational security reasons as described in Section 6.1 or (2) use as specified in RFC-to-be, "The IPv6 Flow Label within a RPL domain". - Ralph >=20 > What do you think? >=20 > Cheers, >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> Sent: lundi 4 ao=FBt 2014 20:23 >> To: Ralph Droms >> Cc: Pascal Thubert (pthubert); Michael Richardson; Routing Over Low = power >> and Lossy networks; ipv6@ietf.org >> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 >>=20 >>=20 >> On Aug 4, 2014, at 11:10 AM, Ralph Droms = wrote: >>=20 >>>=20 >>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) >> wrote: >>>=20 >>>> The change is now done, Ralph. >>>>=20 >>>> The only difference between = draft-thubert-6man-flow-label-for-rpl-03 and >> draft-thubert-6man-flow-label-for-rpl-04 is >>>>=20 >>>> Updates: 6437 (if approved) >>>=20 >>> I suggest adding a section to your doc that explains exactly what is = being >> updated in RFC 6437. >>>=20 >>> - Ralph >>=20 >>=20 >> I agree. I think some of the text in 1.3 can be re-used for this = purpose. >>=20 >> Phil From nobody Fri Aug 8 13:36:52 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0751A0109; Fri, 8 Aug 2014 13:36:51 -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 T_5zgP63Jthn; Fri, 8 Aug 2014 13:36:49 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53E41A00D8; Fri, 8 Aug 2014 13:36:49 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id eu11so7889438pac.31 for ; Fri, 08 Aug 2014 13:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jCX5VXOLf5w1EYCN3Mnngzz3q94BWCN1WAGlc48IhS0=; b=bxiqODlEtd+zxkz8jT68rR43wYDrNkoShv/9RRF7l+PTHjdFQgBl+MIU6KCtrXIRyD Vq6iPgRiGJm+naEjjgxRL3I5gFNL10UIrwwJ/uyBdWiYiO6wDpugbpUXFB8QKCfz0b7b 2h6Wrlf61qbhhH9dD8wl20Uadrhd1qsS2vpm6iSvtZkt2Lbt+SyxK8vFsP3Xa8HAyhUu FTq7kdqZaqPhyVGALQ5Rkh0tTacfWqDoQ57smyM1Bkto7wwpI+0g7WamvWrjPbtD/jsw nnar/fynuN5IOcoiMu0XjQTLK9QXrVfjzecm8Ye/HeR/nQQkpeacsjN1JPmeQVIoKFGl sBAA== X-Received: by 10.70.89.43 with SMTP id bl11mr3647102pdb.163.1407530209289; Fri, 08 Aug 2014 13:36:49 -0700 (PDT) Received: from [192.168.178.23] (146.197.69.111.dynamic.snap.net.nz. [111.69.197.146]) by mx.google.com with ESMTPSA id om8sm5709726pdb.58.2014.08.08.13.36.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 13:36:48 -0700 (PDT) Message-ID: <53E534E8.4050304@gmail.com> Date: Sat, 09 Aug 2014 08:36:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ralph Droms References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> In-Reply-To: <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/XewflubZvAJlAwLH21ZFQGV4HH4 Cc: Michael Richardson , "ipv6@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 08 Aug 2014 20:36:51 -0000 Ralph, On 09/08/2014 08:19, Ralph Droms wrote: > On Aug 5, 2014, at 4:11 AM 8/5/14, Pascal Thubert (pthubert) wrote: > >> I think I see what you are saying, Phil. >> >> I can split 1.3 to isolate the deviations to 6437. >> >> I also need to move the following text from section 3 in that new section >> >> This may seem contradictory with the IPv6 >> Flow Label Specification [RFC6437] which stipulates that once it is >> set, the Flow Label is left unchanged; but the RFC also indicates a >> violation to the rule can be accepted for compelling reasons, and >> that security is a case justifying such a violation. This >> specification suggests that energy-saving is another compelling >> reason for a violation to the aforementioned rule. >> >> Proposed update for that text: >> >> This specification updates the IPv6 >> Flow Label Specification [RFC6437], which stipulates that once it is >> set, the Flow Label is left unchanged. [RFC6437] also indicates that >> a violation to the rule can be accepted for compelling reasons, >> but limit those compelling reasons to security related issues. This >> specification indicates that energy-saving is another compelling >> reason that justifies a violation to the aforementioned rule. > > Well, I personally don't read the text in RFC 6437 as saying "a violation to the rule can be accepted for compelling reasons". To avoid arguments with difficult individuals like me, you might take a more neutral approach: > > This document updates the following text from RFC 6437, "IPv6 Flow > Label Specification": > > OLD: > > Once set to a non-zero value, the Flow Label is expected to be > delivered unchanged to the destination node(s). A forwarding node > MUST either leave a non-zero flow label value unchanged or change it > only for compelling operational security reasons as described in > Section 6.1. > > NEW: > > Once set to a non-zero value, the Flow Label is expected to be > delivered unchanged to the destination node(s). A forwarding node > MUST either leave a non-zero flow label value unchanged or change > it only for (1) compelling operational security reasons as > described in Section 6.1 or (2) use as specified in RFC-to-be, "The > IPv6 Flow Label within a RPL domain". I *really* don't think RFCs are algorithms to the point where we need to do this. I see no reason why flow-label-for-rpl can't simply declare itself an exception to this clause of RFC 6437. Brian From nobody Sun Aug 10 09:29: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 34B421A07A1; Sun, 10 Aug 2014 09:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 2X0LjHp8OfE6; Sun, 10 Aug 2014 09:29:11 -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 611AC1A079F; Sun, 10 Aug 2014 09:29: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 s7AGT4Yg016758; Sun, 10 Aug 2014 18:29:04 +0200 (CEST) Received: from [192.168.217.106] (p54890283.dip0.t-ipconnect.de [84.137.2.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5716C1B3; Sun, 10 Aug 2014 18:29:03 +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: Sun, 10 Aug 2014 18:29:01 +0200 X-Mao-Original-Outgoing-Id: 429380941.471819-dfbf150314bf00e9194c8a1c7e1ac4ac Content-Transfer-Encoding: quoted-printable Message-Id: <64A628BA-EADA-4738-BB8D-2CFFDE8E6CF0@tzi.org> References: To: "ipv6@ietf.org" , roll X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/K3nWYNwmCQTtycJ86aH3qS-ExbA Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 16:29:13 -0000 So far, we have mainly discussed the need for an optimization (it seems = we now agree there is a need) and the interaction between the normative = components of RFC 6437 and those of the draft at hand. I=92d now like to bring up a different question: Is this the right approach? I have written up what appears to be a more natural approach in the = strawman draft: http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00 Why are we doing the flow-label thing and not the more natural thing? [ ] because the flow label hack works on packets that leave the 6lo = networks. =95 but do we really need to optimize this on the non-6lo networks? [ ] because the flow label hack has been around for a while and is now = cast in stone. =95 is it? [ ] because there is a flaw with the way this has been integrated into = the 6lo framework. =95 ______ (fill in the flaw) [ ] because ______ (fill in the reason) Inquiring minds want to know. Gr=FC=DFe, Carsten From nobody Sun Aug 10 09:52:03 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C967A1A07A2; Sun, 10 Aug 2014 09:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 IbgRt-3lZIF0; Sun, 10 Aug 2014 09:48:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D80A1A0470; Sun, 10 Aug 2014 09:48:32 -0700 (PDT) Received: from localhost ([::1]:57692 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XGWIH-0002t1-PF; Sun, 10 Aug 2014 09:48:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com X-Trac-Project: 6man Date: Sun, 10 Aug 2014 16:48:29 -0000 X-URL: http://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/5 Message-ID: <067.98c5b4aa0bdf702996c666086d0b809d@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ZrU2LJcC8lBLx-sHS9loY5JDRgY X-Mailman-Approved-At: Sun, 10 Aug 2014 09:52:02 -0700 Cc: roll@ietf.org, 6man@ietf.org Subject: [Roll] [6man] #5 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 16:48:33 -0000 #5: draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption Source: http://www.ietf.org/mail-archive/web/roll/current/msg08755.html From: Philip Levis Date: Tue, 29 Jul 2014 17:02:17 -0700 I'm worried by the fundamental premise of the approach: "The 8-octets overhead is detrimental to the LLN operation, in particular with regards to bandwidth and battery constraints. The extra encapsulation may cause a containing frame to grow above maximum frame size, leading to Layer 2 or 6LoWPAN [RFC4944] fragmentation, which in turn cause even more energy spending and issues discussed in the LLN Fragment Forwarding and Recovery [I-D.thubert-6lo-forwarding-fragments]." The basic assumption of this paragraph is that energy consumption is dominated by transmission time. Has anyone presented any actual evidence -- i.e., actual energy numbers -- of the cost this introduces? Because "This specification suggests that energy-saving is another compelling reason for a violation to the aforementioned rule." makes the assumption that the energy saving is significant. Breaking the end-to-end nature of the flow label for some tiny saving seems like a mistake. But if this would actually save a significant amount of energy that couldn't be saved through other, simpler, means, then it seems like a great idea. My fear is that this area -- low-power link layers, energy saving protocols -- is an area that is still new to the IETF and tends to have very subtle issues. What's being proposed here is pretty significant. Simple, intuitive arguments might not hold up to scrutiny in real networks. If you look at it in this light, one comment the draft makes is especially troubling: "But if we consider the whole RPL domain as a large virtual host from the standpoint of the rest of the Internet" This is completely contrary to the deep, fundamental premise of the Internet of Things and when we started down the path of bringing IPv6 to LLNs. Before 6lowpan, LLN devices were typically considered peripherals, devices that connect to an Internet host through other interfaces and protocols (USB, ZWave, ZigBee, etc., etc.). This gave greater flexibility on what those networks could do, but it placed a hard barrier on the Internet. You needed new tools, management interfaces, software, and policies for managing the two sides of the network. E.g, you manage your IP network and separately manage your embedded network. The big promise of 6lowpan and all of the subsequent technologies the IETF has developed is that instead, we can consider it IP down into these networks as well. Considering an entire LLN as a virtual host goes back to this segmented model, and so is a step backwards. In summary, this draft presents a tradeoff: break the end-to-end behavior of the flow label for improved energy efficiency. I'd argue strongly in favor of this draft if "improved" meant "doubles". But if it means "5% in 1% of use cases", this seems like a poor tradeoff. The IETF 90 slides say it's a "show stopper" for SDOs. I'm not sure what that means? Is there any greater detail on this? I'd like to make an informed engineering decision, but don't have enough data to do so. Phil -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: new Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Keywords: -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Sun Aug 10 09:52:05 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37B21A07AE; Sun, 10 Aug 2014 09:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 m0clkZqS6Lw7; Sun, 10 Aug 2014 09:50:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A912E1A0465; Sun, 10 Aug 2014 09:50:45 -0700 (PDT) Received: from localhost ([::1]:57824 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XGWKS-0008KK-J1; Sun, 10 Aug 2014 09:50:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6man issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com X-Trac-Project: 6man Date: Sun, 10 Aug 2014 16:50:44 -0000 X-URL: http://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/5#comment:1 Message-ID: <082.2f6b36f09458a02d96c3e91fa0512248@trac.tools.ietf.org> References: <067.98c5b4aa0bdf702996c666086d0b809d@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <067.98c5b4aa0bdf702996c666086d0b809d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/mWERtmZI9OKOJo9TZlwsV-J0u0w X-Mailman-Approved-At: Sun, 10 Aug 2014 09:52:02 -0700 Cc: roll@ietf.org, 6man@ietf.org Subject: Re: [Roll] [6man] #5 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 16:50:47 -0000 #5: draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption Comment (by mariainesrobles@gmail.com): ---------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08756.html From: Brian E Carpenter Date: Wed, 30 Jul 2014 13:36:44 +1200 On 30/07/2014 12:02, Philip Levis wrote: ... > "This specification suggests that energy-saving is another > compelling reason for a violation to the aforementioned > rule." > > makes the assumption that the energy saving is significant. > Breaking the end-to-end nature of the flow label for some > tiny saving seems like a mistake. I can't evaluate whether the energy saving is significant. However, I don't have any deep faith in the e2e-ness of the flow label. The reality (as RFC 6437 tries to recognise) is that it's a mutable field, and is therefore untrustworthy for e2e use. It has value for load balancing if all packets of a given flow have the same label, whether the label is set by the source or by a border device. For that reason, I think the usage proposed in this draft is OK. However, I do agree that at least a hand-waving estimate of the % energy saving would be useful. Brian Carpenter R ---------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08761.html From: Philip Levis Date: Thu, 31 Jul 2014 15:11:21 -0700 On Jul 29, 2014, at 6:36 PM, Brian E Carpenter wrote: > On 30/07/2014 12:02, Philip Levis wrote: > ... >> "This specification suggests that energy-saving is another >> compelling reason for a violation to the aforementioned >> rule." >> >> makes the assumption that the energy saving is significant. >> Breaking the end-to-end nature of the flow label for some >> tiny saving seems like a mistake. > > I can't evaluate whether the energy saving is significant. > However, I don't have any deep faith in the e2e-ness of the > flow label. The reality (as RFC 6437 tries to recognise) > is that it's a mutable field, and is therefore untrustworthy > for e2e use. It has value for load balancing if all packets > of a given flow have the same label, whether the label is > set by the source or by a border device. For that reason, > I think the usage proposed in this draft is OK. > > However, I do agree that at least a hand-waving estimate of > the % energy saving would be useful. > > Brian Carpenter *shrug* My thoughts are pretty simple. I'm sure you know all this (as one of the authors!) but I'll revisit for everyone else's sake. 6437 states "A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1." So, this is a MUST. Either the RPL flow label draft contradicts 6437 (and should say so explicitly), or there should be an explicit update to 6437. In fact, the current draft is misleading and incorrect. It says "but the RFC also indicates a violation to the rule can be accepted for compelling reasons, and that security is a case justifying such a violation. This specification suggests that energy-saving is another compelling reason for a violation to the aforementioned rule." This is *not* what 6437 says. It says for compelling operational security reasons, not compelling reasons, of which one case is security. Having been researching, implementing, and deploying low-power protocols for over a decade, I've become exceedingly skeptical when someone proposes a protocol with energy as a motivation without quantifying it. For example, there are tons of protocols in the research literature which talk about using transmission power control to save energy (trading off range for power). But almost all of these papers ignore the fact that (unlike mobile/cellular systems, which the authors have been publishing in for years) RF is a tiny sliver of power in low-power networks. So reducing your transmission (RF) power by 99% only reduces your radio power by 50%. Generally a losing proposition. This is the same reason why power saving in WiFi involves synchronization on AP beacons and not adjusting transmit power. If someone doesn't quantify the potential benefit based on real hardware and protocols, then it could be based on mistaken assumptions. I mean, it doesn't take much here. Start with a working low-power RPL network. Send packets with sizes following a reasonable distribution based on an actual application. In one experiment send just those packets. In another add the 8 bytes. In a third add 8 + the IP-in-IP encapsulation. Measure the energy cost. And, generally speaking, if you can't demonstrate the problem very easily, then perhaps it isn't a real problem at all. All that being said, I think using the flow label in this way is a good idea, and definitely valuable. But as it is now, doing so violates 6437, and so the assumptions implementers make when reading 6437. I think the bar for doing so should be high, higher than vague suggestions and hand waving which might not be correct. Phil ---------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08763.html From: Xavier Vilajosana Date: Fri, 1 Aug 2014 10:50:15 +0200 Dear Phil, all, I do not completely agree :) Let's look at what IPHC does at the LBR when a flow label is elided and has to be inflated to be forwarded to the IPv6 network, this standardized behaviour is somehow interfering the end to end notion of the flow label as the content is being populated at the border of the LLN. For me this is not different than changing the scope of the flow label inside the LLN to transport RPL information and resetting it at the LBR once data moves outside of the network considering that inside the LLN the flow label has no meaning. Looking into an article we wrote some time back, "A Realistic Energy Consumption Model for TSCH Networks". published in IEEE Sensors we know that the charge used by a mote (something similar to telosb) to send 127bytes is around 69uC and to receive them is 72uC (considering the optimal case where receiver has a guard time of 1ms and the network is synchronized). By using the flow label instead of the RPL extension header we save 5bytes which give us a gain 2,71uC per data packet per hop when sent and something similar when received (i.e ~5uC in total), this is a 8% saving (accounting TX and RX side) considering that motes are always using 127bytes packets. If we go to a more realistic case where motes send ~50bytes packets, the charge needed to send/receive them is something around 27.5uC and being able to save 5 bytes represents a 10% saving for the sender and 10% for the receiver (~20% saving if we look it overall per hop). If we use batteries that power the mote for 5 years, a 20% saving gives us ~1 more year which I think is pretty significant. regards, Xavi ---------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08764.html From: Carsten Bormann Date: Fri, 1 Aug 2014 13:23:44 +0200 On 01 Aug 2014, at 10:50, Xavier Vilajosana wrote: > > Let's look at what IPHC does at the LBR when a flow label is elided and has to be inflated to be forwarded to the IPv6 network, this standardized behaviour is somehow interfering the end to end notion of the flow label as the content is being populated at the border of the LLN. No. With IPHC, the flow label has always been there, it just was transmitted in a very compressed form. I think the visceral reaction that most of us have in using the flow label as a mesh routing header is that this blurs the layer boundaries. So much for O, R, F, and rank. Putting the VLAN (“instance ID”) into the packet is a significantly larger change, because it essentially extends the IP service interface by a VLAN ID. We normally try to hide IDs of this kind below IP. Now, I’m not saying any of this new architecture is wrong. I just think what we need to do is discuss this as the architectural change that it is, not as a simple optimization. (The need for some kind of optimization of IP-in-IP mesh routing for small-packet IoT applications is pretty obvious to me.) The other story is that we are retracting RFC 6437 and turning the flow label into the “field you may trample on in your lower layers if you have a good reason”. Cynically, one could say this is proper payback for designing this field without a compelling purpose and no protocol evolution story attached to it. So the evolution just eats it. Teachable moment. Grüße, Carsten ---------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08766.html From: "Pascal Thubert (pthubert)" Date: Fri, 1 Aug 2014 12:56:40 +0000 > No. With IPHC, the flow label has always been there, it just was transmitted > in a very compressed form. My take is that you are both providing angles on a same thing. It does not make sense for a LLN node to waste compute power and bandwidth to get a random through that is of use only in the core of the internet, should the packet ever get there. So the flow label is effectively zero - or something locally significant in specific standards, which is not design to serve the purpose of load balancing in the core. So in either case, we need the root to 'inflate' the zero flow label, or replace it by something that fits the core of the Internet. That behavior was not specified so far and it should be. This document is covering this particular gap. Cheers, Pascal ---------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08767.html From: "Pascal Thubert (pthubert)" Date: Fri, 1 Aug 2014 13:25:06 +0000 > I think the visceral reaction that most of us have in using the flow label as a > mesh routing header is that this blurs the layer boundaries. So much for O, > R, F, and rank. Putting the VLAN ("instance ID") into the packet is a > significantly larger change, because it essentially extends the IP service > interface by a VLAN ID. We normally try to hide IDs of this kind below IP. > > Now, I'm not saying any of this new architecture is wrong. I just think what > we need to do is discuss this as the architectural change that it is, not as a > simple optimization. (The need for some kind of optimization of IP-in- IP > mesh routing for small-packet IoT applications is pretty obvious to me.) > > I agree, Carsten. An angle is that we allow for localized usage of the flow label as opposed to end-to-end. Another is that we allow for different semantics within a local domain, as long as the packet that leaves the local domain fits the requirements in RFC 6437. As you point out, it is worth noting that we include information about flow isolation and rules by which a flow will be routed, which is akin to Multi-Topology Routing though MTR is based on TOS bits. It would be good to design an architecture that encompasses such capabilities. We'll note that ISA100.11a is shipping with a flow label that contains an index to a state (so-called a contract) that is installed on the nodes on the way and by and large extends the notion of PHB on a per flow basis. Cheers, Pascal -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: new Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Sun Aug 10 10:05:48 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762B91A0470; Sun, 10 Aug 2014 10:05:45 -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 wp9DyDK7ExnF; Sun, 10 Aug 2014 10:05:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3E91A0465; Sun, 10 Aug 2014 10:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2649; q=dns/txt; s=iport; t=1407690343; x=1408899943; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CMXbo64V9nzRzIRAx8nC5eVBs7dzRZcmgode8wOu/rE=; b=EiWDcCjEJLzPS4YKpM2gDQ2Q8lt5xTmoXu5r3XdlE/qghALJPP4Cq0DW BT0XsnfsXsM7xRm5NNBJGVOX96+jre+Ea3GKrkht30aWhNmKzVQ8xMkDC /aMZpTv1ErTycaqQlH6Chq2zQ0wWDjIrAXf7rL7SC2Xm8MRggpvi1JPAA E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAAym51OtJA2B/2dsb2JhbABagw1SV8xlCodIAYEHFneEBAEBAwEBAQFrCwULAgEIRicLJQIEDgWIOggNwSIXjxkzB4MvgR0FkRmEJYZxgVeTJINcbA X-IronPort-AV: E=Sophos;i="5.01,837,1400025600"; d="scan'208";a="346448595" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP; 10 Aug 2014 17:05:41 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7AH5fYp008745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Aug 2014 17:05:41 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.109]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Sun, 10 Aug 2014 12:05:34 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPtLgxSf6MzwEzQpSdG5woHqaOoJvKESgJ Date: Sun, 10 Aug 2014 17:05:34 +0000 Message-ID: <3EE25B75-0EA3-4DE5-82CC-049C173E2A0B@cisco.com> References: , <64A628BA-EADA-4738-BB8D-2CFFDE8E6CF0@tzi.org> In-Reply-To: <64A628BA-EADA-4738-BB8D-2CFFDE8E6CF0@tzi.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/GqbfQSiu0sj8dg_P3gB6Hs_S8Jo Cc: "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 17:05:45 -0000 Hi Carsten I think you jumped too quickly on my suggestion at 6lo. It makes a lot of sense to work on a 6lo routing dispatch and in particular= enable the compression of all RPL artifacts.=20 It will take some time to figure out what goes in there but my suggestion a= t 6lo includes routing header compression, RPL option, but also source dest= ination if we decide to route fragments.=20 I hope this happens and I'll see with Laurent if we use a respin of his dra= ft or I start a new one. This work will be beneficial in the long run, but doubly fails to address t= he issues at stake here: - the draft proposes to update the rules in 6437 with stateful and with dom= ain scoped operations. This is used by the draft itself but also by publish= ed and deployed standards that came up before 6437 (eg ISA100.11a) and we a= re now acknowledging and legalizing a de facto situation. - it will take a year or 2 at best to agree on the new routing dispatch and= its operation. We need an improvement now. And btw we cannot necessarily a= ssume 6lo together with RPL, I know of at least one RPL implementation that= does not use that compression.=20 Finally, Using a dispatch for the RPL option alone seems like a waste, but = that is a discussion for 6lo. I'll publish there when I'm back from vacatio= ns. =20 Cheers, Pascal > Le 10 ao=FBt 2014 =E0 18:29, "Carsten Bormann" a =E9crit : >=20 > So far, we have mainly discussed the need for an optimization (it seems w= e now agree there is a need) and the interaction between the normative comp= onents of RFC 6437 and those of the draft at hand. >=20 > I=92d now like to bring up a different question: >=20 > Is this the right approach? >=20 > I have written up what appears to be a more natural approach in the straw= man draft: > http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00 >=20 > Why are we doing the flow-label thing and not the more natural thing? >=20 > [ ] because the flow label hack works on packets that leave the 6lo netwo= rks. > =95 but do we really need to optimize this on the non-6lo networks? > [ ] because the flow label hack has been around for a while and is now ca= st in stone. > =95 is it? > [ ] because there is a flaw with the way this has been integrated into th= e 6lo framework. > =95 ______ (fill in the flaw) > [ ] because ______ (fill in the reason) >=20 > Inquiring minds want to know. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Sun Aug 10 10:32:53 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5841A0573; Sun, 10 Aug 2014 09:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1M2n7VcU1bTN; Sun, 10 Aug 2014 09:57:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2787F1A0005; Sun, 10 Aug 2014 09:57:11 -0700 (PDT) Received: from localhost ([::1]:58025 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XGWQf-0001Jq-MX; Sun, 10 Aug 2014 09:57:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com X-Trac-Project: 6man Date: Sun, 10 Aug 2014 16:57:09 -0000 X-URL: http://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/6 Message-ID: <067.68f1bb748fae1493f1a4cf0c34b41253@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/VLH-s4czKgRSxYNOCXaVFIjVOFU X-Mailman-Approved-At: Sun, 10 Aug 2014 10:32:47 -0700 Cc: roll@ietf.org, 6man@ietf.org Subject: [Roll] [6man] #6 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 16:57:12 -0000 #6: draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation Source: http://www.ietf.org/mail-archive/web/roll/current/msg08761.html From: Philip Levis Date: Thu, 31 Jul 2014 15:11:21 -0700 On Jul 29, 2014, at 6:36 PM, Brian E Carpenter wrote: > On 30/07/2014 12:02, Philip Levis wrote: > ... >> "This specification suggests that energy-saving is another >> compelling reason for a violation to the aforementioned >> rule." >> >> makes the assumption that the energy saving is significant. >> Breaking the end-to-end nature of the flow label for some >> tiny saving seems like a mistake. > > I can't evaluate whether the energy saving is significant. > However, I don't have any deep faith in the e2e-ness of the > flow label. The reality (as RFC 6437 tries to recognise) > is that it's a mutable field, and is therefore untrustworthy > for e2e use. It has value for load balancing if all packets > of a given flow have the same label, whether the label is > set by the source or by a border device. For that reason, > I think the usage proposed in this draft is OK. > > However, I do agree that at least a hand-waving estimate of > the % energy saving would be useful. > > Brian Carpenter *shrug* My thoughts are pretty simple. I'm sure you know all this (as one of the authors!) but I'll revisit for everyone else's sake. 6437 states "A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1." So, this is a MUST. Either the RPL flow label draft contradicts 6437 (and should say so explicitly), or there should be an explicit update to 6437. In fact, the current draft is misleading and incorrect. It says "but the RFC also indicates a violation to the rule can be accepted for compelling reasons, and that security is a case justifying such a violation. This specification suggests that energy-saving is another compelling reason for a violation to the aforementioned rule." This is *not* what 6437 says. It says for compelling operational security reasons, not compelling reasons, of which one case is security. Having been researching, implementing, and deploying low-power protocols for over a decade, I've become exceedingly skeptical when someone proposes a protocol with energy as a motivation without quantifying it. For example, there are tons of protocols in the research literature which talk about using transmission power control to save energy (trading off range for power). But almost all of these papers ignore the fact that (unlike mobile/cellular systems, which the authors have been publishing in for years) RF is a tiny sliver of power in low-power networks. So reducing your transmission (RF) power by 99% only reduces your radio power by 50%. Generally a losing proposition. This is the same reason why power saving in WiFi involves synchronization on AP beacons and not adjusting transmit power. If someone doesn't quantify the potential benefit based on real hardware and protocols, then it could be based on mistaken assumptions. I mean, it doesn't take much here. Start with a working low-power RPL network. Send packets with sizes following a reasonable distribution based on an actual application. In one experiment send just those packets. In another add the 8 bytes. In a third add 8 + the IP-in-IP encapsulation. Measure the energy cost. And, generally speaking, if you can't demonstrate the problem very easily, then perhaps it isn't a real problem at all. All that being said, I think using the flow label in this way is a good idea, and definitely valuable. But as it is now, doing so violates 6437, and so the assumptions implementers make when reading 6437. I think the bar for doing so should be high, higher than vague suggestions and hand waving which might not be correct. Phil -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: new Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Keywords: -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Sun Aug 10 10:32:54 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EF51A066B; Sun, 10 Aug 2014 10:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.031 X-Spam-Level: ** X-Spam-Status: No, score=2.031 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FB_CIALIS_LEO3=3.899, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668] 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 B2Nqg1t3YyNL; Sun, 10 Aug 2014 10:31:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89A51A0651; Sun, 10 Aug 2014 10:31:32 -0700 (PDT) Received: from localhost ([::1]:59761 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XGWxt-0004CE-Ev; Sun, 10 Aug 2014 10:31:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6man issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com X-Trac-Project: 6man Date: Sun, 10 Aug 2014 17:31:29 -0000 X-URL: http://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/6#comment:1 Message-ID: <082.61f02ac8f587a6aec989ea442d929943@trac.tools.ietf.org> References: <067.68f1bb748fae1493f1a4cf0c34b41253@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <067.68f1bb748fae1493f1a4cf0c34b41253@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/XoSZeXKDbvpb9EjoT0H2geRJLps X-Mailman-Approved-At: Sun, 10 Aug 2014 10:32:47 -0700 Cc: roll@ietf.org, 6man@ietf.org Subject: Re: [Roll] [6man] #6 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 17:31:37 -0000 #6: draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation Comment (by mariainesrobles@gmail.com): Source: http://www.ietf.org/mail-archive/web/roll/current/msg08763.html From: Xavier Vilajosana Date: Fri, 1 Aug 2014 10:50:15 +0200 Dear Phil, all, I do not completely agree :) Let's look at what IPHC does at the LBR when a flow label is elided and has to be inflated to be forwarded to the IPv6 network, this standardized behaviour is somehow interfering the end to end notion of the flow label as the content is being populated at the border of the LLN. For me this is not different than changing the scope of the flow label inside the LLN to transport RPL information and resetting it at the LBR once data moves outside of the network considering that inside the LLN the flow label has no meaning. Looking into an article we wrote some time back, "A Realistic Energy Consumption Model for TSCH Networks". published in IEEE Sensors we know that the charge used by a mote (something similar to telosb) to send 127bytes is around 69uC and to receive them is 72uC (considering the optimal case where receiver has a guard time of 1ms and the network is synchronized). By using the flow label instead of the RPL extension header we save 5bytes which give us a gain 2,71uC per data packet per hop when sent and something similar when received (i.e ~5uC in total), this is a 8% saving (accounting TX and RX side) considering that motes are always using 127bytes packets. If we go to a more realistic case where motes send ~50bytes packets, the charge needed to send/receive them is something around 27.5uC and being able to save 5 bytes represents a 10% saving for the sender and 10% for the receiver (~20% saving if we look it overall per hop). If we use batteries that power the mote for 5 years, a 20% saving gives us ~1 more year which I think is pretty significant. regards, Xavi ---- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08764.html From: Carsten Bormann Date: Fri, 1 Aug 2014 13:23:44 +0200 On 01 Aug 2014, at 10:50, Xavier Vilajosana wrote: > > Let's look at what IPHC does at the LBR when a flow label is elided and has to be inflated to be forwarded to the IPv6 network, this standardized behaviour is somehow interfering the end to end notion of the flow label as the content is being populated at the border of the LLN. No. With IPHC, the flow label has always been there, it just was transmitted in a very compressed form. I think the visceral reaction that most of us have in using the flow label as a mesh routing header is that this blurs the layer boundaries. So much for O, R, F, and rank. Putting the VLAN (“instance ID”) into the packet is a significantly larger change, because it essentially extends the IP service interface by a VLAN ID. We normally try to hide IDs of this kind below IP. Now, I’m not saying any of this new architecture is wrong. I just think what we need to do is discuss this as the architectural change that it is, not as a simple optimization. (The need for some kind of optimization of IP-in-IP mesh routing for small-packet IoT applications is pretty obvious to me.) The other story is that we are retracting RFC 6437 and turning the flow label into the “field you may trample on in your lower layers if you have a good reason”. Cynically, one could say this is proper payback for designing this field without a compelling purpose and no protocol evolution story attached to it. So the evolution just eats it. Teachable moment. Grüße, Carsten ------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08765.html From: Pascal Thubert (pthubert) 2014-08-01 15:44 GMT+03:00 Hello Phil: The end-to-end principle will not break in pieces if we reuse the flow label field within the LLN. FYI, it will break nothing since there is no assumption in the Internet that the flow label will be carried unchanged. Consistently, there is no native way to secure the flow label to make sure it was not tempered with (IOW it is not protected by ULP checksums, IPSec AH or ESP transport mode). The last call at 6MAN is where I expect problems with the use of the flow label field in this draft to be pointed at. I'm happy to report that there was no trace of bigotry there, all the contrary. 6MAN will confirm whether this draft conforms the spirit of the existing RFCs and so far I gathered, from all but you, that it does. About SDOs: To be very clear, ISA100.11a made a clear condition to acceptance of 6LoWPAN that we compress the UDP checksum - 2 bytes. And we made that happen. As the standard is now considering what new work may be taken in, RPL will not be considered if we waste those 5 bytes, simple as that. Sorry that you missed the ROLL meeting, but Pat Kinney was very clear on that both as vice chair of 802.15, and as chair of ISA100.11a where he "fought over every byte". " Both hats say that this is what we need this". We'll also note that each additional octet in a frame is an increased chance of loss and retry. This is an argument that I hear frequently at IEEE and the people there as well as at ISA100 are very sensitive to frame size in general. The distribution of the frame size and the cost of security depend on the application and the app layer. With high levels of security, if the distribution includes NLPDU around 80-90 octets then the extra bytes will cause fragmentation, which will add all sorts of new problems to the picture. The benefits are quite clear, both on actual numbers (thanks Xavi!) and on the political arena where such a waste of bytes is just not defendable. Please reconsider where you are placing your efforts and what you are trying to achieve... Pascal ---- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08766.html From: "Pascal Thubert (pthubert)" Date: Fri, 1 Aug 2014 12:56:40 +0000 > No. With IPHC, the flow label has always been there, it just was transmitted > in a very compressed form. My take is that you are both providing angles on a same thing. It does not make sense for a LLN node to waste compute power and bandwidth to get a random through that is of use only in the core of the internet, should the packet ever get there. So the flow label is effectively zero - or something locally significant in specific standards, which is not design to serve the purpose of load balancing in the core. So in either case, we need the root to 'inflate' the zero flow label, or replace it by something that fits the core of the Internet. That behavior was not specified so far and it should be. This document is covering this particular gap. Cheers, Pascal ------------ Source: http://www.ietf.org/mail-archive/web/roll/current/msg08767.html From: "Pascal Thubert (pthubert)" Date: Fri, 1 Aug 2014 13:25:06 +0000 > I think the visceral reaction that most of us have in using the flow label as a > mesh routing header is that this blurs the layer boundaries. So much for O, > R, F, and rank. Putting the VLAN ("instance ID") into the packet is a > significantly larger change, because it essentially extends the IP service > interface by a VLAN ID. We normally try to hide IDs of this kind below IP. > > Now, I'm not saying any of this new architecture is wrong. I just think what > we need to do is discuss this as the architectural change that it is, not as a > simple optimization. (The need for some kind of optimization of IP-in- IP > mesh routing for small-packet IoT applications is pretty obvious to me.) > > I agree, Carsten. An angle is that we allow for localized usage of the flow label as opposed to end-to-end. Another is that we allow for different semantics within a local domain, as long as the packet that leaves the local domain fits the requirements in RFC 6437. As you point out, it is worth noting that we include information about flow isolation and rules by which a flow will be routed, which is akin to Multi-Topology Routing though MTR is based on TOS bits. It would be good to design an architecture that encompasses such capabilities. We'll note that ISA100.11a is shipping with a flow label that contains an index to a state (so-called a contract) that is installed on the nodes on the way and by and large extends the notion of PHB on a per flow basis. Cheers, Pascal ---------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08768.html From: Philip Levis Date: 2014-08-01 19:21 GMT+03:00 On Aug 1, 2014, at 5:44 AM, Pascal Thubert (pthubert) wrote: > > FYI, it will break nothing since there is no assumption in the Internet that the flow label will be carried unchanged. Consistently, there is no native way to secure the flow label to make sure it was not tempered with (IOW it is not protected by ULP checksums, IPSec AH or ESP transport mode). > > The last call at 6MAN is where I expect problems with the use of the flow label field in this draft to be pointed at. I'm happy to report that there was no trace of bigotry there, all the contrary. 6MAN will confirm whether this draft conforms the spirit of the existing RFCs and so far I gathered, from all but you, that it does Pascal, I don't think this is a question of spirit or anything. I mean, I'll repeat, 6437 states "A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1." If the point is that experience and use and the spirit of the flow label has changed from this MUST, then we should explicitly state so. I'm not arguing that the above prescription is right; but it's what's written. What worries me is the idea of directly contradicting the text of a prior RFC (the one explicitly on flow labels, no less), without correspondingly obsoleting that RFC. This isn't a SHOULD. It's a MUST! I've always thought that using the flow label in this way within an LLN is a good idea. The problem is that you can't do so without violating a MUST in the RFC that specifies how flow labels are used. It sounds like the letter of that document doesn't match the spirit of it -- so let's fix the letter, so it says what was intended! Why is there such recalcitrance to do so? Or provide any quantitative basis for the claims of battery power? You've been proposing this for nearly 4 years now... I personally see two reasonable ways forward: 1) (As Carsten mentioned) Update 6437 to embrace these new and valuable uses of the flow label. 2) Provide evidence that using the flow label in this way would provide significant enough gains that violating a MUST in the RFC specifying the flow label is worth it. It seems like you're advocating a third: 3) Violate a MUST in the RFC specifying how the flow label is used without any evidence that the actual energy savings are significant. As for what I'm trying to achieve, that's pretty simple. I think it's a terrible mistake for a standards body as important as the IETF to rely on the spirit of the standard rather than the letter of the standard, especially when they contradict. If you are one of the hundreds of thousands of network engineers and software developers who work in the Internet, you can't know that a bunch of people in a meeting decided that the spirit of a specification differs from its text. All you have to go on is the text. When the founder of the next YouTube or Instagram or Google or Nicira takes my class and I ask them to write their code to follow an RFC (which I currently do), what should I tell them MUST means? Phil -------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08769.html From: Brian E Carpenter Date: Sat, 02 Aug 2014 07:58:39 +1200 On 01/08/2014 23:23, Carsten Bormann wrote: ... > The other story is that we are retracting RFC 6437 and turning the flow label into the “field you may trample on in your lower layers if you have a good reason”. Cynically, one could say this is proper payback for designing this field without a compelling purpose and no protocol evolution story attached to it. So the evolution just eats it. Teachable moment. RFC 6437 co-author hat on (but only speaking for myself, of course): My opinion is that the draft doesn't retract RFC 6437. As I already said, 6437 attempts to recognise the reality that middleboxes can mess with the flow label, and to set conditions for that messing such that remote systems can still use it for load balancing. Since it's unprotected by checksum or crypto, there is a strict limit to how much it can be trusted anyway. As the RFC says: There is no way to verify whether a flow label has been modified en route or whether it belongs to a uniform distribution. Therefore, no Internet-wide mechanism can depend mathematically on unmodified and uniformly distributed flow labels; they have a "best effort" quality. Implementers should be aware that the flow label is an unprotected field that could have been accidentally or intentionally changed en route (see Section 6). It is true that the RFC also says A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons... There is a case for arguing that flow-label-for-rpl should carry the legend "Updates: 6437 (if approved)" because it adds another exception to this sentence. There is also a case for arguing that flow-label-for-rpl is a stateful mechanism, out of scope for RFC 6437 according to Section 4 of that RFC. Either way, I don't see a problem. Regards Brian -------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08770.html From: Pascal Thubert (pthubert) Date: 2014-08-01 23:27 GMT+03:00 Phil, Though I attended the discussions and have a clear reading of this work I'll certainly defer to Brian on whether there is a violation or not. OTOH you need to understand that there is no need for a bis to update a MUST in an RFC. We recognize the imperfection in our work and are always ready to revise and amend after due consideration. This process takes is another RFC and best judgement from the original group that the new text is indeed valuable and not breaking the original objectives. We are going through that process. Pascal ------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08772.html From: Philip Levis Date: 2014-08-02 9:02 GMT+03:00 On Aug 1, 2014, at 1:27 PM, Pascal Thubert (pthubert) wrote: If the proposal is to have an Updates: 6437 (such that someone looking up 6437 will see a forward reference and know there's an update), I'm all in favor! That seems entirely reasonable. In that way, as I've always said, I think using the flow label is an excellent solution. I just also think doing so is significant in the context of 6437 and so should correctly acknowledge so. Someone reading 6437 should be able to easily learn there's another exception. It seems like an Updates: would do that well. That being said, I don't think the energy claims in the current document will hold up to much experimental scrutiny or actual network measurements. Xavier's back-of-the-envelope calculations don't include preambles, slot padding, or idle listening. TSCH is nice in that it has much lower idle listening costs than ad-hoc algorithms, but they are far from zero. Reducing overhead is valuable due to the corresponding increase in MSS and reduced memory pressure: the energy argument is a red herring. Phil ----- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08774.html From: Michael Richardson Date: 2014-08-02 22:08 GMT+03:00 Pascal Thubert (pthubert) wrote: > OTOH you need to understand that there is no need for a bis to update a > MUST in an RFC. We recognize the imperfection in our work and are > always ready to revise and amend after due consideration. Perhaps this document UPDATES 6437 then? Michael Richardson ------------------------------ Source: http://www.ietf.org/mail-archive/web/roll/current/msg08775.html From: Michael Richardson Date: 2014-08-02 22:23 GMT+03:00 Philip Levis wrote: > The paper is very helpful, thanks! Can you comment on what is a typical > idle slot configuration in a TiSCH network? Can you provide some > insight on what fraction of energy is spent in data communication > versus control and idle listening? Here is a recent post with some real numbers: https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY it concerns diet-ESP, but the numbers are correct. Michael Richardson ------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08776.html From: Pascal Thubert (pthubert) Date: 2014-08-02 23:48 GMT+03:00 That sounds right, Michael, though slightly on the overkill side. And this is consistent with what Brian suggested. This can be added during the rfc editor process I expect? Pascal > Le 2 août 2014 à 21:09, "Michael Richardson" a écrit : > Perhaps this document UPDATES 6437 then? ----------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08777.html From: Ralph Droms Date: 2014-08-02 23:56 GMT+03:00 >On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)" wrote: >That sounds right, Michael, I agree that "updates 6437" is a right thing to do. >though slightly on the overkill side. I disagree that it is overkill. In my opinion, draft-thubert-6man-flow- label-for-RPL pretty clearly contradicts RFC 6437, so "updates 6437" is an appropriate action. > And this is consistent with what Brian suggested. This can be added during the rfc editor >process I expect? It should be added as soon as possible, certainly before it goes to the IESG. In my opinion, the change might warrant a new or extended WGLC; that action is up to the chairs, of course. - Ralph -------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08778.html From: Philip Levis Date: 2014-08-03 0:41 GMT+03:00 > > Here is a recent post with some real numbers: > https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY > it concerns diet-ESP, but the numbers are correct. Michael, I'm confused on what this email message is supposed to be providing: the energy cost of sending a bit? That's pretty simple to calculate. The tradeoff between CPU and network is also very well known, going back to Pottie's "Every bit transmitted brings a sensor node one moment closer to death." If you look at the behavior of most micro controller based devices, the MCU is insignificant -- and 95% of its energy is spent handling interrupts (per-byte, over an SPI bus) for the radio. Yes, unless you're doing something quite silly, the CPU cost of compression is almost always absolutely worth the benefit in terms of reduced transmission energy. My question related to the fraction of radio energy in TSCH that is consumed by data transmission/reception versus everything else (idle listening, guard periods, control frames, etc. To give you a data point -- early low-power link layers continually transmitted a packet (or wakeup frame) until receiving an acknowledgement from the intended receiver. Receivers periodically wake up, listen if there's energy on the channel, and if so, stay awake for 2 packet times (in case they woke up just after the preamble of a packet). If there's no coordination between receiver and sender, this means a sender must send on average for 1/2 of a wakeup interval to deliver a packet. E.g., 0.5s. Clearly in such a protocol a few extra bytes doesn't matter in terms of energy. Of course, TSCH is much, much better than this, I only mention this protocol as a simple explanatory example -- but what's the actual number? Phil ------------------------------------ Source: http://www.ietf.org/mail-archive/web/roll/current/msg08779.html From: Thomas Watteyne Date: 2014-08-03 6:36 GMT+03:00 Phil, There are two parts in answering your question. Let me describe both, I will then justify why the answer is "it depends". a single slot Let's consider for starters only a single TSCH slot: mote A sends a packet to mote B, which replies with an ACK. This timeslot is depicted below (borrowed from [1]) (Please go to the source to see the graphic) Let's assume that the IEEE802.15.4 frame is 127B long, i.e. full length. Let's assume, finally, that you are using the default 10ms timeslot template from the IEEE802.15.4e-2012 standard [2] (Table 52e), no CCA. This is the radio-on time on both A and B: mote A transmitting the data packet: 4256us listening for ACK during the guard time (i.e. idle listening): 200us receiving the ACK (~15B long): 480us mote B: listening for data during the guard time (i.e. idle listening): 1000us receiving data: 4256us transmitting the ACK: 480us From an energy point of view, you also need to account for the time is takes to switch the radio on/off and for the possible energy consumed between the data and ack, in case the radio is kept in a state allowing it to TX/RX fast. Good embedded engineers will reduce this overhead through firmware and hardware wizardry. Considering only time, the radio on-time budget can hence be cut into: total: 10672us transmission of data: 8512us (~80%) desynchronization overhead (i.e. idle listening during guard time): 1200us (~10%) ACK overhead: 960us (~10%) From these numbers, you see that the actual data transmission accounts for ~80% of the radio-on time budget. Of course, this timeslot template is the default one. If you are very good at keeping synchronized, you might be able to shorten the guard times and reduce the desynchronization overhead. full network Now the fun part. In a TSCH network, the communication schedule indicates to every mote what to do: transmit, listen or sleep. You can tune the TSCH communication schedule any way you want. In fact, the 6TiSCH WG was created to define mechanisms for centralized and distributed managements of this schedule. Your goal should be to match the amount of bandwidth in your schedule (i.e. the cells used for transmission and reception) to what is needed by the network. If every cell you schedule is used, the single slot results from above carry over to a full network. If, however, you schedule has too many cells, some might be unused. In that case, the transmitter will keep its radio off (i.e. consume no energy), while the receiver will have to listen for a full guard time, or 2ms when using the default timeslot template. So there you go: it depends. In the best possible case, the portion of radio on-time spent of exchanging actual useful data can be very high (80%+), but it's easy to mess things up, resulting in a large number of over-provisioned cells. For a (hopefully clear) overview of IEEE802.15.4e TSCH, take a look at http://tools.ietf.org/html/draft-ietf-6tisch-tsch-01. Thomas [1] http://tools.ietf.org/html/draft-ietf-6tisch-minimal-02 [2] http://standards.ieee.org/getieee802/download/802.15.4e-2012.pdf ---------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08780.html From: Philip Levis Date: 2014-08-03 20:28 GMT+03:00 Thomas, This is great, thank you! Precise, technical statements. What I conclude from your text (correct me if I'm wrong): 1) If 802.15.4e uses maximum sized frames (127 bytes), the data communication time (reception or transmission) within a transmit slot is 80% of the total radio-on time. I appreciate that you separate the costs of the two sides (e.g., idle listening guard period on receive). 2) Following Xavier's analysis, using 127-byte frames means the RPL option increases data communication time by 4%. This means, from 1), that it will increase energy consumption by ~3.5%. Or, supposing his 8% number is correct (I still don't understand how he reached it), the energy consumption is increased by ~6.5%. 3) For smaller frames (e.g., the 50 bytes Xavier suggested), the idle listening on the receiver takes a larger fraction of the radio-on time, so his 10% number is too high. 4) None of these calculations consider the control overhead or, as you point out, inefficiencies in slot assignment. E.g., if you have a low- bandwidth, low-delay network, then you will allocate slots (for low latency) that you do not use (low bandwidth). For networks that are perfectly tuned, as you suggest, you can approach the transmission slot gains in 1) and 2). But they do not consider the costs and time of beacons or management time slots. Or radio wakeup overhead (dead time): my understanding is that on modern chips this is about 300us? I think your ACK timing considers RX/TX turnaround time. So in that way, 1) and 2) represent the absolute *best* savings this might give you. So my conclusion from this data is that, in the absolute best case -- assuming the radio is all of the system energy, you have a perfectly tuned TSCH schedule, etc., etc., using the flow label will save <10%, and often on the order of 5%. For simpler, less efficient and tuned MAC layers, the savings will be less. 5% or 10% isn't huge, but it is significant and valuable. I've just been a bit confused as to why this proposal has been trotted around for 4 years and yet no-one had yet even done this simple calculation, so WG members could make an informed engineering decision. IMO, a 5-10% savings in already highly tuned networks is above the bar and worth it. In most networks, the savings will be much less, but the benefits of reduced memory pressure and larger application payloads without fragmentation are more than sufficient motivation and justification of the value of the approach. Phil -------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08781.html From: Ole Troan Date: Mon, 4 Aug 2014 11:50:57 +0200 I see the principles in these two documents as mutually exclusive: RFC6437: middleboxes can mess with the flow label -flow-label-for-rpl: networks uses flow label field as an immutable protocol field you can't both use the flow label as an immutable protocol field and have middleboxes rewriting it. cheers, Ole ---------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08782.html From: Michael Richardson Date: 2014-08-04 17:02 GMT+03:00 Philip Levis wrote: > 5% or 10% isn't huge, but it is significant and valuable. I've just > been a bit confused as to why this proposal has been trotted around for > 4 years and yet no-one had yet even done this simple calculation, so WG > members could make an informed engineering decision. IMO, a 5-10% my opinion: 1) the exact calculation was hard to really do until 6tisch made it clearer what the duty cycle was going to be. 2) it took awhile to come back to figuring out how to deal with the flow label issue. 3) it is now clear exactly how close many of our packets are to the 127 byte limit, and how much the HbH header hurts if it is the reason we go into two fraglets. 4) we had other things to worry about! Michael Richardson --------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08783.html From: Michael Richardson Date: Mon, 04 Aug 2014 10:15:15 -0400 Ole Troan wrote: > I see the principles in these two documents as mutually exclusive: > RFC6437: middleboxes can mess with the flow label -flow-label-for- rpl: > networks uses flow label field as an immutable protocol field > you can't both use the flow label as an immutable protocol field and > have middleboxes rewriting it. This is my take. Case 1: packet is within the LLN. No issue; the sender sets the flow label, and we know (by design) that there aren't any (non-RPL) middle boxes that need to rewrite it. Case 2: the packet has to leave the LLN, travel across the Internet, and enter another LLN. Here the arguments about the LLN being a kind of virtual host from the document are relevant. The flow label, when it crosses the Internet, would be immutable. Prior to this document, the flow label would have been compressed out, been zero, and the DODAG root ought to have set it in some consistent fashion anyway. -- Michael Richardson ------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08784.html From: "Pascal Thubert (pthubert)" Date: Mon, 4 Aug 2014 15:41:55 +0000 Exactly; It can be argued that the LLN is a single something that is a more complex form of the classical host-router link from the L3 perspective. RFC6437 understands that the host can leave the flow label to all zeroes and allows the first router to set it in a recommended fashion. The draft pushes that role to the RPL root that is effectively the gateway from the LLN onto the Internet. Upon the WLLC discussion I have added " Updates: 6437 (if approved) " and posted an update with no other change in the text. Cheers, Pascal ----------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08785.html From: Pascal Thubert (pthubert) Date: 2014-08-04 21:01 GMT+03:00 The change is now done, Ralph. The only difference between draft-thubert-6man-flow-label-for-rpl-03 and draft-thubert-6man-flow-label-for-rpl-04 is Updates: 6437 (if approved) Cheers, Pascal ------------------------ Source: http://www.ietf.org/mail-archive/web/roll/current/msg08786.html From: Ralph Droms Date: 2014-08-04 21:10 GMT+03:00 I suggest adding a section to your doc that explains exactly what is being updated in RFC 6437. - Ralph -------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08787.html From: Philip Levis Date: 2014-08-04 21:23 GMT+03:00 I agree. I think some of the text in 1.3 can be re-used for this purpose. Phil -------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08788.html From: Philip Levis Date: 2014-08-04 21:24 GMT+03:00 On Aug 4, 2014, at 7:02 AM, Michael Richardson wrote: > > > 1) the exact calculation was hard to really do until 6tisch made it clearer > what the duty cycle was going to be. > > 2) it took awhile to come back to figuring out how to deal with the flow > label issue. > > 3) it is now clear exactly how close many of our packets are to the 127 byte > limit, and how much the HbH header hurts if it is the reason we go into > two fraglets. > > 4) we had other things to worry about! Michael, 1) doesn't depend on 6tisch, it's based on 15.4e timing, and could have been calculated for any other low power link layer. Years ago. 2) The proposal isn't substantively different -- in terms of bytes sent/saved -- from the first version of the proposal suggested in 2010. 3) The analysis so far hasn't even touched this issue. 4) The entire introduction/motivation for the proposal is saving energy! But no-one thought it important enough to actually estimate how much energy it would save (in a best case, typical case) before a last call? Here's my worry -- the tradeoffs of low-power networks are very different than the kinds of networks the IETF typically deals with. It'll lead to protocol decisions a bit different than always-on networks. But that doesn't mean it should be used as a blanket justification or motivation. Otherwise it's just smoke and mirrors (energy is critical! battery is critical! we therefore need less CPU-intensive compression schemes! here's a new one. we need less CPU-intensive cryptographic schemes! here's a new one.). If energy is so important, and this would be such a big savings, then why the recalcitrance to estimate it? It doesn't help my confidence in the engineering when some of the back-of-the-envelope analyses (Xavier's) have basic arithmetic errors that seem incognizant of how to measure energy. Phil ----------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08789.html From: Pascal Thubert (pthubert) Date: 2014-08-04 21:52 GMT+03:00 Hi Ralph: This is exactly section 3. The section provides a scope of applicability (the RPL domain) and the changes from RFC 6437 that become acceptable within that scope. Cheers, Pascal ------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08790.html From: Ralph Droms Date: Mon, 4 Aug 2014 15:44:10 -0400 On Aug 4, 2014, at 2:52 PM 8/4/14, Pascal Thubert (pthubert) wrote: > Hi Ralph: > > This is exactly section 3. > > The section provides a scope of applicability (the RPL domain) and the changes from RFC 6437 that become acceptable within that scope. I disagree. Section 3 explains how draft-thubert-6man-flow-label-for-rpl can be interpreted as following RFC 6437 rather than describing the specific ways in which it updates RFC 6437. For example, as Philip wrote: > "but the RFC also indicates a violation to the rule can be accepted for compelling reasons, and that security is a case justifying such a violation. This specification suggests that energy-saving is another compelling reason for a violation to the aforementioned rule." > > This is *not* what 6437 says. It says for compelling operational security reasons, not compelling reasons, of which one case is security. - Ralph ----------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08791.html From: Brian E Carpenter Date: 2014-08-04 23:44 GMT+03:00 Ralph, It also says that there may be stateful ways of using the flow label. It's almost a matter of taste whether the RPL usage is a change to the phrase that you quote, or a stateful usage within an RPL domain (reverting to stateless use when leaving RPL). I agree that the draft could usefully be explicit about this. Brian -------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08793.html From: Philip Levis Date: 2014-08-05 3:18 GMT+03:00 On Aug 4, 2014, at 1:44 PM, Brian E Carpenter wrote: > It also says that there may be stateful ways of using the flow label. > It's almost a matter of taste whether the RPL usage is a change to > the phrase that you quote, or a stateful usage within an RPL domain > (reverting to stateless use when leaving RPL). I agree that the draft > could usefully be explicit about this. I'm a bit confused -- the MUST statement is in Section 2, entitled "IPv6 Flow Label Specification". There doesn't seem to be any text that suggests this restriction is dependent on stateless operation. My interpretation, based on the title and its placement in the document, is that the text in this section applies to any and all uses of the flow label. How am I reading this wrong? Should I be reading the final MUST ("… MUST choose labels that conform to Section 3 of this specification") in Section 4 to implicitly mean that Section 2 doesn't necessarily apply? Or is it optional for stateless as well? My (admittedly naive) reading is that Sections 3 and 4 related to how source nodes choose a flow label. (S2: "To enable Flow-Label-based classification, source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow.") This is distinct from what forwarding nodes do to flow labels, which Section 2 covers. Phil -------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08794.html From: Brian E Carpenter Date: 2014-08-05 4:06 GMT+03:00 Philip, I think you're right that it could have been worded more precisely. My personal mental model has always included something like the RPL application (i.e. a specific usage of the flow label within a closed domain) *and* generic stateless use by default, but I don't think that model has ever been the general consensus, so what is supposed to happen at the boundary between such a closed domain and the rest of the Internet has never been written down. Brian --------------------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08795.html From: Pascal Thubert (pthubert) Date: 2014-08-05 11:11 GMT+03:00 I think I see what you are saying, Phil. I can split 1.3 to isolate the deviations to 6437. I also need to move the following text from section 3 in that new section This may seem contradictory with the IPv6 Flow Label Specification [RFC6437] which stipulates that once it is set, the Flow Label is left unchanged; but the RFC also indicates a violation to the rule can be accepted for compelling reasons, and that security is a case justifying such a violation. This specification suggests that energy-saving is another compelling reason for a violation to the aforementioned rule. Proposed update for that text: This specification updates the IPv6 Flow Label Specification [RFC6437], which stipulates that once it is set, the Flow Label is left unchanged. [RFC6437] also indicates that a violation to the rule can be accepted for compelling reasons, but limit those compelling reasons to security related issues. This specification indicates that energy-saving is another compelling reason that justifies a violation to the aforementioned rule. What do you think? Cheers, Pascal ------------------------------------ Source: http://www.ietf.org/mail-archive/web/roll/current/msg08796.html From: Anand SVR Date: 2014-08-05 20:18 GMT+03:00 Hi, The discussion has been very interesting, more so because it is bordering on the legality of the usage of the word MUST. I agree with Philip's take on this. But after reading the RFC, I got this impression that the RFC meant to be a facility or a feature with certain usage guidelines. The MUST usage is more to imply stronger than SHOULD so as to discourage people from modifying it. I suppose at the time of writing, the authors might not have foreseen that in some point in future the value can be changed for other reasons. Therefore the use of MUST MUST be taken with the right spirit it is meant to be taken rather than literally :) Anand --------------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08797.html From: Philip Levis Date: 2014-08-06 7:57 GMT+03:00 I totally agree that the document leaves the question open of whether there could be future uses. The use of the flow label in that way doesn't go against the spirit of the document and so we shouldn't reject the idea out of principle. But it does go against the letter of the document -- hence the need for an Updates: or other explicit note that this is the case. Phil ------------------------ Source: http://www.ietf.org/mail-archive/web/roll/current/msg08800.html From: Philip Levis Date: Thu, 7 Aug 2014 10:35:01 -0700 Seems reasonable to me, although a bit cumbersome. I'd suggest This document updates the IPv6 Flow Label Specification [RFC6437], which stipulates that once the Flow Label is set, forwarding nodes do not update it unless there are compelling security reasons to do so. This document argues that saving energy in LLNs is another sufficiently compelling reason to modify the Flow Label. Phil --------------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08803.html From: Ralph Droms Date: 2014-08-08 23:19 GMT+03:00 On Aug 5, 2014, at 4:11 AM 8/5/14, Pascal Thubert (pthubert) wrote: > I think I see what you are saying, Phil. > > I can split 1.3 to isolate the deviations to 6437. > > I also need to move the following text from section 3 in that new section > > This may seem contradictory with the IPv6 > Flow Label Specification [RFC6437] which stipulates that once it is > set, the Flow Label is left unchanged; but the RFC also indicates a > violation to the rule can be accepted for compelling reasons, and > that security is a case justifying such a violation. This > specification suggests that energy-saving is another compelling > reason for a violation to the aforementioned rule. > > Proposed update for that text: > > This specification updates the IPv6 > Flow Label Specification [RFC6437], which stipulates that once it is > set, the Flow Label is left unchanged. [RFC6437] also indicates that > a violation to the rule can be accepted for compelling reasons, > but limit those compelling reasons to security related issues. This > specification indicates that energy-saving is another compelling > reason that justifies a violation to the aforementioned rule. Well, I personally don't read the text in RFC 6437 as saying "a violation to the rule can be accepted for compelling reasons". To avoid arguments with difficult individuals like me, you might take a more neutral approach: This document updates the following text from RFC 6437, "IPv6 Flow Label Specification": OLD: Once set to a non-zero value, the Flow Label is expected to be delivered unchanged to the destination node(s). A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1. NEW: Once set to a non-zero value, the Flow Label is expected to be delivered unchanged to the destination node(s). A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for (1) compelling operational security reasons as described in Section 6.1 or (2) use as specified in RFC-to-be, "The IPv6 Flow Label within a RPL domain". - Ralph ---------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08804.html From: Brian E Carpenter Date: 2014-08-08 23:36 GMT+03:00 Ralph, I *really* don't think RFCs are algorithms to the point where we need to do this. I see no reason why flow-label-for-rpl can't simply declare itself an exception to this clause of RFC 6437. Brian -------------------------------------------------- -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: new Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Sun Aug 10 12:07:24 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF761A0144; Sun, 10 Aug 2014 12:07:22 -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 j1-J_PzNJ3YF; Sun, 10 Aug 2014 12:07:22 -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 CA89C1A013B; Sun, 10 Aug 2014 12:07:21 -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 s7AJ76mi024556; Sun, 10 Aug 2014 21:07:06 +0200 (CEST) Received: from [192.168.217.106] (p54890283.dip0.t-ipconnect.de [84.137.2.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 16E7C233; Sun, 10 Aug 2014 21:07:05 +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: <3EE25B75-0EA3-4DE5-82CC-049C173E2A0B@cisco.com> Date: Sun, 10 Aug 2014 21:07:04 +0200 X-Mao-Original-Outgoing-Id: 429390424.421653-c3b8ef77752a6542f150a16a6fef2551 Content-Transfer-Encoding: quoted-printable Message-Id: <6F21CB8D-F598-4C74-8E79-25C1F92A9561@tzi.org> References: , <64A628BA-EADA-4738-BB8D-2CFFDE8E6CF0@tzi.org> <3EE25B75-0EA3-4DE5-82CC-049C173E2A0B@cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/3JaCE0nGHtImnOD0dHn_sGvL3kw Cc: Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 19:07:22 -0000 On 10 Aug 2014, at 19:05, Pascal Thubert (pthubert) = wrote: > - it will take a year or 2 at best to agree on the new routing = dispatch and its operation. We need an improvement now. And btw we = cannot necessarily assume 6lo together with RPL, I know of at least one = RPL implementation that does not use that compression.=20 I don=92t understand why we can=92t do the saner equivalent of the flow = label hack now and come up with a source routing header (which is not = covered by the flow label hack) later. Please tell us more about how ISA100.11a uses the flow label; that is = information that has been lacking from the discussion so far. Gr=FC=DFe, Carsten From nobody Mon Aug 11 08:24:16 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15E41A01DC; Mon, 11 Aug 2014 06:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 1MwI2iCiGG0m; Mon, 11 Aug 2014 06:54:38 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576FA1A00C6; Mon, 11 Aug 2014 06:54:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,841,1400025600"; d="scan'208";a="134723257" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 11 Aug 2014 13:54:35 +0000 Received: from dhcp-10-61-111-110.cisco.com (dhcp-10-61-111-110.cisco.com [10.61.111.110]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7BDsYcV019128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2014 13:54:35 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\)) From: Ole Troan In-Reply-To: <53E534E8.4050304@gmail.com> Date: Mon, 11 Aug 2014 15:54:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1971.5) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/fp05GxA0sc0kY5jxtzkZ62U-_ek X-Mailman-Approved-At: Mon, 11 Aug 2014 08:24:12 -0700 Cc: Michael Richardson , Routing Over Low power and Lossy networks , 6man WG Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 11 Aug 2014 13:54:39 -0000 > I *really* don't think RFCs are algorithms to the point where we > need to do this. I see no reason why flow-label-for-rpl can't simply > declare itself an exception to this clause of RFC 6437. I must admit I'm uncomfortable with this draft and its approach. how can = we be sure that we aren't opening a Pandora's box? I'm worried that we set a precedence, and we'll see a new set of = creative proposals for the use of these 20 bits. cheers, Ole= From nobody Mon Aug 11 13:26:30 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 D011C1A0002; Mon, 11 Aug 2014 13:26:23 -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 B9y-KyjDNWLL; Mon, 11 Aug 2014 13:26:22 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7AA1A013B; Mon, 11 Aug 2014 13:26:22 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id r10so11222975pdi.6 for ; Mon, 11 Aug 2014 13:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6JFg7k7qbRCwyF0PghWdOOmyeOMe5+KS3o+Mlb9w+Tw=; b=OHP0/VsFyh/+cYdAW+IxSma7RKIr8JkX22uF4PZH+CZLoKL0J3lwE7UY8V0vYYq7dx RF24mmQyztWoQ1FRLMe+/NjTruc/sA3BTbxhx6sQyXRUr4TYXWYQcrgxm0uJh7WkqIwO RK+GZHXxK6sb5wXLGpQDJbDVnt3eiXPN0Rvq8lviEhPpIv5pnVD+fTWwb58+0SXhpUYT bpYsdZ9xIVWVwgtgSGM5MzxQymGJU3/NzoR9ivTLLTbPF9rcC8bUi8CiJNXCWDklcnpc EYtsVBUFmoJmtm5gkbg5yqqEZaJOXw3Phjy4B2BK6e2WzwRjCuzSs5F6hwb6mZ6qSvTe MNDA== X-Received: by 10.68.106.66 with SMTP id gs2mr76758pbb.141.1407788782157; Mon, 11 Aug 2014 13:26:22 -0700 (PDT) Received: from [192.168.178.23] (110.199.69.111.dynamic.snap.net.nz. [111.69.199.110]) by mx.google.com with ESMTPSA id dr9sm18824938pdb.78.2014.08.11.13.26.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 13:26:21 -0700 (PDT) Message-ID: <53E926EB.9000505@gmail.com> Date: Tue, 12 Aug 2014 08:26:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ole Troan References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/n3IR-pUOFy20w_Spn_LROsfwlTY Cc: Michael Richardson , Routing Over Low power and Lossy networks , 6man WG Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 11 Aug 2014 20:26:24 -0000 On 12/08/2014 01:54, Ole Troan wrote: >> I *really* don't think RFCs are algorithms to the point where we >> need to do this. I see no reason why flow-label-for-rpl can't simply >> declare itself an exception to this clause of RFC 6437. > > I must admit I'm uncomfortable with this draft and its approach. how can we be sure that we aren't opening a Pandora's box? > I'm worried that we set a precedence, and we'll see a new set of creative proposals for the use of these 20 bits. Well, that has been the case for a long time: see RFC 6294. I see the concern. Actually that's why I don't want to see a formal update to 6437, because the only rational update would be to allow any closed domain to invent its own usage. We had that argument at length during the development of 6437, and decided against it. Therefore, treating RPL as a special case is the remaining option. But does the ROLL community actually have consensus that they want this special case? Brian From nobody Mon Aug 11 23:11:39 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A981A0311; Mon, 11 Aug 2014 23:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8Py_fbzJ13Kn; Mon, 11 Aug 2014 23:08:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B036D1A0493; Mon, 11 Aug 2014 23:08:31 -0700 (PDT) Received: from localhost ([::1]:60249 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XH5G1-0000Ng-C0; Mon, 11 Aug 2014 23:08:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com X-Trac-Project: 6man Date: Tue, 12 Aug 2014 06:08:29 -0000 X-URL: http://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/7 Message-ID: <067.e9596359accc0ff63acaa0599b521b5b@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/js74qhU0F9E2OV55bT8XJeshctI X-Mailman-Approved-At: Mon, 11 Aug 2014 23:11:37 -0700 Cc: roll@ietf.org, 6man@ietf.org Subject: [Roll] [6man] #7 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Relation with RFC 6294 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 06:08:33 -0000 #7: draft-thubert-6man-flow-label-for-rpl-03 Relation with RFC 6294 From: Ines Robles Date: 2014-08-04 22:18 GMT+03:00 Should this draft (draft-thubert-6man-flow-label-for-rpl-03) update RFC 6294 as well, section 3.5 last paragraph, since talk about rpl-07 Section 7.2, which is related with flow-label-for-rpl? specially this part of RFC 6294:""..Such uses tend to encode specific local meanings or routing-related tags in the label, so they appear to infringe the dependency prohibition or the immutability of the Flow Label field. The ROLL group has indeed most recently opted not to use the Flow Label field for these reasons,..."" I think it should update this RFC as well, to have all the rfcs in accordance. Thank you, Ines. -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: new Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Keywords: -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Mon Aug 11 23:11:41 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A821A03B5; Mon, 11 Aug 2014 23:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sZU6KX-AKx6S; Mon, 11 Aug 2014 23:09:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7331A0311; Mon, 11 Aug 2014 23:09:58 -0700 (PDT) Received: from localhost ([::1]:60270 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XH5HR-0000UF-Ij; Mon, 11 Aug 2014 23:09:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6man issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com X-Trac-Project: 6man Date: Tue, 12 Aug 2014 06:09:57 -0000 X-URL: http://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/7#comment:1 Message-ID: <082.8a32746b4ccb455599e0dc90e61ef1c4@trac.tools.ietf.org> References: <067.e9596359accc0ff63acaa0599b521b5b@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <067.e9596359accc0ff63acaa0599b521b5b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/-E1B7fpFgA1Iy6CbBZYDIflkYD4 X-Mailman-Approved-At: Mon, 11 Aug 2014 23:11:37 -0700 Cc: roll@ietf.org, 6man@ietf.org Subject: Re: [Roll] [6man] #7 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Relation with RFC 6294 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 06:10:00 -0000 #7: draft-thubert-6man-flow-label-for-rpl-03 Relation with RFC 6294 Comment (by mariainesrobles@gmail.com): From: Adrian Farrel Date: 2014-08-05 17:07 GMT+03:00 “In as much as this I-D diverges from the statements in the IETF consensus document RFC 6294, I will have a relatively high bar for the demonstration of consensus on this document. I understand that RPL runs in a walled garden. In particular, while there may be control flows from outside the RPL network to inside it, those flows *currently* run through an intermediate application (such as a server). I also understand that in the future, when flows run direct between external and internal nodes they will still run through a gateway router. In the former case the flow label is terminated at the server and so we can safely describe the RPL network as a walled garden. In the latter case, however, it is not possible for the flow label to be preserved end-to-end, and the gateway router must impose a flow label on outgoing packets, while the flow label delivered to an end device will be meaningless. In order that this document be successful one of two things is going to be needed. 1. A clear statement that packets from within a RPL network that use the RPL flow label MUST NOT flow out of the RPL network, together with an explanation of how this is policed and guaranteed. More precisely: how will a router in the Internet know that the flow label on a packet was not applied by the source host? 2. A change to the flow label architecture has to be considered acceptable by the IETF community. It needs to be written up clearly stating that it is OK for a gateway router to proxy the source host and insert a flow label, how the gateway router determines what value to set, and why it will not matter to a receiving RPL host that the flow label has been lost. Furthermore, I think some consideration of end-to-end traffic that transits a RPL network may be needed. I don't believe that any of that should be presented as an Update to 6294. Rather, I think that this document needs to be completely clear *and* a new revision of 6294 will be required with the associated changes. Of course, an answer to all this would by IPv6-in-IPv6 encapsulation, but I doubt that that is considered acceptable in a world that is so short of bits. Cheers, Adrian -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: new Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Tue Aug 12 00:15: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 5ADEE1A0739; Tue, 12 Aug 2014 00:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo2bFEa2WOIR; Tue, 12 Aug 2014 00:15:11 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B621B1A06F3; Tue, 12 Aug 2014 00:15:10 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id hy10so12832003vcb.32 for ; Tue, 12 Aug 2014 00:15:09 -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 :cc:content-type; bh=gy1XcLulMPFJ974RoRkizcPmuzDx/+yImn7r2EW3Ulo=; b=0gQU4mrY+pJh2L8KtAMzV9WY60dZUYU+FzMFZDCCjlavGtGRoBHLeHiCMt5a8pdchj lQ7zCM6e4qeFT/DdcXSjVaNKJpa4M7QLUQcBpwKsZ47nXv6UgQLHQtEray57WdONlQXz 4J++NmxXPQoObmSElvHDhXD5L50gX3agL4XQsbJt6F3UTlscrDnaJNRC/tDI82C/owMM mFr1VkQVPwGQ7jhXHzh7Iu0yJz01cZBW9FJSnE62KD2ehZJvSVsdN98fBvcxyOYRD2UF CqA3JMCnFrOKmOIqwRHVqkU8TPqacE25jbNFKy0ObIAj+4/GwGp4k87tCiyx3uSkCE73 DT0g== MIME-Version: 1.0 X-Received: by 10.52.136.196 with SMTP id qc4mr22062846vdb.22.1407827709780; Tue, 12 Aug 2014 00:15:09 -0700 (PDT) Received: by 10.220.58.69 with HTTP; Tue, 12 Aug 2014 00:15:09 -0700 (PDT) In-Reply-To: <53E926EB.9000505@gmail.com> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> Date: Tue, 12 Aug 2014 10:15:09 +0300 Message-ID: From: Ines Robles To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=bcaec51b12bd8beb5e0500696ec5 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/2WkFeQh-dbJcSafzWMd0ejV53os Cc: Michael Richardson , Ole Troan , 6man WG Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 12 Aug 2014 07:15:12 -0000 --bcaec51b12bd8beb5e0500696ec5 Content-Type: text/plain; charset=UTF-8 Hi, On April, it was discussed and got consensus in ROLL [ http://www.ietf.org/mail-archive/web/roll/current/msg08634.html]. This technique saves bytes, as was demonstrated by Xavier in his implementation [ start on Slide 41 - https://bytebucket.org/6tisch/meetings/raw/712902bb451d113494a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plugfest_slides.pdf]. Maybe we should enumerate the advantages and disadvantages of using it. (Some of these are tracked in ticket #5, #6 and #7). Anyway, demostratedIt needs the 6man approval to go forward. Cheers, Ines 2014-08-11 23:26 GMT+03:00 Brian E Carpenter : > On 12/08/2014 01:54, Ole Troan wrote: > >> I *really* don't think RFCs are algorithms to the point where we > >> need to do this. I see no reason why flow-label-for-rpl can't simply > >> declare itself an exception to this clause of RFC 6437. > > > > I must admit I'm uncomfortable with this draft and its approach. how can > we be sure that we aren't opening a Pandora's box? > > I'm worried that we set a precedence, and we'll see a new set of > creative proposals for the use of these 20 bits. > > Well, that has been the case for a long time: see RFC 6294. > > I see the concern. Actually that's why I don't want to see a formal > update to 6437, because the only rational update would be to allow > any closed domain to invent its own usage. We had that argument at > length during the development of 6437, and decided against it. > Therefore, treating RPL as a special case is the remaining option. > But does the ROLL community actually have consensus that they want > this special case? > > Brian > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --bcaec51b12bd8beb5e0500696ec5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,


On April, it was discussed and got consensus in ROLL= [http://www.ietf.org/mail-archive/web/roll/cu= rrent/msg08634.html].


This technique saves bytes, as was demonstrated by X= avier in his implementation [ start on Slide 41 - https://bytebucket.org/6tisch/meetings/raw/712902bb451d1134= 94a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plug= fest_slides.pdf]. Maybe we should enumerate t= he advantages and disadvantages of using it. (Some of these are tracked in = ticket #5, #6 and #7).

=

Anyway, demostratedIt needs the 6man approval to go forw= ard.


Cheers,


Ines


2014-08= -11 23:26 GMT+03:00 Brian E Carpenter <brian.e.carpenter@gmail.c= om>:
On 12/08/2014 01:54, Ole Tro= an wrote:
>> I *really* don't think RFCs are algorithms to the point where = we
>> need to do this. I see no reason why flow-label-for-rpl can't = simply
>> declare itself an exception to this clause of RFC 6437.
>
> I must admit I'm uncomfortable with this draft and its approach. h= ow can we be sure that we aren't opening a Pandora's box?
> I'm worried that we set a precedence, and we'll see a new set = of creative proposals for the use of these 20 bits.

Well, that has been the case for a long time: see RFC 6294.

I see the concern. Actually that's why I don't want to see a formal=
update to 6437, because the only rational update would be to allow
any closed domain to invent its own usage. We had that argument at
length during the development of 6437, and decided against it.
Therefore, treating RPL as a special case is the remaining option.
But does the ROLL community actually have consensus that they want
this special case?

=C2=A0 =C2=A0Brian

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

--bcaec51b12bd8beb5e0500696ec5-- From nobody Tue Aug 12 01:40:59 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 830921A079F; Tue, 12 Aug 2014 01:40:55 -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 uBnI5sB4P3yw; Tue, 12 Aug 2014 01:40:53 -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 7F2101A0376; Tue, 12 Aug 2014 01:40:53 -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 s7C8eM80025798; Tue, 12 Aug 2014 10:40:22 +0200 (CEST) Received: from [192.168.217.145] (p54890742.dip0.t-ipconnect.de [84.137.7.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 67334B76; Tue, 12 Aug 2014 10:40:21 +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: Tue, 12 Aug 2014 10:40:19 +0200 X-Mao-Original-Outgoing-Id: 429525619.778124-1efd2775c48ffb70aab8faa6350b1af9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/JFIhH_97mBv4lSPxBM7vAnXbqWU Cc: Michael Richardson , Ole Troan , 6man WG Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 12 Aug 2014 08:40:55 -0000 On 12 Aug 2014, at 09:15, Ines Robles = wrote: > This technique saves bytes Again, the straw man at = http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00 saves the same number of bytes. Actually, for common cases, it enables = one additional optimization (saving one more byte) that is not available = with the flow label hack. (On the other hand, due to the way RFC 6282 = works, the flow label hack saves one byte where both it and ECN are in = use and the common case does not apply.) The disadvantage of the RPL mesh header is that this approach is not = available outside 6lo networks (i.e., networks employing adaptation = layers that use RFC 6282). I=92m not aware yet of a use case where that = is a problem. In either encoding (RPL mesh header or flow label), it is probably a = good idea anyway to unpack the compressed information back into the RPL = IPv6 option when leaving the 6lo networks. Gr=FC=DFe, Carsten From nobody Tue Aug 12 16:39:02 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 A864A1A0AD2; Tue, 12 Aug 2014 16:38:54 -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 IFRmJdn1jqBB; Tue, 12 Aug 2014 16:38:53 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157611A00E2; Tue, 12 Aug 2014 16:38:52 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id vb8so7695464obc.5 for ; Tue, 12 Aug 2014 16:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hx0eOEFOsL1cjdWvPyKPQ+FEYL6bofpFZsADj0TCRZs=; b=gJzCaqs+LtiFge/Gn7PLxiL5AibdC9gIuVwBJDBrx2kIlbbHgUx2E7HnXwoG81tXlc buPfc4/JT+tKtHo1M2S2RQd9ouMVB/B2wZ11xMhE5OhA8Z7Gl97i3V/jqXC+RSpa6hFH mWLIFg/q/vUQnz92xafvn1Z2TnCUYKObMKloOE7DBEexvQj1FADOFECvXSqklXK/l1Nk UHRZghq1c2YqLD8zmqInFDuTTSqvD7Ohz8KMZgxwBUujKq8gj8Xsf/zeBE57g7rYkuRy Cd2LBWSmNDSTRhA5eGWyNAfvdXsQRnaQgkKZ26ntc3xcJfRnd/QlsWNZYWSOmMWOMpob 68rA== X-Received: by 10.60.43.38 with SMTP id t6mr1146388oel.14.1407886731593; Tue, 12 Aug 2014 16:38:51 -0700 (PDT) Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id s64sm544813oif.5.2014.08.12.16.38.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Aug 2014 16:38:51 -0700 (PDT) Message-ID: <53EAA58D.4060401@gmail.com> Date: Wed, 13 Aug 2014 11:38:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ines Robles References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Jph8NMlyl7HGB-ulhGcFFQnM2Mc Cc: Routing Over Low power and Lossy networks , 6man WG Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 12 Aug 2014 23:38:54 -0000 Ines, Can you perhaps clarify the exact question you are asking 6man? (I'm thinking that 6man isn't being asked whether the number of bits saved is a useful energy saving, or whether Carsten's proposal is better.) Regards Brian On 12/08/2014 19:15, Ines Robles wrote: > Hi, > > On April, it was discussed and got consensus in ROLL [ > http://www.ietf.org/mail-archive/web/roll/current/msg08634.html]. > > This technique saves bytes, as was demonstrated by Xavier in his > implementation [ start on Slide 41 - > https://bytebucket.org/6tisch/meetings/raw/712902bb451d113494a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plugfest_slides.pdf]. > Maybe we should enumerate the advantages and disadvantages of using it. > (Some of these are tracked in ticket #5, #6 and #7). > > > Anyway, demostratedIt needs the 6man approval to go forward. > > Cheers, > > Ines > > > 2014-08-11 23:26 GMT+03:00 Brian E Carpenter : > >> On 12/08/2014 01:54, Ole Troan wrote: >>>> I *really* don't think RFCs are algorithms to the point where we >>>> need to do this. I see no reason why flow-label-for-rpl can't simply >>>> declare itself an exception to this clause of RFC 6437. >>> I must admit I'm uncomfortable with this draft and its approach. how can >> we be sure that we aren't opening a Pandora's box? >>> I'm worried that we set a precedence, and we'll see a new set of >> creative proposals for the use of these 20 bits. >> >> Well, that has been the case for a long time: see RFC 6294. >> >> I see the concern. Actually that's why I don't want to see a formal >> update to 6437, because the only rational update would be to allow >> any closed domain to invent its own usage. We had that argument at >> length during the development of 6437, and decided against it. >> Therefore, treating RPL as a special case is the remaining option. >> But does the ROLL community actually have consensus that they want >> this special case? >> >> Brian >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Aug 12 18:19:33 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 B391E1A6F87; Tue, 12 Aug 2014 18:19:22 -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 GnPSxfmrmhZp; Tue, 12 Aug 2014 18:19:21 -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 6E5C41A6F86; Tue, 12 Aug 2014 18:19:21 -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 s7D1JEe9009134; Wed, 13 Aug 2014 03:19:14 +0200 (CEST) Received: from [192.168.217.145] (p54890709.dip0.t-ipconnect.de [84.137.7.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 65C986F; Wed, 13 Aug 2014 03:19:13 +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: <53EAA58D.4060401@gmail.com> Date: Wed, 13 Aug 2014 03:19:12 +0200 X-Mao-Original-Outgoing-Id: 429585552.308666-c9e5bc6724d010c898925a744d2346d9 Content-Transfer-Encoding: quoted-printable Message-Id: <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/gnHDkAd7cWgb91jc-OvDGCNRqmc Cc: Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 13 Aug 2014 01:19:23 -0000 On 13 Aug 2014, at 01:38, Brian E Carpenter = wrote: > Can you perhaps clarify the exact question you are asking 6man? Well, I=92m not Ines, but I=92m trying to find out why we are in this = peculiar position of discussing this draft right now. ROLL has a routing protocol that requires some data to be shipped around = together with IP packets. RFC 6553 and 6554 define ways to do this that are consistent with the IP = architecture. Unfortunately, the overhead (signal-to-fluff ratio) is relatively high, = and in this area of application, that matters. Normally, the next step would have been looking at ways to do header = compression. We did talk about compressing ROLL, but with a view to compressing the = (control plane) ROLL messages, not so much about the (data plane) IP = packets themselves. GHC is trying to be a reasonably useful, but also = reasonably general way to do the control plane messages. For the data packets, the flow label (and its now predominant non-use) = provides an attractive hole in the IPv6 packets to ship around the RFC = 6533 information, but not the RFC 6554 information. In 6lo networks, normally RFC 6282 compresses away empty flow labels, = but it is cheap to put them in, so a flow label really only costs 3 = bytes (instead of 8 bytes RFC 6553 costs). The most useful information = from RFC 6553 can be stuffed into 19 bits, as demonstrated by the draft = we are discussing here. RFC 6282 has extension points (GHC uses one of them), but not really = useful ones for the ROLL data plane. So it appears it never occurred to us that the best way to handle these = 19 bits is to actually sidestep RFC 6282, and use the existing extension = points of RFC 4944. Until Laurent showed one way of doing this. I just = went from there and did a strawman using Laurent=92s idea for = compressing the RFC 6553 option, in a way that is as efficient as (or, = in most cases, actually more efficient than) using the flow label hole. So to me it seems there no longer is a good technical argument to ask = 6man to liberate the flow label for carrying RFC 6553. But that is maybe something that should now be discussed between 6lo and = ROLL; I don=92t think that this is a 6man issue (unless the answer is a = simple =93sure, go ahead, take it, we don=92t need it any more anyway=94, = which is not what I have perceived RFC 6437 to say). When 6lo and ROLL have generated consensus on the need to do this, we = may or may not want to go back to 6man and actually pry that flow label = hole out of your fingers. Gr=FC=DFe, Carsten From nobody Wed Aug 13 01:00: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 4E4F51A702B; Wed, 13 Aug 2014 01:00:15 -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 CYuYB6ZSjm1r; Wed, 13 Aug 2014 01:00:13 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C461A08D1; Wed, 13 Aug 2014 01:00:13 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id hy4so14831225vcb.27 for ; Wed, 13 Aug 2014 01:00:12 -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 :cc:content-type; bh=HWg2iR9QA75Mz2geZZ1ucbZ9sNX+CuR3KGhdegSzHDQ=; b=yy0GLPPfueRdjSiII+nH82JJ0XFLQgTvfyjiFrgTHx2CXW0QEZXtafv0sOyEnJCs2v UAYXRf88F6jDsN3DcTGsQstGfuWcfaYbiffVUAGTilxDC6sOchjke4oMljue2K5cPZ4L C2QY70dAK44FnfIu+kqgFmr1IcaXlVHyRLEq17xaMmFWI1EQH8gi83NmS3IuiNxCxg8i LWsVRonUthoJe5PYwxoeMA/BeklRmXmXV1cudPOHJ6rHAGxEmziNVaX2M5QD7r7YS5oO DWf2qawt74YHqNTUxkyCGWzKWLhypWCFbYxqXeIHeipXW4wNP49hSUtqybNqQ2g/X6WB 0MlA== MIME-Version: 1.0 X-Received: by 10.220.163.69 with SMTP id z5mr2344006vcx.10.1407916812404; Wed, 13 Aug 2014 01:00:12 -0700 (PDT) Received: by 10.220.58.69 with HTTP; Wed, 13 Aug 2014 01:00:12 -0700 (PDT) In-Reply-To: <53EAA58D.4060401@gmail.com> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> Date: Wed, 13 Aug 2014 11:00:12 +0300 Message-ID: From: Ines Robles To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1133da247a0b7105007e2de5 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/yqbU7vdAZwNNbKPzEzvtMohR1PU Cc: Routing Over Low power and Lossy networks , 6man WG Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 13 Aug 2014 08:00:15 -0000 --001a1133da247a0b7105007e2de5 Content-Type: text/plain; charset=UTF-8 Hi Brian, Thanks for your comment. Actually, I did not ask a question, I just wanted to say that the Pascal's draft got consensus at ROLL in april, and the WGLC was done between 6man and ROLL to know the 6man opinion about the use of flow-label (tickets #5, #6 and #7). With the new Carsten proposal (6lo draft), we (constrained environment WGs) should analyze this approach and decide the further steps on Pascal draft related with that. Thanks, Ines 2014-08-13 2:38 GMT+03:00 Brian E Carpenter : > Ines, > > Can you perhaps clarify the exact question you are asking 6man? > > (I'm thinking that 6man isn't being asked whether the number > of bits saved is a useful energy saving, or whether Carsten's > proposal is better.) > > Regards > Brian > > On 12/08/2014 19:15, Ines Robles wrote: > > Hi, > > > > On April, it was discussed and got consensus in ROLL [ > > http://www.ietf.org/mail-archive/web/roll/current/msg08634.html]. > > > > This technique saves bytes, as was demonstrated by Xavier in his > > implementation [ start on Slide 41 - > > > https://bytebucket.org/6tisch/meetings/raw/712902bb451d113494a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plugfest_slides.pdf > ]. > > Maybe we should enumerate the advantages and disadvantages of using it. > > (Some of these are tracked in ticket #5, #6 and #7). > > > > > > Anyway, demostratedIt needs the 6man approval to go forward. > > > > Cheers, > > > > Ines > > > > > > 2014-08-11 23:26 GMT+03:00 Brian E Carpenter < > brian.e.carpenter@gmail.com>: > > > >> On 12/08/2014 01:54, Ole Troan wrote: > >>>> I *really* don't think RFCs are algorithms to the point where we > >>>> need to do this. I see no reason why flow-label-for-rpl can't simply > >>>> declare itself an exception to this clause of RFC 6437. > >>> I must admit I'm uncomfortable with this draft and its approach. how > can > >> we be sure that we aren't opening a Pandora's box? > >>> I'm worried that we set a precedence, and we'll see a new set of > >> creative proposals for the use of these 20 bits. > >> > >> Well, that has been the case for a long time: see RFC 6294. > >> > >> I see the concern. Actually that's why I don't want to see a formal > >> update to 6437, because the only rational update would be to allow > >> any closed domain to invent its own usage. We had that argument at > >> length during the development of 6437, and decided against it. > >> Therefore, treating RPL as a special case is the remaining option. > >> But does the ROLL community actually have consensus that they want > >> this special case? > >> > >> Brian > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > >> > > > > > > ------------------------------------------------------------------------ > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > --001a1133da247a0b7105007e2de5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

Thanks for your comment.
<= div>
Actually, I did not ask a question, I just wanted to say= that the Pascal's draft got consensus at ROLL in april, and the WGLC w= as done between 6man and ROLL to know the 6man opinion about the use of flo= w-label (tickets #5, #6 and #7). With the new Carsten proposal (6lo draft),= we (constrained environment WGs) should analyze this approach and decide t= he further steps on Pascal draft related with that.

Thanks,

Ines
=


2014-08= -13 2:38 GMT+03:00 Brian E Carpenter <brian.e.carpenter@gmail.co= m>:
Ines,

Can you perhaps clarify the exact question you are asking 6man?

(I'm thinking that 6man isn't being asked whether the number
of bits saved is a useful energy saving, or whether Carsten's
proposal is better.)

Regards
=C2=A0 =C2=A0Brian

On 12/08/2014 19:15, Ines Robles wrote:
> Hi,
>
> On April, it was discussed and got consensus in ROLL [
> http://www.ietf.org/mail-archive/web/roll/current/m= sg08634.html].
>
> This technique saves bytes, as was demonstrated by Xavier in his
> implementation [ start on Slide 41 -
> https://bytebucket.org/6tisch/meetings/r= aw/712902bb451d113494a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/= ietf90_toronto_plugfest_slides.pdf].
> Maybe we should enumerate the advantages and disadvantages of using it= .
> (Some of these are tracked in ticket #5, #6 and #7).
>
>
> Anyway, demostratedIt needs the 6man approval to go forward.
>
> Cheers,
>
> Ines
>
>
> 2014-08-11 23:26 GMT+03:00 Brian E Carpenter <brian.e.carpenter@gmail.com>:
>
>> On 12/08/2014 01:54, Ole Troan wrote:
>>>> I *really* don't think RFCs are algorithms to the poin= t where we
>>>> need to do this. I see no reason why flow-label-for-rpl ca= n't simply
>>>> declare itself an exception to this clause of RFC 6437. >>> I must admit I'm uncomfortable with this draft and its app= roach. how can
>> we be sure that we aren't opening a Pandora's box?
>>> I'm worried that we set a precedence, and we'll see a = new set of
>> creative proposals for the use of these 20 bits.
>>
>> Well, that has been the case for a long time: see RFC 6294.
>>
>> I see the concern. Actually that's why I don't want to see= a formal
>> update to 6437, because the only rational update would be to allow=
>> any closed domain to invent its own usage. We had that argument at=
>> length during the development of 6437, and decided against it.
>> Therefore, treating RPL as a special case is the remaining option.=
>> But does the ROLL community actually have consensus that they want=
>> this special case?
>>
>> =C2=A0 =C2=A0Brian
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>
>
> ----------------------------------------------------------= --------------
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<= br> > --------------------------------------------------------------------

--001a1133da247a0b7105007e2de5-- From nobody Wed Aug 13 02:54: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 1FD8D1A07C0; Wed, 13 Aug 2014 02:54:08 -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 lOjyM-oGmHBV; Wed, 13 Aug 2014 02:54:06 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244F61A86E6; Wed, 13 Aug 2014 02:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3229; q=dns/txt; s=iport; t=1407923647; x=1409133247; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Wy0+wT8UH/s+sCZFCRT5OA/9ijdU+xj/U3zyQCViaoU=; b=Bfc8jVF7ipc1gOYjQRYL61FcgRRYqs6oO3X7j87jQSfqoxyoYt6RC8/F xlCAb1EyC5d6A9AZ1A35LOWyp/E7G582LaI4q8JXQfxDmynkYjkyBgzCf tFdt1B2ATX9gBG+s4I3LTCq0bgjLdKSaImza44mzrf1eR+Qv+VF2UWeUy A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAJg061OtJV2c/2dsb2JhbABaDoJ/gSkE1G0BgRQWd4QDAQEBBHkMBAIBCA4DBAEBAQodByERFAkIAQEEDgUIiCYDEcA2DYVDF40fgVYJHTEHBoMpgR0FimOGOokOkFmGM4MaQmyBB0E X-IronPort-AV: E=Sophos;i="5.01,856,1400025600"; d="scan'208";a="68847867" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 13 Aug 2014 09:54:05 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7D9s4pl027789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 09:54:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 04:54:04 -0500 From: "Pascal Thubert (pthubert)" To: Philip Levis Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAAAz3YlABynPRAAgwPkgAETF4SQ Date: Wed, 13 Aug 2014 09:54:03 +0000 Deferred-Delivery: Wed, 13 Aug 2014 09:53:00 +0000 Message-ID: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <23EA0E40-A503-4F7E-A4A9-7A33D43A215D@cs.stanford.edu> In-Reply-To: <23EA0E40-A503-4F7E-A4A9-7A33D43A215D@cs.stanford.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.52] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/mtfupbrJOa-kE2rlRuocn9pVBTs Cc: Michael Richardson , Routing Over Low power and Lossy networks , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 13 Aug 2014 09:54:08 -0000 Works for me,=20 thanks, Phil. Pascal > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: jeudi 7 ao=FBt 2014 19:35 > To: Pascal Thubert (pthubert) > Cc: Ralph Droms; Michael Richardson; Routing Over Low power and Lossy > networks; ipv6@ietf.org > Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 >=20 > Seems reasonable to me, although a bit cumbersome. I'd suggest >=20 > This document updates the IPv6 > Flow Label Specification [RFC6437], which stipulates that once the Flow > Label is set, forwarding nodes do not update it unless there are compel= ling > security reasons to do so. This document argues that saving energy in L= LNs > is another sufficiently compelling reason to modify the Flow Label. >=20 > Phil >=20 > On Aug 5, 2014, at 1:11 AM, Pascal Thubert (pthubert) > wrote: >=20 > > I think I see what you are saying, Phil. > > > > I can split 1.3 to isolate the deviations to 6437. > > > > I also need to move the following text from section 3 in that new > > section > > > > This may seem contradictory with the IPv6 > > Flow Label Specification [RFC6437] which stipulates that once it is > > set, the Flow Label is left unchanged; but the RFC also indicates a > > violation to the rule can be accepted for compelling reasons, and > > that security is a case justifying such a violation. This > > specification suggests that energy-saving is another compelling > > reason for a violation to the aforementioned rule. > > > > Proposed update for that text: > > > > This specification updates the IPv6 > > Flow Label Specification [RFC6437], which stipulates that once it is > > set, the Flow Label is left unchanged. [RFC6437] also indicates that > > a violation to the rule can be accepted for compelling reasons, > > but limit those compelling reasons to security related issues. This > > specification indicates that energy-saving is another compelling > > reason that justifies a violation to the aforementioned rule. > > > > What do you think? > > > > Cheers, > > > > Pascal > > > > > >> -----Original Message----- > >> From: Philip Levis [mailto:pal@cs.stanford.edu] > >> Sent: lundi 4 ao=FBt 2014 20:23 > >> To: Ralph Droms > >> Cc: Pascal Thubert (pthubert); Michael Richardson; Routing Over Low > >> power and Lossy networks; ipv6@ietf.org > >> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 > >> > >> > >> On Aug 4, 2014, at 11:10 AM, Ralph Droms > wrote: > >> > >>> > >>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) > >> wrote: > >>> > >>>> The change is now done, Ralph. > >>>> > >>>> The only difference between > >>>> draft-thubert-6man-flow-label-for-rpl-03 and > >> draft-thubert-6man-flow-label-for-rpl-04 is > >>>> > >>>> Updates: 6437 (if approved) > >>> > >>> I suggest adding a section to your doc that explains exactly what is > >>> being > >> updated in RFC 6437. > >>> > >>> - Ralph > >> > >> > >> I agree. I think some of the text in 1.3 can be re-used for this purpo= se. > >> > >> Phil From nobody Wed Aug 13 09:37: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 DA3361A0908; Wed, 13 Aug 2014 09:37:39 -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 5c38Gg58Kd9t; Wed, 13 Aug 2014 09:37:33 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEDA1A091F; Wed, 13 Aug 2014 09:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3882; q=dns/txt; s=iport; t=1407947848; x=1409157448; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TB9WueMH+log7hj8wbs53uHcHxfd35qLRzPaSqPJn3A=; b=HJ4HwgcpuCelcWxSML2RwOW6Bw3z3ZN3mR1K5e+K+s6rh5lBinEAPvyA rVKYd3iy5/HbEddSXKA2OG/UPvadYXvNee9qLGf6M4eS/CdLqNnh15/DW c2oa0OXH6KZpy0vBc9+MP10fzqU7zyIKYMGuL9gqlPaHCn/Vh61jERzMO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAPuT61OtJV2U/2dsb2JhbABagw1SVwTNHgqHSAGBFBZ3hAMBAQEEAQEBawsMBAIBCBEEAQEBCh0HIQYLFAkIAQEEAQ0FCAELiBoDEQ3BEg2FRBeNH4FcAQEBCRQxAgUGgymBHQWGEIRThjqEJoRokFmGM4FjHYFcbAGBDjk X-IronPort-AV: E=Sophos;i="5.01,857,1400025600"; d="scan'208";a="68959911" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 13 Aug 2014 16:37:27 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7DGbRaQ018587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 16:37:27 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 11:37:27 -0500 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter , Ines Robles Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAGeLZuUACNu7fA= Date: Wed, 13 Aug 2014 16:37:27 +0000 Deferred-Delivery: Wed, 13 Aug 2014 16:37:00 +0000 Message-ID: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> In-Reply-To: <53EAA58D.4060401@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.52] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/a6Y9zc-ElolNUp3k-zB3ukslfpc Cc: Routing Over Low power and Lossy networks , 6man WG Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 13 Aug 2014 16:37:40 -0000 Hi Brian: The question to 6MAN is really whether the use that the draft makes of the = flow label within the RPL domain is acceptable or not. In particular Sectio= n 1.3 does not force a particular usage of the flow label inside the LLN, i= t simply updates the rules of what is allowed and what is not within that d= omain, knowing that the root will set the label properly towards the Intern= et and reset it from the Internet. It is up to ROLL and other external standards adopting the work (ISA100, WC= I) to decide of its usefulness.=20 Cheers, Pascal > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: mercredi 13 ao=FBt 2014 01:39 > To: Ines Robles > Cc: Routing Over Low power and Lossy networks; 6man WG > Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 >=20 > Ines, >=20 > Can you perhaps clarify the exact question you are asking 6man? >=20 > (I'm thinking that 6man isn't being asked whether the number of bits save= d > is a useful energy saving, or whether Carsten's proposal is better.) >=20 > Regards > Brian >=20 > On 12/08/2014 19:15, Ines Robles wrote: > > Hi, > > > > On April, it was discussed and got consensus in ROLL [ > > http://www.ietf.org/mail-archive/web/roll/current/msg08634.html]. > > > > This technique saves bytes, as was demonstrated by Xavier in his > > implementation [ start on Slide 41 - > > > https://bytebucket.org/6tisch/meetings/raw/712902bb451d113494a7045e97 > 30f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plugfest_s > lides.pdf]. > > Maybe we should enumerate the advantages and disadvantages of using > it. > > (Some of these are tracked in ticket #5, #6 and #7). > > > > > > Anyway, demostratedIt needs the 6man approval to go forward. > > > > Cheers, > > > > Ines > > > > > > 2014-08-11 23:26 GMT+03:00 Brian E Carpenter > : > > > >> On 12/08/2014 01:54, Ole Troan wrote: > >>>> I *really* don't think RFCs are algorithms to the point where we > >>>> need to do this. I see no reason why flow-label-for-rpl can't > >>>> simply declare itself an exception to this clause of RFC 6437. > >>> I must admit I'm uncomfortable with this draft and its approach. how > >>> can > >> we be sure that we aren't opening a Pandora's box? > >>> I'm worried that we set a precedence, and we'll see a new set of > >> creative proposals for the use of these 20 bits. > >> > >> Well, that has been the case for a long time: see RFC 6294. > >> > >> I see the concern. Actually that's why I don't want to see a formal > >> update to 6437, because the only rational update would be to allow > >> any closed domain to invent its own usage. We had that argument at > >> length during the development of 6437, and decided against it. > >> Therefore, treating RPL as a special case is the remaining option. > >> But does the ROLL community actually have consensus that they want > >> this special case? > >> > >> Brian > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > >> > > > > > > ---------------------------------------------------------------------- > > -- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Aug 13 09:48: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 22EAE1A00F6; Wed, 13 Aug 2014 09:48:11 -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 8kNF8DdR09O1; Wed, 13 Aug 2014 09:48:09 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E0E1A0028; Wed, 13 Aug 2014 09:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5548; q=dns/txt; s=iport; t=1407948489; x=1409158089; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+pTBLZOyVz7nKaCMMmxMD+YTWI+/yeJVClIMUKVMaYk=; b=jjDKIxrRta/j8N+qXjgy4g1LfaMgeEOPRYbcxsArGkIKdhbuNd4HyGXV t3Bw0TbaJ4iFBXj0xVSPkhTdEhWSNwbyRW7hDdNUu6vqyC9E5SNmg76u5 9BqguC9GoMz+6tK6kb5boeKwuoUt4ZJZ2rZBTE7YzYQPEUVeZdyWHWqxf o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFACaW61OtJV2Q/2dsb2JhbABagw1SVwTNHgqHSAGBFBZ3hAMBAQEEAQEBawsMBAIBCA4DAQMBAQEKHQchBgsUAwYIAQEEAQ0FCBOIEwMRDcEUDYVEEwSJf4MggV8dMQcGgymBHQWKY4Y6iQ6QWYYzgWMdgVxsAYFH X-IronPort-AV: E=Sophos;i="5.01,857,1400025600"; d="scan'208";a="68961878" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 13 Aug 2014 16:48:07 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7DGm7FN029265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 16:48:07 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 11:48:07 -0500 From: "Pascal Thubert (pthubert)" To: Carsten Bormann , Routing Over Low power and Lossy networks Thread-Topic: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAGeLZuUAA34HwAAE+G98A== Date: Wed, 13 Aug 2014 16:48:06 +0000 Deferred-Delivery: Wed, 13 Aug 2014 16:47:00 +0000 Message-ID: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> In-Reply-To: <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.52] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/blzmGRaG-UZgKZytxae2Z--SvbY Cc: Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 13 Aug 2014 16:48:11 -0000 Hello Carsten: In my view, this work is not competing with 6lo: for the specific value of = keeping the draft whatever 6lo decides to do: - If this draft is not adopted, the flow label from LLN will probably stay = all zeroes as it is today and the goal of 6437 will not be achieved. There = is no way a device will waste 20 bits for a random that has no value inside= the LLN. The text tells the RPL root to set the flow label. - If this draft is not adopted, the root of the LLN will have to forward th= e flow label coming from the Internet down to the end destination device, d= eep in the mesh, wasting 20 bits in each frame. These is a waste that 6lo c= ompression will not be allowed to legally elide if today we decide that we = do not allow it. Note: even if the correspondent sets the FL to zeroes to h= elp the LLN, there is no way to guarantee that the flow label will not be s= et on the way since that much is lawful.=20 - If the draft is not adopted, existing usages in shipping standards that i= ncorporate IPv6 will stay borderline/unlawful. E.g. the draft legalizes the= way ISA100.11a uses the flow label for a stateful flow identification with= in the ISA100 domain. - If the draft is not adopted, we have no leverage over WCI that is definin= g the backbone router for ISA100.11a devices. The draft indicates that the = root should ensure that the flow label is correctly set when going outside,= which is a minor increment to WCI, if pushed in due time with a proper RFC= number that demands it.=20 The need for this work was agreed at ROLL. We need a better solution than a= vailable, for application in RPL domains, that are often but not necessaril= y congruent with 6LowPAN domains. I'm fully supportive to have a 6lo compression that will improve the situat= ion for a 6lowpan network, and at this point we have 3 proposals on the tab= le, Laurent's, yours, and mine, which is to have a routing dispatch for rou= te-over in parallel to the mesh dispatch that is mesh-under. I do hope we c= reate a momentum there and converge. But there is no guarantee. All in all, I will not drop something that works now, with running code and= all, and reached last call status, against the sirens of a compression tha= t will not solve the issues above. Cheers, Pascal > -----Original Message----- > From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: mercredi 13 ao=FBt 2014 03:19 > To: Routing Over Low power and Lossy networks > Cc: Ines Robles; 6man WG; 6lo@ietf.org WG > Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-= 03 >=20 > On 13 Aug 2014, at 01:38, Brian E Carpenter > wrote: >=20 > > Can you perhaps clarify the exact question you are asking 6man? >=20 > Well, I'm not Ines, but I'm trying to find out why we are in this peculia= r > position of discussing this draft right now. >=20 > ROLL has a routing protocol that requires some data to be shipped around > together with IP packets. > RFC 6553 and 6554 define ways to do this that are consistent with the IP > architecture. > Unfortunately, the overhead (signal-to-fluff ratio) is relatively high, a= nd in > this area of application, that matters. >=20 > Normally, the next step would have been looking at ways to do header > compression. > We did talk about compressing ROLL, but with a view to compressing the > (control plane) ROLL messages, not so much about the (data plane) IP > packets themselves. GHC is trying to be a reasonably useful, but also > reasonably general way to do the control plane messages. >=20 > For the data packets, the flow label (and its now predominant non-use) > provides an attractive hole in the IPv6 packets to ship around the RFC 65= 33 > information, but not the RFC 6554 information. > In 6lo networks, normally RFC 6282 compresses away empty flow labels, but > it is cheap to put them in, so a flow label really only costs 3 bytes (in= stead of > 8 bytes RFC 6553 costs). The most useful information from RFC 6553 can b= e > stuffed into 19 bits, as demonstrated by the draft we are discussing here= . >=20 > RFC 6282 has extension points (GHC uses one of them), but not really usef= ul > ones for the ROLL data plane. > So it appears it never occurred to us that the best way to handle these 1= 9 > bits is to actually sidestep RFC 6282, and use the existing extension poi= nts of > RFC 4944. Until Laurent showed one way of doing this. I just went from > there and did a strawman using Laurent's idea for compressing the RFC 655= 3 > option, in a way that is as efficient as (or, in most cases, actually mor= e > efficient than) using the flow label hole. >=20 > So to me it seems there no longer is a good technical argument to ask 6ma= n > to liberate the flow label for carrying RFC 6553. > But that is maybe something that should now be discussed between 6lo and > ROLL; I don't think that this is a 6man issue (unless the answer is a sim= ple > "sure, go ahead, take it, we don't need it any more anyway", which is not > what I have perceived RFC 6437 to say). > When 6lo and ROLL have generated consensus on the need to do this, we > may or may not want to go back to 6man and actually pry that flow label > hole out of your fingers. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo From nobody Wed Aug 13 09:51:29 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 453AC1A0936; Wed, 13 Aug 2014 09:51:25 -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 OxKR4SvenfMF; Wed, 13 Aug 2014 09:51:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BBD1A0415; Wed, 13 Aug 2014 09:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1868; q=dns/txt; s=iport; t=1407948684; x=1409158284; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UAg8jz6yjyMjUYPdUDe+doeVg49RkBjAEPoQNaAXxvw=; b=IBATIewe1AGLBI9F1rCwGLdUfaSKo83oEH3lQvRtnJkjjXSoRvhKKH09 dI/4JMmxCEPKXkNKqnNJgIPnjI3gUOjiNtK3bHlQNh8A+OKg/swyELkqk sqe6OzmKdOF+4prY87aqx7rxUkpkQPsaCK5rW2zgiU1SR9SDKva1brNDU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAESX61OtJA2K/2dsb2JhbABagw1SVwTNHgqHSAGBFBZ3hAMBAQEEAQEBawsMBAIBCA4DBAEBAQodBycLFAkIAgQBDQUIiCYDEQ3BCw2FRBeNH4FfHTEHBoMpgR0FhhCEU4Y6hCaITZMngWMdgVxsgUg X-IronPort-AV: E=Sophos;i="5.01,857,1400025600"; d="scan'208";a="347231243" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP; 13 Aug 2014 16:51:23 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7DGpMhU031948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 16:51:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 11:51:22 -0500 From: "Pascal Thubert (pthubert)" To: Carsten Bormann , Routing Over Low power and Lossy networks Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoADOBvRXAAsYswAAiNKGgAANrl6AABapBoAAAvlzgAA40uRw Date: Wed, 13 Aug 2014 16:51:21 +0000 Deferred-Delivery: Wed, 13 Aug 2014 16:51:00 +0000 Message-ID: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.52] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/6QM0zvceCRwndEk98Wh0VfvMme8 Cc: Michael Richardson , 6man WG Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 13 Aug 2014 16:51:25 -0000 I disagree, Carsten. To save all the bytes, we need to update the 6MAN rules and allow to change= a non-zero flow label, be it only to reset and elide it when coming from t= he Internet. More in my other answer to you today... Pascal > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: mardi 12 ao=FBt 2014 10:40 > To: Routing Over Low power and Lossy networks > Cc: Michael Richardson; 6man WG > Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 >=20 > On 12 Aug 2014, at 09:15, Ines Robles > wrote: >=20 > > This technique saves bytes >=20 > Again, the straw man at http://tools.ietf.org/html/draft-bormann-6lo-rpl- > mesh-00 > saves the same number of bytes. Actually, for common cases, it enables o= ne > additional optimization (saving one more byte) that is not available with= the > flow label hack. (On the other hand, due to the way RFC 6282 works, the > flow label hack saves one byte where both it and ECN are in use and the > common case does not apply.) >=20 > The disadvantage of the RPL mesh header is that this approach is not > available outside 6lo networks (i.e., networks employing adaptation layer= s > that use RFC 6282). I'm not aware yet of a use case where that is a prob= lem. >=20 > In either encoding (RPL mesh header or flow label), it is probably a good= idea > anyway to unpack the compressed information back into the RPL IPv6 option > when leaving the 6lo networks. >=20 > Gr=FC=DFe, Carsten >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Aug 13 10:31:27 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 55D8E1A06DB; Mon, 11 Aug 2014 23:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9i4K5MLaQRVD; Mon, 11 Aug 2014 23:21:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32131A0320; Mon, 11 Aug 2014 23:21:22 -0700 (PDT) Received: from localhost ([::1]:60864 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XH5ST-0008DB-5v; Mon, 11 Aug 2014 23:21:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6man issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com X-Trac-Project: 6man Date: Tue, 12 Aug 2014 06:21:21 -0000 X-URL: http://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/6#comment:2 Message-ID: <082.2a9a64f571bdc35b1c300be0302eaa91@trac.tools.ietf.org> References: <067.68f1bb748fae1493f1a4cf0c34b41253@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <067.68f1bb748fae1493f1a4cf0c34b41253@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/doAOnhyrBFxtSI2C_BirVa9__nw X-Mailman-Approved-At: Wed, 13 Aug 2014 10:31:24 -0700 Cc: roll@ietf.org, 6man@ietf.org Subject: Re: [Roll] [6man] #6 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 06:21:24 -0000 #6: draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation Comment (by mariainesrobles@gmail.com): Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21030.html From: Carsten Bormann Date: Sun, 10 Aug 2014 18:29:01 +0200 So far, we have mainly discussed the need for an optimization (it seems we now agree there is a need) and the interaction between the normative components of RFC 6437 and those of the draft at hand. I’d now like to bring up a different question: Is this the right approach? I have written up what appears to be a more natural approach in the strawman draft: http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00 Why are we doing the flow-label thing and not the more natural thing? [ ] because the flow label hack works on packets that leave the 6lo networks. • but do we really need to optimize this on the non-6lo networks? [ ] because the flow label hack has been around for a while and is now cast in stone. • is it? [ ] because there is a flaw with the way this has been integrated into the 6lo framework. • ______ (fill in the flaw) [ ] because ______ (fill in the reason) Inquiring minds want to know. Grüße, Carsten -------------------------------------- Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21034.html From: "Pascal Thubert (pthubert)" Date: Sun, 10 Aug 2014 17:05:34 +0000 Hi Carsten I think you jumped too quickly on my suggestion at 6lo. It makes a lot of sense to work on a 6lo routing dispatch and in particular enable the compression of all RPL artifacts. It will take some time to figure out what goes in there but my suggestion at 6lo includes routing header compression, RPL option, but also source destination if we decide to route fragments. I hope this happens and I'll see with Laurent if we use a respin of his draft or I start a new one. This work will be beneficial in the long run, but doubly fails to address the issues at stake here: - the draft proposes to update the rules in 6437 with stateful and with domain scoped operations. This is used by the draft itself but also by published and deployed standards that came up before 6437 (eg ISA100.11a) and we are now acknowledging and legalizing a de facto situation. - it will take a year or 2 at best to agree on the new routing dispatch and its operation. We need an improvement now. And btw we cannot necessarily assume 6lo together with RPL, I know of at least one RPL implementation that does not use that compression. Finally, Using a dispatch for the RPL option alone seems like a waste, but that is a discussion for 6lo. I'll publish there when I'm back from vacations. Cheers, Pascal --------------------------------------------------- Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21036.html From: Carsten Bormann Date: Sun, 10 Aug 2014 21:07:04 +0200 On 10 Aug 2014, at 19:05, Pascal Thubert (pthubert) wrote: > - it will take a year or 2 at best to agree on the new routing dispatch and its operation. We need an improvement now. And btw we cannot necessarily assume 6lo together with RPL, I know of at least one RPL implementation that does not use that compression. I don’t understand why we can’t do the saner equivalent of the flow label hack now and come up with a source routing header (which is not covered by the flow label hack) later. Please tell us more about how ISA100.11a uses the flow label; that is information that has been lacking from the discussion so far. Grüße, Carsten ------------------------------------------------------ Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21039.html From: Ole Troan Date: Mon, 11 Aug 2014 15:54:35 +0200 > I *really* don't think RFCs are algorithms to the point where we > need to do this. I see no reason why flow-label-for-rpl can't simply > declare itself an exception to this clause of RFC 6437. I must admit I'm uncomfortable with this draft and its approach. how can we be sure that we aren't opening a Pandora's box? I'm worried that we set a precedence, and we'll see a new set of creative proposals for the use of these 20 bits. cheers, Ole ------------------------------ Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21040.html From: Brian E Carpenter Date: Tue, 12 Aug 2014 08:26:19 +1200 Well, that has been the case for a long time: see RFC 6294. I see the concern. Actually that's why I don't want to see a formal update to 6437, because the only rational update would be to allow any closed domain to invent its own usage. We had that argument at length during the development of 6437, and decided against it. Therefore, treating RPL as a special case is the remaining option. But does the ROLL community actually have consensus that they want this special case? Brian -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: new Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Wed Aug 13 12:08: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 159881A047D; Wed, 13 Aug 2014 12:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 28Gaf_Yogfi9; Wed, 13 Aug 2014 12:08:15 -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 122791A0456; Wed, 13 Aug 2014 12:07:07 -0700 (PDT) Received: from gapx8.stanford.edu ([171.64.70.57]:64636 helo=[10.171.216.192]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XHdt3-000517-IJ; Wed, 13 Aug 2014 12:07:06 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: Date: Wed, 13 Aug 2014 12:07:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/zdXXB1sYbsCnil4PJT4YSiaG4jA Cc: Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 13 Aug 2014 19:08:19 -0000 On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) = wrote: > If this draft is not adopted, the flow label from LLN will probably = stay all zeroes as it is today and the goal of 6437 will not be = achieved. Pascal, I'm trying to reconcile your claim that the goal of 6437 is to = allow enclosed networks to use the flow label with Brian's statement > Actually that's why I don't want to see a formal > update to 6437, because the only rational update would be to allow > any closed domain to invent its own usage. We had that argument at > length during the development of 6437, and decided against it. Phil From nobody Wed Aug 13 12:11: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 A1D931A0489 for ; Wed, 13 Aug 2014 12:11:14 -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 I9EFqoQp9eaK for ; Wed, 13 Aug 2014 12:11:08 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842431A047D for ; Wed, 13 Aug 2014 12:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=964; q=dns/txt; s=iport; t=1407957070; x=1409166670; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OOwtFrY5O16EmOfirmiajTzc+0jwEVFmEjgHUd+ZFBk=; b=AwoxoG+J0KCDYZ37oObjodd0qeU5kBdgAurIjvVzPej/yyNIVAdcRYAU /lIR3ggCP+9ATjK3eK4f3mvwzfE5MI82JTFCqY7YE/OZA0zGM/1lr1UKN mVDmg9HjmQ3fZ3hbp5XTcwQZJF/SKUwvjtlkbhGd3dwnaJ9V2HGKuAWZA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFACC361OtJV2T/2dsb2JhbABagw1SV80kCodIAYEWFneEAwEBAQMBAQEBaxALAgEIGC4nCyUCBBOIOggNxwcTBI57AQEcOoMvgR0FimOGOosclH6DXGyBDw X-IronPort-AV: E=Sophos;i="5.01,857,1400025600"; d="scan'208";a="69000483" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP; 13 Aug 2014 19:11:09 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7DJB7Ga028548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 Aug 2014 19:11:07 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 14:11:07 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPtyoH9NpmEOvPPUCuS34Wv0nHR5vO5laX Date: Wed, 13 Aug 2014 19:11:06 +0000 Message-ID: <181D3791-227B-44D7-9368-E69CEAD03A52@cisco.com> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> , <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> In-Reply-To: <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/nBa5DP9dtgF1jw24NZXhXeA1FdY Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 13 Aug 2014 19:11:14 -0000 Phil, is this your complete mail? Pascal > Le 13 ao=FBt 2014 =E0 21:08, "Philip Levis" a =E9cr= it : >=20 >> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) wrote: >>=20 >> If this draft is not adopted, the flow label from LLN will probably stay= all zeroes as it is today and the goal of 6437 will not be achieved. >=20 > Pascal, I'm trying to reconcile your claim that the goal of 6437 is to al= low enclosed networks to use the flow label with Brian's statement >=20 >> Actually that's why I don't want to see a formal >> update to 6437, because the only rational update would be to allow >> any closed domain to invent its own usage. We had that argument at >> length during the development of 6437, and decided against it. >=20 > Phil >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Aug 13 12:12:03 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EF71A0489; Wed, 13 Aug 2014 12:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 lRJb3vwL0HaL; Wed, 13 Aug 2014 12:11:52 -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 4E2031A047D; Wed, 13 Aug 2014 12:11:52 -0700 (PDT) Received: from gapx8.stanford.edu ([171.64.70.57]:64640 helo=[10.171.216.192]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XHdxc-0005n6-GK; Wed, 13 Aug 2014 12:11:52 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Philip Levis In-Reply-To: Date: Wed, 13 Aug 2014 12:11:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 5fb79390a4aad79c01ba7e4883e5f1df Archived-At: http://mailarchive.ietf.org/arch/msg/roll/4QvfWGH_Y61d6A_wOszxNitBPDo Cc: Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 13 Aug 2014 19:11:58 -0000 On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) = wrote: > The need for this work was agreed at ROLL. We need a better solution = than available, for application in RPL domains, that are often but not = necessarily congruent with 6LowPAN domains. This seems to me to be the strong technical argument in favor of the = draft. While Carsten's approach seems better technically, it only works = for 6lowpan, and RPL should be independent of the underlying link layer. Phil= From nobody Wed Aug 13 12:50:04 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9321A0467; Wed, 13 Aug 2014 12:50:00 -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 Pawfxn1FC44E; Wed, 13 Aug 2014 12:49:54 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2971A039B; Wed, 13 Aug 2014 12:49:53 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so187149qaq.38 for ; Wed, 13 Aug 2014 12:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n5qLDiMq4w1HINQl3Suub/E/OA70xC9ch92L2W73Io4=; b=qwTq6XiM4HCehhOLRjitw1hgDBuroxxmm62JlbN47ARD3vFTPKd9WE3GOhNNNeVUwM qI97+mOcQbwPuha/U7gOnwhGwutsMDx8duX9bJwdx4YRihLS6NEcyTQYZuPjxUbTRSa9 ue35QUNmWZOtgF3wtOxIE3rz43EDHqfpq5Is1JT5yShOg0qx3VjaV2goi+tjT0+Dtlcd Ec3/Yl+NhJxTN3hCeaYlfnCu5Cp0qsto8MeW6vG6cKXbCtZbiG04NP5mfA/apcODnnJF SIi5YASqBMk7mNvExvrN6UQ6lpLvWtj/PPHqxilKOfSO+Q2UgmCr6QVCamPK4r5sbEAd Uwrw== X-Received: by 10.224.65.196 with SMTP id k4mr10501569qai.56.1407959392649; Wed, 13 Aug 2014 12:49:52 -0700 (PDT) Received: from [10.86.254.61] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id u5sm4839422qae.18.2014.08.13.12.49.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Aug 2014 12:49:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: Date: Wed, 13 Aug 2014 15:49:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/6JSk2BzTM6WlbMmFKaQ2fx5W-xo Cc: Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 13 Aug 2014 19:50:00 -0000 On Aug 13, 2014, at 3:11 PM 8/13/14, Philip Levis = wrote: > On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) = wrote: >=20 >> The need for this work was agreed at ROLL. We need a better solution = than available, for application in RPL domains, that are often but not = necessarily congruent with 6LowPAN domains. >=20 > This seems to me to be the strong technical argument in favor of the = draft. While Carsten's approach seems better technically, it only works = for 6lowpan, and RPL should be independent of the underlying link layer. Could we consider Carsten's approach a compression mechanism for the RPL = information options, rather than a replacement, thereby allowing a = one-to-one translation between compressed mode on 6lowpan networks and = uncompressed mode in other networks? - Ralph >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Aug 13 13:52:59 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 C69581A0113; Wed, 13 Aug 2014 13:52: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 szv7RmgRVe8s; Wed, 13 Aug 2014 13:52:55 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFD71A0087; Wed, 13 Aug 2014 13:52:54 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id z10so322066pdj.30 for ; Wed, 13 Aug 2014 13:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Zq13KrjxWEgsU/gEsK0K7I24Yu7AmKYu8Whd/3LQluI=; b=P5dVZO2yPUMgoq7rNcrYoW22KJDT282OBCB4+znGS3XAxfYOynoq8ky45dd4c+wODl +UZI+NmKuQ5CwYJDCtxPKiYP5iMNGi1KAhAdoVAlIHXKfAfDGE/YFRikK4wIWTR/E2+i ZYy6nxmpxcassPPdYg8jMm89ctWq/k9EDb77pmntJUEfu+6NEViEiEBQ03oCgeNJPTH7 lC1nUBSGO9WA0jP1MziwQrCGaL/9JiI7ZXKnAynZc44Nx/FeqE5rBxaumloUcbylMHNG 8m20FlwjjITsuZ2axglbF0k+MiQie5zQZlnshluH6aus3FCr+uiGUY3/3/HcMxfpGt2O glNw== X-Received: by 10.70.61.162 with SMTP id q2mr6166813pdr.50.1407963174616; Wed, 13 Aug 2014 13:52:54 -0700 (PDT) Received: from [192.168.178.23] (60.199.69.111.dynamic.snap.net.nz. [111.69.199.60]) by mx.google.com with ESMTPSA id dn3sm3025074pbc.79.2014.08.13.13.52.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Aug 2014 13:52:53 -0700 (PDT) Message-ID: <53EBD028.30302@gmail.com> Date: Thu, 14 Aug 2014 08:52:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Levis References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> In-Reply-To: <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/rnDJqY9binfP-gohvDiQ0ksyh_Q Cc: Routing Over Low power and Lossy networks , Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 13 Aug 2014 20:52:57 -0000 On 14/08/2014 07:07, Philip Levis wrote: > On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) wrote: > >> If this draft is not adopted, the flow label from LLN will probably stay all zeroes as it is today and the goal of 6437 will not be achieved. > > Pascal, I'm trying to reconcile your claim that the goal of 6437 is to allow enclosed networks to use the flow label with Brian's statement > >> Actually that's why I don't want to see a formal >> update to 6437, because the only rational update would be to allow >> any closed domain to invent its own usage. We had that argument at >> length during the development of 6437, and decided against it. > > Phil Right. I'm drawing a very subtle line between (a) stating an exception to 6437 for this particular usage and (b) opening the door to other usages. Since 6man clearly didn't want (b) during the development of 6437 I think we do need to limit ourselves to (a). Brian From nobody Wed Aug 13 14:02:42 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88FE1A024C; Wed, 13 Aug 2014 14:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.348 X-Spam-Level: ** X-Spam-Status: No, score=2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, 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 3-U63D7qrw_1; Wed, 13 Aug 2014 14:02:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB601A0240; Wed, 13 Aug 2014 14:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7DL2WAY010151; Wed, 13 Aug 2014 23:02:32 +0200 (CEST) Received: from [192.168.217.106] (p54890314.dip0.t-ipconnect.de [84.137.3.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EECFB646; Wed, 13 Aug 2014 23:02:31 +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: <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> Date: Wed, 13 Aug 2014 23:02:30 +0200 X-Mao-Original-Outgoing-Id: 429656550.493394-0b0371c33024aed2238ba978ba9bb142 Content-Transfer-Encoding: quoted-printable Message-Id: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/6tzjG-7Jv4A4FtG0TFEBxtvrIuw Cc: 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 13 Aug 2014 21:02:39 -0000 >> This seems to me to be the strong technical argument in favor of the = draft. While Carsten's approach seems better technically, it only works = for 6lowpan, and RPL should be independent of the underlying link layer. The transport of RPL specific information for data plane packets already = *is* independent of the underlying link layer, as specified in RFC 6553 = and RFC 6554. All we are talking about here is an optimization for = those (for 6553, specifically; actually 6554 is probably the one even = more in need). > Could we consider Carsten's approach a compression mechanism for the = RPL information options, rather than a replacement, thereby allowing a = one-to-one translation between compressed mode on 6lowpan networks and = uncompressed mode in other networks? Indeed, that is probably the best way to view this approach. (In the next version of the draft, I=92ll emphasize this.) My assumption here is: =97 Any subnet that could not live with transporting RFC 6553 as is, = i.e. 8 bytes extra compared to the flow label approach (for uncompressed = packets*), already needs (and, at this point, has) a header compression = solution for the expansive IPv6 header anyway. So adding RFC 6553 compression to that solution is the natural = approach. =97 All subnets that can live with the IPv6 header as is, also can live = with RFC 6553 as is. This argument is on a technical level. I=92m not talking about cognitive dissonance**) here, or political = issues. If there are important political issues (I have no idea what the = ISA100/WCI talk is about), they probably need to be brought out in the = open here. Gr=FC=DFe, Carsten *) less difference for header-compressed packets, e.g., 5 bytes for 6lo. **) http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf, = section 2.6 From nobody Wed Aug 13 16:16:55 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938781A0394 for ; Wed, 13 Aug 2014 16:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.093 X-Spam-Level: X-Spam-Status: No, score=-0.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, URI_OBFU_WWW=2.475] 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 NN2ancU3me_U for ; Wed, 13 Aug 2014 16:16:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252711A0379 for ; Wed, 13 Aug 2014 16:16:47 -0700 (PDT) Received: from localhost ([::1]:37916 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XHhmD-0007MZ-Pj; Wed, 13 Aug 2014 16:16:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-security-threats@tools.ietf.org, mcr@sandelman.ca X-Trac-Project: roll Date: Wed, 13 Aug 2014 23:16:17 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/161 Message-ID: <058.7be8c643f06932abb6e79142aa12d356@trac.tools.ietf.org> X-Trac-Ticket-ID: 161 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-security-threats@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: angel.lozano@upf.edu, mcr+ietf@sandelman.ca, mischa.dohler@cttc.es, roger.alexander@cooperindustries.com, tzeta.tsao@cooperindustries.com, vanesa.daza@upf.edu Archived-At: http://mailarchive.ietf.org/arch/msg/roll/b38BURxrXU3TTlLxw-f8GEPv8QM Cc: roll@ietf.org Subject: [Roll] [roll] #161 (security-threats): AD review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 23:16:48 -0000 #161: AD review {{{ Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3:216:3eff:fe7c:d1f3] by obiwan.sandelman.ca with IMAP (fetchmail-6.3.21) for (single-drop); Fri, 08 Aug 2014 16:30:03 -0400 (EDT) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus v2.4.16-Debian-2.4.16-4+deb7u1) with LMTPA; Fri, 08 Aug 2014 13:03:30 -0400 X-Sieve: CMU Sieve 2.4 Received: from colo4.roaringpenguin.com (colo4.roaringpenguin.com [174.142.115.36]) by tuna.sandelman.ca (Postfix) with ESMTPS id AC73120028 for ; Fri, 8 Aug 2014 13:03:30 -0400 (EDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) by colo4.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id s78H0odl032055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 8 Aug 2014 13:00:52 -0400 Resent-Date: Fri, 8 Aug 2014 13:00:52 -0400 Resent-From: draft-alias-bounces@tools.ietf.org Resent-Message-Id: <201408081700.s78H0odl032055@colo4.roaringpenguin.com> Received: from asmtp2.iomartmail.com ([62.128.201.249]:59423) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XFnX2-0007W6-Bm for draft-ietf-roll-security-threats@tools.ietf.org; Fri, 08 Aug 2014 10:00:46 -0700 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s78H0Xht019353; Fri, 8 Aug 2014 18:00:33 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s78H0WHH019345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Aug 2014 18:00:32 +0100 Reply-To: From: "Adrian Farrel" To: Cc: Date: Fri, 8 Aug 2014 18:00:31 +0100 Message-ID: <039901cfb32a$4396fa40$cac4eec0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+zKjbjWAt8/OXPR76hTX4S1nHWDg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20868.000 X-TM-AS-Result: No--10.129-10.0-31-10 X-imss-scan-details: No--10.129-10.0-31-10 X-TMASE-MatchedRID: uM/FAQ+OoQfLLefpbEkxkJmug812qIbzbv16+gil4jc3Z3efQH+wj0j8 AtVpDcmg30nY8d71auJnI/RGosR8EpVSBURTFYjQoMo9pWsaF6VlrsuS5tC+P/W2znIlYDjDRiX 6fzbAQPUvK5dSZworPLHR1wcQzR2o06P6nK44odAItCy6ZX/lLx852jgffnmI+yNYYwngrxbvv/ IA2HPk+OByqm2JX7QD3Fu/vVUHOxojc2rIhESDRt35+5/2Rxqmbb9qvlMXO4Kyd65qZFFPk2mCt i+JzZB1MzGNNFA7dQEbZLZQawUR5v3oDYuWRaGYEhGH3CRdKUUHZg6HZbmAcfgnJH5vm2+g1BoO 0FXL0sgf8ff5tbWyxfcKXYM536/nF0rpaZ47th8SuhBXNJb1dEyQ5fRSh265BMjYv8ffQVVnKwn YEuaPmLjObRk3pjhHg8SU+T+Au5YzjsQsSbMmptcd9O3aJYmbRtu4vtjjtzQJW4Re2U2py2Rkbo 3bzUFsYu0aFyYZk872vyDIp/5VLuVHGbcDbAq6OX/V8P8ail3Yr6U3ZlQkdsRB0bsfrpPIfiAqr jYtFiQXY+x/7KhI2QdJb2/QOA/yhaNhoUTlUMsjarW1v8ENY37cGd19dSFd X-SA-Exim-Connect-IP: 62.128.201.249 X-SA-Exim-Rcpt-To: draft-ietf-roll-security-threats@tools.ietf.org X-SA-Exim-Mail-From: adrian@olddog.co.uk X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on zinfandel.tools.ietf.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2 autolearn=no autolearn_force=no version=3.4.0 Subject: AD review of draft-ietf-roll-security-threats X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: angel.lozano@upf.edu, mcr+ietf@sandelman.ca, mischa.dohler@cttc.es, roger.alexander@cooperindustries.com, tzeta.tsao@cooperindustries.com, vanesa.daza@upf.edu List-ID: X-Bayes-Prob: 0.0001 (Score 0, tokens from: mcr, @@RPTN) X-Spam-Score: -0.10 () [Hold at 5.10] SPF(none:0),DKIM(none:0),RBL(rp- good:-0.1) X-CanIt-Geo: ip=64.170.98.42; country=US; latitude=38.0000; longitude=-97.0000; http://maps.google.com/maps?q=38.0000,-97.0000&z=6 X-CanItPRO-Stream: sandelman-ca:mcr (inherits from sandelman-ca:default ,rp-customers:default,base:default) X-Canit-Stats-ID: 02MAh0PnT - 101c2b520d28 - 20140808 X-Antispam-Training-Forget: https://antispam.roaringpenguin.com/canit/b.php?i=02MAh0PnT&m=101c2b520d28&t=20140808&c=f X-Antispam-Training-Nonspam: https://antispam.roaringpenguin.com/canit/b.php?i=02MAh0PnT&m=101c2b520d28&t=20140808&c=n X-Antispam-Training-Spam: https://antispam.roaringpenguin.com/canit/b.php?i=02MAh0PnT&m=101c2b520d28&t=20140808&c=s X-CanIt-Archive-Cluster: irqpXI7aJGyo4Ewta7qVH399FOg X-Scanned-By: CanIt (www . roaringpenguin . com) on 174.142.115.36 Hi authors, I have conducted my usual AD review of your document having received a publication request. The purpose of the review is to make sure that the document is in the best possible shape to go through IETF last call and IESG evaluation. Thank you for taking the time and investing the effort on this important document. I find the content readable and easy to understand (thank you). I'm not a security expert, but what you have written is clear and credible. Good job! There is just a small set of editorial issues that I would like you to clean up before I run the IETF last call. I'll put the document into "Revised I-D Needed" state and wait for you to post a revision. Thanks for the work, Adrian ===- The references are a mess as indicated by idnits and the Shepherd write-up. http://www.ietf.org/tools/idnits?url=http://www.ietf.org/archive/id/draft- ietf-r oll-security-threats-08.txt The point here is that you can't just include something in the references section because you think it is a fine document or you are friends with the author :-) If a document is worth reading in the context of this I-D, then there should be a mention of it somewhere (appropriate) in the text. If there is nowhere that you find it appropriate to mention the reference, then remove it from the references section. [I-D.ietf-roll-terminology] is now RFC 7102. --- A few abbreviations are used without expansion. I found MPLS, ESSID/PAN, CCM, PANA, EAP-TLS, DODAG. --- Your one use of RFC 2119 language outside Section 8 is unnecessary. RPL uses multicast as part of it's protocol, and therefore mechanisms which RPL uses to secure this traffic MAY be applicable to MPL control traffic as well: the important part is that the threats are similiar. s/it's/its/ s/MAY/might also/ s/similiar/similar/ Furthermore, while your use of 2119 in Section 8 is fine with me, it is not in harmony with the boilerplate you have included after the Abstract. I suggest you move it to Section 3, and have it read... Although this is not a protocol specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] in order to clarify and emphasize the guidance and directions to implementers and deployers of LLN nodes that utilize RPL. --- 4.3 is a helpful way to present things. I think that "Limited energy, memory, and processing node resources" also needs to highlight the increased susceptibility of LLN nodes to denial of service attacks since it is not only easier o swamp such nodes, but they can be exhausted to the extent that they are never able to function again! Such an attack may be mounted through the routing plane (and impact both routing and data forwarding) or through the data plane (to impact both forwarding and routing). Thus, there is also an interdependency between the two planes that may be tighter in LLNs than in other networks. }}} -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-security- mcr@sandelman.ca | threats@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: security- | Version: threats | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: roll From nobody Wed Aug 13 16:17: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 9666C1A03E1 for ; Wed, 13 Aug 2014 16:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uJXNIf7WO9x2 for ; Wed, 13 Aug 2014 16:16:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D8391A041A for ; Wed, 13 Aug 2014 16:16:58 -0700 (PDT) Received: from localhost ([::1]:37934 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XHhms-0000Js-1c; Wed, 13 Aug 2014 16:16:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mcr@sandelman.ca X-Trac-Project: roll Date: Wed, 13 Aug 2014 23:16:57 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/161#comment:1 Message-ID: <073.5662a509575eb83dbc044a459e388d6b@trac.tools.ietf.org> References: <058.7be8c643f06932abb6e79142aa12d356@trac.tools.ietf.org> X-Trac-Ticket-ID: 161 In-Reply-To: <058.7be8c643f06932abb6e79142aa12d356@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/T28g6odDMGmEXgl2pWqQZvzeXZY Cc: roll@ietf.org Subject: Re: [Roll] [roll] #161 (security-threats): AD review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 23:17:14 -0000 #161: AD review Changes (by mcr@sandelman.ca): * owner: draft-ietf-roll-security-threats@tools.ietf.org => mcr@sandelman.ca * status: new => assigned -- -----------------------------------+------------------------------- Reporter: mcr@sandelman.ca | Owner: mcr@sandelman.ca Type: enhancement | Status: assigned Priority: major | Milestone: milestone1 Component: security-threats | Version: Severity: Submitted WG Document | Resolution: Keywords: | -----------------------------------+------------------------------- Ticket URL: roll From nobody Wed Aug 13 17:42:30 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 DDE531A0640 for ; Wed, 13 Aug 2014 17:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uTDgAg4BsyWW for ; Wed, 13 Aug 2014 17:42:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7FAD1A0639 for ; Wed, 13 Aug 2014 17:42:27 -0700 (PDT) Received: from localhost ([::1]:42172 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XHj7b-0007Kz-Ea; Wed, 13 Aug 2014 17:42:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 14 Aug 2014 00:42:27 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/161#comment:2 Message-ID: <073.1b9e4f7fea0dc39ea2d2eef9b95e4ced@trac.tools.ietf.org> References: <058.7be8c643f06932abb6e79142aa12d356@trac.tools.ietf.org> X-Trac-Ticket-ID: 161 In-Reply-To: <058.7be8c643f06932abb6e79142aa12d356@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/YRp43xxO9QZFM7wwPJeFHRImrYQ Cc: roll@ietf.org Subject: Re: [Roll] [roll] #161 (security-threats): AD review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 00:42:29 -0000 #161: AD review Comment (by mcr@sandelman.ca): Replying to [ticket:161 mcr@…]: > The references are a mess as indicated by idnits and the Shepherd > write-up. > > http://www.ietf.org/tools/idnits?url=http://www.ietf.org/archive/id /draft-ietf-r > oll-security-threats-08.txt Fixed. > The point here is that you can't just include something in the > references section because you think it is a fine document or you are > friends with the author :-) If a document is worth reading in the > context of this I-D, then there should be a mention of it somewhere > (appropriate) in the text. If there is nowhere that you find it > appropriate to mention the reference, then remove it from the references > section. removed manhy of them, added specific references. -- -----------------------------------+------------------------------- Reporter: mcr@sandelman.ca | Owner: mcr@sandelman.ca Type: enhancement | Status: assigned Priority: major | Milestone: milestone1 Component: security-threats | Version: Severity: Submitted WG Document | Resolution: Keywords: | -----------------------------------+------------------------------- Ticket URL: roll From nobody Wed Aug 13 17:43:33 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 BE7BC1A0639 for ; Wed, 13 Aug 2014 17:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nfqbZ5qC0ase for ; Wed, 13 Aug 2014 17:43:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88DD91A0468 for ; Wed, 13 Aug 2014 17:43:25 -0700 (PDT) Received: from localhost ([::1]:42209 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XHj8X-0007a9-FS; Wed, 13 Aug 2014 17:43:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 14 Aug 2014 00:43:25 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/161#comment:3 Message-ID: <073.29d26b960cf2ebb15b0d0a0bbbc55142@trac.tools.ietf.org> References: <058.7be8c643f06932abb6e79142aa12d356@trac.tools.ietf.org> X-Trac-Ticket-ID: 161 In-Reply-To: <058.7be8c643f06932abb6e79142aa12d356@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/b7dYu3pbubzvBaTDrn7QGLQ8XME Cc: roll@ietf.org Subject: Re: [Roll] [roll] #161 (security-threats): AD review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 00:43:31 -0000 #161: AD review Comment (by mcr@sandelman.ca): Replying to [ticket:161 mcr@…]: > A few abbreviations are used without expansion. > > I found MPLS, ESSID/PAN, CCM, PANA, EAP-TLS, DODAG. I did not find MPLS. The rest I added to the terminology section. -- -----------------------------------+------------------------------- Reporter: mcr@sandelman.ca | Owner: mcr@sandelman.ca Type: enhancement | Status: assigned Priority: major | Milestone: milestone1 Component: security-threats | Version: Severity: Submitted WG Document | Resolution: Keywords: | -----------------------------------+------------------------------- Ticket URL: roll From nobody Wed Aug 13 17:45:07 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E111D1A0651 for ; Wed, 13 Aug 2014 17:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0MM7QydBrrII for ; Wed, 13 Aug 2014 17:45:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8445A1A0468 for ; Wed, 13 Aug 2014 17:45:04 -0700 (PDT) Received: from localhost ([::1]:42287 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XHjA8-0007sr-Eb; Wed, 13 Aug 2014 17:45:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 14 Aug 2014 00:45:04 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/161#comment:4 Message-ID: <073.c4d4f5e8e327687dfc75530b8c0d4a4f@trac.tools.ietf.org> References: <058.7be8c643f06932abb6e79142aa12d356@trac.tools.ietf.org> X-Trac-Ticket-ID: 161 In-Reply-To: <058.7be8c643f06932abb6e79142aa12d356@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/7lgxzZR4Jd8sZiVa_7zHxQsylMc Cc: roll@ietf.org Subject: Re: [Roll] [roll] #161 (security-threats): AD review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 00:45:06 -0000 #161: AD review Comment (by mcr@sandelman.ca): Replying to [ticket:161 mcr@…]: > Your one use of RFC 2119 language outside Section 8 is unnecessary. > > RPL uses multicast as part of it's protocol, > and therefore mechanisms which RPL uses to secure this traffic MAY be > applicable to MPL control traffic as well: the important part is that > the threats are similiar. > > s/it's/its/ > s/MAY/might also/ > s/similiar/similar/ > > Furthermore, while your use of 2119 in Section 8 is fine with me, it is > not in harmony with the boilerplate you have included after the > Abstract. > > I suggest you move it to Section 3, and have it read... I've removed that one reference to MAY, and removed the 2119 reference. -- -----------------------------------+------------------------------- Reporter: mcr@sandelman.ca | Owner: mcr@sandelman.ca Type: enhancement | Status: assigned Priority: major | Milestone: milestone1 Component: security-threats | Version: Severity: Submitted WG Document | Resolution: Keywords: | -----------------------------------+------------------------------- Ticket URL: roll From nobody Wed Aug 13 17:58:23 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91F11A0142; Wed, 13 Aug 2014 17:58:14 -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 Yd3c5_yvR33W; Wed, 13 Aug 2014 17:58:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E3F1A0671; Wed, 13 Aug 2014 17:57:59 -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.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140814005759.5337.93753.idtracker@ietfa.amsl.com> Date: Wed, 13 Aug 2014 17:57:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/dQdntBLQEiqaLTXhHtz69XzlZk4 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-security-threats-09.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: Thu, 14 Aug 2014 00:58:15 -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-09.txt Pages : 39 Date : 2014-08-13 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-security-threats-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 14 00:26:08 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C63E1A08F5; Thu, 14 Aug 2014 00:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 K7I603KIxgZk; Thu, 14 Aug 2014 00:21:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629721A08E5; Thu, 14 Aug 2014 00:21:34 -0700 (PDT) Received: from localhost ([::1]:57768 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XHpLo-0006M4-OL; Thu, 14 Aug 2014 00:21:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6man issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com X-Trac-Project: 6man Date: Thu, 14 Aug 2014 07:21:32 -0000 X-URL: http://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/8 Message-ID: <067.39ff52585c7babe2e3fa02e2043cbad6@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/uUhmAHFBfN0NteCZGpx0anY6NOk X-Mailman-Approved-At: Thu, 14 Aug 2014 00:26:06 -0700 Cc: roll@ietf.org, 6man@ietf.org Subject: [Roll] [6man] #8 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 relation with draft-bormann-6lo-rpl-mesh-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 07:21:37 -0000 #8: draft-thubert-6man-flow-label-for-rpl-03 relation with draft-bormann-6lo- rpl-mesh-00 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08805.html From: Carsten Bormann Date: Sun, 10 Aug 2014 18:29:01 +0200 So far, we have mainly discussed the need for an optimization (it seems we now agree there is a need) and the interaction between the normative components of RFC 6437 and those of the draft at hand. I’d now like to bring up a different question: Is this the right approach? I have written up what appears to be a more natural approach in the strawman draft: http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00 Why are we doing the flow-label thing and not the more natural thing? [ ] because the flow label hack works on packets that leave the 6lo networks. • but do we really need to optimize this on the non-6lo networks? [ ] because the flow label hack has been around for a while and is now cast in stone. • is it? [ ] because there is a flaw with the way this has been integrated into the 6lo framework. • ______ (fill in the flaw) [ ] because ______ (fill in the reason) Inquiring minds want to know. Grüße, Carsten -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: new Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Keywords: -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Thu Aug 14 00:26:09 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523F11A08FC; Thu, 14 Aug 2014 00:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.331 X-Spam-Level: * X-Spam-Status: No, score=1.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RP_MATCHES_RCVD=-0.668] 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 5ePIuIQSdZzK; Thu, 14 Aug 2014 00:23:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A741A08F5; Thu, 14 Aug 2014 00:23:44 -0700 (PDT) Received: from localhost ([::1]:57842 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XHpNv-0002o4-GP; Thu, 14 Aug 2014 00:23:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6man issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com X-Trac-Project: 6man Date: Thu, 14 Aug 2014 07:23:43 -0000 X-URL: http://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/8#comment:1 Message-ID: <082.779ea0cba3a3fda448c718ef6764041e@trac.tools.ietf.org> References: <067.39ff52585c7babe2e3fa02e2043cbad6@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <067.39ff52585c7babe2e3fa02e2043cbad6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/roll/mq-J8GItU2IGTDlsFiPCSrhq_5Y X-Mailman-Approved-At: Thu, 14 Aug 2014 00:26:06 -0700 Cc: roll@ietf.org, 6man@ietf.org Subject: Re: [Roll] [6man] #8 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 relation with draft-bormann-6lo-rpl-mesh-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 07:23:51 -0000 #8: draft-thubert-6man-flow-label-for-rpl-03 relation with draft-bormann-6lo- rpl-mesh-00 Comment (by mariainesrobles@gmail.com): Source: http://www.ietf.org/mail-archive/web/roll/current/msg08808.html From: "Pascal Thubert (pthubert)" Date: Sun, 10 Aug 2014 17:05:34 +0000 Hi Carsten I think you jumped too quickly on my suggestion at 6lo. It makes a lot of sense to work on a 6lo routing dispatch and in particular enable the compression of all RPL artifacts. It will take some time to figure out what goes in there but my suggestion at 6lo includes routing header compression, RPL option, but also source destination if we decide to route fragments. I hope this happens and I'll see with Laurent if we use a respin of his draft or I start a new one. This work will be beneficial in the long run, but doubly fails to address the issues at stake here: - the draft proposes to update the rules in 6437 with stateful and with domain scoped operations. This is used by the draft itself but also by published and deployed standards that came up before 6437 (eg ISA100.11a) and we are now acknowledging and legalizing a de facto situation. - it will take a year or 2 at best to agree on the new routing dispatch and its operation. We need an improvement now. And btw we cannot necessarily assume 6lo together with RPL, I know of at least one RPL implementation that does not use that compression. Finally, Using a dispatch for the RPL option alone seems like a waste, but that is a discussion for 6lo. I'll publish there when I'm back from vacations. Cheers, Pascal ------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08811.html From: Carsten Bormann Date: Sun, 10 Aug 2014 21:07:04 +0200 On 10 Aug 2014, at 19:05, Pascal Thubert (pthubert) wrote: > - it will take a year or 2 at best to agree on the new routing dispatch and its operation. We need an improvement now. And btw we cannot necessarily assume 6lo together with RPL, I know of at least one RPL implementation that does not use that compression. I don’t understand why we can’t do the saner equivalent of the flow label hack now and come up with a source routing header (which is not covered by the flow label hack) later. Please tell us more about how ISA100.11a uses the flow label; that is information that has been lacking from the discussion so far. Grüße, Carsten ------------------------------------ Source: http://www.ietf.org/mail-archive/web/roll/current/msg08817.html From: Carsten Bormann Date: Tue, 12 Aug 2014 10:40:19 +0200 On 12 Aug 2014, at 09:15, Ines Robles wrote: > This technique saves bytes Again, the straw man at http://tools.ietf.org/html/draft-bormann-6lo-rpl- mesh-00 saves the same number of bytes. Actually, for common cases, it enables one additional optimization (saving one more byte) that is not available with the flow label hack. (On the other hand, due to the way RFC 6282 works, the flow label hack saves one byte where both it and ECN are in use and the common case does not apply.) The disadvantage of the RPL mesh header is that this approach is not available outside 6lo networks (i.e., networks employing adaptation layers that use RFC 6282). I’m not aware yet of a use case where that is a problem. In either encoding (RPL mesh header or flow label), it is probably a good idea anyway to unpack the compressed information back into the RPL IPv6 option when leaving the 6lo networks. Grüße, Carsten ------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08824.html From: "Pascal Thubert (pthubert)" Date: Wed, 13 Aug 2014 16:51:21 +0000 I disagree, Carsten. To save all the bytes, we need to update the 6MAN rules and allow to change a non-zero flow label, be it only to reset and elide it when coming from the Internet. More in my other answer to you today... Pascal ----------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08818.html From: Brian E Carpenter Date: Wed, 13 Aug 2014 11:38:53 +1200 Ines, Can you perhaps clarify the exact question you are asking 6man? (I'm thinking that 6man isn't being asked whether the number of bits saved is a useful energy saving, or whether Carsten's proposal is better.) Regards Brian On 12/08/2014 19:15, Ines Robles wrote: > Hi, > > On April, it was discussed and got consensus in ROLL [ > http://www.ietf.org/mail-archive/web/roll/current/msg08634.html]. > > This technique saves bytes, as was demonstrated by Xavier in his > implementation [ start on Slide 41 - > https://bytebucket.org/6tisch/meetings/raw/712902bb451d113494a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plugfest_slides.pdf]. > Maybe we should enumerate the advantages and disadvantages of using it. > (Some of these are tracked in ticket #5, #6 and #7). > > > Anyway, demostratedIt needs the 6man approval to go forward. > > Cheers, > > Ines ------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08820.html From: Ines Robles Date: Wed, 13 Aug 2014 11:00:12 +0300 Hi Brian, Thanks for your comment. Actually, I did not ask a question, I just wanted to say that the Pascal's draft got consensus at ROLL in april, and the WGLC was done between 6man and ROLL to know the 6man opinion about the use of flow-label (tickets #5, #6 and #7). With the new Carsten proposal (6lo draft), we (constrained environment WGs) should analyze this approach and decide the further steps on Pascal draft related with that. Thanks, Ines --------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08822.html From: "Pascal Thubert (pthubert)" Date: Wed, 13 Aug 2014 16:37:27 +0000 Hi Brian: The question to 6MAN is really whether the use that the draft makes of the flow label within the RPL domain is acceptable or not. In particular Section 1.3 does not force a particular usage of the flow label inside the LLN, it simply updates the rules of what is allowed and what is not within that domain, knowing that the root will set the label properly towards the Internet and reset it from the Internet. It is up to ROLL and other external standards adopting the work (ISA100, WCI) to decide of its usefulness. Cheers, Pascal -------------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08819.html From: Carsten Bormann Date: Wed, 13 Aug 2014 03:19:12 +0200 On 13 Aug 2014, at 01:38, Brian E Carpenter wrote: > Can you perhaps clarify the exact question you are asking 6man? Well, I’m not Ines, but I’m trying to find out why we are in this peculiar position of discussing this draft right now. ROLL has a routing protocol that requires some data to be shipped around together with IP packets. RFC 6553 and 6554 define ways to do this that are consistent with the IP architecture. Unfortunately, the overhead (signal-to-fluff ratio) is relatively high, and in this area of application, that matters. Normally, the next step would have been looking at ways to do header compression. We did talk about compressing ROLL, but with a view to compressing the (control plane) ROLL messages, not so much about the (data plane) IP packets themselves. GHC is trying to be a reasonably useful, but also reasonably general way to do the control plane messages. For the data packets, the flow label (and its now predominant non-use) provides an attractive hole in the IPv6 packets to ship around the RFC 6533 information, but not the RFC 6554 information. In 6lo networks, normally RFC 6282 compresses away empty flow labels, but it is cheap to put them in, so a flow label really only costs 3 bytes (instead of 8 bytes RFC 6553 costs). The most useful information from RFC 6553 can be stuffed into 19 bits, as demonstrated by the draft we are discussing here. RFC 6282 has extension points (GHC uses one of them), but not really useful ones for the ROLL data plane. So it appears it never occurred to us that the best way to handle these 19 bits is to actually sidestep RFC 6282, and use the existing extension points of RFC 4944. Until Laurent showed one way of doing this. I just went from there and did a strawman using Laurent’s idea for compressing the RFC 6553 option, in a way that is as efficient as (or, in most cases, actually more efficient than) using the flow label hole. So to me it seems there no longer is a good technical argument to ask 6man to liberate the flow label for carrying RFC 6553. But that is maybe something that should now be discussed between 6lo and ROLL; I don’t think that this is a 6man issue (unless the answer is a simple “sure, go ahead, take it, we don’t need it any more anyway”, which is not what I have perceived RFC 6437 to say). When 6lo and ROLL have generated consensus on the need to do this, we may or may not want to go back to 6man and actually pry that flow label hole out of your fingers. Grüße, Carsten ------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08823.html From: "Pascal Thubert (pthubert)" Date: Wed, 13 Aug 2014 16:48:06 +0000 Hello Carsten: In my view, this work is not competing with 6lo: for the specific value of keeping the draft whatever 6lo decides to do: - If this draft is not adopted, the flow label from LLN will probably stay all zeroes as it is today and the goal of 6437 will not be achieved. There is no way a device will waste 20 bits for a random that has no value inside the LLN. The text tells the RPL root to set the flow label. - If this draft is not adopted, the root of the LLN will have to forward the flow label coming from the Internet down to the end destination device, deep in the mesh, wasting 20 bits in each frame. These is a waste that 6lo compression will not be allowed to legally elide if today we decide that we do not allow it. Note: even if the correspondent sets the FL to zeroes to help the LLN, there is no way to guarantee that the flow label will not be set on the way since that much is lawful. - If the draft is not adopted, existing usages in shipping standards that incorporate IPv6 will stay borderline/unlawful. E.g. the draft legalizes the way ISA100.11a uses the flow label for a stateful flow identification within the ISA100 domain. - If the draft is not adopted, we have no leverage over WCI that is defining the backbone router for ISA100.11a devices. The draft indicates that the root should ensure that the flow label is correctly set when going outside, which is a minor increment to WCI, if pushed in due time with a proper RFC number that demands it. The need for this work was agreed at ROLL. We need a better solution than available, for application in RPL domains, that are often but not necessarily congruent with 6LowPAN domains. I'm fully supportive to have a 6lo compression that will improve the situation for a 6lowpan network, and at this point we have 3 proposals on the table, Laurent's, yours, and mine, which is to have a routing dispatch for route-over in parallel to the mesh dispatch that is mesh-under. I do hope we create a momentum there and converge. But there is no guarantee. All in all, I will not drop something that works now, with running code and all, and reached last call status, against the sirens of a compression that will not solve the issues above. Cheers, Pascal ------------------ Source: http://www.ietf.org/mail-archive/web/roll/current/msg08826.html From: Philip Levis Date: Wed, 13 Aug 2014 12:07:04 -0700 On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) wrote: > If this draft is not adopted, the flow label from LLN will probably stay all zeroes as it is today and the goal of 6437 will not be achieved. Pascal, I'm trying to reconcile your claim that the goal of 6437 is to allow enclosed networks to use the flow label with Brian's statement > Actually that's why I don't want to see a formal > update to 6437, because the only rational update would be to allow > any closed domain to invent its own usage. We had that argument at > length during the development of 6437, and decided against it. Phil -------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08830.html From: Brian E Carpenter Date: Thu, 14 Aug 2014 08:52:56 +1200 Right. I'm drawing a very subtle line between (a) stating an exception to 6437 for this particular usage and (b) opening the door to other usages. Since 6man clearly didn't want (b) during the development of 6437 I think we do need to limit ourselves to (a). Brian -------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08828.html From: Philip Levis Date: Wed, 13 Aug 2014 12:11:48 -0700 On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) wrote: > The need for this work was agreed at ROLL. We need a better solution than available, for application in RPL domains, that are often but not necessarily congruent with 6LowPAN domains. This seems to me to be the strong technical argument in favor of the draft. While Carsten's approach seems better technically, it only works for 6lowpan, and RPL should be independent of the underlying link layer. Phil ------------------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08829.html From: Ralph Droms Date: Wed, 13 Aug 2014 15:49:45 -0400 On Aug 13, 2014, at 3:11 PM 8/13/14, Philip Levis wrote: > On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) wrote: > >> The need for this work was agreed at ROLL. We need a better solution than available, for application in RPL domains, that are often but not necessarily congruent with 6LowPAN domains. > > This seems to me to be the strong technical argument in favor of the draft. While Carsten's approach seems better technically, it only works for 6lowpan, and RPL should be independent of the underlying link layer. Could we consider Carsten's approach a compression mechanism for the RPL information options, rather than a replacement, thereby allowing a one-to- one translation between compressed mode on 6lowpan networks and uncompressed mode in other networks? - Ralph ------------------------------------------------ Source: http://www.ietf.org/mail-archive/web/roll/current/msg08831.html From: Carsten Bormann Date: Wed, 13 Aug 2014 23:02:30 +0200 >> This seems to me to be the strong technical argument in favor of the draft. While Carsten's approach seems better technically, it only works for 6lowpan, and RPL should be independent of the underlying link layer. The transport of RPL specific information for data plane packets already *is* independent of the underlying link layer, as specified in RFC 6553 and RFC 6554. All we are talking about here is an optimization for those (for 6553, specifically; actually 6554 is probably the one even more in need). > Could we consider Carsten's approach a compression mechanism for the RPL information options, rather than a replacement, thereby allowing a one-to- one translation between compressed mode on 6lowpan networks and uncompressed mode in other networks? Indeed, that is probably the best way to view this approach. (In the next version of the draft, I’ll emphasize this.) My assumption here is: — Any subnet that could not live with transporting RFC 6553 as is, i.e. 8 bytes extra compared to the flow label approach (for uncompressed packets*), already needs (and, at this point, has) a header compression solution for the expansive IPv6 header anyway. So adding RFC 6553 compression to that solution is the natural approach. — All subnets that can live with the IPv6 header as is, also can live with RFC 6553 as is. This argument is on a technical level. I’m not talking about cognitive dissonance**) here, or political issues. If there are important political issues (I have no idea what the ISA100/WCI talk is about), they probably need to be brought out in the open here. Grüße, Carsten *) less difference for header-compressed packets, e.g., 5 bytes for 6lo. **) http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf, section 2.6 -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: new Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Thu Aug 14 01:54:48 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED4F1A0998; Thu, 14 Aug 2014 01:54:43 -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 xLAAeJD6mhC2; Thu, 14 Aug 2014 01:54:37 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D571A0992; Thu, 14 Aug 2014 01:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2128; q=dns/txt; s=iport; t=1408006475; x=1409216075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=o2qoFD+nZJBPHxj/SiAb5gvj8WcUNST3IF9UFp7IZV0=; b=NPiGWTq8Q8JIpmwkYaTow+KZKY9i7nA01f5pqQ3ZWPqWFxSPUPQicHgr +GWL6iWjWg3+R8UdM0FfEnzBb20k9i7RwBfZMsOX9jokp+HvcEDTw5oeB n8XtwBM/gwaSe2CfjaGbAmzFgKSfXiGwA9CHrjGV8b4yzLvpXnmCRjaRn U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFAIJ47FOtJA2M/2dsb2JhbABagw1SVwTNYQqHSAGBFRZ3hAMBAQEEAQEBawsMBAIBCA4DBAEBAQodBycLFAkIAgQOBQgTiCcNxXwTBI5+HTEHBoMpgR0FimOGOqAag1xsgUg X-IronPort-AV: E=Sophos;i="5.01,862,1400025600"; d="scan'208";a="69171339" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP; 14 Aug 2014 08:54:34 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7E8sYmP005199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 08:54:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 03:54:33 -0500 From: "Pascal Thubert (pthubert)" To: Ralph Droms , "Routing Over Low power and Lossy networks" Thread-Topic: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPty/HkIDTIP3DQEeJJU36r1KfRZvPyktw Date: Thu, 14 Aug 2014 08:54:33 +0000 Deferred-Delivery: Thu, 14 Aug 2014 08:54:00 +0000 Message-ID: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> In-Reply-To: <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.2] 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/LkXwZ1iDbA_NoC8XJ2sKqhTAes0 Cc: Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 14 Aug 2014 08:54:43 -0000 Agreed, Ralph. The work at 6lo would result in a one-to-one equivalence between a compress= ed and an uncompressed packet, including the case where the packet has a RP= L option, or a RH. The flow label draft makes equivalent a packet with a 0 = flow label and a RPL option, and a packet with a flow label set as indicate= d, so it is effectively another form of compression that is applicable in a= ny RPL domain, but only compresses the RPL option. If the 6lo work concludes as an RFC, it should recommend to prefer the 6lo = way against the flow label way. Cheers, Pascal > -----Original Message----- > From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Ralph Droms > Sent: mercredi 13 ao=FBt 2014 21:50 > To: Routing Over Low power and Lossy networks > Cc: Ines Robles; 6man WG; 6lo@ietf.org WG > Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-= 03 >=20 >=20 > On Aug 13, 2014, at 3:11 PM 8/13/14, Philip Levis > wrote: >=20 > > On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) > wrote: > > > >> The need for this work was agreed at ROLL. We need a better solution > than available, for application in RPL domains, that are often but not > necessarily congruent with 6LowPAN domains. > > > > This seems to me to be the strong technical argument in favor of the dr= aft. > While Carsten's approach seems better technically, it only works for > 6lowpan, and RPL should be independent of the underlying link layer. >=20 > Could we consider Carsten's approach a compression mechanism for the RPL > information options, rather than a replacement, thereby allowing a one-to= - > one translation between compressed mode on 6lowpan networks and > uncompressed mode in other networks? >=20 > - Ralph >=20 > > > > Phil > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo From nobody Thu Aug 14 02:05:30 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 563751A09AC; Thu, 14 Aug 2014 02:05:28 -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 T-brZBoibDia; Thu, 14 Aug 2014 02:05:26 -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 787EA1A09A2; Thu, 14 Aug 2014 02:05:26 -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 s7E95FZ0015502; Thu, 14 Aug 2014 11:05:15 +0200 (CEST) Received: from [192.168.217.145] (p54890314.dip0.t-ipconnect.de [84.137.3.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1A41D858; Thu, 14 Aug 2014 11:05:13 +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: Thu, 14 Aug 2014 11:05:12 +0200 X-Mao-Original-Outgoing-Id: 429699912.398908-3583409ce4c12fd784d40291f31fbb34 Content-Transfer-Encoding: quoted-printable Message-Id: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/AYm0wlBUJHQkmzgtLPP9BLoCKIE Cc: Routing Over Low power and Lossy networks , Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 14 Aug 2014 09:05:28 -0000 On 14 Aug 2014, at 10:54, Pascal Thubert (pthubert) = wrote: > If the 6lo work concludes as an RFC, it should recommend to prefer the = 6lo way against the flow label way. It is a bit more complicated. If both representations of the RFC 6553 information are in use: A compressor may need to decide whether a flow label present in an = uncompressed packet is an RFC 3697 flow label or one of these. A decompressor may need to decide whether the information is to be = represented in canonical RFC 6553 form or making use of the flow label = hack. In any case, I=92m not a big fan of providing two different ways of = doing the same thing, at different layers. In particular not in the constrained environment. I really would like to hear a technical argument why the flow label hack = is needed. (Or a political one, if that is the reason.) Gr=FC=DFe, Carsten From nobody Thu Aug 14 03:07:22 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B571A09D2; Thu, 14 Aug 2014 03:07:11 -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 ENvdtvLcENSR; Thu, 14 Aug 2014 03:07:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754E21A09C5; Thu, 14 Aug 2014 03:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5263; q=dns/txt; s=iport; t=1408010826; x=1409220426; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RNg38Eg5JNCEkmYIuYcGjF95xx47XC6PnXyV6dBcl/s=; b=MlD09D7fZVpPC0vcoJ+RZXiRPRSg8OeVOokS+mUtHpQQ+Kw429ju/NJs 5+jLr4nOx/5UXkgqhwlRy7/XGYVzL9ZrLr1NmUwLMaT1yuZNONfI6Kdej Ip02orrYUvtX8kS0DPV/ge026jtvauPWiLMgsQ4tU6z1qn72ipJz+/rG/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAJiJ7FOtJA2B/2dsb2JhbABagw2BKQTVNQGBFRZ3hAMBAQEDAWUUBQcEAgEIDgMEAQEBCgsSBzIUCQgBAQQOBQiIMgjGHReOewEBAR0xBwYEgyWBHQWKY4Y6oBqDXGyBDzk X-IronPort-AV: E=Sophos;i="5.01,862,1400025600"; d="scan'208";a="347484258" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 14 Aug 2014 10:07:05 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7EA74Gq028321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 10:07:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 05:07:04 -0500 From: "Pascal Thubert (pthubert)" To: Carsten Bormann Thread-Topic: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAHkPgwFAAB9osA= Date: Thu, 14 Aug 2014 10:07:03 +0000 Deferred-Delivery: Thu, 14 Aug 2014 10:06:00 +0000 Message-ID: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.2] 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/hYlVkWoDimg9PMBtQBzYbfSmJMk Cc: Routing Over Low power and Lossy networks , Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 14 Aug 2014 10:07:11 -0000 Hello Carsten: > I really would like to hear a technical argument why the flow label hack = is needed. ? Then you probably missed most of my mail from yesterday ? ? The sentence is a rhetorical abuse - like "our just cause" as opposed to = "our cause is just" which can be argued -, and there is no consensus that t= he flow label technique is a hack ? =20 Answering both pending mails from you; I'll rephrase, but please give a sec= ond glance at my previous mail where I made 4 points and you responded to o= nly one. In short, a 6lo compression draft will not achieve all the purposes of the = draft, it will not achieve the same compression, and the use case will not = be fully congruent. For instance, the draft is asking 6MAN the right to reset a flow label at t= he ingress RPL domain. Without this right, a flow label coming from the Int= ernet will be transported in the RPL domain or (more probably) implementati= on will voluntarily fail to conform 6437, and elide them regardless. I'd ra= ther have a realistic rule that sets the expectations right. We disagree on the argument that both approaches save the same bits and alw= ays result in frames of a same size is technically incorrect. In the scenar= io above, the flow label draft saves 20 bits that a 6lo compression cannot = save without the blessing that is being asked here, and the 6lo approach wi= ll need signaling bits that are implicit in the flow label, thus consuming = extra space. OTOH, the 6lo approach could compress the instanceID and save = bits there - not sure I'd play more with the rank as your version suggests.= =20 Another disagreement is on your assumption that compression is the only rea= son for preferring the flow label technique. We have an IOS implementation = that is not for use in 6LoWPAN networks, and relies on the (stateful) stori= ng mode. HbH has known issues in classical routers, makes the header chain = longer and requires silicon processing or punt, so there are reasons not to= use it there either. OTOH making a routing decision that takes the flow la= bel into account is quite natural, this is what load balancers will do at t= he core. We have prototyped indexing the VRF with the RPL instance in the f= low label, and it works like a charm. And even if compression is the reason why the flow label is used, RPL is a = rather new routing protocol and we do not know what the world will make of = it. For all I know it may be deployed in RoHC environments to aggregate fem= tocell traffic for instance. Assuming that the compression will always be 6= LoWPAN is short sighted. And there is no "politics", but external SDOs that base their work on our R= FCs and that we need to treat with all respect. Facts: - ISA100.11a ships with IPv6, 6LoWPAN, and an IPv6 flow label that is a sta= teful indicator of the flow (called a contract ID). We need to be clear on = how we position this WRT 6437 now that we shipped it. The draft makes that = legal, as long as we extend the RPL domain to an ISA100 domain as well. - We can promote behaviors in WCI (e.g. reset the flow label to something v= aluable to the Internet at large at the backbone router) but then we need t= o document them in an RFC that they can reference. I agree that multiple techniques is not a good idea, mostly in LLNs. Sadly = the HbH is already there, uncompressed, and implemented in shipping devices= . So the argument would stall the situation and we cannot have that. What I= 'd rather do is have the 6lo proposal converge the format with the FL, so t= he logic to parse is common. Finding it in the packet is not the complex pi= ece anyway. If we still disagree then we can talk one-to-one, the lists are probably ov= erwhelmed with this thread, and come back when we reach an agreement. We ca= n also talk about the compression logic if you like. I can setup a webex. Cheers, Pascal > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: jeudi 14 ao=FBt 2014 11:05 > To: Pascal Thubert (pthubert) > Cc: Ralph Droms; Routing Over Low power and Lossy networks; Ines Robles; > 6man WG; 6lo@ietf.org WG > Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-= 03 >=20 > On 14 Aug 2014, at 10:54, Pascal Thubert (pthubert) > wrote: >=20 > > If the 6lo work concludes as an RFC, it should recommend to prefer the = 6lo > way against the flow label way. >=20 > It is a bit more complicated. >=20 > If both representations of the RFC 6553 information are in use: > A compressor may need to decide whether a flow label present in an > uncompressed packet is an RFC 3697 flow label or one of these. > A decompressor may need to decide whether the information is to be > represented in canonical RFC 6553 form or making use of the flow label ha= ck. >=20 > In any case, I'm not a big fan of providing two different ways of doing t= he > same thing, at different layers. > In particular not in the constrained environment. >=20 > I really would like to hear a technical argument why the flow label hack = is > needed. > (Or a political one, if that is the reason.) >=20 > Gr=FC=DFe, Carsten From nobody Thu Aug 14 03:28:51 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2751A09D8; Thu, 14 Aug 2014 03:28:44 -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 EZhHvnS92bwD; Thu, 14 Aug 2014 03:28:38 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398731A09DD; Thu, 14 Aug 2014 03:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2399; q=dns/txt; s=iport; t=1408012119; x=1409221719; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ahv4vpnJwd2RZZY9mMG7UR9qhvvqEfk+ovHeJ+Z5LJk=; b=JSfKgqPzp78VOHSQ33/WthxsHZdQroiHy4LkhlFRStxrEaTPElHU5aFD jhrtxq9pl769z8ehLF8ewuK+6kYpVg+Za2Fh8QRAU8Ym6waChjQKyrd1l MtE71P4j8iJDoT1P9Bf3gAcoaYkS9XX4qngdHaeDJl2EbUzD8uqF1IlZM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFAE6O7FOtJV2R/2dsb2JhbABaDoJ/UlcEzWMKh0gBgRUWd4QDAQEBBAEBAWQHCwwEAgEIEQQBAQEKHQcnCxQJCAIEAQ0FCIg6DcYWEwSOaQwJHTEHBoMpgR0FhhCEU4Y6oBqDGkJsgQdB X-IronPort-AV: E=Sophos;i="5.01,862,1400025600"; d="scan'208";a="347488279" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP; 14 Aug 2014 10:28:38 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7EASbLu024628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 10:28:37 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 05:28:37 -0500 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter , Philip Levis Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPtyoH9NpmEOvPPUCuS34Wv0nHR5vPVpsAgACNI8A= Date: Thu, 14 Aug 2014 10:28:36 +0000 Deferred-Delivery: Thu, 14 Aug 2014 10:28:00 +0000 Message-ID: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com> In-Reply-To: <53EBD028.30302@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.2] 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/mM7FNWRDdNWwqJNPCxoUzIMa9oo Cc: Routing Over Low power and Lossy networks , Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 14 Aug 2014 10:28:44 -0000 We can live with this Brian,=20 but then I can we add at least an ISA100.11a network? ISA100.11a was design= ed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow label to ind= icate which flow a packet belongs to. In more details, devices are provisio= ned with per-flow behavior (including routing) and settings in what is call= ed a contract. The contractID is carried in the IPv6 flow label. If so should we name ISA100 specifically or use a more vague description li= ke a "RPL or similar LLN domain"=20 We'll note that resetting an flow label that comes from the Internet is a g= eneric need is that flow label was set according to 6437, cannot be trusted= to be untempered with,=20 Cheers, Pascal > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: mercredi 13 ao=FBt 2014 22:53 > To: Philip Levis > Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man WG; > 6lo@ietf.org WG > Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-= 03 >=20 > On 14/08/2014 07:07, Philip Levis wrote: > > On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) > wrote: > > > >> If this draft is not adopted, the flow label from LLN will probably st= ay all > zeroes as it is today and the goal of 6437 will not be achieved. > > > > Pascal, I'm trying to reconcile your claim that the goal of 6437 is to > > allow enclosed networks to use the flow label with Brian's statement > > > >> Actually that's why I don't want to see a formal update to 6437, > >> because the only rational update would be to allow any closed domain > >> to invent its own usage. We had that argument at length during the > >> development of 6437, and decided against it. > > > > Phil >=20 > Right. I'm drawing a very subtle line between (a) stating an exception to= 6437 > for this particular usage and (b) opening the door to other usages. Since > 6man clearly didn't want (b) during the development of > 6437 I think we do need to limit ourselves to (a). >=20 > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Aug 14 04:29:53 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46891A0A76; Thu, 14 Aug 2014 04:29:36 -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 OyFTuiGtKncu; Thu, 14 Aug 2014 04:29:35 -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 2826B1A0A7E; Thu, 14 Aug 2014 04:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7EBTNRL026812; Thu, 14 Aug 2014 13:29:23 +0200 (CEST) Received: from [192.168.217.145] (p54890314.dip0.t-ipconnect.de [84.137.3.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 098D9952; Thu, 14 Aug 2014 13:29:21 +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: Thu, 14 Aug 2014 13:29:20 +0200 X-Mao-Original-Outgoing-Id: 429708560.40719-59d134129f8d411f3519afd44c8fa26e Content-Transfer-Encoding: quoted-printable Message-Id: <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/818yOwO8LsTXv5LiSo4dd_r-9vA Cc: Routing Over Low power and Lossy networks , Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 14 Aug 2014 11:29:37 -0000 >> I really would like to hear a technical argument why the flow label = hack is needed. >=20 > ? Then you probably missed most of my mail from yesterday ? > ? The sentence is a rhetorical abuse - like "our just cause" as = opposed to "our cause is just" which can be argued -, and there is no = consensus that the flow label technique is a hack ? Oh, OK, I was using this as a technical term. The Internet works = because of a set of hacks piled on hacks. Generally, most people would agree that an instance of =93there are some = bits that aren=92t used very much =97 lets put our stuff there=94 is a = hack. But we don=92t need consensus on that word, in particular if you = perceive it as pejorative. > For instance, the draft is asking 6MAN the right to reset a flow label = at the ingress RPL domain. Without this right, a flow label coming from = the Internet will be transported in the RPL domain or (more probably) = implementation will voluntarily fail to conform 6437, and elide them = regardless. I'd rather have a realistic rule that sets the expectations = right. OK. That is a completely different thing. I certainly would support a =93license to drop=94 draft that says =93a = highly constrained network can discard the information in flow labels=94. (Maybe with some more context. Just as RFC 6282 allows discarding UDP = checksums in certain well-defined cases.) But that is not an argument at all for storing anything different in = those 20 bits. > Another disagreement is on your assumption that compression is the = only reason for preferring the flow label technique. We have an IOS = implementation that is not for use in 6LoWPAN networks, and relies on = the (stateful) storing mode. HbH has known issues in classical routers, = makes the header chain longer and requires silicon processing or punt, = so there are reasons not to use it there either. OTOH making a routing = decision that takes the flow label into account is quite natural, this = is what load balancers will do at the core. We have prototyped indexing = the VRF with the RPL instance in the flow label, and it works like a = charm. Now it gets interesting. I have another draft whose main content could be summarized as = =93hop-by-hop options don=92t seem to work, now what=94. So why did we do RFC 6553? That was a big mistake, no? We need to do the things hop-by-hop options were defined for, for a = number of purposes. =20 This is not being helped by usurping the last free 20 bits in the header = for one, and only one, of those purposes. > And even if compression is the reason why the flow label is used, RPL = is a rather new routing protocol and we do not know what the world will = make of it. For all I know it may be deployed in RoHC environments to = aggregate femtocell traffic for instance. Assuming that the compression = will always be 6LoWPAN is short sighted. Since ROHC is all about flows, it indeed is very good in completely = compressing away static flow labels. ROHC also is very good in completely compressing away static extension = headers. I haven=92t done the math, but I don=92t see a winning argument here. In any case, my argument was that the header compression scheme should = handle this, and, either way, ROHC already does! More importantly, if RPL becomes applicable outside the constrained = environment, the arguments that are being made about the requirements of = (stubby) constrained environments no longer apply. In any case: YAGNI. > And there is no "politics", but external SDOs that base their work on = our RFCs and that we need to treat with all respect. Facts: > - ISA100.11a ships with IPv6, 6LoWPAN, and an IPv6 flow label that is = a stateful indicator of the flow (called a contract ID). We need to be = clear on how we position this WRT 6437 now that we shipped it. The draft = makes that legal, as long as we extend the RPL domain to an ISA100 = domain as well. I don=92t know that a ISA100.11a contract ID is compatible with the = proposed flow-label encoding of RFC 6553. But support for this usage could go with =93license to drop=94 into a = draft about constrained node network usage of flow labels. (In any case, draft-thubert-6man-flow-label-for-rpl-04.txt does nothing = here; it mentions ISA100.11a only in the introduction.) > - We can promote behaviors in WCI (e.g. reset the flow label to = something valuable to the Internet at large at the backbone router) but = then we need to document them in an RFC that they can reference. That seems to be the above argument about =93license to drop", which is = again completely independent from the desire to compress RFC 6553. .oOo. I won=92t continue belaboring this on the three mailing lists here. (One reason being that I=92m going on vacation.) My main point for 6man was that going down the =93let=92s appropriate = the flow label for this=94 route is not at all inevitable. (There also are some good contributions from this discussion for the = ongoing quest for a good, deployable use for flow labels.) For 6lo, the observation is that there is a place for header compression = beyond RFC 6282, and that it is easy to get even better compression for = RFC 6553 in the RFC 4944 framework. For ROLL, my advice would be to take another look at RFC 6554, and see = how that would be compressed in a 6lo context. Most importantly, is = there really a need for the =93segments left" construction, or can the = waypoints be discarded once visited. Gr=FC=DFe, Carsten From nobody Thu Aug 14 05:21:13 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 4EE591A0ACF; Thu, 14 Aug 2014 05:21:08 -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 BCpVDEJcFvZL; Thu, 14 Aug 2014 05:21:05 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11801A0AC7; Thu, 14 Aug 2014 05:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6875; q=dns/txt; s=iport; t=1408018865; x=1409228465; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j9xz9IDcJFCDSTaYyIfwrmgYQi4KQS4IDBzikfTQYL8=; b=Ob/ubk/oFYYcrIf7coF15xkoS0h9ZVrFoNftMqkhWwsitAFqaiIIDOZ1 w/aJS+dTMhHUf8HObRnCssHLBCMhyzpRs2WwAykRDfkW5WK2dAbqqaOKx rHv+Vb1vMAHFFT5qrj6fMqcdR6j1VMD8J9Cag2LUXBNxh+fi/CgAA1rbC U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAAep7FOtJV2U/2dsb2JhbABagw2BKQTVNQGBFhZ3hAMBAQEEZQkLDAQCAQgOAwQBAQsLEgcyFAkIAQEEDgUIiDrGHxeOfh0xBwYEgyWBHQWKY4Y6oBqDXGyBSA X-IronPort-AV: E=Sophos;i="5.01,863,1400025600"; d="scan'208";a="347493019" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 14 Aug 2014 12:21:04 +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 s7ECL4kx008236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 12:21:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 07:21:03 -0500 From: "Pascal Thubert (pthubert)" To: Carsten Bormann Thread-Topic: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAHpRpGMAAFvTaA= Date: Thu, 14 Aug 2014 12:20:54 +0000 Deferred-Delivery: Thu, 14 Aug 2014 12:20:00 +0000 Message-ID: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org> In-Reply-To: <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.2] 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/Kjxx50GE6h9BS7iKRfjLeVro7Mw Cc: Routing Over Low power and Lossy networks , Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 14 Aug 2014 12:21:08 -0000 And my conclusion to 6MAN is that the changes of rules that are requested i= n the draft are useful whether or not people are willing to use the flow la= bel as the transport for the RPL option inside the RPL domain. Since this i= s the question on the table for 6MAN, I think that the answer is now clearl= y a yes. =20 Left will be the conclusion on whether the use of the flow label to carry t= he RPL option is a good idea or not. I guess the answer belongs to ROLL and= the last call there. If Carsten's arguments prevail, I can extract the 6553 compression from the= draft to keep the new rules separate from the particular usage of transpor= ting 6553 flow information.=20 Cheers, Pascal > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: jeudi 14 ao=FBt 2014 13:29 > To: Pascal Thubert (pthubert) > Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man WG; > 6lo@ietf.org WG > Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-= 03 >=20 > >> I really would like to hear a technical argument why the flow label ha= ck is > needed. > > > > ? Then you probably missed most of my mail from yesterday ? > > ? The sentence is a rhetorical abuse - like "our just cause" as opposed= to > "our cause is just" which can be argued -, and there is no consensus that= the > flow label technique is a hack ? >=20 > Oh, OK, I was using this as a technical term. The Internet works because= of a > set of hacks piled on hacks. > Generally, most people would agree that an instance of "there are some bi= ts > that aren't used very much - lets put our stuff there" is a hack. > But we don't need consensus on that word, in particular if you perceive i= t as > pejorative. >=20 > > For instance, the draft is asking 6MAN the right to reset a flow label = at the > ingress RPL domain. Without this right, a flow label coming from the Inte= rnet > will be transported in the RPL domain or (more probably) implementation > will voluntarily fail to conform 6437, and elide them regardless. I'd rat= her > have a realistic rule that sets the expectations right. >=20 > OK. That is a completely different thing. > I certainly would support a "license to drop" draft that says "a highly > constrained network can discard the information in flow labels". > (Maybe with some more context. Just as RFC 6282 allows discarding UDP > checksums in certain well-defined cases.) >=20 > But that is not an argument at all for storing anything different in thos= e 20 > bits. >=20 > > Another disagreement is on your assumption that compression is the only > reason for preferring the flow label technique. We have an IOS > implementation that is not for use in 6LoWPAN networks, and relies on the > (stateful) storing mode. HbH has known issues in classical routers, makes= the > header chain longer and requires silicon processing or punt, so there are > reasons not to use it there either. OTOH making a routing decision that t= akes > the flow label into account is quite natural, this is what load balancers= will > do at the core. We have prototyped indexing the VRF with the RPL instance > in the flow label, and it works like a charm. >=20 > Now it gets interesting. > I have another draft whose main content could be summarized as "hop-by- > hop options don't seem to work, now what". > So why did we do RFC 6553? That was a big mistake, no? > We need to do the things hop-by-hop options were defined for, for a > number of purposes. > This is not being helped by usurping the last free 20 bits in the header = for > one, and only one, of those purposes. >=20 > > And even if compression is the reason why the flow label is used, RPL i= s a > rather new routing protocol and we do not know what the world will make > of it. For all I know it may be deployed in RoHC environments to aggregat= e > femtocell traffic for instance. Assuming that the compression will always= be > 6LoWPAN is short sighted. >=20 > Since ROHC is all about flows, it indeed is very good in completely > compressing away static flow labels. > ROHC also is very good in completely compressing away static extension > headers. > I haven't done the math, but I don't see a winning argument here. > In any case, my argument was that the header compression scheme should > handle this, and, either way, ROHC already does! >=20 > More importantly, if RPL becomes applicable outside the constrained > environment, the arguments that are being made about the requirements of > (stubby) constrained environments no longer apply. >=20 > In any case: YAGNI. >=20 > > And there is no "politics", but external SDOs that base their work on o= ur > RFCs and that we need to treat with all respect. Facts: > > - ISA100.11a ships with IPv6, 6LoWPAN, and an IPv6 flow label that is a > stateful indicator of the flow (called a contract ID). We need to be clea= r on > how we position this WRT 6437 now that we shipped it. The draft makes > that legal, as long as we extend the RPL domain to an ISA100 domain as we= ll. >=20 > I don't know that a ISA100.11a contract ID is compatible with the propose= d > flow-label encoding of RFC 6553. > But support for this usage could go with "license to drop" into a draft a= bout > constrained node network usage of flow labels. > (In any case, draft-thubert-6man-flow-label-for-rpl-04.txt does nothing h= ere; > it mentions ISA100.11a only in the introduction.) >=20 > > - We can promote behaviors in WCI (e.g. reset the flow label to somethi= ng > valuable to the Internet at large at the backbone router) but then we nee= d > to document them in an RFC that they can reference. >=20 > That seems to be the above argument about "license to drop", which is > again completely independent from the desire to compress RFC 6553. >=20 > .oOo. >=20 > I won't continue belaboring this on the three mailing lists here. > (One reason being that I'm going on vacation.) >=20 > My main point for 6man was that going down the "let's appropriate the flo= w > label for this" route is not at all inevitable. > (There also are some good contributions from this discussion for the ongo= ing > quest for a good, deployable use for flow labels.) >=20 > For 6lo, the observation is that there is a place for header compression > beyond RFC 6282, and that it is easy to get even better compression for R= FC > 6553 in the RFC 4944 framework. >=20 > For ROLL, my advice would be to take another look at RFC 6554, and see ho= w > that would be compressed in a 6lo context. Most importantly, is there re= ally > a need for the "segments left" construction, or can the waypoints be > discarded once visited. >=20 > Gr=FC=DFe, Carsten From nobody Thu Aug 14 06:03:28 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47C91A0408; Thu, 14 Aug 2014 06:03:20 -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 nJCBgn6lBdZQ; Thu, 14 Aug 2014 06:03:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A101A0051; Thu, 14 Aug 2014 06:03:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140814130319.24388.62454.idtracker@ietfa.amsl.com> Date: Thu, 14 Aug 2014 06:03:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Nsltg9ESLz6uW1DX5E14MonWOHU Cc: roll@ietf.org Subject: [Roll] Last Call: (A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL)) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 13:03:21 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Aug 14 07:17: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 2B1FF1A0BEC; Thu, 14 Aug 2014 07:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dil1YK_kDMY4; Thu, 14 Aug 2014 07:16:54 -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 9963F1A0B7E; Thu, 14 Aug 2014 07:16:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A815C20012; Thu, 14 Aug 2014 10:19:49 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0A9A863AC9; Thu, 14 Aug 2014 10:16:52 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EB08E638D6; Thu, 14 Aug 2014 10:16:52 -0400 (EDT) From: Michael Richardson To: Carsten Bormann In-Reply-To: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.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/wfgi4EWrd5mywwRssbW6KdE-ilQ Cc: Routing Over Low power and Lossy networks , 6man WG , Ole Troan Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 14 Aug 2014 14:17:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > Again, the straw man at > http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00 saves the sa= me > number of bytes. Actually, for common cases, it enables one addition= al > optimization (saving one more byte) that is not available with the fl= ow > label hack. (On the other hand, due to the way RFC 6282 works, the > flow label hack saves one byte where both it and ECN are in use and t= he > common case does not apply.) I read it, but I didn't understand it. Is this something that fits into the 6lowpan adaptation header? > The disadvantage of the RPL mesh header is that this approach is not > available outside 6lo networks (i.e., networks employing adaptation > layers that use RFC 6282). I=E2=80=99m not aware yet of a use case w= here that > is a problem. > In either encoding (RPL mesh header or flow label), it is probably a > good idea anyway to unpack the compressed information back into the R= PL > IPv6 option when leaving the 6lo networks. A good point, I think. =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) iQEVAwUBU+zE0oCLcPvd0N1lAQK22wgAmPGDjbFmvz/Mbql8qkA/kP99CXWh9DfW 9/VYNn9ZQP0o/XE2BeaEJInwKlYqNvxvKY3S4ixd4FRB5Bb29zdhwEZ9RSYh3ZAl k6TgIT4FJVlR0l1m/b4JTLGHc10PgjRH5jH0FNC/TS2MsDQF/phGDzQVp8E2AruU NfSURltlHCCMmn32xfCjqsXmH7GNjDgcnGyijyBHHr+WhjSRJdwaFZ5VRBmlhST1 NU812ozZGUWOqMXp1Wn6nfV48WvRZw/evPErmFqXSuvJxQ0BdraJQRUy8+B9Wvdj M+v1fVNOwLlMY2FxIOOxfM/Z7zLWTA4c7RSgW22ijvCG5wBQOlTjOQ== =UE9H -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 14 07:44:48 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB13B1A02DE; Thu, 14 Aug 2014 07:44:44 -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 tIZJv_XQxYv6; Thu, 14 Aug 2014 07:44:44 -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 9C8A01A019C; Thu, 14 Aug 2014 07:44:43 -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 s7EEiX31029395; Thu, 14 Aug 2014 16:44:34 +0200 (CEST) Received: from [192.168.217.106] (p54890314.dip0.t-ipconnect.de [84.137.3.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BE3E0ABC; Thu, 14 Aug 2014 16:44:32 +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: <17279.1408025812@sandelman.ca> Date: Thu, 14 Aug 2014 16:44:31 +0200 X-Mao-Original-Outgoing-Id: 429720271.234956-2fc503f092895771aedbebfc3f6f0f15 Content-Transfer-Encoding: quoted-printable Message-Id: <137E1FA2-4AFB-4E1F-99CC-84724C2D6B52@tzi.org> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <17279.1408025812@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/L2XVaHWsf_KPvFRIfMMSiNHeplg Cc: Routing Over Low power and Lossy networks , 6man WG , Ole Troan Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 14 Aug 2014 14:44:45 -0000 > Is this something that fits into the 6lowpan adaptation header? Yes. The idea is that, instead of sending a dispatch [RFC4944 term] of = 011X.XXXX with an RFC 6282 header followed by the hop-by-hop extension = header containing an RFC 6553 option, you send 0100.01S0, one (S=3D0) or two bytes (S=3D1) of RPL information, and then = the RFC 6282 header with the 011 replaced by the ORF bits, followed by = what would be behind the hop-by-hop extension header. Similar for the frag1 header (0100.01S1 then). Since RFC 4944 and RFC 6282 are now being used by quite a few adaptation = layers, I collectively refer to them as =936lo=94. So this will immediately be applicable to BTLE, Z-Wave, DECT ULE, = 6lobac, 1901.2, NFC, etc. Gr=FC=DFe, Carsten From nobody Thu Aug 14 13:00: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 818CC1A872C; Thu, 14 Aug 2014 12:59:59 -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 vJdMNgB57_VP; Thu, 14 Aug 2014 12:59:57 -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 C76B71A871D; Thu, 14 Aug 2014 12:59:56 -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 s7EJxncx014254; Thu, 14 Aug 2014 21:59:49 +0200 (CEST) Received: from [192.168.217.106] (p54890314.dip0.t-ipconnect.de [84.137.3.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 716A1C80; Thu, 14 Aug 2014 21:59:48 +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: <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org> Date: Thu, 14 Aug 2014 21:59:46 +0200 X-Mao-Original-Outgoing-Id: 429739186.592732-927ac8edb4da6dc164db0ac516b644ba Content-Transfer-Encoding: quoted-printable Message-Id: <9322723A-842E-4C10-BFB7-63C88A968169@tzi.org> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org> To: "6lo@ietf.org WG" <6lo@ietf.org> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/roll/hb3N13U_6OPqV0ABPSynb-0j3q4 Cc: Routing Over Low power and Lossy networks , 6man WG Subject: [Roll] RPL Information Header for 6lo (Re: [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03) 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, 14 Aug 2014 20:00:00 -0000 I have updated the RPL Information Header draft (new title, old draft = name*): Thank you all for a lot of helpful input. Htmlized: http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-01 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-6lo-rpl-mesh-01 This now contains a lot more discussion and background information about = what it is trying to do. (There are no technical changes from the Aug 01 version -00, but there = is a second page describing it in more detail.) This draft is both intended as a response to the WGLC referenced in the = subject and as a proposal to the 6lo working group to pick this up as a = working group item. (Clearly, if we do this, we=92ll want lots of input = from ROLL whether we are doing the right thing, while it is 6lo=92s job = to do the thing right. No changes to the IP architecture are required, = so there is no need to bother 6man with this work.) Heads up: I=92ll have limited E-Mail access Aug 16 to Sep 3. Gr=FC=DFe, Carsten *) There is always so much confusion when a draft name is changed and = the numbering starts at -00 again. We can choose a better draft name for draft-ietf-6lo-___, if and when we = get there=85 From nobody Thu Aug 14 13:18:28 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262311A0669; Thu, 14 Aug 2014 13:18:24 -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 PKmL3VfYHoGq; Thu, 14 Aug 2014 13:18:22 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8461A04F6; Thu, 14 Aug 2014 13:18:22 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id hz1so2236839pad.22 for ; Thu, 14 Aug 2014 13:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oZoafNr5dvMw+i6ytj/Ldm3HhBEb5Zcr1opC1Ez7pfw=; b=ncoSvn899pm2PK6RNT26mZKDvWoQQH2LSE9O5UPuhLQneQ/CW4YerHrZFF8ZwkqojR i8Dro0IwginHdzkTEcCurL1PoPQcQnTbUI+rBli7jRNy7EhDpnhhAhdbP0XSwLtJNdn/ wRfq5khxLpX2tNlZAi0I0rrFuoAfBIjftC3jUEAh0vj0nyCB7cbz0JiAXUMBGh2HAZJg GlgqHcDFkDzXbH0nDe9R/Kh/cC9noo0eHFW572mZLneMasiDjWtb0dOTqQ87PnOG8iGl sfCXeCL8UgU7NKH+R2WylljqnUaXcuOrlPu7RMA8o+YVpXVeYpd3W2vTVKG5brMpWx5s ADoQ== X-Received: by 10.66.236.161 with SMTP id uv1mr6579078pac.85.1408047501951; Thu, 14 Aug 2014 13:18:21 -0700 (PDT) Received: from [192.168.178.23] (254.198.69.111.dynamic.snap.net.nz. [111.69.198.254]) by mx.google.com with ESMTPSA id tu10sm6145136pbc.43.2014.08.14.13.18.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Aug 2014 13:18:21 -0700 (PDT) Message-ID: <53ED1992.1010708@gmail.com> Date: Fri, 15 Aug 2014 08:18:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/roll/zgipC4y_Cw7DDZXHJHWpyxh7nqw Cc: Routing Over Low power and Lossy networks , Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 14 Aug 2014 20:18:24 -0000 On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote: > We can live with this Brian,=20 >=20 > but then I can we add at least an ISA100.11a network? ISA100.11a was de= signed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow label = to indicate which flow a packet belongs to.=20 I have no idea what ISA100.11a is or which organisation developed it, but it sounds like a violation of the flow label standard at that time (RFC 3697). If I'd known about it, we would probably have included it in the menagerie of RFC 6294. There's not much the IETF can do about other organisations that misuse our standards, although indeed we sometimes need to document such cases. Brian In more details, devices are provisioned with per-flow behavior (includin= g routing) and settings in what is called a contract. The contractID is carried in the IPv6 flow label. >=20 > If so should we name ISA100 specifically or use a more vague descriptio= n like a "RPL or similar LLN domain"=20 > We'll note that resetting an flow label that comes from the Internet is= a generic need is that flow label was set according to 6437, cannot be t= rusted to be untempered with,=20 >=20 > Cheers, >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpent= er >> Sent: mercredi 13 ao=C3=BBt 2014 22:53 >> To: Philip Levis >> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man WG; >> 6lo@ietf.org WG >> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-r= pl-03 >> >> On 14/08/2014 07:07, Philip Levis wrote: >>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) >> wrote: >>>> If this draft is not adopted, the flow label from LLN will probably = stay all >> zeroes as it is today and the goal of 6437 will not be achieved. >>> Pascal, I'm trying to reconcile your claim that the goal of 6437 is t= o >>> allow enclosed networks to use the flow label with Brian's statement >>> >>>> Actually that's why I don't want to see a formal update to 6437, >>>> because the only rational update would be to allow any closed domain= >>>> to invent its own usage. We had that argument at length during the >>>> development of 6437, and decided against it. >>> Phil >> Right. I'm drawing a very subtle line between (a) stating an exception= to 6437 >> for this particular usage and (b) opening the door to other usages. Si= nce >> 6man clearly didn't want (b) during the development of >> 6437 I think we do need to limit ourselves to (a). >> >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Fri Aug 15 01:51:52 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29E61A0938; Fri, 15 Aug 2014 01:51:43 -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 0El0Jofa6nt7; Fri, 15 Aug 2014 01:51:41 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDAF1A0947; Fri, 15 Aug 2014 01:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4113; q=dns/txt; s=iport; t=1408092702; x=1409302302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=l0bGHmFOQ7yQlw6ygVPdSPJFxNrIukv8yy1k0sa7bsQ=; b=G1UrsprkK5DZId/2xK5xshpVa1kBqjLDvu3Qeemvm7RGWy20Fni9GuJr s2hk9tIdag28X3FlF172taLB+cqrRY/1EVO6nBEnav1oDsLKbHLoiW6NO C/Kp3Cjd3FOKQFvIJH020Qkzabcldqvg+96UgSWvxkNu0Fyw8JwFVAG5N g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEFABLJ7VOtJA2G/2dsb2JhbABZgw1TV81/CodJAYETFneEAwEBAQMBAQEBZAcLBQcEAgEIEQQBAQEnByEGCxQJCAIEDgWILgMJCA2+VQ2FNxMEjR+BSgwJGzMHBoMpgR0FhhCEU4Y6iQ6CD45LhjODXGyBB4FIAQEB X-IronPort-AV: E=Sophos;i="5.01,868,1400025600"; d="scan'208";a="69490934" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP; 15 Aug 2014 08:51:41 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7F8peDS011648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Aug 2014 08:51:40 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Fri, 15 Aug 2014 03:51:39 -0500 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPt/zmHp7q4q9DoEKOFDPz7vG+hJvRXEca Date: Fri, 15 Aug 2014 08:51:38 +0000 Message-ID: <755F123A-A93F-4146-BD4C-4022CD8CE13E@cisco.com> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com> , <53ED1992.1010708@gmail.com> In-Reply-To: <53ED1992.1010708@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/foonQgh55yKRZZEWOKQck1cp1d4 Cc: Routing Over Low power and Lossy networks , Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 08:51:44 -0000 Hello Brian I do not think that ISA10011.a violates RFC 3697. What exactly made you bel= ieve so? For all I know ISA100 does everything by the book. Note that ISA100 does no= t update a non zero FL on the fly since it is not set by a source outside t= he LLN if that is your concern. OTOH It may violate RFC 6437 in that the flow is not a random but a value a= ttributed by a PCE called system manager (along rules in section 4). As thi= ngs stand, we'd certainly want the backbone router at LLN egress to rewrite= the FL in packets towards the Internet with a randomized per flow value. It will violate RFC 6437 because if the flow label is set by a router in th= e Internet - or an updated source that complies to 6437-, the backbone rout= er at LLN Ingress will rewrite it. Both issues are addressed in my draft for a RPL domain. An RFC will also hi= nt a revision of the backbone router that it should rewrite the FL on outgo= ing packets. What do you think? Pascal > Le 14 ao=FBt 2014 =E0 22:18, "Brian E Carpenter" a =E9crit : >=20 >> On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote: >> We can live with this Brian,=20 >>=20 >> but then I can we add at least an ISA100.11a network? ISA100.11a was des= igned in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow label to = indicate which flow a packet belongs to. >=20 > I have no idea what ISA100.11a is or which organisation developed > it, but it sounds like a violation of the flow label standard at that > time (RFC 3697). If I'd known about it, we would probably have included > it in the menagerie of RFC 6294. >=20 > There's not much the IETF can do about other organisations that > misuse our standards, although indeed we sometimes need to > document such cases. >=20 > Brian >=20 >=20 > In more details, devices are provisioned with per-flow behavior (includin= g routing) and settings in what is called a contract. > The contractID is carried in the IPv6 flow label. >>=20 >> If so should we name ISA100 specifically or use a more vague description= like a "RPL or similar LLN domain"=20 >> We'll note that resetting an flow label that comes from the Internet is = a generic need is that flow label was set according to 6437, cannot be trus= ted to be untempered with,=20 >>=20 >> Cheers, >>=20 >> Pascal >>=20 >>=20 >>> -----Original Message----- >>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpente= r >>> Sent: mercredi 13 ao=FBt 2014 22:53 >>> To: Philip Levis >>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man WG; >>> 6lo@ietf.org WG >>> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rp= l-03 >>>=20 >>>> On 14/08/2014 07:07, Philip Levis wrote: >>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) >>> wrote: >>>>> If this draft is not adopted, the flow label from LLN will probably s= tay all >>> zeroes as it is today and the goal of 6437 will not be achieved. >>>> Pascal, I'm trying to reconcile your claim that the goal of 6437 is to >>>> allow enclosed networks to use the flow label with Brian's statement >>>>=20 >>>>> Actually that's why I don't want to see a formal update to 6437, >>>>> because the only rational update would be to allow any closed domain >>>>> to invent its own usage. We had that argument at length during the >>>>> development of 6437, and decided against it. >>>> Phil >>> Right. I'm drawing a very subtle line between (a) stating an exception = to 6437 >>> for this particular usage and (b) opening the door to other usages. Sin= ce >>> 6man clearly didn't want (b) during the development of >>> 6437 I think we do need to limit ourselves to (a). >>>=20 >>> Brian >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >=20 From nobody Fri Aug 15 17:33:43 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 6E2F41A08FD; Fri, 15 Aug 2014 17:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.268 X-Spam-Level: X-Spam-Status: No, score=-4.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 SB6vNeuh8FL9; Fri, 15 Aug 2014 17:33:39 -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 58E901A08F7; Fri, 15 Aug 2014 17:33:39 -0700 (PDT) Received: from [76.14.66.110] (port=61003 helo=[192.168.0.106]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XIRw8-0002NS-Bh; Fri, 15 Aug 2014 17:33:37 -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: <53EE6441.1000908@globis.net> Date: Fri, 15 Aug 2014 17:33:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1510) X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/e3dXR5dgfjPSoiwLUtMGTaOI08Q Cc: "ipv6@ietf.org" , roll Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 00:33:40 -0000 On Aug 15, 2014, at 12:49 PM, Ray Hunter wrote: > After reading the draft it seems to me that what is being attempted is > 1) to add some stuff to the IPv6 header that is RPL domain specific > 2) to reduce the overall packet length to reduce active radio time and = thus save energy > by > 3) overloading an existing well-defined and used IPv6 header field >=20 > My simple logic tells me that > 1) could be best solved at an architecture level via an extension = header http://tools.ietf.org/html/rfc2460#page-11 + = http://tools.ietf.org/html/rfc7045 > 2) could be best solved at an architecture level via IP header = compression http://tools.ietf.org/html/rfc2507.html with or without = additional tweaks > and that overloading an opaque field in 3) by incorporating values = with low entropy (as per the RPL flow label) gives additional security = risks to http://tools.ietf.org/html/rfc7098 >=20 > So what's wrong with my simple logic? 1) There is an extension header already; the problem is that it can = introduce a significant (ballpark estimates are, in well engineered = networks, up to 5-10%) cost. The proposal is to replace the extension = header with using the flow label. 2) There'a already significant IP header compression in the cases we're = talking about. Phil= From nobody Fri Aug 15 17:41: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 65FAE1A0911; Fri, 15 Aug 2014 17:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5hYcEJA9C8vM; Fri, 15 Aug 2014 17:41:41 -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 35B6B1A0910; Fri, 15 Aug 2014 17:41:41 -0700 (PDT) Received: from [76.14.66.110] (port=61066 helo=[192.168.0.106]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1XIS3w-0003uj-1t; Fri, 15 Aug 2014 17:41:40 -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: <53E926EB.9000505@gmail.com> Date: Fri, 15 Aug 2014 17:41:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <200645F3-ACEA-4F88-AD30-35998803FB54@cs.stanford.edu> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1510) X-Scan-Signature: b64bce576883819501cf77c9371f4538 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/77LKcHLhqFNggHKQpLAaq0-bZog Cc: 6man WG , Michael Richardson , Routing Over Low power and Lossy networks , Ole Troan Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 00:41:42 -0000 On Aug 11, 2014, at 1:26 PM, Brian E Carpenter = wrote: > Therefore, treating RPL as a special case is the remaining option. > But does the ROLL community actually have consensus that they want > this special case? I'd argue that if you look at the 15+ so years of work into mesh routing = on low power and lossy networks, data path validation is a common = technique to almost every approach. That is, there is absolutely = consensus in the people engineering these protocols that data packets = need to carry information about the route so the network can quickly = discover and adapt to changes in the topology. The reason is that the = topology can change very quickly, on the order of a few tens to hundreds = of packets.=20 It turns out that this is very difficult to do efficiently in the IP = architecture if you have small packets. HbH headers aren't tiny, and = IP-in-IP encapsulation is significant. In the broader scope of running IP over LLNs, I think that the ability = to encode data path information into IPv6 headers without introducing = significant overhead is critical. I therefore think this special case is = worth it and important enough. But I also think it's important to very = explicitly state that it is an additional special case, e.g., through an = Updates:. Phil= From nobody Fri Aug 15 18:12:51 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2488A1A094B; Fri, 15 Aug 2014 18:12:48 -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 FDqmh8Tg_DKh; Fri, 15 Aug 2014 18:12:46 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3351A092E; Fri, 15 Aug 2014 18:12:46 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id lj1so4335166pab.5 for ; Fri, 15 Aug 2014 18:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JrIp4y27SDoItWowBuataiu428Kxkk2xVyAlG6WnWlQ=; b=FZ+l5llCpml8eltPQWSP1VkQ2RaKiQNcoInVw2EkJTu7NHh8IX3I4lPdvL9qzGhOEN tFFMV8yxniecy4uX2lIHOi77a9Sx10sciemQ0kJASy02fTQ/kg6F2Hzi0MOI1dNTTfgW nTBO9HT5mSF7hvcDZsboGvGTILEU5RU7bXSe3SBW1AUnHGAq7SyoXsZTfJHrMj+yoUe1 fbeEiESY1e+YAlkFoyTSxvknz1BtuHTTfpKmHUUd9hks5fWdhZtVDZBvvtjCphnxcU7Z raP5nvzq45+tpjkA+2Q6wXmsNPM4ne8cbcT0tbVAgmKhQ8wGBzlQkpZj8Qu9+fH7hjLk zwPA== X-Received: by 10.70.62.5 with SMTP id u5mr22595483pdr.100.1408151566197; Fri, 15 Aug 2014 18:12:46 -0700 (PDT) Received: from [192.168.178.23] (7.199.69.111.dynamic.snap.net.nz. [111.69.199.7]) by mx.google.com with ESMTPSA id ss5sm9157837pbc.27.2014.08.15.18.12.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Aug 2014 18:12:45 -0700 (PDT) Message-ID: <53EEB016.4030105@gmail.com> Date: Sat, 16 Aug 2014 13:12:54 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com> , <53ED1992.1010708@gmail.com> <755F123A-A93F-4146-BD4C-4022CD8CE13E@cisco.com> In-Reply-To: <755F123A-A93F-4146-BD4C-4022CD8CE13E@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/roll/wKK-pe-VKkynOB2TAwZjcicvVkc Cc: Routing Over Low power and Lossy networks , Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 01:12:48 -0000 On 15/08/2014 20:51, Pascal Thubert (pthubert) wrote: > Hello Brian >=20 > I do not think that ISA10011.a violates RFC 3697. What exactly made you= believe so? I was over-interpreting what you wrote, I guess. It's true that 3697 was = rather vague about what it called "flow state establishment methods" and permitt= ed both sequential and pseudo-random flow label values. Is the ISA10011.a on line somewhere? > For all I know ISA100 does everything by the book. Note that ISA100 doe= s not update a non zero FL on the fly since it is not set by a source out= side the LLN if that is your concern. >=20 > OTOH It may violate RFC 6437 in that the flow is not a random but a val= ue attributed by a PCE called system manager (along rules in section 4). = As things stand, we'd certainly want the backbone router at LLN egress to= rewrite the FL in packets towards the Internet with a randomized per flo= w value. >=20 > It will violate RFC 6437 because if the flow label is set by a router i= n the Internet - or an updated source that complies to 6437-, the backbon= e router at LLN Ingress will rewrite it. >=20 > Both issues are addressed in my draft for a RPL domain. An RFC will als= o hint a revision of the backbone router that it should rewrite the FL on= outgoing packets. > > What do you think? I think that Phil's last message frames the question to 6man correctly, so I will respond to him... Regards Brian >=20 > Pascal >=20 >> Le 14 ao=C3=BBt 2014 =C3=A0 22:18, "Brian E Carpenter" a =C3=A9crit : >> >>> On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote: >>> We can live with this Brian,=20 >>> >>> but then I can we add at least an ISA100.11a network? ISA100.11a was = designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow labe= l to indicate which flow a packet belongs to. >> I have no idea what ISA100.11a is or which organisation developed >> it, but it sounds like a violation of the flow label standard at that >> time (RFC 3697). If I'd known about it, we would probably have include= d >> it in the menagerie of RFC 6294. >> >> There's not much the IETF can do about other organisations that >> misuse our standards, although indeed we sometimes need to >> document such cases. >> >> Brian >> >> >> In more details, devices are provisioned with per-flow behavior (inclu= ding routing) and settings in what is called a contract. >> The contractID is carried in the IPv6 flow label. >>> If so should we name ISA100 specifically or use a more vague descript= ion like a "RPL or similar LLN domain"=20 >>> We'll note that resetting an flow label that comes from the Internet = is a generic need is that flow label was set according to 6437, cannot be= trusted to be untempered with,=20 >>> >>> Cheers, >>> >>> Pascal >>> >>> >>>> -----Original Message----- >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpe= nter >>>> Sent: mercredi 13 ao=C3=BBt 2014 22:53 >>>> To: Philip Levis >>>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man WG;= >>>> 6lo@ietf.org WG >>>> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for= -rpl-03 >>>> >>>>> On 14/08/2014 07:07, Philip Levis wrote: >>>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) >>>> wrote: >>>>>> If this draft is not adopted, the flow label from LLN will probabl= y stay all >>>> zeroes as it is today and the goal of 6437 will not be achieved. >>>>> Pascal, I'm trying to reconcile your claim that the goal of 6437 is= to >>>>> allow enclosed networks to use the flow label with Brian's statemen= t >>>>> >>>>>> Actually that's why I don't want to see a formal update to 6437, >>>>>> because the only rational update would be to allow any closed doma= in >>>>>> to invent its own usage. We had that argument at length during the= >>>>>> development of 6437, and decided against it. >>>>> Phil >>>> Right. I'm drawing a very subtle line between (a) stating an excepti= on to 6437 >>>> for this particular usage and (b) opening the door to other usages. = Since >>>> 6man clearly didn't want (b) during the development of >>>> 6437 I think we do need to limit ourselves to (a). >>>> >>>> Brian >>>> >>>> --------------------------------------------------------------------= >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> --------------------------------------------------------------------= >=20 From nobody Fri Aug 15 18:21:08 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D76B1A0959; Fri, 15 Aug 2014 18:21:04 -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 5xHOdagvKJen; Fri, 15 Aug 2014 18:21:02 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E95E1A0953; Fri, 15 Aug 2014 18:21:02 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so4270332pad.24 for ; Fri, 15 Aug 2014 18:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8JFOC1ieICmhwUeYDHL0ZqqXtOsGSNsBGL+Cnt4sI/U=; b=N1Feyn3iwKQqiBPa4Jzyk89gaaktuP6cSeY4UR/HGwi1Kk3Tzg48QkLpfczYotfi1V nblmXf9fZUcWD+PMrYeE13Ft0nlYPmJIpi9799YayjtZHbWqrQB51O3w5J1TeYxIa3fe 6o/KiEl3oEJ7Qhri4NLlQhAiM//34CfUX3R71TXGng5DUyOJwttw6DKpHBl7H+QE78uv XYslj6el8Zp8wO5oKZhg6zqp4nfDQqAnakDqfYKAa0tXkwyAcBm9mVE62JWCQH+0jrT8 Q3Hslrqqjg5hTCprRmmObFWp0rVNDsujY6h/ACVPbEI45VH8Qj7/OBreXijDOlA8ueBn 3aqQ== X-Received: by 10.69.17.230 with SMTP id gh6mr16865368pbd.0.1408152062199; Fri, 15 Aug 2014 18:21:02 -0700 (PDT) Received: from [192.168.178.23] (7.199.69.111.dynamic.snap.net.nz. [111.69.199.7]) by mx.google.com with ESMTPSA id ib5sm9163033pbb.55.2014.08.15.18.20.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Aug 2014 18:21:01 -0700 (PDT) Message-ID: <53EEB205.3040205@gmail.com> Date: Sat, 16 Aug 2014 13:21:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Levis References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <200645F3-ACEA-4F88-AD30-35998803FB54@cs.stanford.edu> In-Reply-To: <200645F3-ACEA-4F88-AD30-35998803FB54@cs.stanford.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/4jGDVNW2UlmKyFu2I1KFXt3bomI Cc: 6man WG , Michael Richardson , Routing Over Low power and Lossy networks , Ole Troan Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 01:21:04 -0000 On 16/08/2014 12:41, Philip Levis wrote: > On Aug 11, 2014, at 1:26 PM, Brian E Carpenter wrote: > >> Therefore, treating RPL as a special case is the remaining option. >> But does the ROLL community actually have consensus that they want >> this special case? > > I'd argue that if you look at the 15+ so years of work into mesh routing on low power and lossy networks, data path validation is a common technique to almost every approach. That is, there is absolutely consensus in the people engineering these protocols that data packets need to carry information about the route so the network can quickly discover and adapt to changes in the topology. The reason is that the topology can change very quickly, on the order of a few tens to hundreds of packets. > > It turns out that this is very difficult to do efficiently in the IP architecture if you have small packets. HbH headers aren't tiny, and IP-in-IP encapsulation is significant. > > In the broader scope of running IP over LLNs, I think that the ability to encode data path information into IPv6 headers without introducing significant overhead is critical. I therefore think this special case is worth it and important enough. But I also think it's important to very explicitly state that it is an additional special case, e.g., through an Updates:. Firstly, I think that captures the 6man question: is this special-case walled-garden exception to RFC 6437 acceptable? My personal answer is yes; we're here to make things work, not to enforce dogma. Secondly, here is my reasoning why a formal Updates: 6437 is *not* needed: A reader of flow-label-for-rpl needs to read RFC 6437 in order to correctly understand and implement flow-label-for-rpl. So RFC 6437 is correctly a normative reference. However, a reader of RFC 6437 has no need to be aware of flow-label-for-rpl in order to correctly implement RFC 6437 in any non-RPL node. So I see no logic in saying that flow-label-for-rpl updates 6437. Brian From nobody Fri Aug 15 23:54:25 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958C01A0406; Fri, 15 Aug 2014 12:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 oS3lrnMJ7-Uq; Fri, 15 Aug 2014 12:49:51 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC6861A0404; Fri, 15 Aug 2014 12:49:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 96E8787153A; Fri, 15 Aug 2014 21:49:49 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL1gd1XAlV1i; Fri, 15 Aug 2014 21:49:49 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:b577:54cb:5162:9077]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 3F5F9871519; Fri, 15 Aug 2014 21:49:49 +0200 (CEST) Message-ID: <53EE6441.1000908@globis.net> Date: Fri, 15 Aug 2014 21:49:21 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Carsten Bormann References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> In-Reply-To: <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Vyjxz6RedaxbPkXAM-Xb4OOaxfY X-Mailman-Approved-At: Fri, 15 Aug 2014 23:54:21 -0700 Cc: roll , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 19:49:52 -0000 Carsten Bormann wrote: > On 01 Aug 2014, at 10:50, Xavier Vilajosana wrote: > >> Let's look at what IPHC does at the LBR when a flow label is elided and has to be inflated to be forwarded to the IPv6 network, this standardized behaviour is somehow interfering the end to end notion of the flow label as the content is being populated at the border of the LLN. > > No. With IPHC, the flow label has always been there, it just was transmitted in a very compressed form. > > I think the visceral reaction that most of us have in using the flow label as a mesh routing header is that this blurs the layer boundaries. So much for O, R, F, and rank. Putting the VLAN (“instance ID”) into the packet is a significantly larger change, because it essentially extends the IP service interface by a VLAN ID. We normally try to hide IDs of this kind below IP. > > Now, I’m not saying any of this new architecture is wrong. I just think what we need to do is discuss this as the architectural change that it is, not as a simple optimization. (The need for some kind of optimization of IP-in-IP mesh routing for small-packet IoT applications is pretty obvious to me.) > > The other story is that we are retracting RFC 6437 and turning the flow label into the “field you may trample on in your lower layers if you have a good reason”. Cynically, one could say this is proper payback for designing this field without a compelling purpose and no protocol evolution story attached to it. So the evolution just eats it. Teachable moment. > > Grüße, Carsten > > +1 Apologies for tardy response (holidays) After reading the draft it seems to me that what is being attempted is 1) to add some stuff to the IPv6 header that is RPL domain specific 2) to reduce the overall packet length to reduce active radio time and thus save energy by 3) overloading an existing well-defined and used IPv6 header field My simple logic tells me that 1) could be best solved at an architecture level via an extension header http://tools.ietf.org/html/rfc2460#page-11 + http://tools.ietf.org/html/rfc7045 2) could be best solved at an architecture level via IP header compression http://tools.ietf.org/html/rfc2507.html with or without additional tweaks and that overloading an opaque field in 3) by incorporating values with low entropy (as per the RPL flow label) gives additional security risks to http://tools.ietf.org/html/rfc7098 So what's wrong with my simple logic? "But if we consider the whole RPL domain as a large virtual host from the standpoint of the rest of the Internet" would suggest to me that the cost of stripping out the additional IPv6 hop by hop extension header at the edge of the domain is a bogus argument, as you'll anyway have to provide some adaption and security at the root of each RPL domain to detect and bounce spoofed RPL Information from entering, or private RPL Information leaking out of each domain. Whether this domain-specificRPL Information is encoded in an explicit hop by hop option or an overloaded flow label would seem largely irrelevant to that operation at the RPL root (especially since the RPL root anyway has to be a high power node to be able communicate with the rest of the Internet). IMHO If you overload the flow label you're looking at creating an incompatible walled garden, with competing IETF standards that are mutually exclusive. -- Regards, RayH From nobody Fri Aug 15 23:54:27 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 C15691A702C; Fri, 15 Aug 2014 23:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, 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 XwfX6C6_oUnF; Fri, 15 Aug 2014 23:49:48 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9995A1A0830; Fri, 15 Aug 2014 23:49:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9584F87153A; Sat, 16 Aug 2014 08:49:47 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceeOCizm1C5a; Sat, 16 Aug 2014 08:49:47 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:2c3d:d324:45ec:29d7]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 4041C870025; Sat, 16 Aug 2014 08:49:47 +0200 (CEST) Message-ID: <53EEFEEE.8020505@globis.net> Date: Sat, 16 Aug 2014 08:49:18 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Philip Levis References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> In-Reply-To: <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HOt2EeFsMpcgtt1J25t7FREewMY X-Mailman-Approved-At: Fri, 15 Aug 2014 23:54:21 -0700 Cc: "ipv6@ietf.org" , roll Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 06:49:50 -0000 > Philip Levis > 16 August 2014 02:33 > > 1) There is an extension header already; the problem is that it can > introduce a significant (ballpark estimates are, in well engineered > networks, up to 5-10%) cost. The proposal is to replace the extension > header with using the flow label. > > 2) There'a already significant IP header compression in the cases > we're talking about. > > Phil I'm sympathetic to the needs of low power devices. However, to be clear, we are reengineering a standards track document that is around 2 years old (http://tools.ietf.org/html/rfc6553), and which works technically, and we are proposing an additional encoding of exactly the same information to achieve theoretical efficiency gains that are still only rough estimates? Where's the experimental proof that this will really pay off in increased battery life? You write "replace". Will 6553 now be deprecated? If not we'll have: 6553 to carry RPL information as an option header. draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a flow label flow label information used to select patch and load balancing in multi-path networks. e.g. http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203 http://tools.ietf.org/html/rfc6438 http://tools.ietf.org/html/rfc7098 I do not see that these applications for this one field are mutually compatible, and worse still, the only way to decode the semantics of the overloaded field is by applying some unknown external context ("within RPL domain"/ "on the Internet"). The hidden "cost" here is that we will have 3 different overlapping solutions = code bloat and potentially a lot of additional processing to locate the correct information and then process it, which is also a hit on energy efficiency. IMHO the bar should be pretty high for accepting this proposal, as it is not actually solving a tangible issue. Also my prediction of the next request for field overloading will be: My ISP only delegates one /64 with PD I have multiple links in my Homenet All my media is EUI48 based. No one really uses EUI64. I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for routing in Homenet by encoding a (V)LAN ID in it. It's OK though. Homenet is a walled garden and I'll rewrite the field at the exit so no one will ever know. As an alternative: if this information is really RPL specific, why not just add the RPL Information as a tag to the front of the packet e.g. via an MPLS label? MPLS labels are only 4 octets, and are designed to be very efficient and fast. You can easily strip them at egress, and munge it/set it on ingress. It's clear where an MPLS domain ends and starts: no chance of RPL information leaking onto the Internet, or entering from the Internet. The MPLS label also transports the 20 bits of information you need. MPLS labels are at a clear fixed position in the packet and are easy and efficient to parse. You could also then nest RPL domains if you ever wanted to do that. It's also extensible, as you can push more labels on the stack in the future if you ever want to extend the RPL Information transported, whereas the flow label is a single fixed field. It does not require any new standard, except maybe an informational RFC on how to encode the RPL Information into MPLS labels. And it doesn't overload anything. regards, > Ray Hunter > 15 August 2014 21:49 > > > > +1 > > Apologies for tardy response (holidays) > > After reading the draft it seems to me that what is being attempted is > 1) to add some stuff to the IPv6 header that is RPL domain specific > 2) to reduce the overall packet length to reduce active radio time and > thus save energy > by > 3) overloading an existing well-defined and used IPv6 header field > > My simple logic tells me that > 1) could be best solved at an architecture level via an extension > header http://tools.ietf.org/html/rfc2460#page-11 + > http://tools.ietf.org/html/rfc7045 > 2) could be best solved at an architecture level via IP header > compression http://tools.ietf.org/html/rfc2507.html with or without > additional tweaks > and that overloading an opaque field in 3) by incorporating values > with low entropy (as per the RPL flow label) gives additional security > risks to http://tools.ietf.org/html/rfc7098 > > So what's wrong with my simple logic? > > "But if we consider the whole RPL domain as a large virtual host from > the standpoint of the rest of the Internet" would suggest to me that > the cost of stripping out the additional IPv6 hop by hop extension > header at the edge of the domain is a bogus argument, as you'll anyway > have to provide some adaption and security at the root of each RPL > domain to detect and bounce spoofed RPL Information from entering, or > private RPL Information leaking out of each domain. Whether this > domain-specificRPL Information is encoded in an explicit hop by hop > option or an overloaded flow label would seem largely irrelevant to > that operation at the RPL root (especially since the RPL root anyway > has to be a high power node to be able communicate with the rest of > the Internet). > > IMHO If you overload the flow label you're looking at creating an > incompatible walled garden, with competing IETF standards that are > mutually exclusive. > > ------------------------------------------------------------------------ -- Regards, RayH From nobody Sat Aug 16 12:55:08 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168BA1A01FF; Sat, 16 Aug 2014 12:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_51=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bwwnHugpsFl; Sat, 16 Aug 2014 12:55:03 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EF01A01E5; Sat, 16 Aug 2014 12:55:03 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id r10so5085267pdi.6 for ; Sat, 16 Aug 2014 12:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yqkvNql2yfGUXXQZLiuv3+oqHvdPB7VTDCG0TY3B+w0=; b=cYyPAUGU9mrXSerCfVAC+7Dju7eJj+L46wzla6QvYJD/q6JDdDHWLa9jCqeMUibunR sHx6HM00pLNuofi1imtW+85cmSgz/FpghaDciTpREx2pjazY4Y90qGXp78x0YzV41AgA iH8lsb1kKbPuK8hjarYgeCh2yFhIBJCHtDUlIpHbm9uezezrlCymCnq0wlmg90HNEqQy SmRLvAGS5Z0WO0s1RaS8Kb4P5WwVYBeKcT4opNiPcr0sIjOc0h6TYZxh2sBMIiv5XGE9 poNP0l1qVqDixrj5HZ4nYQ96BQS9DjnzBOWXk+xB8GRfRq1lucKqUrYJDDU/lOqjI2bI XQJg== X-Received: by 10.66.159.8 with SMTP id wy8mr22606819pab.17.1408218901413; Sat, 16 Aug 2014 12:55:01 -0700 (PDT) Received: from [192.168.178.23] (128.198.69.111.dynamic.snap.net.nz. [111.69.198.128]) by mx.google.com with ESMTPSA id h5sm1153264pdn.83.2014.08.16.12.54.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Aug 2014 12:55:00 -0700 (PDT) Message-ID: <53EFB719.70508@gmail.com> Date: Sun, 17 Aug 2014 07:55:05 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> <53EEFEEE.8020505@globis.net> In-Reply-To: <53EEFEEE.8020505@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ybcg7F3sgOnV9yej6CaLREk_aq4 Cc: roll , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 19:55:05 -0000 Ray, On 16/08/2014 18:49, Ray Hunter wrote: >> Philip Levis >> 16 August 2014 02:33 >> >> 1) There is an extension header already; the problem is that it can >> introduce a significant (ballpark estimates are, in well engineered >> networks, up to 5-10%) cost. The proposal is to replace the extension >> header with using the flow label. >> >> 2) There'a already significant IP header compression in the cases >> we're talking about. >> >> Phil > > I'm sympathetic to the needs of low power devices. > > However, to be clear, we are reengineering a standards track document > that is around 2 years old (http://tools.ietf.org/html/rfc6553), and > which works technically, and we are proposing an additional encoding of > exactly the same information to achieve theoretical efficiency gains > that are still only rough estimates? > > Where's the experimental proof that this will really pay off in > increased battery life? > > You write "replace". Will 6553 now be deprecated? > > If not we'll have: > > 6553 to carry RPL information as an option header. > > draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a > flow label > > flow label information used to select patch and load balancing in > multi-path networks. e.g. > http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203 > > http://tools.ietf.org/html/rfc6438 > http://tools.ietf.org/html/rfc7098 > > I do not see that these applications for this one field are mutually > compatible, and worse still, the only way to decode the semantics of the > overloaded field is by applying some unknown external context ("within > RPL domain"/ "on the Internet"). No, I don't see a problem there. The boundary of a RPL domain is very well defined and flow-label-for-rpl clearly specifies that outside that boundary, RFC 6437 applies (which enables RFC 6438 and 7098). > The hidden "cost" here is that we will have 3 different overlapping > solutions = code bloat and potentially a lot of additional processing to > locate the correct information and then process it, which is also a hit > on energy efficiency. > > IMHO the bar should be pretty high for accepting this proposal, as it is > not actually solving a tangible issue. Whether ROLL wants to endorse alternative methods within RPL domains is not a 6man question. > > Also my prediction of the next request for field overloading will be: > My ISP only delegates one /64 with PD > I have multiple links in my Homenet > All my media is EUI48 based. No one really uses EUI64. > I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for > routing in Homenet by encoding a (V)LAN ID in it. > It's OK though. Homenet is a walled garden and I'll rewrite the field at > the exit so no one will ever know. Nice strawman, but why is it relevant? There's no need to rewrite the bits, BTW. As RFC 7136 says: "However, the method of generating IIDs for specific link types MAY define some local significance for certain bits... the whole IID value MUST be viewed as an opaque bit string by third parties, except possibly in the local context." Brian > As an alternative: if this information is really RPL specific, why not > just add the RPL Information as a tag to the front of the packet e.g. > via an MPLS label? > > MPLS labels are only 4 octets, and are designed to be very efficient and > fast. > You can easily strip them at egress, and munge it/set it on ingress. > It's clear where an MPLS domain ends and starts: no chance of RPL > information leaking onto the Internet, or entering from the Internet. > The MPLS label also transports the 20 bits of information you need. > MPLS labels are at a clear fixed position in the packet and are easy and > efficient to parse. > You could also then nest RPL domains if you ever wanted to do that. > It's also extensible, as you can push more labels on the stack in the > future if you ever want to extend the RPL Information transported, > whereas the flow label is a single fixed field. > It does not require any new standard, except maybe an informational RFC > on how to encode the RPL Information into MPLS labels. > And it doesn't overload anything. > > regards, > >> Ray Hunter >> 15 August 2014 21:49 >> >> >> >> +1 >> >> Apologies for tardy response (holidays) >> >> After reading the draft it seems to me that what is being attempted is >> 1) to add some stuff to the IPv6 header that is RPL domain specific >> 2) to reduce the overall packet length to reduce active radio time and >> thus save energy >> by >> 3) overloading an existing well-defined and used IPv6 header field >> >> My simple logic tells me that >> 1) could be best solved at an architecture level via an extension >> header http://tools.ietf.org/html/rfc2460#page-11 + >> http://tools.ietf.org/html/rfc7045 >> 2) could be best solved at an architecture level via IP header >> compression http://tools.ietf.org/html/rfc2507.html with or without >> additional tweaks >> and that overloading an opaque field in 3) by incorporating values >> with low entropy (as per the RPL flow label) gives additional security >> risks to http://tools.ietf.org/html/rfc7098 >> >> So what's wrong with my simple logic? >> >> "But if we consider the whole RPL domain as a large virtual host from >> the standpoint of the rest of the Internet" would suggest to me that >> the cost of stripping out the additional IPv6 hop by hop extension >> header at the edge of the domain is a bogus argument, as you'll anyway >> have to provide some adaption and security at the root of each RPL >> domain to detect and bounce spoofed RPL Information from entering, or >> private RPL Information leaking out of each domain. Whether this >> domain-specificRPL Information is encoded in an explicit hop by hop >> option or an overloaded flow label would seem largely irrelevant to >> that operation at the RPL root (especially since the RPL root anyway >> has to be a high power node to be able communicate with the rest of >> the Internet). >> >> IMHO If you overload the flow label you're looking at creating an >> incompatible walled garden, with competing IETF standards that are >> mutually exclusive. >> >> ------------------------------------------------------------------------ > > From nobody Sat Aug 16 14:03:06 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 0D88D1A036F; Sat, 16 Aug 2014 14:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qdjtyNjrVr1r; Sat, 16 Aug 2014 14:03:00 -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 B4D011A036D; Sat, 16 Aug 2014 14:03:00 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 57DE72002B; Sat, 16 Aug 2014 17:06:03 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EEEDF63AC9; Sat, 16 Aug 2014 17:02:58 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DB71C638D6; Sat, 16 Aug 2014 17:02:58 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks , 6man WG , Ralph Droms In-Reply-To: <53EEB205.3040205@gmail.com> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <200645F3-ACEA-4F88-AD30-35998803FB54@cs.stanford.edu> <53EEB205.3040205@gmail.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/2CWHfI3ID5vvNuA0VAVsxHi9j94 Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 21:03:03 -0000 Brian E Carpenter wrote: > A reader of flow-label-for-rpl needs to read RFC 6437 in order to > correctly > understand and implement flow-label-for-rpl. So RFC 6437 is correctly a > normative reference. However, a reader of RFC 6437 has no need to be > aware > of flow-label-for-rpl in order to correctly implement RFC 6437 in any > non-RPL > node. So I see no logic in saying that flow-label-for-rpl updates 6437. So, if 6437 was revised, when you would not see a reason to pull any of the text from flow-label-for-rpl into a 6437bis? (that's my logic for Updates:... ) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Sat Aug 16 15:07: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 52B441A0406; Sat, 16 Aug 2014 15:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, 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 ONpAKBMD8SwU; Sat, 16 Aug 2014 15:07:48 -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 2F3721A0404; Sat, 16 Aug 2014 15:07:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F39E320029; Sat, 16 Aug 2014 18:10:51 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 75DA763AC9; Sat, 16 Aug 2014 18:07:47 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5F9A6638D6; Sat, 16 Aug 2014 18:07:47 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <9051878F-04DC-4FAD-BE53-056826FD1070@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/sdkUCvipLixECDt5DEpgpN0S1gs Cc: 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 22:07:50 -0000 --=-=-= Pascal Thubert (pthubert) wrote: > And my conclusion to 6MAN is that the changes of rules that are > requested in the draft are useful whether or not people are willing to > use the flow label as the transport for the RPL option inside the RPL > domain. Since this is the question on the table for 6MAN, I think that > the answer is now clearly a yes. Should we split the issue up? 1) blessing/permission/exception to reset flow label within an LLN, (which would include simply setting it to zero so it can be compressed out) 2) a document on how to compress 6553 HbH into ?flow-label vs ?6lo-HC. I am not enthusiastic about multiple ways. We will have an existing problem of figuring out 6553 vs new-way, and also noting that some nodes will needed to continue to speak 6553 on some links anyway (backhaul ethernet). >> it mentions ISA100.11a only in the introduction.) My understanding is that ISA100.11a uses the flow label to pick a path, but not in a way that involves rewritting it on each hop in the LLN. Please correct me if I'm wrong; it seems that document (1) is needed to retro-actively bless ISA100.11a usage :-) [I'm writing this on a rainy Saturday afternoon, at a friend's house, playing 1st Ed AD&D, and my two characters are unconcious... so when I use the term "bless"... you'll understand the context] -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU+/WL4CLcPvd0N1lAQIFwgf9HSEQB5AhWfoJYn9bmmw7h8j1Y3S+nDfi oHAW7r4xBRLG32IB7R91yt4DOzHBpsOD2uU3PTycgNhqWXNbCxnAhEBqsgAVuqBs SWfd4JABP2DH0EXFkTBYKI2DCYBIemgWSBCQ1ct6zsKrVeqrJUibcIXmRK84Q2+c ly2ZEsdIR0Jt4dtPH/55Z+O9zCJCsPaiYQC2JogQht8/ZY5whQ2kj6j32ryHjqk5 M3xjGXMeyUeLlISdL9/mNitCBvRex3juYJEbwPME6gRLYjBsjVN/budJE/4vPsHM 9eFzUGGiHNm2MbpFuC2L/36qrga+EgGaF0RDswnTYecLcqnSx1tk7g== =qjIU -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 16 15:12: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 F35831A0479; Sat, 16 Aug 2014 15:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 id0X9nBsY-rK; Sat, 16 Aug 2014 15:12:10 -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 DC8E11A0478; Sat, 16 Aug 2014 15:12:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AEA8520029; Sat, 16 Aug 2014 18:15:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 206E863AC9; Sat, 16 Aug 2014 18:12:09 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 08045638D6; Sat, 16 Aug 2014 18:12:09 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <9322723A-842E-4C10-BFB7-63C88A968169@tzi.org> References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org> <9322723A-842E-4C10-BFB7-63C88A968169@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/1n6AVy_mVqAWEbFs7KV5C3EHQnQ Cc: 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] RPL Information Header for 6lo (Re: [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 22:12:11 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > This draft is both intended as a response to the WGLC referenced in t= he > subject and as a proposal to the 6lo working group to pick this up as= a > working group item. (Clearly, if we do this, we=E2=80=99ll want lots= of input > from ROLL whether we are doing the right thing, while it is 6lo=E2=80= =99s job > to do the thing right. No changes to the IP architecture are require= d, > so there is no need to bother 6man with this work.) I think that we still need a blessing to reset the flow label to zero upon entering the LLN, so that it can be nicely compressed out. I think that we have that blessing. Please see my other email suggesting a split. > Heads up: I=E2=80=99ll have limited E-Mail access Aug 16 to Sep 3. In your absense I am interested to hear from others about any preference about technical solutions. Please speak up. =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) iQEVAwUBU+/XNoCLcPvd0N1lAQJaTgf/aCiLMi6ZJ04I54AGDEy9F4pLsELaZUar ldC4uB5335Ml/JDWUbl0o4sgFwfedFjAXw8/wgv3J4Z2xH+WFknO4n4LlAHCFuNZ 5Ol2/OyfQijyweMwPhp3u5YNxVmsf8fQeWmjcNoJyKwmlmnqMK9jOtxvLTWhvJef eiGEgTpPEwoUXPHxILodyx/EhcNP3PB+E0QmMeHmirLjCbeO4ty6oDf/7JY2vzW6 SR3Ec6OM1Wv4lQQYQLOeRBjRD0M4WRVE9sI56dU+JhWjnhiuCJUu23salHAbP9Eh oz4krqFUq/z5EhAtn0qzw5tGVDH/JxyltpQF5qxJsLt1PKDHpWPVcg== =sj9n -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 16 15:33: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 0ECCB1A0489; Sat, 16 Aug 2014 15:33:00 -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 Ug5SdD1BZS8i; Sat, 16 Aug 2014 15:32:59 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABB31A0487; Sat, 16 Aug 2014 15:32:58 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id eu11so5432404pac.32 for ; Sat, 16 Aug 2014 15:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Mcus3dMyu/W08/fwUBYxpixiK/1cX3W5voNQd9erCdw=; b=oM3uz1W+0ZzsF3cv4bD6EDh7YlrM58DRUEPj1VyysAVNKaX5jFbTfPi0eqjNwLD+nl KtCQTTBMtu8BH/yI86CwoTx6myJt/XyujfjRsbOOhAyjc/WJVZy6Q8sAuPirSmgnucFv +50TWCiddW7+M7wOcOBfZ0VncJejDQcLbOxma3QCOWgvAEA0TZXd86dzRDAACmU8aDXN hYw6qMHCRCxAFZ7w6vqQy0WHD3X5mAeIV86EHPsdnqbqFp0iKLnumlQRIiqI48Qm5WRA rj1Nkwh7kCXL66H0gfYm/Bc35b2q8vEmciWZHXey6sHJs73h550wiRg/pjdDPzsvPJ/z JpFg== X-Received: by 10.68.163.100 with SMTP id yh4mr23158900pbb.122.1408228378552; Sat, 16 Aug 2014 15:32:58 -0700 (PDT) Received: from [192.168.178.23] (128.198.69.111.dynamic.snap.net.nz. [111.69.198.128]) by mx.google.com with ESMTPSA id zf5sm41985113pac.41.2014.08.16.15.32.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Aug 2014 15:32:57 -0700 (PDT) Message-ID: <53EFDC26.1010706@gmail.com> Date: Sun, 17 Aug 2014 10:33:10 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <200645F3-ACEA-4F88-AD30-35998803FB54@cs.stanford.edu> <53EEB205.3040205@gmail.com> <3278.1408222978@sandelman.ca> In-Reply-To: <3278.1408222978@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/K8eqEIOTYFH_NGDH5QskT1uavzY Cc: Routing Over Low power and Lossy networks , 6man WG Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 22:33:00 -0000 On 17/08/2014 09:02, Michael Richardson wrote: > Brian E Carpenter wrote: > > A reader of flow-label-for-rpl needs to read RFC 6437 in order to > > correctly > > understand and implement flow-label-for-rpl. So RFC 6437 is correctly a > > normative reference. However, a reader of RFC 6437 has no need to be > > aware > > of flow-label-for-rpl in order to correctly implement RFC 6437 in any > > non-RPL > > node. So I see no logic in saying that flow-label-for-rpl updates 6437. > > So, if 6437 was revised, when you would not see a reason to pull any of > the text from flow-label-for-rpl into a 6437bis? > (that's my logic for Updates:... ) Well, it's a matter of taste. I'd say not: I see no reason why an implementer of a normal (non-RPL-aware) node should be sent off to read a bunch of RPL documents, which is what such an update would imply. Brian From nobody Sun Aug 17 07:15:27 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 A852B1A081B; Sun, 17 Aug 2014 02:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, 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 SeQDP-mdF1F9; Sun, 17 Aug 2014 02:52:47 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id C40ED1A081E; Sun, 17 Aug 2014 02:52:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8943787153F; Sun, 17 Aug 2014 11:52:45 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8cVLh72qPyl; Sun, 17 Aug 2014 11:52:45 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:71e5:ffdb:956c:66e1]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 3B43687005C; Sun, 17 Aug 2014 11:52:45 +0200 (CEST) Message-ID: <53F07B55.7050708@globis.net> Date: Sun, 17 Aug 2014 11:52:21 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Brian E Carpenter References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> <53EEFEEE.8020505@globis.net> <53EFB719.70508@gmail.com> In-Reply-To: <53EFB719.70508@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/v2ahmuFwL9feIdffekDt_qPZQDA X-Mailman-Approved-At: Sun, 17 Aug 2014 07:15:24 -0700 Cc: roll , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 09:52:49 -0000 > Brian E Carpenter > 16 August 2014 21:55 > Ray, > > On 16/08/2014 18:49, Ray Hunter wrote: >>> Philip Levis >>> 16 August 2014 02:33 >>> >>> 1) There is an extension header already; the problem is that it can >>> introduce a significant (ballpark estimates are, in well engineered >>> networks, up to 5-10%) cost. The proposal is to replace the extension >>> header with using the flow label. >>> >>> 2) There'a already significant IP header compression in the cases >>> we're talking about. >>> >>> Phil >> I'm sympathetic to the needs of low power devices. >> >> However, to be clear, we are reengineering a standards track document >> that is around 2 years old (http://tools.ietf.org/html/rfc6553), and >> which works technically, and we are proposing an additional encoding of >> exactly the same information to achieve theoretical efficiency gains >> that are still only rough estimates? >> >> Where's the experimental proof that this will really pay off in >> increased battery life? >> >> You write "replace". Will 6553 now be deprecated? >> >> If not we'll have: >> >> 6553 to carry RPL information as an option header. >> >> draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a >> flow label >> >> flow label information used to select patch and load balancing in >> multi-path networks. e.g. >> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203 >> >> http://tools.ietf.org/html/rfc6438 >> http://tools.ietf.org/html/rfc7098 >> >> I do not see that these applications for this one field are mutually >> compatible, and worse still, the only way to decode the semantics of the >> overloaded field is by applying some unknown external context ("within >> RPL domain"/ "on the Internet"). > > No, I don't see a problem there. The boundary of a RPL domain is > very well defined and flow-label-for-rpl clearly specifies that > outside that boundary, RFC 6437 applies (which enables RFC 6438 > and 7098). But inside an RPL domain, you cannot use any RFC's that reference the flow label as per 6437, because all of the entropy has gone. And what happened to our end to end architecture? I just do not like the concept of parsing a packet, and then having to determine the semantics of the contents of a particular field based on a "domain" that is not carried anywhere in the packet. e.g. think about decoding offline captures >> The hidden "cost" here is that we will have 3 different overlapping >> solutions = code bloat and potentially a lot of additional processing to >> locate the correct information and then process it, which is also a hit >> on energy efficiency. >> >> IMHO the bar should be pretty high for accepting this proposal, as it is >> not actually solving a tangible issue. > > Whether ROLL wants to endorse alternative methods within RPL > domains is not a 6man question. >> Also my prediction of the next request for field overloading will be: >> My ISP only delegates one /64 with PD >> I have multiple links in my Homenet >> All my media is EUI48 based. No one really uses EUI64. >> I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for >> routing in Homenet by encoding a (V)LAN ID in it. >> It's OK though. Homenet is a walled garden and I'll rewrite the field at >> the exit so no one will ever know. > > Nice strawman, but why is it relevant? There's no need to rewrite > the bits, BTW. As RFC 7136 says: > "However, the method of generating IIDs for specific link types MAY > define some local significance for certain bits... the whole IID value > MUST be viewed as an opaque bit string by third parties, except possibly > in the local context." > > Brian > >> As an alternative: if this information is really RPL specific, why not >> just add the RPL Information as a tag to the front of the packet e.g. >> via an MPLS label? >> >> MPLS labels are only 4 octets, and are designed to be very efficient and >> fast. >> You can easily strip them at egress, and munge it/set it on ingress. >> It's clear where an MPLS domain ends and starts: no chance of RPL >> information leaking onto the Internet, or entering from the Internet. >> The MPLS label also transports the 20 bits of information you need. >> MPLS labels are at a clear fixed position in the packet and are easy and >> efficient to parse. >> You could also then nest RPL domains if you ever wanted to do that. >> It's also extensible, as you can push more labels on the stack in the >> future if you ever want to extend the RPL Information transported, >> whereas the flow label is a single fixed field. >> It does not require any new standard, except maybe an informational RFC >> on how to encode the RPL Information into MPLS labels. >> And it doesn't overload anything. >> >> regards, >> >>> Ray Hunter >>> 15 August 2014 21:49 >>> >>> >>> >>> +1 >>> >>> Apologies for tardy response (holidays) >>> >>> After reading the draft it seems to me that what is being attempted is >>> 1) to add some stuff to the IPv6 header that is RPL domain specific >>> 2) to reduce the overall packet length to reduce active radio time and >>> thus save energy >>> by >>> 3) overloading an existing well-defined and used IPv6 header field >>> >>> My simple logic tells me that >>> 1) could be best solved at an architecture level via an extension >>> header http://tools.ietf.org/html/rfc2460#page-11 + >>> http://tools.ietf.org/html/rfc7045 >>> 2) could be best solved at an architecture level via IP header >>> compression http://tools.ietf.org/html/rfc2507.html with or without >>> additional tweaks >>> and that overloading an opaque field in 3) by incorporating values >>> with low entropy (as per the RPL flow label) gives additional security >>> risks to http://tools.ietf.org/html/rfc7098 >>> >>> So what's wrong with my simple logic? >>> >>> "But if we consider the whole RPL domain as a large virtual host from >>> the standpoint of the rest of the Internet" would suggest to me that >>> the cost of stripping out the additional IPv6 hop by hop extension >>> header at the edge of the domain is a bogus argument, as you'll anyway >>> have to provide some adaption and security at the root of each RPL >>> domain to detect and bounce spoofed RPL Information from entering, or >>> private RPL Information leaking out of each domain. Whether this >>> domain-specificRPL Information is encoded in an explicit hop by hop >>> option or an overloaded flow label would seem largely irrelevant to >>> that operation at the RPL root (especially since the RPL root anyway >>> has to be a high power node to be able communicate with the rest of >>> the Internet). >>> >>> IMHO If you overload the flow label you're looking at creating an >>> incompatible walled garden, with competing IETF standards that are >>> mutually exclusive. >>> >>> ------------------------------------------------------------------------ > ------------------------------------------------------------------------ -- Regards, RayH From nobody Sun Aug 17 12:58:21 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9711A6FCF; Sun, 17 Aug 2014 12:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_51=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP3WD53madc4; Sun, 17 Aug 2014 12:58:10 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77731A0AA3; Sun, 17 Aug 2014 12:58:10 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so6241236pdj.28 for ; Sun, 17 Aug 2014 12:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NpWmIR4H2InPyhtgEmo2FAQzRlXEVF03ACMf4v0NNTQ=; b=0InAO5GLB0+m2lgPSmCf7/VorbkQyZVcq2bT8a/5lUnqMTDbMOcaRxqGnYAeraOKM2 cGcGETCCoMuNsK1wjrCYzFP6ABkjIF5Tc/XgitPjuxbOMAGjCbLdu6NPASGHgTe4a6Ts Q6njxudkfpj9z8y02W+v/C3WITM6Cl50LspcjbYSS0wjYDmmu57ehFhWF08/Fy1X5Hww Dt09gIvUcDTBIlZMBQgiWTxY3j+zpPCre5JTWzUDjdR9OcuKvf7hzLvog8qIUKFoN8z5 IoiHY73f3bhsnNSEIbTxCJffG0lj0GTiA7ZD4e9Pwe41465QzH7lG42KtHZb3Ksq/e50 UQig== X-Received: by 10.69.20.11 with SMTP id gy11mr29540063pbd.28.1408305490215; Sun, 17 Aug 2014 12:58:10 -0700 (PDT) Received: from [192.168.178.23] (58.199.69.111.dynamic.snap.net.nz. [111.69.199.58]) by mx.google.com with ESMTPSA id qb2sm14094392pbb.0.2014.08.17.12.58.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Aug 2014 12:58:09 -0700 (PDT) Message-ID: <53F10959.2000102@gmail.com> Date: Mon, 18 Aug 2014 07:58:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> <53EEFEEE.8020505@globis.net> <53EFB719.70508@gmail.com> <53F07B55.7050708@globis.net> In-Reply-To: <53F07B55.7050708@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/yGf5T0eplP_uLzcSWbrHYcnm7LA Cc: roll , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 19:58:13 -0000 On 17/08/2014 21:52, Ray Hunter wrote: >> Brian E Carpenter >> 16 August 2014 21:55 >> Ray, >> >> On 16/08/2014 18:49, Ray Hunter wrote: >>>> Philip Levis >>>> 16 August 2014 02:33 >>>> >>>> 1) There is an extension header already; the problem is that it can >>>> introduce a significant (ballpark estimates are, in well engineered >>>> networks, up to 5-10%) cost. The proposal is to replace the extension >>>> header with using the flow label. >>>> >>>> 2) There'a already significant IP header compression in the cases >>>> we're talking about. >>>> >>>> Phil >>> I'm sympathetic to the needs of low power devices. >>> >>> However, to be clear, we are reengineering a standards track document >>> that is around 2 years old (http://tools.ietf.org/html/rfc6553), and >>> which works technically, and we are proposing an additional encoding of >>> exactly the same information to achieve theoretical efficiency gains >>> that are still only rough estimates? >>> >>> Where's the experimental proof that this will really pay off in >>> increased battery life? >>> >>> You write "replace". Will 6553 now be deprecated? >>> >>> If not we'll have: >>> >>> 6553 to carry RPL information as an option header. >>> >>> draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a >>> flow label >>> >>> flow label information used to select patch and load balancing in >>> multi-path networks. e.g. >>> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203 >>> >>> >>> http://tools.ietf.org/html/rfc6438 >>> http://tools.ietf.org/html/rfc7098 >>> >>> I do not see that these applications for this one field are mutually >>> compatible, and worse still, the only way to decode the semantics of the >>> overloaded field is by applying some unknown external context ("within >>> RPL domain"/ "on the Internet"). >> >> No, I don't see a problem there. The boundary of a RPL domain is >> very well defined and flow-label-for-rpl clearly specifies that >> outside that boundary, RFC 6437 applies (which enables RFC 6438 >> and 7098). > But inside an RPL domain, you cannot use any RFC's that reference the > flow label as per 6437, because all of the entropy has gone. Correct. But isn't that a trade-off that might be reasonable in the low-power lossy environment? (That's not intended as a rhetorical question - I just don't have enough knowledge of that environment to answer it.) > > And what happened to our end to end architecture? There are various views of what e2e means, but I still like the phrase "certain required end-to-end functions can only be performed correctly by the end-systems themselves". Load balancing and adaptive routing are not actually e2e functions in that sense. > I just do not like the concept of parsing a packet, and then having to > determine the semantics of the contents of a particular field based on a > "domain" that is not carried anywhere in the packet. I see the objection, but we've been doing it for years; diffserv does it by definition. Brian > e.g. think about decoding offline captures >>> The hidden "cost" here is that we will have 3 different overlapping >>> solutions = code bloat and potentially a lot of additional processing to >>> locate the correct information and then process it, which is also a hit >>> on energy efficiency. >>> >>> IMHO the bar should be pretty high for accepting this proposal, as it is >>> not actually solving a tangible issue. >> >> Whether ROLL wants to endorse alternative methods within RPL >> domains is not a 6man question. >>> Also my prediction of the next request for field overloading will be: >>> My ISP only delegates one /64 with PD >>> I have multiple links in my Homenet >>> All my media is EUI48 based. No one really uses EUI64. >>> I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for >>> routing in Homenet by encoding a (V)LAN ID in it. >>> It's OK though. Homenet is a walled garden and I'll rewrite the field at >>> the exit so no one will ever know. >> >> Nice strawman, but why is it relevant? There's no need to rewrite >> the bits, BTW. As RFC 7136 says: >> "However, the method of generating IIDs for specific link types MAY >> define some local significance for certain bits... the whole IID value >> MUST be viewed as an opaque bit string by third parties, except possibly >> in the local context." >> >> Brian >> >>> As an alternative: if this information is really RPL specific, why not >>> just add the RPL Information as a tag to the front of the packet e.g. >>> via an MPLS label? >>> >>> MPLS labels are only 4 octets, and are designed to be very efficient and >>> fast. >>> You can easily strip them at egress, and munge it/set it on ingress. >>> It's clear where an MPLS domain ends and starts: no chance of RPL >>> information leaking onto the Internet, or entering from the Internet. >>> The MPLS label also transports the 20 bits of information you need. >>> MPLS labels are at a clear fixed position in the packet and are easy and >>> efficient to parse. >>> You could also then nest RPL domains if you ever wanted to do that. >>> It's also extensible, as you can push more labels on the stack in the >>> future if you ever want to extend the RPL Information transported, >>> whereas the flow label is a single fixed field. >>> It does not require any new standard, except maybe an informational RFC >>> on how to encode the RPL Information into MPLS labels. >>> And it doesn't overload anything. >>> >>> regards, >>> >>>> Ray Hunter >>>> 15 August 2014 21:49 >>>> >>>> >>>> >>>> +1 >>>> >>>> Apologies for tardy response (holidays) >>>> >>>> After reading the draft it seems to me that what is being attempted is >>>> 1) to add some stuff to the IPv6 header that is RPL domain specific >>>> 2) to reduce the overall packet length to reduce active radio time and >>>> thus save energy >>>> by >>>> 3) overloading an existing well-defined and used IPv6 header field >>>> >>>> My simple logic tells me that >>>> 1) could be best solved at an architecture level via an extension >>>> header http://tools.ietf.org/html/rfc2460#page-11 + >>>> http://tools.ietf.org/html/rfc7045 >>>> 2) could be best solved at an architecture level via IP header >>>> compression http://tools.ietf.org/html/rfc2507.html with or without >>>> additional tweaks >>>> and that overloading an opaque field in 3) by incorporating values >>>> with low entropy (as per the RPL flow label) gives additional security >>>> risks to http://tools.ietf.org/html/rfc7098 >>>> >>>> So what's wrong with my simple logic? >>>> >>>> "But if we consider the whole RPL domain as a large virtual host from >>>> the standpoint of the rest of the Internet" would suggest to me that >>>> the cost of stripping out the additional IPv6 hop by hop extension >>>> header at the edge of the domain is a bogus argument, as you'll anyway >>>> have to provide some adaption and security at the root of each RPL >>>> domain to detect and bounce spoofed RPL Information from entering, or >>>> private RPL Information leaking out of each domain. Whether this >>>> domain-specificRPL Information is encoded in an explicit hop by hop >>>> option or an overloaded flow label would seem largely irrelevant to >>>> that operation at the RPL root (especially since the RPL root anyway >>>> has to be a high power node to be able communicate with the rest of >>>> the Internet). >>>> >>>> IMHO If you overload the flow label you're looking at creating an >>>> incompatible walled garden, with competing IETF standards that are >>>> mutually exclusive. >>>> >>>> ------------------------------------------------------------------------ >>>> >> ------------------------------------------------------------------------ > > From nobody Mon Aug 18 03:06:19 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19881A03A7; Mon, 18 Aug 2014 03:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.569 X-Spam-Level: X-Spam-Status: No, score=-14.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, 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 wGfMG2m53rdu; Mon, 18 Aug 2014 03:06:15 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA611A03A6; Mon, 18 Aug 2014 03:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3633; q=dns/txt; s=iport; t=1408356376; x=1409565976; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sBLDQrNzuw5RnVjBaLMW5qHxdD0jl6tnDGod3YtooL8=; b=TdTw+1cO2UafMqjBVz/+PUGubZhbZxKahwsaaRZ/U+qxoj7CVDTGp4pB kav3CqtF+ya/RCrnFIXGSq6GBrr3QGOjPg6KGiWZZMFMTdwM3XjwwzLua x6zEgm2g3yrB41GUT4hqxI+Erw3Y/LvKlcvkVWFOl51ndHSZLJfQwd7WA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAP7O8VOtJA2N/2dsb2JhbABZgw2BKgTURwGBGhZ3hAMBAQEEeQwEAgEIEQQBAQEKHQcyFAkIAgQOBQiIOsECF45+HTEHBoMpgR0FimaGP6Agg11sgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.01,885,1400025600"; d="scan'208";a="348273976" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP; 18 Aug 2014 10:06:15 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7IA6DfQ021839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 10:06:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 05:06:13 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPuswKNbfwRx2Yk0qsf2NSaa5I/A== Date: Mon, 18 Aug 2014 10:06:12 +0000 Deferred-Delivery: Mon, 18 Aug 2014 10:06:00 +0000 Message-ID: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org> <18424.1408226867@sandelman.ca> In-Reply-To: <18424.1408226867@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.27] 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/PCeE8i_s_LVKbB8z-NmrC5N_Msk Cc: "6tisch@ietf.org" <6tisch@ietf.org>, 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 18 Aug 2014 10:06:16 -0000 Hello Michael; The discussion was difficult enough with 2 WGs (just keeping clear on which= WG was asked what question). Now Carsten has broadened the discussion to 6lo and thus the complexity.=20 In practice the discussion also impacts 6TiSCH because 6TiSCH will ship the= minimal RPL over TSCH to IESG this year (draft-ietf-6tisch-minimal). I'm not fan of 2 ways either. But we have to face that unless we keep the H= BH-based approach only (which is doubtlessly the worst possible outcome), t= hen we are already in that situation for some implementation(s). For the lack of any other (pending) RFC, the 6TiSCH minimal draft will have= point on the HbH-based approach and that approach will spread to 6TiSCH as= well, where it hurts the most due to the very small frame size. And then t= here will have to be a deprecation and a migration to whatever ROLL and 6lo= decide to do. I'd rather have the starting point be the flow label and the= n decide if we really want something else for 6TiSCH, what that something e= lse is and if that something else is actually beneficial, which is not a do= ne deal yet. In any fashion, I think that we all agree that we need 6MAN to allow the bo= rder router (RPL root) to update the Flow Label. So I'm in full agreement w= ith you that the complexity we are now facing can be better addressed by sp= litting the draft. One 6MAN-only draft that allows ROLL to do what the curr= ent draft does, and one ROLL draft that does it. At that point it will be u= p to ROLL (only) to standardize the second draft immediately or to wait and= see whatever progress happens at 6lo. Cheers, Pascal > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: dimanche 17 ao=FBt 2014 00:08 > To: Routing Over Low power and Lossy networks > Cc: 6man WG; 6lo@ietf.org WG > Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-= 03 >=20 >=20 > Pascal Thubert (pthubert) wrote: > > And my conclusion to 6MAN is that the changes of rules that are > > requested in the draft are useful whether or not people are willing= to > > use the flow label as the transport for the RPL option inside the R= PL > > domain. Since this is the question on the table for 6MAN, I think t= hat > > the answer is now clearly a yes. >=20 > Should we split the issue up? > 1) blessing/permission/exception to reset flow label within an LLN, > (which would include simply setting it to zero so it can be compressed > out) >=20 > 2) a document on how to compress 6553 HbH into ?flow-label vs ?6lo-HC. >=20 > I am not enthusiastic about multiple ways. > We will have an existing problem of figuring out 6553 vs new-way, > and also noting that some nodes will needed to continue to speak 6553 > on some links anyway (backhaul ethernet). >=20 >=20 > >> it mentions ISA100.11a only in the introduction.) >=20 > My understanding is that ISA100.11a uses the flow label to pick a path, b= ut > not in a way that involves rewritting it on each hop in the LLN. > Please correct me if I'm wrong; it seems that document (1) is needed to > retro-actively bless ISA100.11a usage :-) >=20 > [I'm writing this on a rainy Saturday afternoon, at a friend's house, pla= ying > 1st Ed AD&D, and my two characters are unconcious... so when I use the > term "bless"... you'll understand the context] >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Mon Aug 18 05:51:51 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFC81A024F; Mon, 18 Aug 2014 05:51:45 -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 WHn7577gj1oQ; Mon, 18 Aug 2014 05:51:43 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829471A01BD; Mon, 18 Aug 2014 05:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9398; q=dns/txt; s=iport; t=1408366304; x=1409575904; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OrnELmPzcPxGrIlAcbEtLy8zy5/sClgkLs5GP8ErCkI=; b=RTLtjg24o4t/ad2BJfD6aERh892Qd03PEd4KBKoVIV69l/0RdnehHl4V V6fA52LONT88hglZT+/QMtssJxOcTHscSjQ3xAbdcRCH6ZGIirvedI41f rTvtGd3oBx3umb4zgseVbKmnaO1FwgpzAzmtF61lUKy8a36iqnAAhhT35 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFAA328VOtJA2G/2dsb2JhbABZgw1TVwSCeMlyDodUARmBAhZ3hAMBAQECAgEBASARMwcLDAQCAQgRAQMBAQECAgYdAwICAh8GCxQBAgYIAgQBDQUIiCYDEQ2rf486DYUzF4Esi3OBSgwJHRYbBwaCczaBHQWGEYsUhl+CL5BfhjODXWwBAYEFQYEHAQEB X-IronPort-AV: E=Sophos;i="5.01,885,1400025600"; d="scan'208";a="70148401" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 18 Aug 2014 12:51:42 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7ICpgWT008194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 12:51:42 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 07:51:41 -0500 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter , Michael Richardson Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPt/zmHp7q4q9DoEKOFDPz7vG+hJvRXEcagAFl+gCAA4xFwA== Date: Mon, 18 Aug 2014 12:51:41 +0000 Deferred-Delivery: Mon, 18 Aug 2014 12:51:00 +0000 Message-ID: References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com> , <53ED1992.1010708@gmail.com> <755F123A-A93F-4146-BD4C-4022CD8CE13E@cisco.com> <53EEB016.4030105@gmail.com> In-Reply-To: <53EEB016.4030105@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/K8duW8wKTRoLqcI5h8jGl_EnLsY Cc: Routing Over Low power and Lossy networks , Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 18 Aug 2014 12:51:45 -0000 SGVsbG8gQnJpYW46DQoNCkkgZG8gbm90IHRoaW5rIHRoYXQgeW91IGNhbiBmcmVlbHkgZG93bmxv YWQgdGhlIHNwZWNpZmljYXRpb24uIFlvdSBwcm9iYWJseSBuZWVkIG1lbWJlcnNoaXAgZmlyc3Qu IFRoZSBsaW5rcyBleGlzdCBmcm9tIHRoZSBXaWtpcGVkaWEgcGFnZSBidXQgdGhleSBhcmUgYnJv a2VuLiBTYW1lIGdvZXMgZm9yIHRoZSBJRUMgdmVyc2lvbiB3aGljaCBpcyBJRUMgNjI3MzQsIGJ1 dCBpZiB5b3UgaGF2ZSBhY2Nlc3MgdG8gdGhlIElFQyB0aGVuIHRoZSBjdXJyZW50IHdvcmsgaXMg aGVyZSBodHRwOi8vd3d3LmllYy5jaC9jZ2ktYmluL3Jlc3RyaWN0ZWQvZ2V0ZmlsZS5wbC82NUNf NzM1ZWFfQ0RWLnBkZj9kaXI9NjVDJmZvcm1hdD1wZGYmdHlwZT1fQ0RWJmZpbGU9NzM1ZWEucGRm DQoNClF1b3RlczogDQoNCiJUaGUgQ29udHJhY3RJRCBpcyBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0 aWN1bGFyIEQtcm91dGUuIFRoaXMgbWF5IGJlIHVzZWQgd2hlbiBhIHBhcnRpY3VsYXIgZ3JhcGgg b3Igc291cmNlIEQtcm91dGUgaXMgaW50ZW5kZWQgdG8gcHJvdmlkZSBhIGRlZmluZWQgbGV2ZWwg b2Ygc2VydmljZSINCg0KIkZsb3dMYWJlbDogVGhlIGxvd2VyIG9yZGVyIDE2IGJpdHMgb2YgdGhl IEZsb3dMYWJlbCBzaGFsbCBiZSBzZXQgdG8gQ29udHJhY3RJRC4gVGhlIGhpZ2hlciBvcmRlciA0 IGJpdHMgc2hhbGwgYmUgYWxsIHplcm9zLiBUaGlzIGZpZWxkIHNoYWxsIG9ubHkgYmUgcHJlc2Vu dCBpZiBvY3RldHMgMyB0aHJvdWdoIDUgYXJlIHByZXNlbnQsIGFzIGluZGljYXRlZCBieSBMT1dQ QU5fSVBIQyBlbmNvZGluZy4iDQoNCk5vdGUgdGhhdCB0aGUgNlRpU0NIIGFyY2hpdGVjdHVyZSBl Y2hvZXMgdGhpcyBkZXNpZ24sIGFuZCBhIGQtcm91dGUgaXMgdmVyeSBzaW1pbGFyIHRvIGEgNlRp U0NIIHRyYWNrLg0KDQpGb3IgdGhlIHNha2Ugb2YgaGlzdG9yeSBhbmQgdG8gbXkgYmVzdCBrbm93 bGVkZ2UsIElTQTEwMC4xMWEgd2FzIHRoZSBmaXJzdCBpbmR1c3RyaWFsIHN0YW5kYXJkIHRvIGFk b3B0IElQdjYgZm9yIHByb2Nlc3MgY29udHJvbCBhcHBsaWNhdGlvbnMgKGNvbnRyb2wgbG9vcHMg YW5kIG1vbml0b3JpbmcpLiANCkl0IGlzIGVmZmVjdGl2ZWx5IGVuYWJsaW5nIElQIGluIHRoZSBj b250cm9sIG5ldHdvcmssIHdoaWNoIGlzIGFuIGhpc3RvcmljYWwgc3RlcCB0b3dhcmQgdGhlIElU L09UIGNvbnZlcmdlbmNlLCB0aGF0IGlzIHRoZSBJbmR1c3RyaWFsIGVxdWl2YWxlbnQgb2Ygdm9p Y2UgYW5kIHZpZGVvIGNvbnZlcmdlbmNlIG92ZXIgSVAuDQoNCkFuZCBhbHNvIHRvIG15IGJlc3Qg a25vd2xlZGdlIGFuZCBjb25mb3JtaW5nIFJGQyAzNjk3LCBJU0ExMDAuMTFhIGRvZXMgbm90IG11 dGUgdGhlIEZsb3cgTGFiZWwgaW5zaWRlIHRoZSBuZXR3b3JrLCBhcyBNaWNoYWVsIHBvaW50cyBv dXQuIE9ubHkgd2hlbiB0aGUgYWRkaXRpb25hbCBiYWNrYm9uZSBSb3V0ZXIgZnVuY3Rpb25hbGl0 eSBpcyBkZWZpbmVkIGRvZXMgdGhlIHByb2JsZW0gb2YgcmV3cml0aW5nIGNvbWUgaW50byBwbGF5 IGF0IHRoZSBCYWNrYm9uZSBSb3V0ZXIgKHNhbWUgcG9zaXRpb24gYXMgUlBMIHJvb3QpLiBGb3Ig YWxsIEkga25vdyB0aGlzIHdvcmsgaXMgdGFraW5nIHBsYWNlIGF0IHRoZSBXaXJlbGVzcyBDb21w bGlhbmNlIEluc3RpdHV0ZSwgV0NJLCBidXQgSSBkbyBub3QgaGF2ZSB0aGUgbGF0ZXN0Lg0KDQpD aGVlcnMsDQoNClBhc2NhbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21d DQo+IFNlbnQ6IHNhbWVkaSAxNiBhb8O7dCAyMDE0IDAzOjEzDQo+IFRvOiBQYXNjYWwgVGh1YmVy dCAocHRodWJlcnQpDQo+IENjOiBQaGlsaXAgTGV2aXM7IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIg YW5kIExvc3N5IG5ldHdvcmtzOyBJbmVzIFJvYmxlczsNCj4gNm1hbiBXRzsgNmxvQGlldGYub3Jn IFdHDQo+IFN1YmplY3Q6IFJlOiBbUm9sbF0gWzZsb10gV0dMQyBmb3IgZHJhZnQtdGh1YmVydC02 bWFuLWZsb3ctbGFiZWwtZm9yLXJwbC0wMw0KPiANCj4gT24gMTUvMDgvMjAxNCAyMDo1MSwgUGFz Y2FsIFRodWJlcnQgKHB0aHViZXJ0KSB3cm90ZToNCj4gPiBIZWxsbyBCcmlhbg0KPiA+DQo+ID4g SSBkbyBub3QgdGhpbmsgdGhhdCBJU0ExMDAxMS5hIHZpb2xhdGVzIFJGQyAzNjk3LiBXaGF0IGV4 YWN0bHkgbWFkZSB5b3UNCj4gYmVsaWV2ZSBzbz8NCj4gDQo+IEkgd2FzIG92ZXItaW50ZXJwcmV0 aW5nIHdoYXQgeW91IHdyb3RlLCBJIGd1ZXNzLiBJdCdzIHRydWUgdGhhdCAzNjk3IHdhcyByYXRo ZXINCj4gdmFndWUgYWJvdXQgd2hhdCBpdCBjYWxsZWQgImZsb3cgc3RhdGUgZXN0YWJsaXNobWVu dCBtZXRob2RzIiBhbmQNCj4gcGVybWl0dGVkIGJvdGggc2VxdWVudGlhbCBhbmQgcHNldWRvLXJh bmRvbSBmbG93IGxhYmVsIHZhbHVlcy4gSXMgdGhlDQo+IElTQTEwMDExLmEgb24gbGluZSBzb21l d2hlcmU/DQo+IA0KPiA+IEZvciBhbGwgSSBrbm93IElTQTEwMCBkb2VzIGV2ZXJ5dGhpbmcgYnkg dGhlIGJvb2suIE5vdGUgdGhhdCBJU0ExMDAgZG9lcw0KPiBub3QgdXBkYXRlIGEgbm9uIHplcm8g Rkwgb24gdGhlIGZseSBzaW5jZSBpdCBpcyBub3Qgc2V0IGJ5IGEgc291cmNlIG91dHNpZGUgdGhl DQo+IExMTiBpZiB0aGF0IGlzIHlvdXIgY29uY2Vybi4NCj4gPg0KPiA+IE9UT0ggSXQgbWF5IHZp b2xhdGUgUkZDIDY0MzcgaW4gdGhhdCB0aGUgZmxvdyBpcyBub3QgYSByYW5kb20gYnV0IGEgdmFs dWUNCj4gYXR0cmlidXRlZCBieSBhIFBDRSBjYWxsZWQgc3lzdGVtIG1hbmFnZXIgKGFsb25nIHJ1 bGVzIGluIHNlY3Rpb24gNCkuIEFzDQo+IHRoaW5ncyBzdGFuZCwgd2UnZCBjZXJ0YWlubHkgd2Fu dCB0aGUgYmFja2JvbmUgcm91dGVyIGF0IExMTiBlZ3Jlc3MgdG8NCj4gcmV3cml0ZSB0aGUgRkwg aW4gcGFja2V0cyB0b3dhcmRzIHRoZSBJbnRlcm5ldCB3aXRoIGEgcmFuZG9taXplZCBwZXIgZmxv dw0KPiB2YWx1ZS4NCj4gPg0KPiA+IEl0IHdpbGwgdmlvbGF0ZSBSRkMgNjQzNyBiZWNhdXNlIGlm IHRoZSBmbG93IGxhYmVsIGlzIHNldCBieSBhIHJvdXRlciBpbiB0aGUNCj4gSW50ZXJuZXQgLSBv ciBhbiB1cGRhdGVkIHNvdXJjZSB0aGF0IGNvbXBsaWVzIHRvIDY0MzctLCB0aGUgYmFja2JvbmUg cm91dGVyDQo+IGF0IExMTiBJbmdyZXNzIHdpbGwgcmV3cml0ZSBpdC4NCj4gPg0KPiA+IEJvdGgg aXNzdWVzIGFyZSBhZGRyZXNzZWQgaW4gbXkgZHJhZnQgZm9yIGEgUlBMIGRvbWFpbi4gQW4gUkZD IHdpbGwgYWxzbw0KPiBoaW50IGEgcmV2aXNpb24gb2YgdGhlIGJhY2tib25lIHJvdXRlciB0aGF0 IGl0IHNob3VsZCByZXdyaXRlIHRoZSBGTCBvbg0KPiBvdXRnb2luZyBwYWNrZXRzLg0KPiA+DQo+ ID4gV2hhdCBkbyB5b3UgdGhpbms/DQo+IA0KPiBJIHRoaW5rIHRoYXQgUGhpbCdzIGxhc3QgbWVz c2FnZSBmcmFtZXMgdGhlIHF1ZXN0aW9uIHRvIDZtYW4gY29ycmVjdGx5LCBzbyBJDQo+IHdpbGwg cmVzcG9uZCB0byBoaW0uLi4NCj4gDQo+IFJlZ2FyZHMNCj4gICAgIEJyaWFuDQo+ID4NCj4gPiBQ YXNjYWwNCj4gPg0KPiA+PiBMZSAxNCBhb8O7dCAyMDE0IMOgIDIyOjE4LCAiQnJpYW4gRSBDYXJw ZW50ZXIiDQo+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IGEgw6ljcml0IDoNCj4gPj4N Cj4gPj4+IE9uIDE0LzA4LzIwMTQgMjI6MjgsIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgd3Jv dGU6DQo+ID4+PiBXZSBjYW4gbGl2ZSB3aXRoIHRoaXMgQnJpYW4sDQo+ID4+Pg0KPiA+Pj4gYnV0 IHRoZW4gSSBjYW4gd2UgYWRkIGF0IGxlYXN0IGFuIElTQTEwMC4xMWEgbmV0d29yaz8gSVNBMTAw LjExYSB3YXMNCj4gZGVzaWduZWQgaW4gMjAwNy84LCBhZG9wdGVkIElQdjYgYW5kIDZMb1dQQU4s IGFuZCB1c2VzIHRoZSBJUHY2IGZsb3cgbGFiZWwNCj4gdG8gaW5kaWNhdGUgd2hpY2ggZmxvdyBh IHBhY2tldCBiZWxvbmdzIHRvLg0KPiA+PiBJIGhhdmUgbm8gaWRlYSB3aGF0IElTQTEwMC4xMWEg aXMgb3Igd2hpY2ggb3JnYW5pc2F0aW9uIGRldmVsb3BlZCBpdCwNCj4gPj4gYnV0IGl0IHNvdW5k cyBsaWtlIGEgdmlvbGF0aW9uIG9mIHRoZSBmbG93IGxhYmVsIHN0YW5kYXJkIGF0IHRoYXQNCj4g Pj4gdGltZSAoUkZDIDM2OTcpLiBJZiBJJ2Qga25vd24gYWJvdXQgaXQsIHdlIHdvdWxkIHByb2Jh Ymx5IGhhdmUNCj4gPj4gaW5jbHVkZWQgaXQgaW4gdGhlIG1lbmFnZXJpZSBvZiBSRkMgNjI5NC4N Cj4gPj4NCj4gPj4gVGhlcmUncyBub3QgbXVjaCB0aGUgSUVURiBjYW4gZG8gYWJvdXQgb3RoZXIg b3JnYW5pc2F0aW9ucyB0aGF0DQo+ID4+IG1pc3VzZSBvdXIgc3RhbmRhcmRzLCBhbHRob3VnaCBp bmRlZWQgd2Ugc29tZXRpbWVzIG5lZWQgdG8gZG9jdW1lbnQNCj4gPj4gc3VjaCBjYXNlcy4NCj4g Pj4NCj4gPj4gICBCcmlhbg0KPiA+Pg0KPiA+Pg0KPiA+PiBJbiBtb3JlIGRldGFpbHMsIGRldmlj ZXMgYXJlIHByb3Zpc2lvbmVkIHdpdGggcGVyLWZsb3cgYmVoYXZpb3IgKGluY2x1ZGluZw0KPiBy b3V0aW5nKSBhbmQgc2V0dGluZ3MgaW4gd2hhdCBpcyBjYWxsZWQgYSBjb250cmFjdC4NCj4gPj4g VGhlIGNvbnRyYWN0SUQgaXMgY2FycmllZCBpbiB0aGUgSVB2NiBmbG93IGxhYmVsLg0KPiA+Pj4g SWYgc28gc2hvdWxkIHdlIG5hbWUgSVNBMTAwIHNwZWNpZmljYWxseSBvciB1c2UgYSBtb3JlIHZh Z3VlIGRlc2NyaXB0aW9uDQo+IGxpa2UgYSAiUlBMIG9yIHNpbWlsYXIgTExOIGRvbWFpbiINCj4g Pj4+IFdlJ2xsIG5vdGUgdGhhdCByZXNldHRpbmcgYW4gZmxvdyBsYWJlbCB0aGF0IGNvbWVzIGZy b20gdGhlIEludGVybmV0DQo+ID4+PiBpcyBhIGdlbmVyaWMgbmVlZCBpcyB0aGF0IGZsb3cgbGFi ZWwgd2FzIHNldCBhY2NvcmRpbmcgdG8gNjQzNywNCj4gPj4+IGNhbm5vdCBiZSB0cnVzdGVkIHRv IGJlIHVudGVtcGVyZWQgd2l0aCwNCj4gPj4+DQo+ID4+PiBDaGVlcnMsDQo+ID4+Pg0KPiA+Pj4g UGFzY2FsDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+Pj4+IEZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBCcmlhbiBFDQo+ID4+Pj4gQ2FycGVudGVyDQo+ID4+Pj4gU2VudDogbWVyY3JlZGkgMTMg YW/Du3QgMjAxNCAyMjo1Mw0KPiA+Pj4+IFRvOiBQaGlsaXAgTGV2aXMNCj4gPj4+PiBDYzogUm91 dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3M7IEluZXMgUm9ibGVzOyA2bWFu DQo+ID4+Pj4gV0c7IDZsb0BpZXRmLm9yZyBXRw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbUm9sbF0g WzZsb10gV0dMQyBmb3INCj4gPj4+PiBkcmFmdC10aHViZXJ0LTZtYW4tZmxvdy1sYWJlbC1mb3It cnBsLTAzDQo+ID4+Pj4NCj4gPj4+Pj4gT24gMTQvMDgvMjAxNCAwNzowNywgUGhpbGlwIExldmlz IHdyb3RlOg0KPiA+Pj4+PiBPbiBBdWcgMTMsIDIwMTQsIGF0IDk6NDggQU0sIFBhc2NhbCBUaHVi ZXJ0IChwdGh1YmVydCkNCj4gPj4+PiA8cHRodWJlcnRAY2lzY28uY29tPiB3cm90ZToNCj4gPj4+ Pj4+IElmIHRoaXMgZHJhZnQgaXMgbm90IGFkb3B0ZWQsIHRoZSBmbG93IGxhYmVsIGZyb20gTExO IHdpbGwNCj4gPj4+Pj4+IHByb2JhYmx5IHN0YXkgYWxsDQo+ID4+Pj4gemVyb2VzIGFzIGl0IGlz IHRvZGF5IGFuZCB0aGUgZ29hbCBvZiA2NDM3IHdpbGwgbm90IGJlIGFjaGlldmVkLg0KPiA+Pj4+ PiBQYXNjYWwsIEknbSB0cnlpbmcgdG8gcmVjb25jaWxlIHlvdXIgY2xhaW0gdGhhdCB0aGUgZ29h bCBvZiA2NDM3DQo+ID4+Pj4+IGlzIHRvIGFsbG93IGVuY2xvc2VkIG5ldHdvcmtzIHRvIHVzZSB0 aGUgZmxvdyBsYWJlbCB3aXRoIEJyaWFuJ3MNCj4gPj4+Pj4gc3RhdGVtZW50DQo+ID4+Pj4+DQo+ ID4+Pj4+PiBBY3R1YWxseSB0aGF0J3Mgd2h5IEkgZG9uJ3Qgd2FudCB0byBzZWUgYSBmb3JtYWwg dXBkYXRlIHRvIDY0MzcsDQo+ID4+Pj4+PiBiZWNhdXNlIHRoZSBvbmx5IHJhdGlvbmFsIHVwZGF0 ZSB3b3VsZCBiZSB0byBhbGxvdyBhbnkgY2xvc2VkDQo+ID4+Pj4+PiBkb21haW4gdG8gaW52ZW50 IGl0cyBvd24gdXNhZ2UuIFdlIGhhZCB0aGF0IGFyZ3VtZW50IGF0IGxlbmd0aA0KPiA+Pj4+Pj4g ZHVyaW5nIHRoZSBkZXZlbG9wbWVudCBvZiA2NDM3LCBhbmQgZGVjaWRlZCBhZ2FpbnN0IGl0Lg0K PiA+Pj4+PiBQaGlsDQo+ID4+Pj4gUmlnaHQuIEknbSBkcmF3aW5nIGEgdmVyeSBzdWJ0bGUgbGlu ZSBiZXR3ZWVuIChhKSBzdGF0aW5nIGFuDQo+ID4+Pj4gZXhjZXB0aW9uIHRvIDY0MzcgZm9yIHRo aXMgcGFydGljdWxhciB1c2FnZSBhbmQgKGIpIG9wZW5pbmcgdGhlDQo+ID4+Pj4gZG9vciB0byBv dGhlciB1c2FnZXMuIFNpbmNlIDZtYW4gY2xlYXJseSBkaWRuJ3Qgd2FudCAoYikgZHVyaW5nIHRo ZQ0KPiA+Pj4+IGRldmVsb3BtZW50IG9mDQo+ID4+Pj4gNjQzNyBJIHRoaW5rIHdlIGRvIG5lZWQg dG8gbGltaXQgb3Vyc2VsdmVzIHRvIChhKS4NCj4gPj4+Pg0KPiA+Pj4+ICAgIEJyaWFuDQo+ID4+ Pj4NCj4gPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4gLSBJRVRGIElQdjYgd29ya2luZyBncm91cCBt YWlsaW5nIGxpc3QgaXB2NkBpZXRmLm9yZyBBZG1pbmlzdHJhdGl2ZQ0KPiA+Pj4+IFJlcXVlc3Rz OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID4+Pj4gLQ0KPiA+DQoNCg== From nobody Mon Aug 18 10:27:36 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 3B0F01A0702; Mon, 18 Aug 2014 10:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, 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 j5rf4Ij21BiF; Mon, 18 Aug 2014 10:27:23 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA2C1A06FE; Mon, 18 Aug 2014 10:27:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 24F5D87153A; Mon, 18 Aug 2014 19:27:22 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8cOLHoESt9b; Mon, 18 Aug 2014 19:27:22 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:d08:e91:f56:fe00]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id D2989871519; Mon, 18 Aug 2014 19:27:21 +0200 (CEST) Message-ID: <53F2375E.6000501@globis.net> Date: Mon, 18 Aug 2014 19:26:54 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Brian E Carpenter References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> <53EEFEEE.8020505@globis.net> <53EFB719.70508@gmail.com> <53F07B55.7050708@globis.net> <53F10959.2000102@gmail.com> In-Reply-To: <53F10959.2000102@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/roll/2FaLx1VVU6dzhbAxtpFKGcvaIUc Cc: roll , "ipv6@ietf.org" Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 18 Aug 2014 17:27:29 -0000 > Brian E Carpenter > 17 August 2014 21:58 > On 17/08/2014 21:52, Ray Hunter wrote: >>> Brian E Carpenter >>> 16 August 2014 21:55 >>> Ray, >>> >>> On 16/08/2014 18:49, Ray Hunter wrote: >>>>> Philip Levis >>>>> 16 August 2014 02:33 >>>>> >>>>> 1) There is an extension header already; the problem is that it can >>>>> introduce a significant (ballpark estimates are, in well engineered >>>>> networks, up to 5-10%) cost. The proposal is to replace the extension >>>>> header with using the flow label. >>>>> >>>>> 2) There'a already significant IP header compression in the cases >>>>> we're talking about. >>>>> >>>>> Phil >>>> I'm sympathetic to the needs of low power devices. >>>> >>>> However, to be clear, we are reengineering a standards track document >>>> that is around 2 years old (http://tools.ietf.org/html/rfc6553), and >>>> which works technically, and we are proposing an additional encoding of >>>> exactly the same information to achieve theoretical efficiency gains >>>> that are still only rough estimates? >>>> >>>> Where's the experimental proof that this will really pay off in >>>> increased battery life? >>>> >>>> You write "replace". Will 6553 now be deprecated? >>>> >>>> If not we'll have: >>>> >>>> 6553 to carry RPL information as an option header. >>>> >>>> draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a >>>> flow label >>>> >>>> flow label information used to select patch and load balancing in >>>> multi-path networks. e.g. >>>> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203 >>>> >>>> >>>> http://tools.ietf.org/html/rfc6438 >>>> http://tools.ietf.org/html/rfc7098 >>>> >>>> I do not see that these applications for this one field are mutually >>>> compatible, and worse still, the only way to decode the semantics of the >>>> overloaded field is by applying some unknown external context ("within >>>> RPL domain"/ "on the Internet"). >>> No, I don't see a problem there. The boundary of a RPL domain is >>> very well defined and flow-label-for-rpl clearly specifies that >>> outside that boundary, RFC 6437 applies (which enables RFC 6438 >>> and 7098). >> But inside an RPL domain, you cannot use any RFC's that reference the >> flow label as per 6437, because all of the entropy has gone. > > Correct. But isn't that a trade-off that might be reasonable in > the low-power lossy environment? (That's not intended as a rhetorical > question - I just don't have enough knowledge of that environment > to answer it.) I would prefer to avoid making the trade off if we don't have to. Who knows what future application will use the flow label? I'm no RPL expert, but http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-01 seems more elegant and avoids all of this discussion. >> And what happened to our end to end architecture? > > There are various views of what e2e means, but I still like the > phrase "certain required end-to-end functions can only be performed > correctly by the end-systems themselves". Load balancing and adaptive > routing are not actually e2e functions in that sense. > >> I just do not like the concept of parsing a packet, and then having to >> determine the semantics of the contents of a particular field based on a >> "domain" that is not carried anywhere in the packet. > > I see the objection, but we've been doing it for years; diffserv does > it by definition. > > Brian Agreed. But that is also largely being overtaken by MPLS Traffic Engineering, precisely so you can have an extensible label stack, or nest QoS domains, whilst still easily accessing the required label info at all points along the forwarding path. >> e.g. think about decoding offline captures > >>>> The hidden "cost" here is that we will have 3 different overlapping >>>> solutions = code bloat and potentially a lot of additional processing to >>>> locate the correct information and then process it, which is also a hit >>>> on energy efficiency. >>>> >>>> IMHO the bar should be pretty high for accepting this proposal, as it is >>>> not actually solving a tangible issue. >>> Whether ROLL wants to endorse alternative methods within RPL >>> domains is not a 6man question. >>>> Also my prediction of the next request for field overloading will be: >>>> My ISP only delegates one /64 with PD >>>> I have multiple links in my Homenet >>>> All my media is EUI48 based. No one really uses EUI64. >>>> I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for >>>> routing in Homenet by encoding a (V)LAN ID in it. >>>> It's OK though. Homenet is a walled garden and I'll rewrite the field at >>>> the exit so no one will ever know. >>> Nice strawman, but why is it relevant? There's no need to rewrite >>> the bits, BTW. As RFC 7136 says: >>> "However, the method of generating IIDs for specific link types MAY >>> define some local significance for certain bits... the whole IID value >>> MUST be viewed as an opaque bit string by third parties, except possibly >>> in the local context." >>> >>> Brian >>> >>>> As an alternative: if this information is really RPL specific, why not >>>> just add the RPL Information as a tag to the front of the packet e.g. >>>> via an MPLS label? >>>> >>>> MPLS labels are only 4 octets, and are designed to be very efficient and >>>> fast. >>>> You can easily strip them at egress, and munge it/set it on ingress. >>>> It's clear where an MPLS domain ends and starts: no chance of RPL >>>> information leaking onto the Internet, or entering from the Internet. >>>> The MPLS label also transports the 20 bits of information you need. >>>> MPLS labels are at a clear fixed position in the packet and are easy and >>>> efficient to parse. >>>> You could also then nest RPL domains if you ever wanted to do that. >>>> It's also extensible, as you can push more labels on the stack in the >>>> future if you ever want to extend the RPL Information transported, >>>> whereas the flow label is a single fixed field. >>>> It does not require any new standard, except maybe an informational RFC >>>> on how to encode the RPL Information into MPLS labels. >>>> And it doesn't overload anything. >>>> >>>> regards, >>>> >>>>> Ray Hunter >>>>> 15 August 2014 21:49 >>>>> >>>>> >>>>> >>>>> +1 >>>>> >>>>> Apologies for tardy response (holidays) >>>>> >>>>> After reading the draft it seems to me that what is being attempted is >>>>> 1) to add some stuff to the IPv6 header that is RPL domain specific >>>>> 2) to reduce the overall packet length to reduce active radio time and >>>>> thus save energy >>>>> by >>>>> 3) overloading an existing well-defined and used IPv6 header field >>>>> >>>>> My simple logic tells me that >>>>> 1) could be best solved at an architecture level via an extension >>>>> header http://tools.ietf.org/html/rfc2460#page-11 + >>>>> http://tools.ietf.org/html/rfc7045 >>>>> 2) could be best solved at an architecture level via IP header >>>>> compression http://tools.ietf.org/html/rfc2507.html with or without >>>>> additional tweaks >>>>> and that overloading an opaque field in 3) by incorporating values >>>>> with low entropy (as per the RPL flow label) gives additional security >>>>> risks to http://tools.ietf.org/html/rfc7098 >>>>> >>>>> So what's wrong with my simple logic? >>>>> >>>>> "But if we consider the whole RPL domain as a large virtual host from >>>>> the standpoint of the rest of the Internet" would suggest to me that >>>>> the cost of stripping out the additional IPv6 hop by hop extension >>>>> header at the edge of the domain is a bogus argument, as you'll anyway >>>>> have to provide some adaption and security at the root of each RPL >>>>> domain to detect and bounce spoofed RPL Information from entering, or >>>>> private RPL Information leaking out of each domain. Whether this >>>>> domain-specificRPL Information is encoded in an explicit hop by hop >>>>> option or an overloaded flow label would seem largely irrelevant to >>>>> that operation at the RPL root (especially since the RPL root anyway >>>>> has to be a high power node to be able communicate with the rest of >>>>> the Internet). >>>>> >>>>> IMHO If you overload the flow label you're looking at creating an >>>>> incompatible walled garden, with competing IETF standards that are >>>>> mutually exclusive. >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>> ------------------------------------------------------------------------ > -- Regards, RayH From nobody Mon Aug 18 14:20:22 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D36F1A6F96; Mon, 18 Aug 2014 14:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CrqT3rY-qxeM; Mon, 18 Aug 2014 14:20:18 -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 4D1811A6F9A; Mon, 18 Aug 2014 14:20:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B260020028; Mon, 18 Aug 2014 17:23:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6FFC463AC9; Mon, 18 Aug 2014 17:20:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 59695638D7; Mon, 18 Aug 2014 17:20:16 -0400 (EDT) From: Michael Richardson To: Ray Hunter In-Reply-To: <53F2375E.6000501@globis.net> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> <53EEFEEE.8020505@globis.net> <53EFB719.70508@gmail.com> <53F07B55.7050708@globis.net> <53F10959.2000102@gmail.com> <53F2375E.6000501@globis.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/2gehtasyab87FZPehoOLHx4haZE Cc: roll , "ipv6@ietf.org" , Brian E Carpenter Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 18 Aug 2014 21:20:20 -0000 --=-=-= I just want to point out that the RPL Instance ID isn't used for routing like the MPLS label. RPL nodes still do longest prefix match routing on IPv6 destination address. If you had to make an analogy to other technology, it's more like a VLAN tag being used to pick a virtual router/routing table. > I would prefer to avoid making the trade off if we don't have to. Who knows > what future application will use the flow label? Yes, my response is: "hi, we are the future. Do you mind if we use that thing you reserved for us?" > I'm no RPL expert, but > http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-01 seems more elegant > and avoids all of this discussion. 6lo-rpl-mesh is certainly merits discussion. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU/JuDoCLcPvd0N1lAQLk5Qf/TfASntPM7m7Cwx3WXGnDGdVrVEm5CZIn fSN65SynSQrOWJiV5TYYErt1KU0LzLGrrHLe4d3D2lvi5esm9zd8eunY2enFnMS8 btyxs1UH/NlbPc8hs9tb6xAq5XYg90sq8P/k1abyY7LoLax8m9jqIgdJaFs8XpTQ waKIpeEX/WKTPlyYx65/O6l8fNCvKKB58c/9E4iKZQBQEBYQxkPTDMsi7X5AU/ny g+ImUKGB2TmS2ktwjsmeBmKiuFRPtAXgAf/3bNkN5r1KpN8+5Bgl9KxG6pjDo8tW vSYFsVCKm/lCnvWv1nc9/29zWZl+gfiPZYaAV40tC0T3XY2ElWmHUA== =aZPW -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 19 13:31:54 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575781A6EF6; Tue, 19 Aug 2014 13:31:50 -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 cuMhiHYjI6Mp; Tue, 19 Aug 2014 13:31:47 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06D11A016B; Tue, 19 Aug 2014 13:31:47 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id et14so10516385pad.35 for ; Tue, 19 Aug 2014 13:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4OnGCL2FsypqTrAu4nkvHDbi9nh/tbN/FXoUM5RvEDA=; b=W8sWL5ZyXuTGMvY9Z4ezTNJUhJqiN9Q90jiaD7RxlPuaMAEOxJqoxQq2NUeMCGdoNR kj+PA9Gt11/m0xX5AswYOZ9dVUko4640WlutgHWjp4UkRi58b9DE/WYyxt+B/YxtvpuX TAhG2UOdKX0H1MgYbrq1mkS1Ye51EJHuQoERGExshycY1/gbDML/9YNNRsPVUzFKjWtj 9IQGEyzCX/ul4S6dMvlg8Qo0ZIWguwhXTqcUbSybKseTBFA94TFokDhUhLUgMACKo99O nJH2mAeuv6iFYuLBJFXOuGooQWr6RjVkim1aDPBp6LrZbiWttR6mCRUN+4Y4JThFd+Ed 8vWA== X-Received: by 10.66.222.132 with SMTP id qm4mr23358367pac.140.1408480305184; Tue, 19 Aug 2014 13:31:45 -0700 (PDT) Received: from [192.168.178.23] (182.199.69.111.dynamic.snap.net.nz. [111.69.199.182]) by mx.google.com with ESMTPSA id ob14sm30763457pdb.40.2014.08.19.13.31.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 13:31:44 -0700 (PDT) Message-ID: <53F3B431.7060703@gmail.com> Date: Wed, 20 Aug 2014 08:31:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <53E926EB.9000505@gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com> , <53ED1992.1010708@gmail.com> <755F123A-A93F-4146-BD4C-4022CD8CE13E@cisco.com> <53EEB016.4030105@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/roll/QOgJYyyIuXyGRjhIO_eKc4Z5jcc Cc: 6man WG , Michael Richardson , Routing Over Low power and Lossy networks , Ines Robles , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 19 Aug 2014 20:31:50 -0000 Hi Pascal, If we're really going to discuss this, we need the IAB to establish liaison and get the right to let us all see the specification. I'm not going to spend my time speculating about a secret document. However, the bit you quote: "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to ContractID. The higher order 4 bits shall be all zeros." certainly seems to violate RFC 6437. Whether it violated the somewhat confused situation left by RFC 2460 and RFC 3697 is less clear. I have no recollection of anybody from ISA or IEC talking to the IETF about this issue. Regards Brian On 19/08/2014 00:51, Pascal Thubert (pthubert) wrote: > Hello Brian: >=20 > I do not think that you can freely download the specification. You prob= ably need membership first. The links exist from the Wikipedia page but t= hey are broken. Same goes for the IEC version which is IEC 62734, but if = you have access to the IEC then the current work is here http://www.iec.c= h/cgi-bin/restricted/getfile.pl/65C_735ea_CDV.pdf?dir=3D65C&format=3Dpdf&= type=3D_CDV&file=3D735ea.pdf >=20 > Quotes:=20 >=20 > "The ContractID is associated with a particular D-route. This may be us= ed when a particular graph or source D-route is intended to provide a def= ined level of service" >=20 > "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to Co= ntractID. The higher order 4 bits shall be all zeros. This field shall on= ly be present if octets 3 through 5 are present, as indicated by LOWPAN_I= PHC encoding." >=20 > Note that the 6TiSCH architecture echoes this design, and a d-route is = very similar to a 6TiSCH track. >=20 > For the sake of history and to my best knowledge, ISA100.11a was the fi= rst industrial standard to adopt IPv6 for process control applications (c= ontrol loops and monitoring).=20 > It is effectively enabling IP in the control network, which is an histo= rical step toward the IT/OT convergence, that is the Industrial equivalen= t of voice and video convergence over IP. >=20 > And also to my best knowledge and conforming RFC 3697, ISA100.11a does = not mute the Flow Label inside the network, as Michael points out. Only w= hen the additional backbone Router functionality is defined does the prob= lem of rewriting come into play at the Backbone Router (same position as = RPL root). For all I know this work is taking place at the Wireless Compl= iance Institute, WCI, but I do not have the latest. >=20 > Cheers, >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: samedi 16 ao=C3=BBt 2014 03:13 >> To: Pascal Thubert (pthubert) >> Cc: Philip Levis; Routing Over Low power and Lossy networks; Ines Robl= es; >> 6man WG; 6lo@ietf.org WG >> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-r= pl-03 >> >> On 15/08/2014 20:51, Pascal Thubert (pthubert) wrote: >>> Hello Brian >>> >>> I do not think that ISA10011.a violates RFC 3697. What exactly made y= ou >> believe so? >> >> I was over-interpreting what you wrote, I guess. It's true that 3697 w= as rather >> vague about what it called "flow state establishment methods" and >> permitted both sequential and pseudo-random flow label values. Is the >> ISA10011.a on line somewhere? >> >>> For all I know ISA100 does everything by the book. Note that ISA100 d= oes >> not update a non zero FL on the fly since it is not set by a source ou= tside the >> LLN if that is your concern. >>> OTOH It may violate RFC 6437 in that the flow is not a random but a v= alue >> attributed by a PCE called system manager (along rules in section 4). = As >> things stand, we'd certainly want the backbone router at LLN egress to= >> rewrite the FL in packets towards the Internet with a randomized per f= low >> value. >>> It will violate RFC 6437 because if the flow label is set by a router= in the >> Internet - or an updated source that complies to 6437-, the backbone r= outer >> at LLN Ingress will rewrite it. >>> Both issues are addressed in my draft for a RPL domain. An RFC will a= lso >> hint a revision of the backbone router that it should rewrite the FL o= n >> outgoing packets. >>> What do you think? >> I think that Phil's last message frames the question to 6man correctly= , so I >> will respond to him... >> >> Regards >> Brian >>> Pascal >>> >>>> Le 14 ao=C3=BBt 2014 =C3=A0 22:18, "Brian E Carpenter" >> a =C3=A9crit : >>>>> On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote: >>>>> We can live with this Brian, >>>>> >>>>> but then I can we add at least an ISA100.11a network? ISA100.11a wa= s >> designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow l= abel >> to indicate which flow a packet belongs to. >>>> I have no idea what ISA100.11a is or which organisation developed it= , >>>> but it sounds like a violation of the flow label standard at that >>>> time (RFC 3697). If I'd known about it, we would probably have >>>> included it in the menagerie of RFC 6294. >>>> >>>> There's not much the IETF can do about other organisations that >>>> misuse our standards, although indeed we sometimes need to document >>>> such cases. >>>> >>>> Brian >>>> >>>> >>>> In more details, devices are provisioned with per-flow behavior (inc= luding >> routing) and settings in what is called a contract. >>>> The contractID is carried in the IPv6 flow label. >>>>> If so should we name ISA100 specifically or use a more vague descri= ption >> like a "RPL or similar LLN domain" >>>>> We'll note that resetting an flow label that comes from the Interne= t >>>>> is a generic need is that flow label was set according to 6437, >>>>> cannot be trusted to be untempered with, >>>>> >>>>> Cheers, >>>>> >>>>> Pascal >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E >>>>>> Carpenter >>>>>> Sent: mercredi 13 ao=C3=BBt 2014 22:53 >>>>>> To: Philip Levis >>>>>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man >>>>>> WG; 6lo@ietf.org WG >>>>>> Subject: Re: [Roll] [6lo] WGLC for >>>>>> draft-thubert-6man-flow-label-for-rpl-03 >>>>>> >>>>>>> On 14/08/2014 07:07, Philip Levis wrote: >>>>>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) >>>>>> wrote: >>>>>>>> If this draft is not adopted, the flow label from LLN will >>>>>>>> probably stay all >>>>>> zeroes as it is today and the goal of 6437 will not be achieved. >>>>>>> Pascal, I'm trying to reconcile your claim that the goal of 6437 >>>>>>> is to allow enclosed networks to use the flow label with Brian's >>>>>>> statement >>>>>>> >>>>>>>> Actually that's why I don't want to see a formal update to 6437,= >>>>>>>> because the only rational update would be to allow any closed >>>>>>>> domain to invent its own usage. We had that argument at length >>>>>>>> during the development of 6437, and decided against it. >>>>>>> Phil >>>>>> Right. I'm drawing a very subtle line between (a) stating an >>>>>> exception to 6437 for this particular usage and (b) opening the >>>>>> door to other usages. Since 6man clearly didn't want (b) during th= e >>>>>> development of >>>>>> 6437 I think we do need to limit ourselves to (a). >>>>>> >>>>>> Brian >>>>>> >>>>>> ------------------------------------------------------------------= - >>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org Administrativ= e >>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> ------------------------------------------------------------------= - >>>>>> - >=20 From nobody Wed Aug 20 07:48:49 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DACD1A0435; Wed, 20 Aug 2014 07:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozeKkKyF_pmm; Wed, 20 Aug 2014 07:48:37 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan12.extendcp.co.uk [79.170.45.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680DA1A0436; Wed, 20 Aug 2014 07:48:33 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g66.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1XK7Bg-0004Ed-AB; Wed, 20 Aug 2014 15:48:32 +0100 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1XK7Bd-00034e-PV; Wed, 20 Aug 2014 15:48:32 +0100 Received: from host86-171-66-149.range86-171.btcentralplus.com ([86.171.66.149] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XK7Bc-0000VM-5b; Wed, 20 Aug 2014 15:48:28 +0100 Message-ID: <53F4B536.3060101@gridmerge.com> Date: Wed, 20 Aug 2014 15:48:22 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: roll@ietf.org, "6lo@ietf.org" <6lo@ietf.org> References: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> <53EEFEEE.8020505@globis.net> <53EFB719.70508@gmail.com> <53F07B55.7050708@globis.net> <53F10959.2000102@gmail.com> <53F2375E.6000501@globis.net> <7414.1408396816@sandelman.ca> In-Reply-To: <7414.1408396816@sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080103090101000104060601" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/roll/H3MxdKSGQDl3MfoFuTpzfDY4348 Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 14:48:44 -0000 This is a cryptographically signed message in MIME format. --------------ms080103090101000104060601 Content-Type: multipart/alternative; boundary="------------090004030207030100000409" This is a multi-part message in MIME format. --------------090004030207030100000409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I have been following this discussion with interest and here is my quick = take on it: * Flow label seems a fairly abstract concept and it doesn't seem=20 unreasonable to use the space it occupies within a specific domain like=20 RPL. What is proposed in draft-thubert-6man-flow-label-for-rpl-03=20 doesn't seem consistent with the principle of what a "flow" is though as = it changes hop-by-hop, which is clearly not the intended purpose for a=20 flow label field. However, as others have pointed out, it is still a=20 mutable field as far as AH is concerned and therefore that does not=20 preclude the use as specified in=20 draft-thubert-6man-flow-label-for-rpl-03. It is also clear that the flow = label has to be reset at the edge of the domain anyway. * Route-over in a mesh network changes everything. The use of the RPL=20 option in RFC6553 does indeed seem reasonable but the IP-in-IP=20 construction then complicates matters considerably. * What Carsten proposes in draft-bormann-6lo-rpl-mesh-01 makes the most=20 sense to me as putting it at "layer 2.5" is the logical place to put=20 this sort of information due to it being hop-by-hop So in summary, I have no real objection to what is proposed in=20 draft-thubert-6man-flow-label-for-rpl-03 but I think Carsten's approach=20 is better. Robert On 18/08/2014 10:20 PM, Michael Richardson wrote: > I just want to point out that the RPL Instance ID isn't used for routin= g > like the MPLS label. RPL nodes still do longest prefix match routing > on IPv6 destination address. > > If you had to make an analogy to other technology, it's more like a VLA= N > tag being used to pick a virtual router/routing table. > >> I would prefer to avoid making the trade off if we don't have to. Who = knows >> what future application will use the flow label? > Yes, my response is: "hi, we are the future. Do you mind if we use that= > thing you reserved for us?" > >> I'm no RPL expert, but >> http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-01 seems more el= egant >> and avoids all of this discussion. > 6lo-rpl-mesh is certainly merits discussion. > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------090004030207030100000409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have been following this discussion with interest and here is my quick take on it:

* Flow label seems a fairly abstract concept and it doesn't seem unreasonable to use the space it occupies within a specific domain like RPL. What is proposed in draft-thubert-6man-flow-label-for-rpl-03 doesn't seem consistent with the principle of what a "flow" is though as it changes hop-by-hop, which is clearly not the intended purpose for a flow label field. However, as others have pointed out, it is still a mutable field as far as AH is concerned and therefore that does not preclude the use as specified in draft-thubert-6man-flow-label-for-rpl-03. It is also clear that the flow label has to be reset at the edge of the domain anyway.
* Route-over in a mesh network changes everything. The use of the RPL option in RFC6553 does indeed seem reasonable but the IP-in-IP construction then complicates matters considerably.
* What Carsten proposes in draft-bormann-6lo-rpl-mesh-01 makes the most sense to me as putting it at "layer 2.5" is the logical place to put this sort of information due to it being hop-by-hop

So in summary, I have no real objection to what is proposed in draft-thubert-6man-flow-label-for-rpl-03 but I think Carsten's approach is better.

Robert

On 18/08/2014 10:20 PM, Michael Richardson wrote:
I just want to point out that the RPL Instance ID isn't used for routing
like the MPLS label. RPL nodes still do longest prefix match routing
on IPv6 destination address.

If you had to make an analogy to other technology, it's more like a VLAN
tag being used to pick a virtual router/routing table.


I would prefer to avoid making the trade off if we=
 don't have to. Who knows
what future application will use the flow label?

Yes, my response is: "hi, we are the future. Do you mind if we use that
     thing you reserved for us?"


I'm no RPL expert, but
http://tools.ietf.org/html/draft-bormann-6lo-=
rpl-mesh-01 seems more elegant
and avoids all of this discussion.

6lo-rpl-mesh is certainly merits discussion.

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






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

--------------090004030207030100000409-- --------------ms080103090101000104060601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDA4MjAxNDQ4MjJaMCMGCSqGSIb3DQEJBDEWBBS34zGZ13fJAOJ4B7fcz/sPBdUAczBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAKomOTSECxQY99dtMuxUnVmYX7uiPVrXQZG17P2rzpnEfLpm XygWIoSYfJy4nSYXndso7uLFLRW5XMKi/U8OCkLVlC+HkgO5qHh4G4HpptlAXwk2QZl4z+oY hKDafI4SpV+y8uvUqSvoBdRYlmF+0K5+YbD8D7TMBRmspMp66B0dMbksHshjslYkKLA/SYR4 HIkr/BDR8dAmmTyq5xcEwtETwsRBcjVFAavmepABM4uXeBIB/w8VCDqxvkORsee9TVqnQW7v /+TNaOWwoxC0xvkqjCITYIbnIhvBNyLNg2hZu4dg/hudbCzUoFffHPjJinso7AKfM2RmbU8r AKVmWbkAAAAAAAA= --------------ms080103090101000104060601-- From nobody Thu Aug 21 06:49: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 1C04C1A02F7 for ; Thu, 21 Aug 2014 06:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Oqy3IcfGHweW for ; Thu, 21 Aug 2014 06:49:27 -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 B6D551A02DB for ; Thu, 21 Aug 2014 06:49:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5314020012 for ; Thu, 21 Aug 2014 09:52:46 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D10B963AC9; Thu, 21 Aug 2014 09:49:25 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BDF0F638D7 for ; Thu, 21 Aug 2014 09:49:25 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HPUBdMD8NPKbiy2JtFNWlNDl3Ts Subject: Re: [Roll] h-b applicability draft 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, 21 Aug 2014 13:49:30 -0000 --=-=-= peter van der Stok wrote: > Attached the hopefully last version of the applicability > draft. (ignoring AD > and IESG comments) > After a telco with Robert and Michael, the contents of section 7.1 and > 7.2 > was adapted. > There was some misunderstanding about meaning of incremental deployment. I wonder if you can suggest some text to clarify the template? -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU/X44oCLcPvd0N1lAQLSJwf/agZsvfB/qqFaNSrwkTYBQanmNIZIMziE PqEe5Nc+KNY4issUUW6gKZsQz1TD06nlUIsA3u9G+DpT7ZWB+U9AmSjYxHi6PaZe Qu99/rpH1eafhjcNw/lioMDS4XKpV9jwKn9CAdN1gUh4tO58LP0r/mXls1MIPQrg bIgwyZ2OAfULid6ZW69FlB/CEvFHhUVD7oPnsiXVbU03s1APSnTCZ9VjHf3UrBOD TIBzc0dqJVh412FOKdKnSAL730UVuaXr5p/zXN5tGLIU+RWcjbJsC/d74gXxqMfc ehqXJsu9cdsGfawGiv/P8ouH1hYMeIKvOuRZTm3hAhWjgEf0x6EZlA== =feWZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 22 05:56:22 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215BC1A02DE; Fri, 22 Aug 2014 05:56:18 -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 Lx9Nwtpv6ofK; Fri, 22 Aug 2014 05:56:15 -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 3EB3C1A02D7; Fri, 22 Aug 2014 05:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13200; q=dns/txt; s=iport; t=1408712175; x=1409921775; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=AsZPIuEfYTmQN7twmskU2h/6pGwI957g+GQtY6JlGsA=; b=Dsi3uYflokISIeq/hQIOglrW/CwOVT/ptF+lrZTXZKifpBvYNd9kBqD8 MLak3LEpERVsz1BZay4jjMc3XBQJpFGGjbNbp2heMsuHtG1Cokb+LxeCH KGuIKxem4+o9Uz1psbPYlhVVRd86TqNXz0qkxnQnXVZOB7F7DKwGkDDW4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAAs991OtJV2Y/2dsb2JhbABZgw1TVwSCeMlYCodMARl0FneEAwEBAQICAQEBIBEzBwsMBgEIEQEDAQEBAgIGHQMCBB8GCxQBAgYJAQQOBQiIJgMRDa8Lj3YNhRkXgSyLc4FKDAkdFhsNgnM2gR0FhhGLFYZjgjCQZ4Y1g15sAYEGQYEHAQEB X-IronPort-AV: E=Sophos;i="5.04,380,1406592000"; d="scan'208";a="71453774" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 22 Aug 2014 12:56:13 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7MCuDG4027555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 12:56:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 07:56:13 -0500 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: Ac++CEw2eULOCzQzTxOZUvA7hQn3Ew== Date: Fri, 22 Aug 2014 12:56:13 +0000 Deferred-Delivery: Fri, 22 Aug 2014 12:56: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.49.80.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/OWHEQCQy62OqT4ZvqDGwRl4X2rw Cc: 6man WG , Michael Richardson , Routing Over Low power and Lossy networks , Ines Robles , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 22 Aug 2014 12:56:18 -0000 SGVsbG8gQnJpYW46DQoNClRoZSBxdWVzdGlvbiBvZiBhIGxpYWlzb24gd2FzIGRpc2N1c3NlZCBh dCBib3RoIElFQyBhbmQgSVNBMTAwLCBhbmQgdGhleSB3ZXJlIHZlcnkgcG9zaXRpdmUgYWJvdXQg dGhlIGlkZWEuIFdlIGNhbiBjZXJ0YWlubHkgbWFrZSB0aGF0IGhhcHBlbi4NCkkgZG91YnQgdGhh dCB0aGVyZSBpcyB2YWx1ZSBpbiBhbmFseXppbmcgZmluZWx5IElTQTEwMC4xMWEgdGhhdCBpcyBt b3N0bHkgY2FzdCBpbiBzdG9uZSBub3cuIFdlIG1hZGUgdGhlIGFuYWx5c2lzIGF0IHRoZSB0aW1l IGFuZCBjb25jbHVkZWQgdGhhdCBpdCB3YXMgY29uZm9ybWluZyBSRkMgMzY5NywgYW5kIHdlIGtu b3cgbm93IHRoYXQgaXQgZG9lcyBub3QgY29uZm9ybSBSRkMgNjQzNy4NCldlIGNvdWxkIHN0aWxs IHBhcnRpY2lwYXRlIHRvIHRoZSB3b3JrIG9uIHRoZSBiYWNrYm9uZSByb3V0ZXIgYnV0IHRoZSBy dWxlcyBpbiBSRkMgNjQzNyB3aWxsIG5vdCBiZSBhY2NlcHRhYmxlIHRoZXJlIGZvciB0aGUgZXhh Y3Qgc2FtZSByZWFzb25zIHRoYXQgdGhleSBhcmUgbm90IGFjY2VwdGFibGUgaW4gYSBSUEwgZG9t YWluLCBhbmQgdGhlIExhdXJlbnQrQ2Fyc3RlbiBwcm9wb3NhbCB3aWxsIG5vdCBjaGFuZ2UgdGhh dCBhIGlvdGEuDQoNClRoZSBtb3N0IGNvbnN0cnVjdGl2ZSB3b3VsZCBiZSAoSU1ITyk6DQotIGFk b3B0IHRoZSBwcm9wb3NlZCBjaGFuZ2UgdG8gdGhlIDZNQU4gcnVsZXMgc2VwYXJhdGVseSBmcm9t IHRoZSBwcm9wb3NlZCB1c2UgaW4gUlBMIGFuZCANCi0gZXh0ZW5kIHRoZSByaWdodHMgdGhhdCB3 ZSBhcmUgYXNraW5nIGZvciBhIFJQTCBkb21haW4gdG8gYW4gSVNBMTAwIHN1Ym5ldHdvcmsgYXMg d2VsbCBzbyBhcyB0byBtYWtlIElTQTEwMCBjb21wbGlhbnQgYWdhaW4NCi0gdXBkYXRlIDYyODQg dG8gcG9zaXRpb24gSVNBMTAwLjExYS9JRUM2MjczNCB2cy4gYm90aCBSRkNzIGFuZCB0aGUgNk1B TiBSUEwgZmxvdyBsYWJlbCB3b3JrIChzcGxpdCBvciBub3QpIGFzIEluZXMgc3VnZ2VzdGVkDQot IGdvIHRvIFdDSSBhbmQgZW5mb3JjZSB0aGUgYXBwbGljYXRpb24gb2YgdGhlIG5ldyBSRkMgc28g dGhhdCBwYWNrZXRzIG91dGdvaW5nIHRoZSBJU0ExMDAgc3VibmV0d29yayBhcmUgbWFkZSBjb21w bGlhbnQgdG8gUkZDIDY0MzcgKGJ5IHRoZSBiYWNrYm9uZSByb3V0ZXIpLg0KDQpXb3VsZCB3ZSBh Z3JlZSBvbiB0aGlzIHBhdGg/IA0KDQpQYXNjYWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50 ZXJAZ21haWwuY29tXQ0KPiBTZW50OiBtYXJkaSAxOSBhb8O7dCAyMDE0IDIyOjMyDQo+IFRvOiBQ YXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQo+IENjOiBNaWNoYWVsIFJpY2hhcmRzb247IFBoaWxp cCBMZXZpczsgUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kNCj4gbmV0d29ya3M7IElu ZXMgUm9ibGVzOyA2bWFuIFdHOyA2bG9AaWV0Zi5vcmcgV0cNCj4gU3ViamVjdDogUmU6IFtSb2xs XSBbNmxvXSBXR0xDIGZvciBkcmFmdC10aHViZXJ0LTZtYW4tZmxvdy1sYWJlbC1mb3ItcnBsLTAz DQo+IA0KPiBIaSBQYXNjYWwsDQo+IA0KPiBJZiB3ZSdyZSByZWFsbHkgZ29pbmcgdG8gZGlzY3Vz cyB0aGlzLCB3ZSBuZWVkIHRoZSBJQUIgdG8gZXN0YWJsaXNoIGxpYWlzb24gYW5kDQo+IGdldCB0 aGUgcmlnaHQgdG8gbGV0IHVzIGFsbCBzZWUgdGhlIHNwZWNpZmljYXRpb24uIEknbSBub3QgZ29p bmcgdG8gc3BlbmQgbXkNCj4gdGltZSBzcGVjdWxhdGluZyBhYm91dCBhIHNlY3JldCBkb2N1bWVu dC4gSG93ZXZlciwgdGhlIGJpdCB5b3UgcXVvdGU6DQo+ICJGbG93TGFiZWw6IFRoZSBsb3dlciBv cmRlciAxNiBiaXRzIG9mIHRoZSBGbG93TGFiZWwgc2hhbGwgYmUgc2V0IHRvDQo+IENvbnRyYWN0 SUQuIFRoZSBoaWdoZXIgb3JkZXIgNCBiaXRzIHNoYWxsIGJlIGFsbCB6ZXJvcy4iDQo+IGNlcnRh aW5seSBzZWVtcyB0byB2aW9sYXRlIFJGQyA2NDM3LiBXaGV0aGVyIGl0IHZpb2xhdGVkIHRoZSBz b21ld2hhdA0KPiBjb25mdXNlZCBzaXR1YXRpb24gbGVmdCBieSBSRkMgMjQ2MCBhbmQgUkZDIDM2 OTcgaXMgbGVzcyBjbGVhci4gSSBoYXZlIG5vDQo+IHJlY29sbGVjdGlvbiBvZiBhbnlib2R5IGZy b20gSVNBIG9yIElFQyB0YWxraW5nIHRvIHRoZSBJRVRGIGFib3V0IHRoaXMgaXNzdWUuDQo+IA0K PiBSZWdhcmRzDQo+ICAgIEJyaWFuDQo+IA0KPiBPbiAxOS8wOC8yMDE0IDAwOjUxLCBQYXNjYWwg VGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPiA+IEhlbGxvIEJyaWFuOg0KPiA+DQo+ID4gSSBk byBub3QgdGhpbmsgdGhhdCB5b3UgY2FuIGZyZWVseSBkb3dubG9hZCB0aGUgc3BlY2lmaWNhdGlv bi4gWW91DQo+ID4gcHJvYmFibHkgbmVlZCBtZW1iZXJzaGlwIGZpcnN0LiBUaGUgbGlua3MgZXhp c3QgZnJvbSB0aGUgV2lraXBlZGlhDQo+ID4gcGFnZSBidXQgdGhleSBhcmUgYnJva2VuLiBTYW1l IGdvZXMgZm9yIHRoZSBJRUMgdmVyc2lvbiB3aGljaCBpcyBJRUMNCj4gPiA2MjczNCwgYnV0IGlm IHlvdSBoYXZlIGFjY2VzcyB0byB0aGUgSUVDIHRoZW4gdGhlIGN1cnJlbnQgd29yayBpcyBoZXJl DQo+ID4gaHR0cDovL3d3dy5pZWMuY2gvY2dpLWJpbi9yZXN0cmljdGVkL2dldGZpbGUucGwvNjVD XzczNWVhX0NEVi5wZGY/ZGlyPQ0KPiA+IDY1QyZmb3JtYXQ9cGRmJnR5cGU9X0NEViZmaWxlPTcz NWVhLnBkZg0KPiA+DQo+ID4gUXVvdGVzOg0KPiA+DQo+ID4gIlRoZSBDb250cmFjdElEIGlzIGFz c29jaWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIgRC1yb3V0ZS4gVGhpcyBtYXkgYmUgdXNlZA0KPiB3 aGVuIGEgcGFydGljdWxhciBncmFwaCBvciBzb3VyY2UgRC1yb3V0ZSBpcyBpbnRlbmRlZCB0byBw cm92aWRlIGEgZGVmaW5lZA0KPiBsZXZlbCBvZiBzZXJ2aWNlIg0KPiA+DQo+ID4gIkZsb3dMYWJl bDogVGhlIGxvd2VyIG9yZGVyIDE2IGJpdHMgb2YgdGhlIEZsb3dMYWJlbCBzaGFsbCBiZSBzZXQg dG8NCj4gQ29udHJhY3RJRC4gVGhlIGhpZ2hlciBvcmRlciA0IGJpdHMgc2hhbGwgYmUgYWxsIHpl cm9zLiBUaGlzIGZpZWxkIHNoYWxsIG9ubHkgYmUNCj4gcHJlc2VudCBpZiBvY3RldHMgMyB0aHJv dWdoIDUgYXJlIHByZXNlbnQsIGFzIGluZGljYXRlZCBieSBMT1dQQU5fSVBIQw0KPiBlbmNvZGlu Zy4iDQo+ID4NCj4gPiBOb3RlIHRoYXQgdGhlIDZUaVNDSCBhcmNoaXRlY3R1cmUgZWNob2VzIHRo aXMgZGVzaWduLCBhbmQgYSBkLXJvdXRlIGlzIHZlcnkNCj4gc2ltaWxhciB0byBhIDZUaVNDSCB0 cmFjay4NCj4gPg0KPiA+IEZvciB0aGUgc2FrZSBvZiBoaXN0b3J5IGFuZCB0byBteSBiZXN0IGtu b3dsZWRnZSwgSVNBMTAwLjExYSB3YXMgdGhlIGZpcnN0DQo+IGluZHVzdHJpYWwgc3RhbmRhcmQg dG8gYWRvcHQgSVB2NiBmb3IgcHJvY2VzcyBjb250cm9sIGFwcGxpY2F0aW9ucyAoY29udHJvbA0K PiBsb29wcyBhbmQgbW9uaXRvcmluZykuDQo+ID4gSXQgaXMgZWZmZWN0aXZlbHkgZW5hYmxpbmcg SVAgaW4gdGhlIGNvbnRyb2wgbmV0d29yaywgd2hpY2ggaXMgYW4gaGlzdG9yaWNhbA0KPiBzdGVw IHRvd2FyZCB0aGUgSVQvT1QgY29udmVyZ2VuY2UsIHRoYXQgaXMgdGhlIEluZHVzdHJpYWwgZXF1 aXZhbGVudCBvZiB2b2ljZQ0KPiBhbmQgdmlkZW8gY29udmVyZ2VuY2Ugb3ZlciBJUC4NCj4gPg0K PiA+IEFuZCBhbHNvIHRvIG15IGJlc3Qga25vd2xlZGdlIGFuZCBjb25mb3JtaW5nIFJGQyAzNjk3 LCBJU0ExMDAuMTFhIGRvZXMNCj4gbm90IG11dGUgdGhlIEZsb3cgTGFiZWwgaW5zaWRlIHRoZSBu ZXR3b3JrLCBhcyBNaWNoYWVsIHBvaW50cyBvdXQuIE9ubHkNCj4gd2hlbiB0aGUgYWRkaXRpb25h bCBiYWNrYm9uZSBSb3V0ZXIgZnVuY3Rpb25hbGl0eSBpcyBkZWZpbmVkIGRvZXMgdGhlDQo+IHBy b2JsZW0gb2YgcmV3cml0aW5nIGNvbWUgaW50byBwbGF5IGF0IHRoZSBCYWNrYm9uZSBSb3V0ZXIg KHNhbWUgcG9zaXRpb24NCj4gYXMgUlBMIHJvb3QpLiBGb3IgYWxsIEkga25vdyB0aGlzIHdvcmsg aXMgdGFraW5nIHBsYWNlIGF0IHRoZSBXaXJlbGVzcw0KPiBDb21wbGlhbmNlIEluc3RpdHV0ZSwg V0NJLCBidXQgSSBkbyBub3QgaGF2ZSB0aGUgbGF0ZXN0Lg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+ DQo+ID4gUGFzY2FsDQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+PiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbV0NCj4gPj4gU2VudDogc2FtZWRpIDE2IGFvw7t0IDIwMTQgMDM6MTMNCj4gPj4gVG86 IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCj4gPj4gQ2M6IFBoaWxpcCBMZXZpczsgUm91dGlu ZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3M7IEluZXMNCj4gPj4gUm9ibGVzOyA2 bWFuIFdHOyA2bG9AaWV0Zi5vcmcgV0cNCj4gPj4gU3ViamVjdDogUmU6IFtSb2xsXSBbNmxvXSBX R0xDIGZvcg0KPiA+PiBkcmFmdC10aHViZXJ0LTZtYW4tZmxvdy1sYWJlbC1mb3ItcnBsLTAzDQo+ ID4+DQo+ID4+IE9uIDE1LzA4LzIwMTQgMjA6NTEsIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkg d3JvdGU6DQo+ID4+PiBIZWxsbyBCcmlhbg0KPiA+Pj4NCj4gPj4+IEkgZG8gbm90IHRoaW5rIHRo YXQgSVNBMTAwMTEuYSB2aW9sYXRlcyBSRkMgMzY5Ny4gV2hhdCBleGFjdGx5IG1hZGUNCj4gPj4+ IHlvdQ0KPiA+PiBiZWxpZXZlIHNvPw0KPiA+Pg0KPiA+PiBJIHdhcyBvdmVyLWludGVycHJldGlu ZyB3aGF0IHlvdSB3cm90ZSwgSSBndWVzcy4gSXQncyB0cnVlIHRoYXQgMzY5Nw0KPiA+PiB3YXMg cmF0aGVyIHZhZ3VlIGFib3V0IHdoYXQgaXQgY2FsbGVkICJmbG93IHN0YXRlIGVzdGFibGlzaG1l bnQNCj4gPj4gbWV0aG9kcyIgYW5kIHBlcm1pdHRlZCBib3RoIHNlcXVlbnRpYWwgYW5kIHBzZXVk by1yYW5kb20gZmxvdyBsYWJlbA0KPiA+PiB2YWx1ZXMuIElzIHRoZSBJU0ExMDAxMS5hIG9uIGxp bmUgc29tZXdoZXJlPw0KPiA+Pg0KPiA+Pj4gRm9yIGFsbCBJIGtub3cgSVNBMTAwIGRvZXMgZXZl cnl0aGluZyBieSB0aGUgYm9vay4gTm90ZSB0aGF0IElTQTEwMA0KPiA+Pj4gZG9lcw0KPiA+PiBu b3QgdXBkYXRlIGEgbm9uIHplcm8gRkwgb24gdGhlIGZseSBzaW5jZSBpdCBpcyBub3Qgc2V0IGJ5 IGEgc291cmNlDQo+ID4+IG91dHNpZGUgdGhlIExMTiBpZiB0aGF0IGlzIHlvdXIgY29uY2Vybi4N Cj4gPj4+IE9UT0ggSXQgbWF5IHZpb2xhdGUgUkZDIDY0MzcgaW4gdGhhdCB0aGUgZmxvdyBpcyBu b3QgYSByYW5kb20gYnV0IGENCj4gPj4+IHZhbHVlDQo+ID4+IGF0dHJpYnV0ZWQgYnkgYSBQQ0Ug Y2FsbGVkIHN5c3RlbSBtYW5hZ2VyIChhbG9uZyBydWxlcyBpbiBzZWN0aW9uIDQpLg0KPiA+PiBB cyB0aGluZ3Mgc3RhbmQsIHdlJ2QgY2VydGFpbmx5IHdhbnQgdGhlIGJhY2tib25lIHJvdXRlciBh dCBMTE4NCj4gPj4gZWdyZXNzIHRvIHJld3JpdGUgdGhlIEZMIGluIHBhY2tldHMgdG93YXJkcyB0 aGUgSW50ZXJuZXQgd2l0aCBhDQo+ID4+IHJhbmRvbWl6ZWQgcGVyIGZsb3cgdmFsdWUuDQo+ID4+ PiBJdCB3aWxsIHZpb2xhdGUgUkZDIDY0MzcgYmVjYXVzZSBpZiB0aGUgZmxvdyBsYWJlbCBpcyBz ZXQgYnkgYQ0KPiA+Pj4gcm91dGVyIGluIHRoZQ0KPiA+PiBJbnRlcm5ldCAtIG9yIGFuIHVwZGF0 ZWQgc291cmNlIHRoYXQgY29tcGxpZXMgdG8gNjQzNy0sIHRoZSBiYWNrYm9uZQ0KPiA+PiByb3V0 ZXIgYXQgTExOIEluZ3Jlc3Mgd2lsbCByZXdyaXRlIGl0Lg0KPiA+Pj4gQm90aCBpc3N1ZXMgYXJl IGFkZHJlc3NlZCBpbiBteSBkcmFmdCBmb3IgYSBSUEwgZG9tYWluLiBBbiBSRkMgd2lsbA0KPiA+ Pj4gYWxzbw0KPiA+PiBoaW50IGEgcmV2aXNpb24gb2YgdGhlIGJhY2tib25lIHJvdXRlciB0aGF0 IGl0IHNob3VsZCByZXdyaXRlIHRoZSBGTA0KPiA+PiBvbiBvdXRnb2luZyBwYWNrZXRzLg0KPiA+ Pj4gV2hhdCBkbyB5b3UgdGhpbms/DQo+ID4+IEkgdGhpbmsgdGhhdCBQaGlsJ3MgbGFzdCBtZXNz YWdlIGZyYW1lcyB0aGUgcXVlc3Rpb24gdG8gNm1hbg0KPiA+PiBjb3JyZWN0bHksIHNvIEkgd2ls bCByZXNwb25kIHRvIGhpbS4uLg0KPiA+Pg0KPiA+PiBSZWdhcmRzDQo+ID4+ICAgICBCcmlhbg0K PiA+Pj4gUGFzY2FsDQo+ID4+Pg0KPiA+Pj4+IExlIDE0IGFvw7t0IDIwMTQgw6AgMjI6MTgsICJC cmlhbiBFIENhcnBlbnRlciINCj4gPj4gPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gYSDD qWNyaXQgOg0KPiA+Pj4+PiBPbiAxNC8wOC8yMDE0IDIyOjI4LCBQYXNjYWwgVGh1YmVydCAocHRo dWJlcnQpIHdyb3RlOg0KPiA+Pj4+PiBXZSBjYW4gbGl2ZSB3aXRoIHRoaXMgQnJpYW4sDQo+ID4+ Pj4+DQo+ID4+Pj4+IGJ1dCB0aGVuIEkgY2FuIHdlIGFkZCBhdCBsZWFzdCBhbiBJU0ExMDAuMTFh IG5ldHdvcms/IElTQTEwMC4xMWENCj4gPj4+Pj4gd2FzDQo+ID4+IGRlc2lnbmVkIGluIDIwMDcv OCwgYWRvcHRlZCBJUHY2IGFuZCA2TG9XUEFOLCBhbmQgdXNlcyB0aGUgSVB2NiBmbG93DQo+ID4+ IGxhYmVsIHRvIGluZGljYXRlIHdoaWNoIGZsb3cgYSBwYWNrZXQgYmVsb25ncyB0by4NCj4gPj4+ PiBJIGhhdmUgbm8gaWRlYSB3aGF0IElTQTEwMC4xMWEgaXMgb3Igd2hpY2ggb3JnYW5pc2F0aW9u IGRldmVsb3BlZA0KPiA+Pj4+IGl0LCBidXQgaXQgc291bmRzIGxpa2UgYSB2aW9sYXRpb24gb2Yg dGhlIGZsb3cgbGFiZWwgc3RhbmRhcmQgYXQNCj4gPj4+PiB0aGF0IHRpbWUgKFJGQyAzNjk3KS4g SWYgSSdkIGtub3duIGFib3V0IGl0LCB3ZSB3b3VsZCBwcm9iYWJseSBoYXZlDQo+ID4+Pj4gaW5j bHVkZWQgaXQgaW4gdGhlIG1lbmFnZXJpZSBvZiBSRkMgNjI5NC4NCj4gPj4+Pg0KPiA+Pj4+IFRo ZXJlJ3Mgbm90IG11Y2ggdGhlIElFVEYgY2FuIGRvIGFib3V0IG90aGVyIG9yZ2FuaXNhdGlvbnMg dGhhdA0KPiA+Pj4+IG1pc3VzZSBvdXIgc3RhbmRhcmRzLCBhbHRob3VnaCBpbmRlZWQgd2Ugc29t ZXRpbWVzIG5lZWQgdG8NCj4gZG9jdW1lbnQNCj4gPj4+PiBzdWNoIGNhc2VzLg0KPiA+Pj4+DQo+ ID4+Pj4gICBCcmlhbg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBJbiBtb3JlIGRldGFpbHMsIGRl dmljZXMgYXJlIHByb3Zpc2lvbmVkIHdpdGggcGVyLWZsb3cgYmVoYXZpb3INCj4gPj4+PiAoaW5j bHVkaW5nDQo+ID4+IHJvdXRpbmcpIGFuZCBzZXR0aW5ncyBpbiB3aGF0IGlzIGNhbGxlZCBhIGNv bnRyYWN0Lg0KPiA+Pj4+IFRoZSBjb250cmFjdElEIGlzIGNhcnJpZWQgaW4gdGhlIElQdjYgZmxv dyBsYWJlbC4NCj4gPj4+Pj4gSWYgc28gc2hvdWxkIHdlIG5hbWUgSVNBMTAwIHNwZWNpZmljYWxs eSBvciB1c2UgYSBtb3JlIHZhZ3VlDQo+ID4+Pj4+IGRlc2NyaXB0aW9uDQo+ID4+IGxpa2UgYSAi UlBMIG9yIHNpbWlsYXIgTExOIGRvbWFpbiINCj4gPj4+Pj4gV2UnbGwgbm90ZSB0aGF0IHJlc2V0 dGluZyBhbiBmbG93IGxhYmVsIHRoYXQgY29tZXMgZnJvbSB0aGUNCj4gPj4+Pj4gSW50ZXJuZXQg aXMgYSBnZW5lcmljIG5lZWQgaXMgdGhhdCBmbG93IGxhYmVsIHdhcyBzZXQgYWNjb3JkaW5nIHRv DQo+ID4+Pj4+IDY0MzcsIGNhbm5vdCBiZSB0cnVzdGVkIHRvIGJlIHVudGVtcGVyZWQgd2l0aCwN Cj4gPj4+Pj4NCj4gPj4+Pj4gQ2hlZXJzLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBQYXNjYWwNCj4gPj4+ Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+ PiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg QnJpYW4gRQ0KPiA+Pj4+Pj4gQ2FycGVudGVyDQo+ID4+Pj4+PiBTZW50OiBtZXJjcmVkaSAxMyBh b8O7dCAyMDE0IDIyOjUzDQo+ID4+Pj4+PiBUbzogUGhpbGlwIExldmlzDQo+ID4+Pj4+PiBDYzog Um91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3M7IEluZXMgUm9ibGVzOyA2 bWFuDQo+ID4+Pj4+PiBXRzsgNmxvQGlldGYub3JnIFdHDQo+ID4+Pj4+PiBTdWJqZWN0OiBSZTog W1JvbGxdIFs2bG9dIFdHTEMgZm9yDQo+ID4+Pj4+PiBkcmFmdC10aHViZXJ0LTZtYW4tZmxvdy1s YWJlbC1mb3ItcnBsLTAzDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+IE9uIDE0LzA4LzIwMTQgMDc6MDcs IFBoaWxpcCBMZXZpcyB3cm90ZToNCj4gPj4+Pj4+PiBPbiBBdWcgMTMsIDIwMTQsIGF0IDk6NDgg QU0sIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCj4gPj4+Pj4+IDxwdGh1YmVydEBjaXNjby5j b20+IHdyb3RlOg0KPiA+Pj4+Pj4+PiBJZiB0aGlzIGRyYWZ0IGlzIG5vdCBhZG9wdGVkLCB0aGUg ZmxvdyBsYWJlbCBmcm9tIExMTiB3aWxsDQo+ID4+Pj4+Pj4+IHByb2JhYmx5IHN0YXkgYWxsDQo+ ID4+Pj4+PiB6ZXJvZXMgYXMgaXQgaXMgdG9kYXkgYW5kIHRoZSBnb2FsIG9mIDY0Mzcgd2lsbCBu b3QgYmUgYWNoaWV2ZWQuDQo+ID4+Pj4+Pj4gUGFzY2FsLCBJJ20gdHJ5aW5nIHRvIHJlY29uY2ls ZSB5b3VyIGNsYWltIHRoYXQgdGhlIGdvYWwgb2YgNjQzNw0KPiA+Pj4+Pj4+IGlzIHRvIGFsbG93 IGVuY2xvc2VkIG5ldHdvcmtzIHRvIHVzZSB0aGUgZmxvdyBsYWJlbCB3aXRoIEJyaWFuJ3MNCj4g Pj4+Pj4+PiBzdGF0ZW1lbnQNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBBY3R1YWxseSB0aGF0J3Mg d2h5IEkgZG9uJ3Qgd2FudCB0byBzZWUgYSBmb3JtYWwgdXBkYXRlIHRvDQo+ID4+Pj4+Pj4+IDY0 MzcsIGJlY2F1c2UgdGhlIG9ubHkgcmF0aW9uYWwgdXBkYXRlIHdvdWxkIGJlIHRvIGFsbG93IGFu eQ0KPiA+Pj4+Pj4+PiBjbG9zZWQgZG9tYWluIHRvIGludmVudCBpdHMgb3duIHVzYWdlLiBXZSBo YWQgdGhhdCBhcmd1bWVudCBhdA0KPiA+Pj4+Pj4+PiBsZW5ndGggZHVyaW5nIHRoZSBkZXZlbG9w bWVudCBvZiA2NDM3LCBhbmQgZGVjaWRlZCBhZ2FpbnN0IGl0Lg0KPiA+Pj4+Pj4+IFBoaWwNCj4g Pj4+Pj4+IFJpZ2h0LiBJJ20gZHJhd2luZyBhIHZlcnkgc3VidGxlIGxpbmUgYmV0d2VlbiAoYSkg c3RhdGluZyBhbg0KPiA+Pj4+Pj4gZXhjZXB0aW9uIHRvIDY0MzcgZm9yIHRoaXMgcGFydGljdWxh ciB1c2FnZSBhbmQgKGIpIG9wZW5pbmcgdGhlDQo+ID4+Pj4+PiBkb29yIHRvIG90aGVyIHVzYWdl cy4gU2luY2UgNm1hbiBjbGVhcmx5IGRpZG4ndCB3YW50IChiKSBkdXJpbmcNCj4gPj4+Pj4+IHRo ZSBkZXZlbG9wbWVudCBvZg0KPiA+Pj4+Pj4gNjQzNyBJIHRoaW5rIHdlIGRvIG5lZWQgdG8gbGlt aXQgb3Vyc2VsdmVzIHRvIChhKS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICBCcmlhbg0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+PiAtLQ0KPiA+Pj4+Pj4gLSBJRVRGIElQdjYg d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgaXB2NkBpZXRmLm9yZw0KPiA+Pj4+Pj4gQWRtaW5p c3RyYXRpdmUNCj4gPj4+Pj4+IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwdjYNCj4gPj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+PiAtLQ0KPiA+Pj4+Pj4g LQ0KPiA+DQoNCg== From nobody Fri Aug 22 08:23:39 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566C71A032C for ; Fri, 22 Aug 2014 08:23:37 -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 CYhffq5eoagQ for ; Fri, 22 Aug 2014 08:23:36 -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 55C441A032A for ; Fri, 22 Aug 2014 08:23:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B702A2002A for ; Fri, 22 Aug 2014 11:26:59 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9662863ACB; Fri, 22 Aug 2014 11:23:35 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 823F9638D7 for ; Fri, 22 Aug 2014 11:23:35 -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/91N0Uq7PwsTa4H0Odxd2hK3gkws Subject: [Roll] IPR claim on home-building applicability statement 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, 22 Aug 2014 15:23:37 -0000 --=-=-= The document: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ has an IPR claim: http://datatracker.ietf.org/ipr/2413/ The authors and I believe that this relates to the "real-time layer" that is mentioned as part of making MPL perform with lower latency. > From: Ledeboer, Jodie [mailto:jodie.ledeboer@philips.com] > Sent: 15 August 2014 12:34 > To: Michael Richardson; Ines Robles > Cc: Adrian Farrel; consultancy@vanderstok.org > Subject: RE: Naveen Khan: Philip's IPR disclosure > > As a follow-up: > > With reference to the latest, version 4, of the > draft-ietf-roll-applicability-home- > building, the IPR in question concerns adding a real-time layer > between MPL and MAC to throw away too late messages and favor the most > recent ones. > Accordingly, sections of the version 4 draft that relate to the IPR > are > 4.1.7 and 5.1. > > Kind regards, > > Jodie Ledeboer > Senior IP Counsel > Philips Intellectual Property & Standards -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU/dgdICLcPvd0N1lAQJ9igf+KWispD1+SkXnAg6N+TQsP46+IS1wBg0I keHQQOjT3Zl728FZahNH/wHyeoLiFnd+z2XqZHe2FC45BUzKXP2cwHbUpFHmIU6C heMqIBl6ZmhtXTJE3510QAaPtDX3fSyAgHbHaCjxnzFOf0eqDgpXvCBPsTks7Yzg 2AiykiGIrdLmY592bcgMW0BEBuEqhmXYVph+YF2YtKXaSy1vMgEf9gisSNh+Kcax Lf8xmnzrHUuMhEkdDzZIFX+PGEPOqBVUIYi33bnVHrMPsFwH7afZC5T4e5Z9LNKL WSX9V+4sOcvAterAGQh4cIOrpyt8uwyg7hb2nE15dkm5YELeBNTdnQ== =Y0Ob -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 22 08:44:30 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 EB5271A00DD; Fri, 22 Aug 2014 08:44:23 -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 cdAJtv2HAvTK; Fri, 22 Aug 2014 08:44:20 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A141A032A; Fri, 22 Aug 2014 08:44:19 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so10261236lam.14 for ; Fri, 22 Aug 2014 08:44:17 -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 :cc:content-type; bh=ahkIlJ8fPIrVbsSTxFF/Okmu/zljYFGaADFAXECSGm4=; b=nFvBEmOGujGO/GwLxS+DGXKbEIJ7dDxuHAjjb6uh4llzjzItbmU2A0Ls3t8tUibV5b Zz9iwD4ym5sAIBr9sFQk6lCo3n3q2TcLE+gnTRycH2mYFcxnMU41NHoduvrVHeJ+sQJm H4zoCck/mPtLcv2SNpFvzCDysv3x8uyvUjYQPtFtbwWM3m4ENciTNncf9YBXJH3CP+Ku yWM3IGdF2ejGIrMSgEbHBu/M6jCAQ3CcJJjzv6U8y9VAdcFo5GCwgUKPZmqShrQOPs24 8ObZUxqT5XcwwRVZ4LaP/E+MiTSTD3pLrn3bSEuu3Z987QMUPq/R161tTvU0yIRT/Orh Sk+g== MIME-Version: 1.0 X-Received: by 10.112.150.106 with SMTP id uh10mr5084266lbb.11.1408722257886; Fri, 22 Aug 2014 08:44:17 -0700 (PDT) Received: by 10.25.209.212 with HTTP; Fri, 22 Aug 2014 08:44:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Aug 2014 18:44:17 +0300 Message-ID: From: Ines Robles To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=047d7b34340cc4c9f5050139b57c Archived-At: http://mailarchive.ietf.org/arch/msg/roll/5SnjIryMyaXqZ9AV3W7yaRZkEYA Cc: 6man WG , Michael Richardson , Routing Over Low power and Lossy networks , "6lo@ietf.org WG" <6lo@ietf.org>, Brian E Carpenter Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 22 Aug 2014 15:44:24 -0000 --047d7b34340cc4c9f5050139b57c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Thank you all for your comments during this WGLC. Our conclusion is that we= did not see consensus for the draft. We need please more participation on that. (We think that most of the people are on vacations). So, we leave this thread open, and we are going to have another WGLC during september. Thank you very much in advance, Kind Regards, Michael & Ines. 2014-08-22 15:56 GMT+03:00 Pascal Thubert (pthubert) : > Hello Brian: > > The question of a liaison was discussed at both IEC and ISA100, and they > were very positive about the idea. We can certainly make that happen. > I doubt that there is value in analyzing finely ISA100.11a that is mostly > cast in stone now. We made the analysis at the time and concluded that it > was conforming RFC 3697, and we know now that it does not conform RFC 643= 7. > We could still participate to the work on the backbone router but the > rules in RFC 6437 will not be acceptable there for the exact same reasons > that they are not acceptable in a RPL domain, and the Laurent+Carsten > proposal will not change that a iota. > > The most constructive would be (IMHO): > - adopt the proposed change to the 6MAN rules separately from the propose= d > use in RPL and > - extend the rights that we are asking for a RPL domain to an ISA100 > subnetwork as well so as to make ISA100 compliant again > - update 6284 to position ISA100.11a/IEC62734 vs. both RFCs and the 6MAN > RPL flow label work (split or not) as Ines suggested > - go to WCI and enforce the application of the new RFC so that packets > outgoing the ISA100 subnetwork are made compliant to RFC 6437 (by the > backbone router). > > Would we agree on this path? > > Pascal > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > Sent: mardi 19 ao=C3=BBt 2014 22:32 > > To: Pascal Thubert (pthubert) > > Cc: Michael Richardson; Philip Levis; Routing Over Low power and Lossy > > networks; Ines Robles; 6man WG; 6lo@ietf.org WG > > Subject: Re: [Roll] [6lo] WGLC for > draft-thubert-6man-flow-label-for-rpl-03 > > > > Hi Pascal, > > > > If we're really going to discuss this, we need the IAB to establish > liaison and > > get the right to let us all see the specification. I'm not going to > spend my > > time speculating about a secret document. However, the bit you quote: > > "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to > > ContractID. The higher order 4 bits shall be all zeros." > > certainly seems to violate RFC 6437. Whether it violated the somewhat > > confused situation left by RFC 2460 and RFC 3697 is less clear. I have = no > > recollection of anybody from ISA or IEC talking to the IETF about this > issue. > > > > Regards > > Brian > > > > On 19/08/2014 00:51, Pascal Thubert (pthubert) wrote: > > > Hello Brian: > > > > > > I do not think that you can freely download the specification. You > > > probably need membership first. The links exist from the Wikipedia > > > page but they are broken. Same goes for the IEC version which is IEC > > > 62734, but if you have access to the IEC then the current work is her= e > > > http://www.iec.ch/cgi-bin/restricted/getfile.pl/65C_735ea_CDV.pdf?dir= =3D > > > 65C&format=3Dpdf&type=3D_CDV&file=3D735ea.pdf > > > > > > Quotes: > > > > > > "The ContractID is associated with a particular D-route. This may be > used > > when a particular graph or source D-route is intended to provide a > defined > > level of service" > > > > > > "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to > > ContractID. The higher order 4 bits shall be all zeros. This field shal= l > only be > > present if octets 3 through 5 are present, as indicated by LOWPAN_IPHC > > encoding." > > > > > > Note that the 6TiSCH architecture echoes this design, and a d-route i= s > very > > similar to a 6TiSCH track. > > > > > > For the sake of history and to my best knowledge, ISA100.11a was the > first > > industrial standard to adopt IPv6 for process control applications > (control > > loops and monitoring). > > > It is effectively enabling IP in the control network, which is an > historical > > step toward the IT/OT convergence, that is the Industrial equivalent of > voice > > and video convergence over IP. > > > > > > And also to my best knowledge and conforming RFC 3697, ISA100.11a doe= s > > not mute the Flow Label inside the network, as Michael points out. Only > > when the additional backbone Router functionality is defined does the > > problem of rewriting come into play at the Backbone Router (same positi= on > > as RPL root). For all I know this work is taking place at the Wireless > > Compliance Institute, WCI, but I do not have the latest. > > > > > > Cheers, > > > > > > Pascal > > > > > > > > >> -----Original Message----- > > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > >> Sent: samedi 16 ao=C3=BBt 2014 03:13 > > >> To: Pascal Thubert (pthubert) > > >> Cc: Philip Levis; Routing Over Low power and Lossy networks; Ines > > >> Robles; 6man WG; 6lo@ietf.org WG > > >> Subject: Re: [Roll] [6lo] WGLC for > > >> draft-thubert-6man-flow-label-for-rpl-03 > > >> > > >> On 15/08/2014 20:51, Pascal Thubert (pthubert) wrote: > > >>> Hello Brian > > >>> > > >>> I do not think that ISA10011.a violates RFC 3697. What exactly made > > >>> you > > >> believe so? > > >> > > >> I was over-interpreting what you wrote, I guess. It's true that 3697 > > >> was rather vague about what it called "flow state establishment > > >> methods" and permitted both sequential and pseudo-random flow label > > >> values. Is the ISA10011.a on line somewhere? > > >> > > >>> For all I know ISA100 does everything by the book. Note that ISA100 > > >>> does > > >> not update a non zero FL on the fly since it is not set by a source > > >> outside the LLN if that is your concern. > > >>> OTOH It may violate RFC 6437 in that the flow is not a random but a > > >>> value > > >> attributed by a PCE called system manager (along rules in section 4)= . > > >> As things stand, we'd certainly want the backbone router at LLN > > >> egress to rewrite the FL in packets towards the Internet with a > > >> randomized per flow value. > > >>> It will violate RFC 6437 because if the flow label is set by a > > >>> router in the > > >> Internet - or an updated source that complies to 6437-, the backbone > > >> router at LLN Ingress will rewrite it. > > >>> Both issues are addressed in my draft for a RPL domain. An RFC will > > >>> also > > >> hint a revision of the backbone router that it should rewrite the FL > > >> on outgoing packets. > > >>> What do you think? > > >> I think that Phil's last message frames the question to 6man > > >> correctly, so I will respond to him... > > >> > > >> Regards > > >> Brian > > >>> Pascal > > >>> > > >>>> Le 14 ao=C3=BBt 2014 =C3=A0 22:18, "Brian E Carpenter" > > >> a =C3=A9crit : > > >>>>> On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote: > > >>>>> We can live with this Brian, > > >>>>> > > >>>>> but then I can we add at least an ISA100.11a network? ISA100.11a > > >>>>> was > > >> designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow > > >> label to indicate which flow a packet belongs to. > > >>>> I have no idea what ISA100.11a is or which organisation developed > > >>>> it, but it sounds like a violation of the flow label standard at > > >>>> that time (RFC 3697). If I'd known about it, we would probably hav= e > > >>>> included it in the menagerie of RFC 6294. > > >>>> > > >>>> There's not much the IETF can do about other organisations that > > >>>> misuse our standards, although indeed we sometimes need to > > document > > >>>> such cases. > > >>>> > > >>>> Brian > > >>>> > > >>>> > > >>>> In more details, devices are provisioned with per-flow behavior > > >>>> (including > > >> routing) and settings in what is called a contract. > > >>>> The contractID is carried in the IPv6 flow label. > > >>>>> If so should we name ISA100 specifically or use a more vague > > >>>>> description > > >> like a "RPL or similar LLN domain" > > >>>>> We'll note that resetting an flow label that comes from the > > >>>>> Internet is a generic need is that flow label was set according t= o > > >>>>> 6437, cannot be trusted to be untempered with, > > >>>>> > > >>>>> Cheers, > > >>>>> > > >>>>> Pascal > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E > > >>>>>> Carpenter > > >>>>>> Sent: mercredi 13 ao=C3=BBt 2014 22:53 > > >>>>>> To: Philip Levis > > >>>>>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man > > >>>>>> WG; 6lo@ietf.org WG > > >>>>>> Subject: Re: [Roll] [6lo] WGLC for > > >>>>>> draft-thubert-6man-flow-label-for-rpl-03 > > >>>>>> > > >>>>>>> On 14/08/2014 07:07, Philip Levis wrote: > > >>>>>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) > > >>>>>> wrote: > > >>>>>>>> If this draft is not adopted, the flow label from LLN will > > >>>>>>>> probably stay all > > >>>>>> zeroes as it is today and the goal of 6437 will not be achieved. > > >>>>>>> Pascal, I'm trying to reconcile your claim that the goal of 643= 7 > > >>>>>>> is to allow enclosed networks to use the flow label with Brian'= s > > >>>>>>> statement > > >>>>>>> > > >>>>>>>> Actually that's why I don't want to see a formal update to > > >>>>>>>> 6437, because the only rational update would be to allow any > > >>>>>>>> closed domain to invent its own usage. We had that argument at > > >>>>>>>> length during the development of 6437, and decided against it. > > >>>>>>> Phil > > >>>>>> Right. I'm drawing a very subtle line between (a) stating an > > >>>>>> exception to 6437 for this particular usage and (b) opening the > > >>>>>> door to other usages. Since 6man clearly didn't want (b) during > > >>>>>> the development of > > >>>>>> 6437 I think we do need to limit ourselves to (a). > > >>>>>> > > >>>>>> Brian > > >>>>>> > > >>>>>> ----------------------------------------------------------------= - > > >>>>>> -- > > >>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org > > >>>>>> Administrative > > >>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > >>>>>> ----------------------------------------------------------------= - > > >>>>>> -- > > >>>>>> - > > > > > --047d7b34340cc4c9f5050139b57c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Thank you all for your comments = during this WGLC. Our conclusion is that we=C2=A0did not see consensus for the=C2=A0draft. We need= please more participation on that. (We think that most of the people are o= n vacations).=C2=A0

So,= we leave this thread open, and we are going to have another WGLC during se= ptember.

Tha= nk you very much in advance,

Kind Regards,

Michael & Ines.


2014-08= -22 15:56 GMT+03:00 Pascal Thubert (pthubert) <pthubert@cisco.com>= :
Hello Brian:

The question of a liaison was discussed at both IEC and ISA100, and they we= re very positive about the idea. We can certainly make that happen.
I doubt that there is value in analyzing finely ISA100.11a that is mostly c= ast in stone now. We made the analysis at the time and concluded that it wa= s conforming RFC 3697, and we know now that it does not conform RFC 6437. We could still participate to the work on the backbone router but the rules= in RFC 6437 will not be acceptable there for the exact same reasons that t= hey are not acceptable in a RPL domain, and the Laurent+Carsten proposal wi= ll not change that a iota.

The most constructive would be (IMHO):
- adopt the proposed change to the 6MAN rules separately from the proposed = use in RPL and
- extend the rights that we are asking for a RPL domain to an ISA100 subnet= work as well so as to make ISA100 compliant again
- update 6284 to position ISA100.11a/IEC62734 vs. both RFCs and the 6MAN RP= L flow label work (split or not) as Ines suggested
- go to WCI and enforce the application of the new RFC so that packets outg= oing the ISA100 subnetwork are made compliant to RFC 6437 (by the backbone = router).

Would we agree on this path?

Pascal


> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: mardi 19 ao=C3=BBt 2014 22:32
> To: Pascal Thubert (pthubert)
> Cc: Michael Richardson; Philip Levis; Routing Over Low power and Lossy=
> networks; Ines Robles; 6man WG; 6lo@ie= tf.org WG
> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-r= pl-03
>
> Hi Pascal,
>
> If we're really going to discuss this, we need the IAB to establis= h liaison and
> get the right to let us all see the specification. I'm not going t= o spend my
> time speculating about a secret document. However, the bit you quote:<= br> > "FlowLabel: The lower order 16 bits of the FlowLabel shall be set= to
> ContractID. The higher order 4 bits shall be all zeros."
> certainly seems to violate RFC 6437. Whether it violated the somewhat<= br> > confused situation left by RFC 2460 and RFC 3697 is less clear. I have= no
> recollection of anybody from ISA or IEC talking to the IETF about this= issue.
>
> Regards
>=C2=A0 =C2=A0 Brian
>
> On 19/08/2014 00:51, Pascal Thubert (pthubert) wrote:
> > Hello Brian:
> >
> > I do not think that you can freely download the specification. Yo= u
> > probably need membership first. The links exist from the Wikipedi= a
> > page but they are broken. Same goes for the IEC version which is = IEC
> > 62734, but if you have access to the IEC then the current work is= here
> > http://www.iec.ch/cgi-bin/restricted/= getfile.pl/65C_735ea_CDV.pdf?dir=3D
> > 65C&format=3Dpdf&type=3D_CDV&file=3D735ea.pdf
> >
> > Quotes:
> >
> > "The ContractID is associated with a particular D-route. Thi= s may be used
> when a particular graph or source D-route is intended to provide a def= ined
> level of service"
> >
> > "FlowLabel: The lower order 16 bits of the FlowLabel shall b= e set to
> ContractID. The higher order 4 bits shall be all zeros. This field sha= ll only be
> present if octets 3 through 5 are present, as indicated by LOWPAN_IPHC=
> encoding."
> >
> > Note that the 6TiSCH architecture echoes this design, and a d-rou= te is very
> similar to a 6TiSCH track.
> >
> > For the sake of history and to my best knowledge, ISA100.11a was = the first
> industrial standard to adopt IPv6 for process control applications (co= ntrol
> loops and monitoring).
> > It is effectively enabling IP in the control network, which is an= historical
> step toward the IT/OT convergence, that is the Industrial equivalent o= f voice
> and video convergence over IP.
> >
> > And also to my best knowledge and conforming RFC 3697, ISA100.11a= does
> not mute the Flow Label inside the network, as Michael points out. Onl= y
> when the additional backbone Router functionality is defined does the<= br> > problem of rewriting come into play at the Backbone Router (same posit= ion
> as RPL root). For all I know this work is taking place at the Wireless=
> Compliance Institute, WCI, but I do not have the latest.
> >
> > Cheers,
> >
> > Pascal
> >
> >
> >> -----Original Message-----
> >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> >> Sent: samedi 16 ao=C3=BBt 2014 03:13
> >> To: Pascal Thubert (pthubert)
> >> Cc: Philip Levis; Routing Over Low power and Lossy networks; = Ines
> >> Robles; 6man WG; 6lo@ietf.org= WG
> >> Subject: Re: [Roll] [6lo] WGLC for
> >> draft-thubert-6man-flow-label-for-rpl-03
> >>
> >> On 15/08/2014 20:51, Pascal Thubert (pthubert) wrote:
> >>> Hello Brian
> >>>
> >>> I do not think that ISA10011.a violates RFC 3697. What ex= actly made
> >>> you
> >> believe so?
> >>
> >> I was over-interpreting what you wrote, I guess. It's tru= e that 3697
> >> was rather vague about what it called "flow state establ= ishment
> >> methods" and permitted both sequential and pseudo-random= flow label
> >> values. Is the ISA10011.a on line somewhere?
> >>
> >>> For all I know ISA100 does everything by the book. Note t= hat ISA100
> >>> does
> >> not update a non zero FL on the fly since it is not set by a = source
> >> outside the LLN if that is your concern.
> >>> OTOH It may violate RFC 6437 in that the flow is not a ra= ndom but a
> >>> value
> >> attributed by a PCE called system manager (along rules in sec= tion 4).
> >> As things stand, we'd certainly want the backbone router = at LLN
> >> egress to rewrite the FL in packets towards the Internet with= a
> >> randomized per flow value.
> >>> It will violate RFC 6437 because if the flow label is set= by a
> >>> router in the
> >> Internet - or an updated source that complies to 6437-, the b= ackbone
> >> router at LLN Ingress will rewrite it.
> >>> Both issues are addressed in my draft for a RPL domain. A= n RFC will
> >>> also
> >> hint a revision of the backbone router that it should rewrite= the FL
> >> on outgoing packets.
> >>> What do you think?
> >> I think that Phil's last message frames the question to 6= man
> >> correctly, so I will respond to him...
> >>
> >> Regards
> >>=C2=A0 =C2=A0 =C2=A0Brian
> >>> Pascal
> >>>
> >>>> Le 14 ao=C3=BBt 2014 =C3=A0 22:18, "Brian E Carp= enter"
> >> <brian.e.ca= rpenter@gmail.com> a =C3=A9crit :
> >>>>> On 14/08/2014 22:28, Pascal Thubert (pthubert) wr= ote:
> >>>>> We can live with this Brian,
> >>>>>
> >>>>> but then I can we add at least an ISA100.11a netw= ork? ISA100.11a
> >>>>> was
> >> designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IP= v6 flow
> >> label to indicate which flow a packet belongs to.
> >>>> I have no idea what ISA100.11a is or which organisati= on developed
> >>>> it, but it sounds like a violation of the flow label = standard at
> >>>> that time (RFC 3697). If I'd known about it, we w= ould probably have
> >>>> included it in the menagerie of RFC 6294.
> >>>>
> >>>> There's not much the IETF can do about other orga= nisations that
> >>>> misuse our standards, although indeed we sometimes ne= ed to
> document
> >>>> such cases.
> >>>>
> >>>>=C2=A0 =C2=A0Brian
> >>>>
> >>>>
> >>>> In more details, devices are provisioned with per-flo= w behavior
> >>>> (including
> >> routing) and settings in what is called a contract.
> >>>> The contractID is carried in the IPv6 flow label.
> >>>>> If so should we name ISA100 specifically or use a= more vague
> >>>>> description
> >> like a "RPL or similar LLN domain"
> >>>>> We'll note that resetting an flow label that = comes from the
> >>>>> Internet is a generic need is that flow label was= set according to
> >>>>> 6437, cannot be trusted to be untempered with, > >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Pascal
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E
> >>>>>> Carpenter
> >>>>>> Sent: mercredi 13 ao=C3=BBt 2014 22:53
> >>>>>> To: Philip Levis
> >>>>>> Cc: Routing Over Low power and Lossy networks= ; Ines Robles; 6man
> >>>>>> WG; 6lo@ietf.= org WG
> >>>>>> Subject: Re: [Roll] [6lo] WGLC for
> >>>>>> draft-thubert-6man-flow-label-for-rpl-03
> >>>>>>
> >>>>>>> On 14/08/2014 07:07, Philip Levis wrote:<= br> > >>>>>>> On Aug 13, 2014, at 9:48 AM, Pascal Thube= rt (pthubert)
> >>>>>> <pth= ubert@cisco.com> wrote:
> >>>>>>>> If this draft is not adopted, the flo= w label from LLN will
> >>>>>>>> probably stay all
> >>>>>> zeroes as it is today and the goal of 6437 wi= ll not be achieved.
> >>>>>>> Pascal, I'm trying to reconcile your = claim that the goal of 6437
> >>>>>>> is to allow enclosed networks to use the = flow label with Brian's
> >>>>>>> statement
> >>>>>>>
> >>>>>>>> Actually that's why I don't w= ant to see a formal update to
> >>>>>>>> 6437, because the only rational updat= e would be to allow any
> >>>>>>>> closed domain to invent its own usage= . We had that argument at
> >>>>>>>> length during the development of 6437= , and decided against it.
> >>>>>>> Phil
> >>>>>> Right. I'm drawing a very subtle line bet= ween (a) stating an
> >>>>>> exception to 6437 for this particular usage a= nd (b) opening the
> >>>>>> door to other usages. Since 6man clearly didn= 't want (b) during
> >>>>>> the development of
> >>>>>> 6437 I think we do need to limit ourselves to= (a).
> >>>>>>
> >>>>>>=C2=A0 =C2=A0 Brian
> >>>>>>
> >>>>>> ---------------------------------------------= --------------------
> >>>>>> --
> >>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org
> >>>>>> Administrative
> >>>>>> Requests: https://www.ietf.org/mailman/listinfo= /ipv6
> >>>>>> ---------------------------------------------= --------------------
> >>>>>> --
> >>>>>> -
> >


--047d7b34340cc4c9f5050139b57c-- From nobody Fri Aug 22 20:07:41 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6A01A70E2; Fri, 22 Aug 2014 20:07:38 -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 QKDBrVSI4Lm4; Fri, 22 Aug 2014 20:07:34 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DAE1A0B10; Fri, 22 Aug 2014 20:07:34 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id rd3so17698614pab.40 for ; Fri, 22 Aug 2014 20:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cp44kTSz5ct06tK7//Cp7f6jBf+Fu1C6llr/YAtVIXM=; b=ZV2vT32vkQtdoE+N7OvJCbAITxzRlzcd7PSSksRQxm4dODUenuDwbKO3j3tHPeiK5e DF4wGVOlbIaDr/NgpK8s/yt5ir9JtQ8uDlNG7fb9irNHoBn965sOCEivS5fKzPw69K/k nZHJE5hjGA2A3pG6cb4rBA2S3CoZOlp8NM8YzkXdPO7x7p5G+pemzdO79x7Xytj0/RtW sb5ibiFZVfnUY57tFWG1vFy5B5VjW8EBQ2Q0Ul55FnU9UDt7H6Wf3jfS2PPIgCcdbVy6 FkWjspVkcLRu4VcUh3ieyWPqcFyd3KI5twL6alZpeWEg4GRWBTt3frEfMc57PKX9g9J2 eErQ== X-Received: by 10.66.163.164 with SMTP id yj4mr10710168pab.91.1408763253781; Fri, 22 Aug 2014 20:07:33 -0700 (PDT) Received: from [192.168.178.23] (31.196.69.111.dynamic.snap.net.nz. [111.69.196.31]) by mx.google.com with ESMTPSA id h5sm29631089pdn.83.2014.08.22.20.07.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Aug 2014 20:07:33 -0700 (PDT) Message-ID: <53F8057C.9080904@gmail.com> Date: Sat, 23 Aug 2014 15:07:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/roll/3dCLBxyPey3utTIIHZOepicuTzA Cc: 6man WG , Michael Richardson , Routing Over Low power and Lossy networks , Ines Robles , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 03:07:39 -0000 Hi Pascal, On 23/08/2014 00:56, Pascal Thubert (pthubert) wrote: > Hello Brian: >=20 > The question of a liaison was discussed at both IEC and ISA100, and the= y were very positive about the idea. We can certainly make that happen. That's something that you would need to raise with the IAB. I imagine the= re are quite a few IEC documents that are relevant to the IETF; given that we have a long history of liaison with ITU and ISO, it's actually a bit surprising we have never set it up with IEC. Anyway, that's above my current pay grade in the IETF ;-). > I doubt that there is value in analyzing finely ISA100.11a that is most= ly cast in stone now. We made the analysis at the time and concluded that= it was conforming RFC 3697, and we know now that it does not conform RFC= 6437. > We could still participate to the work on the backbone router but the r= ules in RFC 6437 will not be acceptable there for the exact same reasons = that they are not acceptable in a RPL domain, and the Laurent+Carsten pro= posal will not change that a iota. >=20 > The most constructive would be (IMHO): > - adopt the proposed change to the 6MAN rules separately from the propo= sed use in RPL and=20 The problem is that something like this was in the draft that became RFC = 6437, and was removed after a very negative reaction from 6MAN. Quoting from a slide shown to 6MAN in November 2010: "A network domain MUST NOT forward packets outside the domain whose flow labels are other than zero or pseudorandom. [Backstop rule for sites that break other rules.] o New compared to RFC 3697." This made it into draft-ietf-6man-flow-update-00 and then draft-ietf-6man-flow-3697bis-00, but was removed from draft-ietf-6man-flow-3697bis-01 because the WG simply didn't want it. The text "However, any node that sets flow label values according to a stateful scheme MUST ensure that packets conform to Section 3 of the present specification if they are sent outside the network domain using the stateful scheme." was present in the -01 draft but was removed at WG request in -04. So there was an extremely clear 6MAN consensus against this in 2010/11. We were explicitly asked to remove the notion of domains with their own rules. Brian > - extend the rights that we are asking for a RPL domain to an ISA100 su= bnetwork as well so as to make ISA100 compliant again > - update 6284 to position ISA100.11a/IEC62734 vs. both RFCs and the 6MA= N RPL flow label work (split or not) as Ines suggested > - go to WCI and enforce the application of the new RFC so that packets = outgoing the ISA100 subnetwork are made compliant to RFC 6437 (by the bac= kbone router). >=20 > Would we agree on this path?=20 >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: mardi 19 ao=C3=BBt 2014 22:32 >> To: Pascal Thubert (pthubert) >> Cc: Michael Richardson; Philip Levis; Routing Over Low power and Lossy= >> networks; Ines Robles; 6man WG; 6lo@ietf.org WG >> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-r= pl-03 >> >> Hi Pascal, >> >> If we're really going to discuss this, we need the IAB to establish li= aison and >> get the right to let us all see the specification. I'm not going to sp= end my >> time speculating about a secret document. However, the bit you quote: >> "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to >> ContractID. The higher order 4 bits shall be all zeros." >> certainly seems to violate RFC 6437. Whether it violated the somewhat >> confused situation left by RFC 2460 and RFC 3697 is less clear. I have= no >> recollection of anybody from ISA or IEC talking to the IETF about this= issue. >> >> Regards >> Brian >> >> On 19/08/2014 00:51, Pascal Thubert (pthubert) wrote: >>> Hello Brian: >>> >>> I do not think that you can freely download the specification. You >>> probably need membership first. The links exist from the Wikipedia >>> page but they are broken. Same goes for the IEC version which is IEC >>> 62734, but if you have access to the IEC then the current work is her= e >>> http://www.iec.ch/cgi-bin/restricted/getfile.pl/65C_735ea_CDV.pdf?dir= =3D >>> 65C&format=3Dpdf&type=3D_CDV&file=3D735ea.pdf >>> >>> Quotes: >>> >>> "The ContractID is associated with a particular D-route. This may be = used >> when a particular graph or source D-route is intended to provide a def= ined >> level of service" >>> "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to >> ContractID. The higher order 4 bits shall be all zeros. This field sha= ll only be >> present if octets 3 through 5 are present, as indicated by LOWPAN_IPHC= >> encoding." >>> Note that the 6TiSCH architecture echoes this design, and a d-route i= s very >> similar to a 6TiSCH track. >>> For the sake of history and to my best knowledge, ISA100.11a was the = first >> industrial standard to adopt IPv6 for process control applications (co= ntrol >> loops and monitoring). >>> It is effectively enabling IP in the control network, which is an his= torical >> step toward the IT/OT convergence, that is the Industrial equivalent o= f voice >> and video convergence over IP. >>> And also to my best knowledge and conforming RFC 3697, ISA100.11a doe= s >> not mute the Flow Label inside the network, as Michael points out. Onl= y >> when the additional backbone Router functionality is defined does the >> problem of rewriting come into play at the Backbone Router (same posit= ion >> as RPL root). For all I know this work is taking place at the Wireless= >> Compliance Institute, WCI, but I do not have the latest. >>> Cheers, >>> >>> Pascal >>> >>> >>>> -----Original Message----- >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>> Sent: samedi 16 ao=C3=BBt 2014 03:13 >>>> To: Pascal Thubert (pthubert) >>>> Cc: Philip Levis; Routing Over Low power and Lossy networks; Ines >>>> Robles; 6man WG; 6lo@ietf.org WG >>>> Subject: Re: [Roll] [6lo] WGLC for >>>> draft-thubert-6man-flow-label-for-rpl-03 >>>> >>>> On 15/08/2014 20:51, Pascal Thubert (pthubert) wrote: >>>>> Hello Brian >>>>> >>>>> I do not think that ISA10011.a violates RFC 3697. What exactly made= >>>>> you >>>> believe so? >>>> >>>> I was over-interpreting what you wrote, I guess. It's true that 3697= >>>> was rather vague about what it called "flow state establishment >>>> methods" and permitted both sequential and pseudo-random flow label >>>> values. Is the ISA10011.a on line somewhere? >>>> >>>>> For all I know ISA100 does everything by the book. Note that ISA100= >>>>> does >>>> not update a non zero FL on the fly since it is not set by a source >>>> outside the LLN if that is your concern. >>>>> OTOH It may violate RFC 6437 in that the flow is not a random but a= >>>>> value >>>> attributed by a PCE called system manager (along rules in section 4)= =2E >>>> As things stand, we'd certainly want the backbone router at LLN >>>> egress to rewrite the FL in packets towards the Internet with a >>>> randomized per flow value. >>>>> It will violate RFC 6437 because if the flow label is set by a >>>>> router in the >>>> Internet - or an updated source that complies to 6437-, the backbone= >>>> router at LLN Ingress will rewrite it. >>>>> Both issues are addressed in my draft for a RPL domain. An RFC will= >>>>> also >>>> hint a revision of the backbone router that it should rewrite the FL= >>>> on outgoing packets. >>>>> What do you think? >>>> I think that Phil's last message frames the question to 6man >>>> correctly, so I will respond to him... >>>> >>>> Regards >>>> Brian >>>>> Pascal >>>>> >>>>>> Le 14 ao=C3=BBt 2014 =C3=A0 22:18, "Brian E Carpenter" >>>> a =C3=A9crit : >>>>>>> On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote: >>>>>>> We can live with this Brian, >>>>>>> >>>>>>> but then I can we add at least an ISA100.11a network? ISA100.11a >>>>>>> was >>>> designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow= >>>> label to indicate which flow a packet belongs to. >>>>>> I have no idea what ISA100.11a is or which organisation developed >>>>>> it, but it sounds like a violation of the flow label standard at >>>>>> that time (RFC 3697). If I'd known about it, we would probably hav= e >>>>>> included it in the menagerie of RFC 6294. >>>>>> >>>>>> There's not much the IETF can do about other organisations that >>>>>> misuse our standards, although indeed we sometimes need to >> document >>>>>> such cases. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> In more details, devices are provisioned with per-flow behavior >>>>>> (including >>>> routing) and settings in what is called a contract. >>>>>> The contractID is carried in the IPv6 flow label. >>>>>>> If so should we name ISA100 specifically or use a more vague >>>>>>> description >>>> like a "RPL or similar LLN domain" >>>>>>> We'll note that resetting an flow label that comes from the >>>>>>> Internet is a generic need is that flow label was set according t= o >>>>>>> 6437, cannot be trusted to be untempered with, >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E >>>>>>>> Carpenter >>>>>>>> Sent: mercredi 13 ao=C3=BBt 2014 22:53 >>>>>>>> To: Philip Levis >>>>>>>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man= >>>>>>>> WG; 6lo@ietf.org WG >>>>>>>> Subject: Re: [Roll] [6lo] WGLC for >>>>>>>> draft-thubert-6man-flow-label-for-rpl-03 >>>>>>>> >>>>>>>>> On 14/08/2014 07:07, Philip Levis wrote: >>>>>>>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) >>>>>>>> wrote: >>>>>>>>>> If this draft is not adopted, the flow label from LLN will >>>>>>>>>> probably stay all >>>>>>>> zeroes as it is today and the goal of 6437 will not be achieved.= >>>>>>>>> Pascal, I'm trying to reconcile your claim that the goal of 643= 7 >>>>>>>>> is to allow enclosed networks to use the flow label with Brian'= s >>>>>>>>> statement >>>>>>>>> >>>>>>>>>> Actually that's why I don't want to see a formal update to >>>>>>>>>> 6437, because the only rational update would be to allow any >>>>>>>>>> closed domain to invent its own usage. We had that argument at= >>>>>>>>>> length during the development of 6437, and decided against it.= >>>>>>>>> Phil >>>>>>>> Right. I'm drawing a very subtle line between (a) stating an >>>>>>>> exception to 6437 for this particular usage and (b) opening the >>>>>>>> door to other usages. Since 6man clearly didn't want (b) during >>>>>>>> the development of >>>>>>>> 6437 I think we do need to limit ourselves to (a). >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> ----------------------------------------------------------------= - >>>>>>>> -- >>>>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org >>>>>>>> Administrative >>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>> ----------------------------------------------------------------= - >>>>>>>> -- >>>>>>>> - >=20 From nobody Mon Aug 25 09:41:13 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 A6BF91A0055; Mon, 25 Aug 2014 09:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.469 X-Spam-Level: X-Spam-Status: No, score=-12.469 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 rg0F8gQUVqxT; Mon, 25 Aug 2014 09:41:05 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B1D1A0081; Mon, 25 Aug 2014 09:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18442; q=dns/txt; s=iport; t=1408984257; x=1410193857; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Sp91gMsmPaYhYcOlB+OfnHeEmNiaQfq7P5Q29bdH7Rs=; b=Ium0Y6uyghsSiYUwiv/r/gtPdkcrhG6lSw9neQYiV57Plm48Nm3S1339 es1oZ5LN59vF0HGjo0fSoZSVIrdwAKS4AO0mK3dcpgDmPS4UaL9FEOBkU LOpRBbVUSJuhZk04o6n6UsDMMzz72UJ88jym8Ar2zmUCeEzI/rTVLglEo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAGVk+1OtJA2I/2dsb2JhbABagw1TVwSCeMlSCodNARmBCRZ3hAMBAQECAgEBASARMwcLDAQCAQgRAQMBAQECAgYdAwICAh8GCxQBAgYIAQEEDgUIAYglAxENqyaPKQ2FIheBLItzgUoMCR0WGwcGgnM2gR0FhhGIb4ImhmOCMIpHhiCGNYNebAGBBkGBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,397,1406592000"; d="scan'208";a="72150635" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 25 Aug 2014 16:30:55 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7PGUs7H030640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 16:30:55 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 11:30:54 -0500 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: Ac++CEw2eULOCzQzTxOZUvA7hQn3EwAoQK0AAHUlFjA= Date: Mon, 25 Aug 2014 16:30:53 +0000 Deferred-Delivery: Mon, 25 Aug 2014 16:30:00 +0000 Message-ID: References: <53F8057C.9080904@gmail.com> In-Reply-To: <53F8057C.9080904@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/f3hONrbDhDTE6TsmAVAPEl1FMoU Cc: 6man WG , Michael Richardson , Routing Over Low power and Lossy networks , Ines Robles , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 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, 25 Aug 2014 16:41:10 -0000 SSB1bmRlcnN0YW5kLCBCcmlhbjoNCg0KSXQgbWFrZXMgc2Vuc2UgdG8gcHJvcG9zZSBhIGdlbmVy aWMgcnVsZSBhbmQgdHJ5IGl0IG9uIHRoZSByZWFsIHdvcmxkLiBCdXQgaXQgaXMgbm90IHN1cnBy aXNpbmcgdGhhdCBzdWNoIGEgYm9sZCBhcHByb2FjaCBmYWlscyB0byBiZSB1bml2ZXJzYWwgd2hl biBjb25mcm9udGVkIHRvIHRoZSByZWFsIHdvcmxkLg0KVG8gYmUgdmVyeSBjbGVhciBvbiB0aGUg bmVlZCBmb3IgNk1BTiB0byB0YWtlIG91ciByZXNwb25zaWJpbGl0aWVzLCBJIGFkZGVkIHRleHQg dG8gY2xhcmlmeSB0aGF0IDY0MzcgYXMgb2YgdG9kYXkgaXMgZHJhbWF0aWNhbGx5IGNvdW50ZXJw cm9kdWN0aXZlIGZvciB0aGUgZGV2ZWxvcG1lbnQgb2YgSVB2NiBpbiBMTE5zLg0KDQpPdGhlcndp c2UsIEkgdXBkYXRlZCBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXRodWJlcnQtNm1hbi1m bG93LWxhYmVsLWZvci1ycGwtMDUudHh0IGFsb25nIHdpdGggeW91ciByZWNvbW1lbmRhdGlvbnMg YXMgZm9sbG93czoNCg0KLSByZW1vdmVkIHRoZSB1cGRhdGVkOiB0aWxsIHdlIGdldCBjb25zZW5z dXMgb24gaGF2aW5nIGl0LCBidXQgZm9sbG93aW5nIFBoaWwncyByZWNvbW1lbmRhdGlvbiwgSSBp c29sYXRlZCB0aGUgNjQzNyB1cGRhdGVzIGluIHNlY3Rpb24gNS4gIFVwZGF0ZWQgUnVsZXMNCi0g cmVtb3ZlZCB0aGUgdGV4dCBvbiB0aGUgYXBwbGljYXRpb24gdG8gdGhlIFJQTCBvcHRpb24uIFRo ZSBydWxlcyB0aGF0IGFyZSBuZWVkZWQgd2hhdGV2ZXIgdGhlIGRlY2lzaW9uIGlzIGxhdGVyIGlu IExMTiBXR3MgYXMgb2YgaG93IHRoZSBSUEwgb3B0aW9uIGlzIGNvbXByZXNzZWQsIHlldCBsZWF2 aW5nIGFsbCBwb3NzaWJpbGl0aWVzIG9wZW4uIFRoaXMgYWxsb3dzIDZNQU4gdG8gbWFrZSBhbiBp bmRlcGVuZGVudCBkZWNpc2lvbi4NCi0gaW5kaWNhdGVkIHRoYXQgYSBjb25zdHJhaW5lZCBMTE4g ZG9tYWluIGlzIGFuIGV4Y2VwdGlvbiB0byB0aGUgZ2VuZXJhbG5lc3Mgb2YgNjQzNyB3aGVyZSBl bmVyZ3ktc2F2aW5nIGlzIGFub3RoZXIgY29tcGVsbGluZyByZWFzb24gdG8gYWxsb3cgdGhlIG1v ZGlmaWNhdGlvbiBvZiBhIG5vbi16ZXJvIGZsb3cgbGFiZWwuDQotIGV4dGVuZGVkIHRoZSBhcHBs aWNhYmlsaXR5IHRvIElTQTEwMC4xMWEgbmV0d29ya3MgYXMgYW4gZWZmb3J0IGZyb20gdGhlIElF VEYgdG8ga2VlcCB0aGF0IHN0YW5kYXJkIGNvbXBsaWFudCB3aXRoIElQdjYgYXMgd2VsbCBhcyBz aW1pbGFyIExMTnMgc2luY2UgdGhlIGlzc3VlIHdpdGggNjQzNyBpcyBnZW5lcmljIHRvIGFsbCBj b25zdHJhaW5lZCBMTE4uDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUu Y2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogc2FtZWRpIDIzIGFvw7t0IDIwMTQgMDU6MDgN Cj4gVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCj4gQ2M6IE1pY2hhZWwgUmljaGFyZHNv bjsgUGhpbGlwIExldmlzOyBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeQ0KPiBuZXR3 b3JrczsgSW5lcyBSb2JsZXM7IDZtYW4gV0c7IDZsb0BpZXRmLm9yZyBXRw0KPiBTdWJqZWN0OiBS ZTogW1JvbGxdIFs2bG9dIFdHTEMgZm9yIGRyYWZ0LXRodWJlcnQtNm1hbi1mbG93LWxhYmVsLWZv ci1ycGwtMDMNCj4gDQo+IEhpIFBhc2NhbCwNCj4gDQo+IE9uIDIzLzA4LzIwMTQgMDA6NTYsIFBh c2NhbCBUaHViZXJ0IChwdGh1YmVydCkgd3JvdGU6DQo+ID4gSGVsbG8gQnJpYW46DQo+ID4NCj4g PiBUaGUgcXVlc3Rpb24gb2YgYSBsaWFpc29uIHdhcyBkaXNjdXNzZWQgYXQgYm90aCBJRUMgYW5k IElTQTEwMCwgYW5kIHRoZXkNCj4gd2VyZSB2ZXJ5IHBvc2l0aXZlIGFib3V0IHRoZSBpZGVhLiBX ZSBjYW4gY2VydGFpbmx5IG1ha2UgdGhhdCBoYXBwZW4uDQo+IA0KPiBUaGF0J3Mgc29tZXRoaW5n IHRoYXQgeW91IHdvdWxkIG5lZWQgdG8gcmFpc2Ugd2l0aCB0aGUgSUFCLiBJIGltYWdpbmUgdGhl cmUNCj4gYXJlIHF1aXRlIGEgZmV3IElFQyBkb2N1bWVudHMgdGhhdCBhcmUgcmVsZXZhbnQgdG8g dGhlIElFVEY7IGdpdmVuIHRoYXQgd2UNCj4gaGF2ZSBhIGxvbmcgaGlzdG9yeSBvZiBsaWFpc29u IHdpdGggSVRVIGFuZCBJU08sIGl0J3MgYWN0dWFsbHkgYSBiaXQgc3VycHJpc2luZw0KPiB3ZSBo YXZlIG5ldmVyIHNldCBpdCB1cCB3aXRoIElFQy4gQW55d2F5LCB0aGF0J3MgYWJvdmUgbXkgY3Vy cmVudCBwYXkgZ3JhZGUNCj4gaW4gdGhlIElFVEYgOy0pLg0KPiANCj4gPiBJIGRvdWJ0IHRoYXQg dGhlcmUgaXMgdmFsdWUgaW4gYW5hbHl6aW5nIGZpbmVseSBJU0ExMDAuMTFhIHRoYXQgaXMgbW9z dGx5IGNhc3QNCj4gaW4gc3RvbmUgbm93LiBXZSBtYWRlIHRoZSBhbmFseXNpcyBhdCB0aGUgdGlt ZSBhbmQgY29uY2x1ZGVkIHRoYXQgaXQgd2FzDQo+IGNvbmZvcm1pbmcgUkZDIDM2OTcsIGFuZCB3 ZSBrbm93IG5vdyB0aGF0IGl0IGRvZXMgbm90IGNvbmZvcm0gUkZDIDY0MzcuDQo+ID4gV2UgY291 bGQgc3RpbGwgcGFydGljaXBhdGUgdG8gdGhlIHdvcmsgb24gdGhlIGJhY2tib25lIHJvdXRlciBi dXQgdGhlIHJ1bGVzDQo+IGluIFJGQyA2NDM3IHdpbGwgbm90IGJlIGFjY2VwdGFibGUgdGhlcmUg Zm9yIHRoZSBleGFjdCBzYW1lIHJlYXNvbnMgdGhhdA0KPiB0aGV5IGFyZSBub3QgYWNjZXB0YWJs ZSBpbiBhIFJQTCBkb21haW4sIGFuZCB0aGUgTGF1cmVudCtDYXJzdGVuIHByb3Bvc2FsDQo+IHdp bGwgbm90IGNoYW5nZSB0aGF0IGEgaW90YS4NCj4gPg0KPiA+IFRoZSBtb3N0IGNvbnN0cnVjdGl2 ZSB3b3VsZCBiZSAoSU1ITyk6DQo+ID4gLSBhZG9wdCB0aGUgcHJvcG9zZWQgY2hhbmdlIHRvIHRo ZSA2TUFOIHJ1bGVzIHNlcGFyYXRlbHkgZnJvbSB0aGUNCj4gPiBwcm9wb3NlZCB1c2UgaW4gUlBM IGFuZA0KPiANCj4gVGhlIHByb2JsZW0gaXMgdGhhdCBzb21ldGhpbmcgbGlrZSB0aGlzIHdhcyBp biB0aGUgZHJhZnQgdGhhdCBiZWNhbWUgUkZDDQo+IDY0MzcsIGFuZCB3YXMgcmVtb3ZlZCBhZnRl ciBhIHZlcnkgbmVnYXRpdmUgcmVhY3Rpb24gZnJvbSA2TUFOLg0KPiANCj4gUXVvdGluZyBmcm9t IGEgc2xpZGUgc2hvd24gdG8gNk1BTiBpbiBOb3ZlbWJlciAyMDEwOg0KPiANCj4gIkEgbmV0d29y ayBkb21haW4gTVVTVCBOT1QgZm9yd2FyZCBwYWNrZXRzIG91dHNpZGUgdGhlIGRvbWFpbiB3aG9z ZQ0KPiBmbG93IGxhYmVscyBhcmUgb3RoZXIgdGhhbiB6ZXJvIG9yIHBzZXVkb3JhbmRvbS4NCj4g W0JhY2tzdG9wIHJ1bGUgZm9yIHNpdGVzIHRoYXQgYnJlYWsgb3RoZXIgcnVsZXMuXSBvIE5ldyBj b21wYXJlZCB0byBSRkMNCj4gMzY5Ny4iDQo+IA0KPiBUaGlzIG1hZGUgaXQgaW50byBkcmFmdC1p ZXRmLTZtYW4tZmxvdy11cGRhdGUtMDAgYW5kIHRoZW4gZHJhZnQtaWV0Zi02bWFuLQ0KPiBmbG93 LTM2OTdiaXMtMDAsIGJ1dCB3YXMgcmVtb3ZlZCBmcm9tDQo+IGRyYWZ0LWlldGYtNm1hbi1mbG93 LTM2OTdiaXMtMDEgYmVjYXVzZSB0aGUgV0cgc2ltcGx5IGRpZG4ndCB3YW50IGl0Lg0KPiANCj4g VGhlIHRleHQgIkhvd2V2ZXIsIGFueSBub2RlIHRoYXQgc2V0cyBmbG93IGxhYmVsIHZhbHVlcyBh Y2NvcmRpbmcgdG8gYQ0KPiBzdGF0ZWZ1bCBzY2hlbWUgTVVTVCBlbnN1cmUgdGhhdCBwYWNrZXRz IGNvbmZvcm0gdG8gU2VjdGlvbiAzIG9mIHRoZQ0KPiBwcmVzZW50IHNwZWNpZmljYXRpb24gaWYg dGhleSBhcmUgc2VudCBvdXRzaWRlIHRoZSBuZXR3b3JrIGRvbWFpbiB1c2luZyB0aGUNCj4gc3Rh dGVmdWwgc2NoZW1lLiIgd2FzIHByZXNlbnQgaW4gdGhlIC0wMSBkcmFmdCBidXQgd2FzIHJlbW92 ZWQgYXQgV0cNCj4gcmVxdWVzdCBpbiAtMDQuDQo+IA0KPiBTbyB0aGVyZSB3YXMgYW4gZXh0cmVt ZWx5IGNsZWFyIDZNQU4gY29uc2Vuc3VzIGFnYWluc3QgdGhpcyBpbiAyMDEwLzExLg0KPiBXZSB3 ZXJlIGV4cGxpY2l0bHkgYXNrZWQgdG8gcmVtb3ZlIHRoZSBub3Rpb24gb2YgZG9tYWlucyB3aXRo IHRoZWlyIG93bg0KPiBydWxlcy4NCj4gDQo+ICAgIEJyaWFuDQo+IA0KPiA+IC0gZXh0ZW5kIHRo ZSByaWdodHMgdGhhdCB3ZSBhcmUgYXNraW5nIGZvciBhIFJQTCBkb21haW4gdG8gYW4gSVNBMTAw DQo+ID4gc3VibmV0d29yayBhcyB3ZWxsIHNvIGFzIHRvIG1ha2UgSVNBMTAwIGNvbXBsaWFudCBh Z2Fpbg0KPiA+IC0gdXBkYXRlIDYyODQgdG8gcG9zaXRpb24gSVNBMTAwLjExYS9JRUM2MjczNCB2 cy4gYm90aCBSRkNzIGFuZCB0aGUNCj4gPiA2TUFOIFJQTCBmbG93IGxhYmVsIHdvcmsgKHNwbGl0 IG9yIG5vdCkgYXMgSW5lcyBzdWdnZXN0ZWQNCj4gPiAtIGdvIHRvIFdDSSBhbmQgZW5mb3JjZSB0 aGUgYXBwbGljYXRpb24gb2YgdGhlIG5ldyBSRkMgc28gdGhhdCBwYWNrZXRzDQo+IG91dGdvaW5n IHRoZSBJU0ExMDAgc3VibmV0d29yayBhcmUgbWFkZSBjb21wbGlhbnQgdG8gUkZDIDY0MzcgKGJ5 IHRoZQ0KPiBiYWNrYm9uZSByb3V0ZXIpLg0KPiA+DQo+ID4gV291bGQgd2UgYWdyZWUgb24gdGhp cyBwYXRoPw0KPiA+DQo+ID4gUGFzY2FsDQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUu Y2FycGVudGVyQGdtYWlsLmNvbV0NCj4gPj4gU2VudDogbWFyZGkgMTkgYW/Du3QgMjAxNCAyMjoz Mg0KPiA+PiBUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KPiA+PiBDYzogTWljaGFlbCBS aWNoYXJkc29uOyBQaGlsaXAgTGV2aXM7IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kDQo+ID4+ IExvc3N5IG5ldHdvcmtzOyBJbmVzIFJvYmxlczsgNm1hbiBXRzsgNmxvQGlldGYub3JnIFdHDQo+ ID4+IFN1YmplY3Q6IFJlOiBbUm9sbF0gWzZsb10gV0dMQyBmb3INCj4gPj4gZHJhZnQtdGh1YmVy dC02bWFuLWZsb3ctbGFiZWwtZm9yLXJwbC0wMw0KPiA+Pg0KPiA+PiBIaSBQYXNjYWwsDQo+ID4+ DQo+ID4+IElmIHdlJ3JlIHJlYWxseSBnb2luZyB0byBkaXNjdXNzIHRoaXMsIHdlIG5lZWQgdGhl IElBQiB0byBlc3RhYmxpc2gNCj4gPj4gbGlhaXNvbiBhbmQgZ2V0IHRoZSByaWdodCB0byBsZXQg dXMgYWxsIHNlZSB0aGUgc3BlY2lmaWNhdGlvbi4gSSdtDQo+ID4+IG5vdCBnb2luZyB0byBzcGVu ZCBteSB0aW1lIHNwZWN1bGF0aW5nIGFib3V0IGEgc2VjcmV0IGRvY3VtZW50Lg0KPiBIb3dldmVy LCB0aGUgYml0IHlvdSBxdW90ZToNCj4gPj4gIkZsb3dMYWJlbDogVGhlIGxvd2VyIG9yZGVyIDE2 IGJpdHMgb2YgdGhlIEZsb3dMYWJlbCBzaGFsbCBiZSBzZXQgdG8NCj4gPj4gQ29udHJhY3RJRC4g VGhlIGhpZ2hlciBvcmRlciA0IGJpdHMgc2hhbGwgYmUgYWxsIHplcm9zLiINCj4gPj4gY2VydGFp bmx5IHNlZW1zIHRvIHZpb2xhdGUgUkZDIDY0MzcuIFdoZXRoZXIgaXQgdmlvbGF0ZWQgdGhlIHNv bWV3aGF0DQo+ID4+IGNvbmZ1c2VkIHNpdHVhdGlvbiBsZWZ0IGJ5IFJGQyAyNDYwIGFuZCBSRkMg MzY5NyBpcyBsZXNzIGNsZWFyLiBJDQo+ID4+IGhhdmUgbm8gcmVjb2xsZWN0aW9uIG9mIGFueWJv ZHkgZnJvbSBJU0Egb3IgSUVDIHRhbGtpbmcgdG8gdGhlIElFVEYgYWJvdXQNCj4gdGhpcyBpc3N1 ZS4NCj4gPj4NCj4gPj4gUmVnYXJkcw0KPiA+PiAgICBCcmlhbg0KPiA+Pg0KPiA+PiBPbiAxOS8w OC8yMDE0IDAwOjUxLCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPiA+Pj4gSGVs bG8gQnJpYW46DQo+ID4+Pg0KPiA+Pj4gSSBkbyBub3QgdGhpbmsgdGhhdCB5b3UgY2FuIGZyZWVs eSBkb3dubG9hZCB0aGUgc3BlY2lmaWNhdGlvbi4gWW91DQo+ID4+PiBwcm9iYWJseSBuZWVkIG1l bWJlcnNoaXAgZmlyc3QuIFRoZSBsaW5rcyBleGlzdCBmcm9tIHRoZSBXaWtpcGVkaWENCj4gPj4+ IHBhZ2UgYnV0IHRoZXkgYXJlIGJyb2tlbi4gU2FtZSBnb2VzIGZvciB0aGUgSUVDIHZlcnNpb24g d2hpY2ggaXMgSUVDDQo+ID4+PiA2MjczNCwgYnV0IGlmIHlvdSBoYXZlIGFjY2VzcyB0byB0aGUg SUVDIHRoZW4gdGhlIGN1cnJlbnQgd29yayBpcw0KPiA+Pj4gaGVyZQ0KPiA+Pj4gaHR0cDovL3d3 dy5pZWMuY2gvY2dpLWJpbi9yZXN0cmljdGVkL2dldGZpbGUucGwvNjVDXzczNWVhX0NEVi5wZGY/ ZGkNCj4gPj4+IHI9IDY1QyZmb3JtYXQ9cGRmJnR5cGU9X0NEViZmaWxlPTczNWVhLnBkZg0KPiA+ Pj4NCj4gPj4+IFF1b3RlczoNCj4gPj4+DQo+ID4+PiAiVGhlIENvbnRyYWN0SUQgaXMgYXNzb2Np YXRlZCB3aXRoIGEgcGFydGljdWxhciBELXJvdXRlLiBUaGlzIG1heSBiZQ0KPiA+Pj4gdXNlZA0K PiA+PiB3aGVuIGEgcGFydGljdWxhciBncmFwaCBvciBzb3VyY2UgRC1yb3V0ZSBpcyBpbnRlbmRl ZCB0byBwcm92aWRlIGENCj4gPj4gZGVmaW5lZCBsZXZlbCBvZiBzZXJ2aWNlIg0KPiA+Pj4gIkZs b3dMYWJlbDogVGhlIGxvd2VyIG9yZGVyIDE2IGJpdHMgb2YgdGhlIEZsb3dMYWJlbCBzaGFsbCBi ZSBzZXQgdG8NCj4gPj4gQ29udHJhY3RJRC4gVGhlIGhpZ2hlciBvcmRlciA0IGJpdHMgc2hhbGwg YmUgYWxsIHplcm9zLiBUaGlzIGZpZWxkDQo+ID4+IHNoYWxsIG9ubHkgYmUgcHJlc2VudCBpZiBv Y3RldHMgMyB0aHJvdWdoIDUgYXJlIHByZXNlbnQsIGFzIGluZGljYXRlZA0KPiA+PiBieSBMT1dQ QU5fSVBIQyBlbmNvZGluZy4iDQo+ID4+PiBOb3RlIHRoYXQgdGhlIDZUaVNDSCBhcmNoaXRlY3R1 cmUgZWNob2VzIHRoaXMgZGVzaWduLCBhbmQgYSBkLXJvdXRlDQo+ID4+PiBpcyB2ZXJ5DQo+ID4+ IHNpbWlsYXIgdG8gYSA2VGlTQ0ggdHJhY2suDQo+ID4+PiBGb3IgdGhlIHNha2Ugb2YgaGlzdG9y eSBhbmQgdG8gbXkgYmVzdCBrbm93bGVkZ2UsIElTQTEwMC4xMWEgd2FzIHRoZQ0KPiA+Pj4gZmly c3QNCj4gPj4gaW5kdXN0cmlhbCBzdGFuZGFyZCB0byBhZG9wdCBJUHY2IGZvciBwcm9jZXNzIGNv bnRyb2wgYXBwbGljYXRpb25zDQo+ID4+IChjb250cm9sIGxvb3BzIGFuZCBtb25pdG9yaW5nKS4N Cj4gPj4+IEl0IGlzIGVmZmVjdGl2ZWx5IGVuYWJsaW5nIElQIGluIHRoZSBjb250cm9sIG5ldHdv cmssIHdoaWNoIGlzIGFuDQo+ID4+PiBoaXN0b3JpY2FsDQo+ID4+IHN0ZXAgdG93YXJkIHRoZSBJ VC9PVCBjb252ZXJnZW5jZSwgdGhhdCBpcyB0aGUgSW5kdXN0cmlhbCBlcXVpdmFsZW50DQo+ID4+ IG9mIHZvaWNlIGFuZCB2aWRlbyBjb252ZXJnZW5jZSBvdmVyIElQLg0KPiA+Pj4gQW5kIGFsc28g dG8gbXkgYmVzdCBrbm93bGVkZ2UgYW5kIGNvbmZvcm1pbmcgUkZDIDM2OTcsIElTQTEwMC4xMWEN Cj4gPj4+IGRvZXMNCj4gPj4gbm90IG11dGUgdGhlIEZsb3cgTGFiZWwgaW5zaWRlIHRoZSBuZXR3 b3JrLCBhcyBNaWNoYWVsIHBvaW50cyBvdXQuDQo+ID4+IE9ubHkgd2hlbiB0aGUgYWRkaXRpb25h bCBiYWNrYm9uZSBSb3V0ZXIgZnVuY3Rpb25hbGl0eSBpcyBkZWZpbmVkDQo+ID4+IGRvZXMgdGhl IHByb2JsZW0gb2YgcmV3cml0aW5nIGNvbWUgaW50byBwbGF5IGF0IHRoZSBCYWNrYm9uZSBSb3V0 ZXINCj4gPj4gKHNhbWUgcG9zaXRpb24gYXMgUlBMIHJvb3QpLiBGb3IgYWxsIEkga25vdyB0aGlz IHdvcmsgaXMgdGFraW5nIHBsYWNlDQo+ID4+IGF0IHRoZSBXaXJlbGVzcyBDb21wbGlhbmNlIElu c3RpdHV0ZSwgV0NJLCBidXQgSSBkbyBub3QgaGF2ZSB0aGUgbGF0ZXN0Lg0KPiA+Pj4gQ2hlZXJz LA0KPiA+Pj4NCj4gPj4+IFBhc2NhbA0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJy aWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gPj4+PiBTZW50OiBzYW1lZGkgMTYgYW/Du3Qg MjAxNCAwMzoxMw0KPiA+Pj4+IFRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQo+ID4+Pj4g Q2M6IFBoaWxpcCBMZXZpczsgUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29y a3M7IEluZXMNCj4gPj4+PiBSb2JsZXM7IDZtYW4gV0c7IDZsb0BpZXRmLm9yZyBXRw0KPiA+Pj4+ IFN1YmplY3Q6IFJlOiBbUm9sbF0gWzZsb10gV0dMQyBmb3INCj4gPj4+PiBkcmFmdC10aHViZXJ0 LTZtYW4tZmxvdy1sYWJlbC1mb3ItcnBsLTAzDQo+ID4+Pj4NCj4gPj4+PiBPbiAxNS8wOC8yMDE0 IDIwOjUxLCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPiA+Pj4+PiBIZWxsbyBC cmlhbg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIGRvIG5vdCB0aGluayB0aGF0IElTQTEwMDExLmEgdmlv bGF0ZXMgUkZDIDM2OTcuIFdoYXQgZXhhY3RseQ0KPiA+Pj4+PiBtYWRlIHlvdQ0KPiA+Pj4+IGJl bGlldmUgc28/DQo+ID4+Pj4NCj4gPj4+PiBJIHdhcyBvdmVyLWludGVycHJldGluZyB3aGF0IHlv dSB3cm90ZSwgSSBndWVzcy4gSXQncyB0cnVlIHRoYXQNCj4gPj4+PiAzNjk3IHdhcyByYXRoZXIg dmFndWUgYWJvdXQgd2hhdCBpdCBjYWxsZWQgImZsb3cgc3RhdGUNCj4gPj4+PiBlc3RhYmxpc2ht ZW50IG1ldGhvZHMiIGFuZCBwZXJtaXR0ZWQgYm90aCBzZXF1ZW50aWFsIGFuZA0KPiA+Pj4+IHBz ZXVkby1yYW5kb20gZmxvdyBsYWJlbCB2YWx1ZXMuIElzIHRoZSBJU0ExMDAxMS5hIG9uIGxpbmUN Cj4gc29tZXdoZXJlPw0KPiA+Pj4+DQo+ID4+Pj4+IEZvciBhbGwgSSBrbm93IElTQTEwMCBkb2Vz IGV2ZXJ5dGhpbmcgYnkgdGhlIGJvb2suIE5vdGUgdGhhdA0KPiA+Pj4+PiBJU0ExMDAgZG9lcw0K PiA+Pj4+IG5vdCB1cGRhdGUgYSBub24gemVybyBGTCBvbiB0aGUgZmx5IHNpbmNlIGl0IGlzIG5v dCBzZXQgYnkgYSBzb3VyY2UNCj4gPj4+PiBvdXRzaWRlIHRoZSBMTE4gaWYgdGhhdCBpcyB5b3Vy IGNvbmNlcm4uDQo+ID4+Pj4+IE9UT0ggSXQgbWF5IHZpb2xhdGUgUkZDIDY0MzcgaW4gdGhhdCB0 aGUgZmxvdyBpcyBub3QgYSByYW5kb20gYnV0DQo+ID4+Pj4+IGEgdmFsdWUNCj4gPj4+PiBhdHRy aWJ1dGVkIGJ5IGEgUENFIGNhbGxlZCBzeXN0ZW0gbWFuYWdlciAoYWxvbmcgcnVsZXMgaW4gc2Vj dGlvbiA0KS4NCj4gPj4+PiBBcyB0aGluZ3Mgc3RhbmQsIHdlJ2QgY2VydGFpbmx5IHdhbnQgdGhl IGJhY2tib25lIHJvdXRlciBhdCBMTE4NCj4gPj4+PiBlZ3Jlc3MgdG8gcmV3cml0ZSB0aGUgRkwg aW4gcGFja2V0cyB0b3dhcmRzIHRoZSBJbnRlcm5ldCB3aXRoIGENCj4gPj4+PiByYW5kb21pemVk IHBlciBmbG93IHZhbHVlLg0KPiA+Pj4+PiBJdCB3aWxsIHZpb2xhdGUgUkZDIDY0MzcgYmVjYXVz ZSBpZiB0aGUgZmxvdyBsYWJlbCBpcyBzZXQgYnkgYQ0KPiA+Pj4+PiByb3V0ZXIgaW4gdGhlDQo+ ID4+Pj4gSW50ZXJuZXQgLSBvciBhbiB1cGRhdGVkIHNvdXJjZSB0aGF0IGNvbXBsaWVzIHRvIDY0 MzctLCB0aGUNCj4gPj4+PiBiYWNrYm9uZSByb3V0ZXIgYXQgTExOIEluZ3Jlc3Mgd2lsbCByZXdy aXRlIGl0Lg0KPiA+Pj4+PiBCb3RoIGlzc3VlcyBhcmUgYWRkcmVzc2VkIGluIG15IGRyYWZ0IGZv ciBhIFJQTCBkb21haW4uIEFuIFJGQw0KPiA+Pj4+PiB3aWxsIGFsc28NCj4gPj4+PiBoaW50IGEg cmV2aXNpb24gb2YgdGhlIGJhY2tib25lIHJvdXRlciB0aGF0IGl0IHNob3VsZCByZXdyaXRlIHRo ZQ0KPiA+Pj4+IEZMIG9uIG91dGdvaW5nIHBhY2tldHMuDQo+ID4+Pj4+IFdoYXQgZG8geW91IHRo aW5rPw0KPiA+Pj4+IEkgdGhpbmsgdGhhdCBQaGlsJ3MgbGFzdCBtZXNzYWdlIGZyYW1lcyB0aGUg cXVlc3Rpb24gdG8gNm1hbg0KPiA+Pj4+IGNvcnJlY3RseSwgc28gSSB3aWxsIHJlc3BvbmQgdG8g aGltLi4uDQo+ID4+Pj4NCj4gPj4+PiBSZWdhcmRzDQo+ID4+Pj4gICAgIEJyaWFuDQo+ID4+Pj4+ IFBhc2NhbA0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gTGUgMTQgYW/Du3QgMjAxNCDDoCAyMjoxOCwgIkJy aWFuIEUgQ2FycGVudGVyIg0KPiA+Pj4+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IGEg w6ljcml0IDoNCj4gPj4+Pj4+PiBPbiAxNC8wOC8yMDE0IDIyOjI4LCBQYXNjYWwgVGh1YmVydCAo cHRodWJlcnQpIHdyb3RlOg0KPiA+Pj4+Pj4+IFdlIGNhbiBsaXZlIHdpdGggdGhpcyBCcmlhbiwN Cj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IGJ1dCB0aGVuIEkgY2FuIHdlIGFkZCBhdCBsZWFzdCBhbiBJ U0ExMDAuMTFhIG5ldHdvcms/IElTQTEwMC4xMWENCj4gPj4+Pj4+PiB3YXMNCj4gPj4+PiBkZXNp Z25lZCBpbiAyMDA3LzgsIGFkb3B0ZWQgSVB2NiBhbmQgNkxvV1BBTiwgYW5kIHVzZXMgdGhlIElQ djYNCj4gPj4+PiBmbG93IGxhYmVsIHRvIGluZGljYXRlIHdoaWNoIGZsb3cgYSBwYWNrZXQgYmVs b25ncyB0by4NCj4gPj4+Pj4+IEkgaGF2ZSBubyBpZGVhIHdoYXQgSVNBMTAwLjExYSBpcyBvciB3 aGljaCBvcmdhbmlzYXRpb24gZGV2ZWxvcGVkDQo+ID4+Pj4+PiBpdCwgYnV0IGl0IHNvdW5kcyBs aWtlIGEgdmlvbGF0aW9uIG9mIHRoZSBmbG93IGxhYmVsIHN0YW5kYXJkIGF0DQo+ID4+Pj4+PiB0 aGF0IHRpbWUgKFJGQyAzNjk3KS4gSWYgSSdkIGtub3duIGFib3V0IGl0LCB3ZSB3b3VsZCBwcm9i YWJseQ0KPiA+Pj4+Pj4gaGF2ZSBpbmNsdWRlZCBpdCBpbiB0aGUgbWVuYWdlcmllIG9mIFJGQyA2 Mjk0Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoZXJlJ3Mgbm90IG11Y2ggdGhlIElFVEYgY2FuIGRv IGFib3V0IG90aGVyIG9yZ2FuaXNhdGlvbnMgdGhhdA0KPiA+Pj4+Pj4gbWlzdXNlIG91ciBzdGFu ZGFyZHMsIGFsdGhvdWdoIGluZGVlZCB3ZSBzb21ldGltZXMgbmVlZCB0bw0KPiA+PiBkb2N1bWVu dA0KPiA+Pj4+Pj4gc3VjaCBjYXNlcy4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgIEJyaWFuDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEluIG1vcmUgZGV0YWlscywgZGV2aWNlcyBhcmUgcHJv dmlzaW9uZWQgd2l0aCBwZXItZmxvdyBiZWhhdmlvcg0KPiA+Pj4+Pj4gKGluY2x1ZGluZw0KPiA+ Pj4+IHJvdXRpbmcpIGFuZCBzZXR0aW5ncyBpbiB3aGF0IGlzIGNhbGxlZCBhIGNvbnRyYWN0Lg0K PiA+Pj4+Pj4gVGhlIGNvbnRyYWN0SUQgaXMgY2FycmllZCBpbiB0aGUgSVB2NiBmbG93IGxhYmVs Lg0KPiA+Pj4+Pj4+IElmIHNvIHNob3VsZCB3ZSBuYW1lIElTQTEwMCBzcGVjaWZpY2FsbHkgb3Ig dXNlIGEgbW9yZSB2YWd1ZQ0KPiA+Pj4+Pj4+IGRlc2NyaXB0aW9uDQo+ID4+Pj4gbGlrZSBhICJS UEwgb3Igc2ltaWxhciBMTE4gZG9tYWluIg0KPiA+Pj4+Pj4+IFdlJ2xsIG5vdGUgdGhhdCByZXNl dHRpbmcgYW4gZmxvdyBsYWJlbCB0aGF0IGNvbWVzIGZyb20gdGhlDQo+ID4+Pj4+Pj4gSW50ZXJu ZXQgaXMgYSBnZW5lcmljIG5lZWQgaXMgdGhhdCBmbG93IGxhYmVsIHdhcyBzZXQgYWNjb3JkaW5n DQo+ID4+Pj4+Pj4gdG8gNjQzNywgY2Fubm90IGJlIHRydXN0ZWQgdG8gYmUgdW50ZW1wZXJlZCB3 aXRoLA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gQ2hlZXJzLA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4g UGFzY2FsDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4+PiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRQ0KPiA+Pj4+Pj4+PiBDYXJwZW50ZXINCj4gPj4+ Pj4+Pj4gU2VudDogbWVyY3JlZGkgMTMgYW/Du3QgMjAxNCAyMjo1Mw0KPiA+Pj4+Pj4+PiBUbzog UGhpbGlwIExldmlzDQo+ID4+Pj4+Pj4+IENjOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBM b3NzeSBuZXR3b3JrczsgSW5lcyBSb2JsZXM7DQo+ID4+Pj4+Pj4+IDZtYW4gV0c7IDZsb0BpZXRm Lm9yZyBXRw0KPiA+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW1JvbGxdIFs2bG9dIFdHTEMgZm9yDQo+ ID4+Pj4+Pj4+IGRyYWZ0LXRodWJlcnQtNm1hbi1mbG93LWxhYmVsLWZvci1ycGwtMDMNCj4gPj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4+IE9uIDE0LzA4LzIwMTQgMDc6MDcsIFBoaWxpcCBMZXZpcyB3cm90 ZToNCj4gPj4+Pj4+Pj4+IE9uIEF1ZyAxMywgMjAxNCwgYXQgOTo0OCBBTSwgUGFzY2FsIFRodWJl cnQgKHB0aHViZXJ0KQ0KPiA+Pj4+Pj4+PiA8cHRodWJlcnRAY2lzY28uY29tPiB3cm90ZToNCj4g Pj4+Pj4+Pj4+PiBJZiB0aGlzIGRyYWZ0IGlzIG5vdCBhZG9wdGVkLCB0aGUgZmxvdyBsYWJlbCBm cm9tIExMTiB3aWxsDQo+ID4+Pj4+Pj4+Pj4gcHJvYmFibHkgc3RheSBhbGwNCj4gPj4+Pj4+Pj4g emVyb2VzIGFzIGl0IGlzIHRvZGF5IGFuZCB0aGUgZ29hbCBvZiA2NDM3IHdpbGwgbm90IGJlIGFj aGlldmVkLg0KPiA+Pj4+Pj4+Pj4gUGFzY2FsLCBJJ20gdHJ5aW5nIHRvIHJlY29uY2lsZSB5b3Vy IGNsYWltIHRoYXQgdGhlIGdvYWwgb2YNCj4gPj4+Pj4+Pj4+IDY0MzcgaXMgdG8gYWxsb3cgZW5j bG9zZWQgbmV0d29ya3MgdG8gdXNlIHRoZSBmbG93IGxhYmVsIHdpdGgNCj4gPj4+Pj4+Pj4+IEJy aWFuJ3Mgc3RhdGVtZW50DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IEFjdHVhbGx5IHRoYXQn cyB3aHkgSSBkb24ndCB3YW50IHRvIHNlZSBhIGZvcm1hbCB1cGRhdGUgdG8NCj4gPj4+Pj4+Pj4+ PiA2NDM3LCBiZWNhdXNlIHRoZSBvbmx5IHJhdGlvbmFsIHVwZGF0ZSB3b3VsZCBiZSB0byBhbGxv dyBhbnkNCj4gPj4+Pj4+Pj4+PiBjbG9zZWQgZG9tYWluIHRvIGludmVudCBpdHMgb3duIHVzYWdl LiBXZSBoYWQgdGhhdCBhcmd1bWVudA0KPiA+Pj4+Pj4+Pj4+IGF0IGxlbmd0aCBkdXJpbmcgdGhl IGRldmVsb3BtZW50IG9mIDY0MzcsIGFuZCBkZWNpZGVkIGFnYWluc3QNCj4gaXQuDQo+ID4+Pj4+ Pj4+PiBQaGlsDQo+ID4+Pj4+Pj4+IFJpZ2h0LiBJJ20gZHJhd2luZyBhIHZlcnkgc3VidGxlIGxp bmUgYmV0d2VlbiAoYSkgc3RhdGluZyBhbg0KPiA+Pj4+Pj4+PiBleGNlcHRpb24gdG8gNjQzNyBm b3IgdGhpcyBwYXJ0aWN1bGFyIHVzYWdlIGFuZCAoYikgb3BlbmluZyB0aGUNCj4gPj4+Pj4+Pj4g ZG9vciB0byBvdGhlciB1c2FnZXMuIFNpbmNlIDZtYW4gY2xlYXJseSBkaWRuJ3Qgd2FudCAoYikg ZHVyaW5nDQo+ID4+Pj4+Pj4+IHRoZSBkZXZlbG9wbWVudCBvZg0KPiA+Pj4+Pj4+PiA2NDM3IEkg dGhpbmsgd2UgZG8gbmVlZCB0byBsaW1pdCBvdXJzZWx2ZXMgdG8gKGEpLg0KPiA+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+PiAgICBCcmlhbg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+ Pj4+Pj4gLS0NCj4gPj4+Pj4+Pj4gLS0NCj4gPj4+Pj4+Pj4gLSBJRVRGIElQdjYgd29ya2luZyBn cm91cCBtYWlsaW5nIGxpc3QgaXB2NkBpZXRmLm9yZw0KPiA+Pj4+Pj4+PiBBZG1pbmlzdHJhdGl2 ZQ0KPiA+Pj4+Pj4+PiBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHY2DQo+ID4+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+Pj4+PiAtLQ0KPiA+Pj4+Pj4+PiAt LQ0KPiA+Pj4+Pj4+PiAtDQo+ID4NCg0K From nobody Tue Aug 26 05:54: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 DCB8A1A6FCD for ; Tue, 26 Aug 2014 05:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.227 X-Spam-Level: ** X-Spam-Status: No, score=2.227 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 QOx08JASaaJb for ; Tue, 26 Aug 2014 05:54:54 -0700 (PDT) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110291A6FC7 for ; Tue, 26 Aug 2014 05:54:53 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube10.xs4all.net [194.109.20.208]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id s7QCsoOr011217; Tue, 26 Aug 2014 14:54:51 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 26 Aug 2014 14:54:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 26 Aug 2014 14:54:50 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <11473.1408628965@sandelman.ca> References: <11473.1408628965@sandelman.ca> Message-ID: <4e3baa11ac4e55c3968ec90705ed2e04@xs4all.nl> X-Sender: stokcons@xs4all.nl (ugspFs/vQrGU31LEnvWXQy+XmvyMIUiO) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/roll/OzcpY9-XBoSKU8VRmodR2D7NCMo Cc: Michael Richardson Subject: Re: [Roll] h-b applicability draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 12:54:56 -0000 Hi Michael, Original text of section 7.2 of applicability template (This section explains how that replaces a failed node takes on the dead nodes’ identity, or not. How are nodes retired. How are nodes removed if they are compromised) New suggested text: (This section explains how during operation of the network, (possibly compromised) nodes are removed, and how newly joining nodes get their initial trust anchors, and initial network keys. Differences between joining nodes to an operational network compared to bootstrapping a network are explained) Hope this helps. Peter Michael Richardson schreef op 2014-08-21 15:49: > peter van der Stok wrote: > > Attached the hopefully last version of the applicability > > draft. (ignoring AD > > and IESG comments) > > After a telco with Robert and Michael, the contents of section > 7.1 and > > 7.2 > > was adapted. > > There was some misunderstanding about meaning of incremental > deployment. > > I wonder if you can suggest some text to clarify the template? > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Aug 26 13:03:21 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6D71A0252; Tue, 26 Aug 2014 13:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xX7XKxzfcmVC; Tue, 26 Aug 2014 13:02:53 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5920B1A8769; Tue, 26 Aug 2014 13:02:44 -0700 (PDT) Received: from BLUPR07MB611.namprd07.prod.outlook.com (10.141.207.16) by BLUPR07MB610.namprd07.prod.outlook.com (10.141.207.15) with Microsoft SMTP Server (TLS) id 15.0.1015.17; Tue, 26 Aug 2014 20:02:29 +0000 Received: from BLUPR07MB611.namprd07.prod.outlook.com ([10.141.207.16]) by BLUPR07MB611.namprd07.prod.outlook.com ([10.141.207.16]) with mapi id 15.00.1015.017; Tue, 26 Aug 2014 20:02:28 +0000 From: Richard Kelsey To: Routing Over Low power and Lossy networks , "Brian E Carpenter" Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: Ac++CEw2ncG58gG1qkm9oMVdmX2ItgAdxngAAICihoAAOXaTGA== Date: Tue, 26 Aug 2014 20:02:28 +0000 Message-ID: <8ed59484d41d44649bcc5e1150a1daef@BLUPR07MB611.namprd07.prod.outlook.com> References: <53F8057C.9080904@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [173.48.207.178] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03152A99FF x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(377454003)(51704005)(189002)(66066001)(19580405001)(2656002)(99286002)(4396001)(19580395003)(83322001)(76176999)(80022001)(95666004)(81342001)(64706001)(21056001)(85852003)(87936001)(50986999)(99396002)(90102001)(106356001)(105586002)(31966008)(33646002)(79102001)(230783001)(20776003)(107046002)(76482001)(81542001)(74662001)(74502001)(83072002)(85306004)(74316001)(46102001)(92566001)(76576001)(108616004)(86362001)(101416001)(77982001)(54356999)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR07MB610; H:BLUPR07MB611.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: silabs.com Archived-At: http://mailarchive.ietf.org/arch/msg/roll/yknps_mYWFTraH5FsnHDuBHajnQ Cc: Michael Richardson , Ines Robles , 6man WG , "6lo@ietf.org WG" <6lo@ietf.org> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:03:03 -0000 > From: Pascal Thubert (pthubert) [pthubert@cisco.com] > Sent: Monday, August 25, 2014 12:30 PM >=20 > I understand, Brian: > > It makes sense to propose a generic rule and try it on the real > world. But it is not surprising that such a bold approach fails to > be universal when confronted to the real world. To be very clear on > the need for 6MAN to take our responsibilities, I added text to > clarify that 6437 as of today is dramatically counterproductive for > the development of IPv6 in LLNs. Pascal, Hold on a second. First of all, not everyone doing IPv6 in LLNs is using RPL. Second of all, not everyone using RPL in LLNs is particularly hindered by the overhead of using RFC 6553. And finally, Carsten's suggested 6lo encoding of the RPL Option arguably has better properties than using the flow label and is definitely not "dramatically" worse. Personally, I think using the flow label in this way is a very bad idea. The games that are played within an LLN to make IPv6 work there need to be invisible to the rest of the Internet. Universal rules are what its all about. -Richard Kelsey From nobody Tue Aug 26 13:19:04 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1505E1A87E3; Tue, 26 Aug 2014 13:18:59 -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 uZo-Lw_ci-Xj; Tue, 26 Aug 2014 13:18:57 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3AC1A87E1; Tue, 26 Aug 2014 13:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1894; q=dns/txt; s=iport; t=1409084337; x=1410293937; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gShpDtW+2BWsJIdJ2Xn2dMstXfHQKA/nzEok5ixEgT0=; b=fo+5xdJzrKs2Gll+PTr1v2t0epzOwROew966LJKBF69E9iN/44OIXmM2 XfpNK4m4rW4vz56IrVReYFqirkxFD1A8KNTalkxVIa/RBLqbyXAj23Si0 RUKvpOclmWZGnDlwCRpzct2cIbFsUraJIm66/0lPt1t3+UpYrvh7pc7R/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAM7q/FOtJV2Z/2dsb2JhbABbgw1TV8xTCodMAYEXFneEAwEBAQMBAQEBawsQAgEIFQEwJwslAgQOBYg6CA2/QhMEjxkzB4MvgR0FimyGQYsnlRSDXmyCTwEBAQ X-IronPort-AV: E=Sophos;i="5.04,406,1406592000"; d="scan'208";a="350454121" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 26 Aug 2014 20:18:57 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7QKIuoa026066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 20:18:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.236]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 15:18:56 -0500 From: "Pascal Thubert (pthubert)" To: Richard Kelsey Thread-Topic: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03 Thread-Index: AQHPwWjiidypJfPYN0WvEDAQ9LxuP5vjUxoi Date: Tue, 26 Aug 2014 20:18:55 +0000 Message-ID: <93C4A100-0DEB-4C3F-99CA-D68298DA5F53@cisco.com> References: <53F8057C.9080904@gmail.com>, , <8ed59484d41d44649bcc5e1150a1daef@BLUPR07MB611.namprd07.prod.outlook.com> In-Reply-To: <8ed59484d41d44649bcc5e1150a1daef@BLUPR07MB611.namprd07.prod.outlook.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/roll/aD1rH10KRbHaQlWnIMgpWos3jFc Cc: 6man WG , Michael Richardson , Routing Over Low power and Lossy networks , Ines Robles , "6lo@ietf.org WG" <6lo@ietf.org>, Brian E Carpenter Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:18:59 -0000 Richard: Maybe you should read the draft. I removed all references to my proposal of how to use the Flow label for RP= L. What the 6MAN draft is now asking is only the right to manipulate a flow la= bel in the LLN, RPL or not RPL, be it only to reset it to zero so as to eli= de it. The Idea to propose a 6lowpan compression is actually from Laurent and I wa= s the first on the ML to support it. Cheers, Pascal Le 26 ao=FBt 2014 =E0 22:04, "Richard Kelsey" a= =E9crit : >> From: Pascal Thubert (pthubert) [pthubert@cisco.com] >> Sent: Monday, August 25, 2014 12:30 PM >>=20 >> I understand, Brian: >>=20 >> It makes sense to propose a generic rule and try it on the real >> world. But it is not surprising that such a bold approach fails to >> be universal when confronted to the real world. To be very clear on >> the need for 6MAN to take our responsibilities, I added text to >> clarify that 6437 as of today is dramatically counterproductive for >> the development of IPv6 in LLNs. >=20 > Pascal, >=20 > Hold on a second. First of all, not everyone doing IPv6 in LLNs > is using RPL. Second of all, not everyone using RPL in LLNs is > particularly hindered by the overhead of using RFC 6553. And finally, > Carsten's suggested 6lo encoding of the RPL Option arguably has > better properties than using the flow label and is definitely not > "dramatically" worse. >=20 > Personally, I think using the flow label in this way is a very bad > idea. The games that are played within an LLN to make IPv6 work there > need to be invisible to the rest of the Internet. Universal rules > are what its all about. >=20 > -Richard Kelsey >=20 >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo