From mariainesrobles@googlemail.com Wed Jan 1 01:36: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 E2C001AE4D7 for ; Wed, 1 Jan 2014 01:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 3cI3fqmJuSOG for ; Wed, 1 Jan 2014 01:36:41 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 521CA1AE1D4 for ; Wed, 1 Jan 2014 01:36:41 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so11650501wgh.29 for ; Wed, 01 Jan 2014 01:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=pfSK0Vd/NGFf5BBLV8B5aParbwp15JtV0zHhaoMZiUA=; b=aUODHZz0ivsoDQKw33i24JVNXewkU2JPCGsnMuCbcu4HC86zzvW5WuXLOnitT1Lt3R SCPFFZKAYp6/x97k4zcCaEDNNc1buiYWO0R5yJFjd1t+PVtWjKKXggPVsdr6ei5lgUFz wDaLkqmiT9WeTQoX57LICH74dcBArLuXsxyzAR6evVBS+dhqDt39BwrsQ6DFUVxnkDM9 mzXBEhrZnvWIBA6sHFWyoSC9dwk6mnlL3pG2GG547IjtcCCSkbx/SNtJ1l3leldbDr4N 3V/pbidNHIdFtShBm7fNfCN4xaYZevyTCgMtOQBPv+N7/5krawt8m8C+hK6s60QFJqte LlVw== MIME-Version: 1.0 X-Received: by 10.180.13.74 with SMTP id f10mr50431970wic.34.1388568994309; Wed, 01 Jan 2014 01:36:34 -0800 (PST) Received: by 10.216.44.144 with HTTP; Wed, 1 Jan 2014 01:36:34 -0800 (PST) Date: Wed, 1 Jan 2014 10:36:34 +0100 Message-ID: From: Ines Robles To: zhanglan_uestc@163.com, fenggang@uestc.edu.cn, blueqs@uestc.edu.cn Content-Type: multipart/alternative; boundary=001a11c24a94a6ec5c04eee5699b Cc: Michael Richardson , roll@ietf.org Subject: [Roll] draft-zhang-roll-rpl-intrusion-defence-00 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, 01 Jan 2014 09:36:43 -0000 --001a11c24a94a6ec5c04eee5699b Content-Type: text/plain; charset=ISO-8859-1 Hello Lan Zhang, Gang Feng and Shuang Qin Thank you for this draft, https://datatracker.ietf.org/doc/draft-zhang-roll-rpl-intrusion-defence/, which was posted on November 2013: -------------------------------------------------------------------------------------------------------------------------- Abstract: This document specifies intrusion detection systems (IDSs) as the second line of defence, to secure the Routing Protocol for Low-power and Lossy Networks (RPL). ---------------------------------------------------------------------------------------------------------------------------- We would like to know please, what the author's intend for this document? How it would fit into the charter? Do we need re-chartering of ROLL? I think the draft should mention draft-ietf-roll-security-threats-06. I found interesting the design of IDS for ETX intrusion detection. Do you know if there is some implementations of it? Thank you very much in advance, Kind Regards, Ines Robles --001a11c24a94a6ec5c04eee5699b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello Lan Zhang, Gang Feng and Shuang Qin

Tha= nk you for this draft, https://datatracke= r.ietf.org/doc/draft-zhang-roll-rpl-intrusion-defence/, which was posted on November= 2013:

---= ---------------------------------------------------------------------------= --------------------------------------------

Abstract:
=A0=A0=A0=A0=A0=A0This document specifies intrusion detection systems (IDS= s) as the
=A0=A0=A0=A0=A0=A0second line of defence, to secu= re the Routing Protocol for Low-power
=A0=A0=A0=A0=A0=A0and= Lossy Networks (RPL).

--------------------= ---------------------------------------------------------------------------= -----------------------------

We = would like to know please, what the author= 9;s intend for this document? How it would fit into the charter? Do = we need re-chartering of ROLL?

I think the draft should mention draft-ietf-roll-security-threats-06. I=20 found interesting the design of IDS for ETX intrusion detection. Do you know if there is some implementations of it?

Thank you very muc= h in advance,

Kind Regards,
Ines Ro= bles
--001a11c24a94a6ec5c04eee5699b-- From mcr@sandelman.ca Thu Jan 2 14:39:53 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0C31ACCE8 for ; Thu, 2 Jan 2014 14:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.928 X-Spam-Level: ** X-Spam-Status: No, score=2.928 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_MIME_NO_TEXT=0.01, 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 ewVKYiIW-eCz for ; Thu, 2 Jan 2014 14:39:50 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id C5F8B1ACC8B for ; Thu, 2 Jan 2014 14:39:50 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 946502004F for ; Thu, 2 Jan 2014 18:54:42 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1B8F564647; Thu, 2 Jan 2014 17:39:41 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 034C463AD7 for ; Thu, 2 Jan 2014 17:39:41 -0500 (EST) 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 Subject: [Roll] multiple PIO payloads in a single DIO 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, 02 Jan 2014 22:39:53 -0000 --=-=-= As far as I can see, there is nothing in RFC6550 to forbid multiple PIO options in a DIO, and therefore in a single DODAG. Other than renumbering, it seems that most use cases where there could be multiple prefixes present in an LLN will use multiple DODAGs. If renumbering is the only use for mutiple PIO options, then it seems that supporting at most 2 or 3 prefixes per DODAG seems reasonable. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUsXqrIqHRg3pndX9AQIFwAQAyHZOn418JILVv9WYd89b9iFe+TFi163S gs6A9GGPSJfqFoL2ZDtzos5Qjp3wyafM6QUYfWIFAWxkvf7tfAXYawYiErxZTDBU +I4SZXJ3wimHa1gV643azp7Kt8akiXRCIeGvKgk//9I0pMbIs8McsqrWivn0DuU4 1nQlSGBSsXs= =+2OB -----END PGP SIGNATURE----- --=-=-=-- From mariainesrobles@googlemail.com Sun Jan 5 06:31: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 93FC21AE939 for ; Sun, 5 Jan 2014 06:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.773 X-Spam-Level: *** X-Spam-Status: No, score=3.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, MIME_CHARSET_FARAWAY=2.45, 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 jmjPaPP6aQXD for ; Sun, 5 Jan 2014 06:31:21 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C3C9F1AE94C for ; Sun, 5 Jan 2014 06:31:20 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id y10so14703404wgg.0 for ; Sun, 05 Jan 2014 06:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S+Q+6AxzPccVHqDnEmkVL+LdSkrarNN9CQqqxg3oo1k=; b=yO1Nx72fCVUPzxtC30pGPLHfPM0KrQosdKQZBCtbomfTnnycmxZwRny2CdhhQ7AOEw 2Q0UkZePspsaO9zTN3OlXCzHVmkitrmNWOsIGAP83KKTU/iZz4NcTnJtXTi004UbbBM3 KB9si4e+atEEUtUOJFOIVVNe8+OYmCp5s+hVndyLy9U3I1hbIzXXfA6pS8Ti1xPFZdEM TJthaInBocGLffuFUHXkzSps4TIkWZlTv1OymOu+JKpBiEwzhGAzp7rUz1GyZuzPayXJ bOJIk+X5CY3+zfL7tHlh+AY0+5RaG8iNVOcZJuT6q7w3ys7cuxM1KlvT9i3N8loOuiRT 3g9w== MIME-Version: 1.0 X-Received: by 10.180.95.162 with SMTP id dl2mr8956100wib.17.1388932272268; Sun, 05 Jan 2014 06:31:12 -0800 (PST) Received: by 10.216.44.144 with HTTP; Sun, 5 Jan 2014 06:31:12 -0800 (PST) In-Reply-To: <201401030929590784939@uestc.edu.cn> References: <201401030929590784939@uestc.edu.cn> Date: Sun, 5 Jan 2014 12:31:12 -0200 Message-ID: From: Ines Robles To: Feng Gang Content-Type: multipart/alternative; boundary=f46d0444e983b4ac1404ef39fe9d Cc: Michael Richardson , roll , blueqs , zhanglan_uestc Subject: Re: [Roll] draft-zhang-roll-rpl-intrusion-defence-00 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, 05 Jan 2014 14:31:23 -0000 --f46d0444e983b4ac1404ef39fe9d Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hello, Thanks for your comments. My comments below, 2014/1/2 Feng Gang > > Thank you for your response. We are not quite sure if we can understand > your questions well. > I apologize if I was not clear, the idea was to ask how this draft is aligned with roll charter. For example in the charter a work item is: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. --> To satisfy this item, the RFC 6551 was produced. In case that it is not aligned with the charter, we should re-chartering. > > Our main purpose of submitting this document is to seek possibility that > our proposal is meaningful in ROLL. We wonder if the document can be > "standard track" or "informational". > Maybe experimental [BCP9 ], anyway I=A1=AFm going to discuss with Michael about that. > > We have studied draft-ietf-roll-security-threats-06 and will mention it i= n > the next update. We have implemented our design of IDS to detect ETX > intrusion in Contiki OS, Sky platform and validated its effectiveness. > That is great, do you have some academic papers about it. Thank you in advance, Kind Regards, Ines Robles > > Kind regards, > > > Lan Zhang, Gang Feng and Shuang Qin > > > > > > 2014-01-03 > ------------------------------ > Feng Gang > ------------------------------ > *=B7=A2=BC=FE=C8=CB=A3=BA* Ines Robles > *=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA* 2014-01-01 17:37:16 > *=CA=D5=BC=FE=C8=CB=A3=BA* zhanglan_uestc; fenggang; blueqs > *=B3=AD=CB=CD=A3=BA* Michael Richardson; roll > *=D6=F7=CC=E2=A3=BA* draft-zhang-roll-rpl-intrusion-defence-00 > > Hello Lan Zhang, Gang Feng and Shuang Qin > > Thank you for this draft, > https://datatracker.ietf.org/doc/draft-zhang-roll-rpl-intrusion-defence/, > which was posted on November 2013: > > > -------------------------------------------------------------------------= ------------------------------------------------- > > Abstract: > This document specifies intrusion detection systems (IDSs) as the > second line of defence, to secure the Routing Protocol for Low-powe= r > and Lossy Networks (RPL). > > > -------------------------------------------------------------------------= --------------------------------------------------- > > We would like to know please, what the author's intend for this document? > How it would fit into the charter? Do we need re-chartering of ROLL? > > I think the draft should mention draft-ietf-roll-security-threats-06. I > found interesting the design of IDS for ETX intrusion detection. Do you > know if there is some implementations of it? > > Thank you very much in advance, > Kind Regards, > > Ines Robles > --f46d0444e983b4ac1404ef39fe9d Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hello,

Thanks for your comments.

My commen= ts below,

2014/1/2 Feng Gang <fenggang@uestc.edu.cn>
 
Thank=20 you for your response. We are not quite sure if we can understand your ques= tions=20 well.
I apologize i= f I was not clear, the idea was to ask how this draft is aligned with roll = charter. For example in the charter a work item is:

- Specification of routing metrics used in path calculation. This
includes static and dynamic link/node attributes required for routing in<= br> LLNs. --> To satisfy this item, the RFC 6551 was produced.

In case that it is not aligned with the charter, we should re-charte= ring.
<= /font> 
Our=20 main purpose of submitting this document is to seek possibility that o= ur=20 proposal is meaningful in ROLL. We=20 wonder if the document can be "standard track" or=20 "informational".

Maybe experimental [BCP9], anyway I’m going to discuss with= Michael about that.
<= /font> 
We=20 have studied draft-ietf-roll-security-threats-06 and will mention it i= n the=20 next update. We=20 have implemented our design of IDS to detect ETX intrusion in Contiki = OS,=20 Sky platform and validated its effectiveness.
That is great,  do you have some acad= emic papers about it.

Thank you in advance,

=
Kind Regards,

Ines Robles
<= /font> 
Kind=20 regards,
<= /font> 
<= /font> 
Lan=20 Zhang, Gang Feng and Shuang Qin 
<= /font> 
<= /font> 
<= /font> 
 
 
2014-01-03
Feng Gang=20
=B7=A2=BC=FE=C8=CB=A3=BA Ines Robles
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2014-01-0= 1  17:37:16=20
=CA=D5=BC=FE=C8=CB=A3=BA zhanglan_uestc;= fenggang;=20 blueqs
=B3=AD=CB=CD=A3=BA Michael Richardson; r= oll=20
=D6=F7=CC=E2=A3=BA=20 draft-zhang-roll-rpl-intrusion-defence-00
<= div class=3D"h5">

Hello=20 Lan Zhang, Gang Feng and Shuang Qin

Thank=20 you for this draft, https://datatracker.ietf.org/doc/dra= ft-zhang-roll-rpl-intrusion-defence/,=20 which was posted on November 2013:

-------------------------------------= ---------------------------------------------------------------------------= ----------

Abstract:=20
      This document specifies intrusion= =20 detection systems (IDSs) as the
      sec= ond=20 line of defence, to secure the Routing Protocol for Low-power=20
      and Lossy Networks (RPL).

-------------------------------------= ---------------------------------------------------------------------------= ------------

We=20 would like to know please, what the author's=20 intend for this document? How it would fit into the charter? Do we n= eed=20 re-chartering of ROLL?

I=20 think the draft should mention draft-ietf-roll-security-threats-06. I found= =20 interesting the design of IDS for ETX intrusion detection. Do you know if t= here=20 is some implementations of it?

Thank=20 you very much in advance,

Kind=20 Regards,

Ines=20 Robles

--f46d0444e983b4ac1404ef39fe9d-- From mariainesrobles@googlemail.com Mon Jan 6 10:10: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 8BA7D1AE058 for ; Mon, 6 Jan 2014 10:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWtPFTgkCIoT for ; Mon, 6 Jan 2014 10:10:54 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id EE7B61AE068 for ; Mon, 6 Jan 2014 10:10:53 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id z2so3148072wiv.12 for ; Mon, 06 Jan 2014 10:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=wRJLzLar8/zKvsmOJqDRztFiabL0P2uXFZMTvNQuaSU=; b=bBPuvtFThHvYPsGsdVBpmgU7Z638edwXUABqy/L3WhsMBQS6kIqVqkSpxXOCRvS5Eb 4a3MkMQAzbhgXYHZ/y18oB7M5bbnbVrcysECV1VEIPOLejQd6Nq3n+3m8VUpOsgoOHew 9zp0YtBMV9F79pCkBcSJt2y1M3TDfKYbxfYb8qntfIWvFnuFGW8YQwmOU0Xnl9jq1vtu F+4fe2ffEe1kbZRBi3G8zHUpJmi37GoHC/PjcQyuDYECjqg2TMmCdIb3yONKF0/0RM6K 1MunEqjFIU8tF1NYQVHnB1xM7o63+eewDxc+1BoviflQYpDp+dNi4/vKTpCusVC1blbh JRXQ== MIME-Version: 1.0 X-Received: by 10.194.222.38 with SMTP id qj6mr2502974wjc.66.1389031844768; Mon, 06 Jan 2014 10:10:44 -0800 (PST) Received: by 10.216.44.144 with HTTP; Mon, 6 Jan 2014 10:10:44 -0800 (PST) Date: Mon, 6 Jan 2014 16:10:44 -0200 Message-ID: From: Ines Robles To: jt369@drexel.edu, jau@coe.drexel.edu, c.chauvenet@watteco.com, JP Vasseur Content-Type: multipart/alternative; boundary=001a11c1b73ab0720704ef512d81 Cc: Michael Richardson , roll Subject: [Roll] Intend for draft-tripathi-roll-reactive-applicability 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, 06 Jan 2014 18:10:55 -0000 --001a11c1b73ab0720704ef512d81 Content-Type: text/plain; charset=ISO-8859-1 *Hi,Thanks for this draft, https://ietf.org/doc/draft-tripathi-roll-reactive-applicability/ AbstractThis document describes serious issues and shortcomings regarding the use of reactive routing protocols in low power and lossy networks(LLNs). Routing requirements for various LLN deployments are discussed in order to judge how reactive routing may or may notadhere to the necessary criteria.We would like to know please, how is the intend for this document? how this draft would be aligned with roll charter?, should we re-chartering?* *Thank you in advance,* Ines Robles --001a11c1b73ab0720704ef512d81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

=

Thanks for this draft= , https://ietf.org/doc/draft-tripathi-roll-rea= ctive-applicability/


Abstract<= /span>

=

= This docum= ent describes serious issues and shortcomings regarding the use of reactive= routing protocols in low power and lossy networks(LLNs). Routing requireme= nts for various LLN deployments are discussed in order to judge how reactiv= e routing may or may notadhere to the necessary criteria.


We would = like to know please, =A0how is the intend for this document? how this dra= ft would be aligned with roll charter?, should we re-chartering?=

Thank you in advance,

Ines Robles
--001a11c1b73ab0720704ef512d81-- From jvasseur@cisco.com Mon Jan 6 10:24: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 75D311AE15A for ; Mon, 6 Jan 2014 10:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 ryUo7V4NKaoz for ; Mon, 6 Jan 2014 10:24:53 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7B91AE159 for ; Mon, 6 Jan 2014 10:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5230; q=dns/txt; s=iport; t=1389032685; x=1390242285; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tNd+l3+slH1il8u769uGEHtqu4UoormqUmURzD3blko=; b=Xa/6T9z7M2MsVEzMdPpbmRUHtrDsesaduoq3/I3qCkLC1ty9kYf6DiQd TwtinjRtgdvsoqQIDfz1bIgdOY2lvH02ALhLs/UybHKAaNfOx1wLaiG59 qjBjRr/qiAWgnSNNe80g7JnfVK3P6FI80RX5m8LxEavHMuIFR4LalGzup A=; X-IronPort-AV: E=Sophos;i="4.95,614,1384300800"; d="scan'208,217";a="10854813" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 06 Jan 2014 18:24:45 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s06IOijH009836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jan 2014 18:24:44 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.29]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 6 Jan 2014 12:24:44 -0600 From: "JP Vasseur (jvasseur)" To: Ines Robles Thread-Topic: Intend for draft-tripathi-roll-reactive-applicability Thread-Index: AQHPCwySkaJmD9RduUaGNYAD4XxD5w== Date: Mon, 6 Jan 2014 18:24:44 +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: [10.60.114.226] Content-Type: multipart/alternative; boundary="_000_E9B58E97B9C84BCF8B488EF6E0B8CDBDciscocom_" MIME-Version: 1.0 Cc: Michael Richardson , roll , Joydeep Tripathi , "Jaudelice C. de Oliveira" Subject: Re: [Roll] Intend for draft-tripathi-roll-reactive-applicability 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, 06 Jan 2014 18:24:55 -0000 --_000_E9B58E97B9C84BCF8B488EF6E0B8CDBDciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I can see two paths: (1) ROLL WG ID (not the easiest though, although this = could be seen as an applicability ID) or (2) AD sponsored ? On Jan 6, 2014, at 7:10 PM, Ines Robles > wrote: Hi, Thanks for this draft, https://ietf.org/doc/draft-tripathi-roll-reactive-ap= plicability/ Abstract This document describes serious issues and shortcomings regarding the use o= f reactive routing protocols in low power and lossy networks(LLNs). Routing= requirements for various LLN deployments are discussed in order to judge h= ow reactive routing may or may notadhere to the necessary criteria. We would like to know please, how is the intend for this document? how thi= s draft would be aligned with roll charter?, should we re-chartering? Thank you in advance, Ines Robles --_000_E9B58E97B9C84BCF8B488EF6E0B8CDBDciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable I can see two paths: (1) ROLL WG ID (not the easiest though, although this = could be seen as an applicability
ID) or (2) AD sponsored ?

On Jan 6, 2014, at 7:10 PM, Ines Robles <mariainesrobles@googlemail.com> wrote:

Hi,


Abstract

This document describ= es serious issues and shortcomings regarding the use of reactive routing protocols in low power and lossy networks(LLNs= ). Routing requirements for various LLN deployments are discussed in order = to judge how reactive routing may or may notadhere to the necessary criteri= a.

We would like to know please,  how is the intend for this document? how = this draft would be aligned with roll charter?, should we re-chartering?

Thank you in advance,

Ines Robles

--_000_E9B58E97B9C84BCF8B488EF6E0B8CDBDciscocom_-- From ulrich@herberg.name Mon Jan 6 16:14: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 6DA431AE38D for ; Mon, 6 Jan 2014 16:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 uZysI2JJ-mVQ for ; Mon, 6 Jan 2014 16:14:33 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 586EF1AD9AE for ; Mon, 6 Jan 2014 16:14:33 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id kx10so19176204pab.22 for ; Mon, 06 Jan 2014 16:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XVz2oQMk4y8XDgth5AtzEH3OTOz6RC3U/JObRO80WtY=; b=jkZvlfgKJ0b+3WFxigyvXI0V3PGVgnt0ojJ+VTAW9hkc9KMzLeGlNYaZZhvMUaPjHP fqUemApobQeThENfwxYW3W5BvyT3i2PkBZ6WeGLXF5rjQglvjxOXLdxy92eURDo5AX5I 2TOrd4LXUrcdLPcrvdZztkpfGS7nN6ml7Ty7o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XVz2oQMk4y8XDgth5AtzEH3OTOz6RC3U/JObRO80WtY=; b=A1nqZlfZj6Oe2x1KPKyXl17AudDJup0INIJOTPEBIJ/0L4bMchaE1G3ACfUKAQTa4/ K9zsuktphEIXCAl9HC+1Q58QHJk5Ob8iMRhTqklUgvmDvU0ZWolRRK9qoGNBi2uOd+aq vlBL/QTvxZSlJQ9AKy+dRZCVdGVVVRnp/87w9S22CpzYkVsq2cYBSwCGMYxfCv4COHcS i74VDuuPey8eu64NfKhqvdn62MNaao5Hx67mctgGIXo8OMEzu1rHf6qOGbzHSzqM68N0 7dDrLucGydMXODW8JTwGGb2/YB118GAaG+L12nsdLND7rjUI9QMvVl/AHqS6dxAJG/1W adNQ== X-Gm-Message-State: ALoCoQl9u6t5cjX0MpJn00o07eqOkRrZ+KHscqnbulMb12XT9BCmyLsyOaLbld4kWoNw+j49kj4Y MIME-Version: 1.0 X-Received: by 10.68.191.73 with SMTP id gw9mr10815545pbc.158.1389053663938; Mon, 06 Jan 2014 16:14:23 -0800 (PST) Received: by 10.70.13.161 with HTTP; Mon, 6 Jan 2014 16:14:23 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Jan 2014 16:14:23 -0800 Message-ID: From: Ulrich Herberg To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=e89a8fb2082a36a53d04ef5642cd Cc: Michael Richardson , Joydeep Tripathi , Ines Robles , "Jaudelice C. de Oliveira" Subject: Re: [Roll] Intend for draft-tripathi-roll-reactive-applicability 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, 07 Jan 2014 00:14:36 -0000 --e89a8fb2082a36a53d04ef5642cd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ines, I object any form of publication of this draft. In my opinion, it is another attempt to discredit LOADng and reactive protocols in general with false arguments. As has been mentioned before, reactive protocols (in particular LOADng) have been very successfully deployed in large LLN deployments. So there is proof that in some LLN deployments, reactive protocols work very well. Note that I do not claim they work in all such use cases, but the MANET WG has understood this more than a decade before that reactive protocols can work in some scenarios, not in all. It is possible to create scenarios where reactive protocols are better, and others where proactive protocols are better. Claiming that, in general, for LLNs one is better than the other is incorrect in my opinion. But let me argue why I think this draft is flawed by picking the arguments made in the draft: 3.1. Inability to support P2MP traffic pattern This very much depends on the use case. LOADng has been deployed in several scenarios where P2MP traffic is sparse, and where few concurrent traffic flows are used. This is not a theoretic scenario, but a deployment that is actually used by some utilities. We have shown in [1] that in this case, LOADng outperforms RPL by far. See also [5] further evaluations. Not only has LOADng orders of magnitude less control traffic than RPL in the investigated scenarios, but also the state requirements are far smaller. 3.2. Inability to support MP2P traffic pattern There is an easy-to-implement extension to LOADng submitted as [2] that solves this. Performance evaluations in [3] show the efficiency of the solution. 4. Dependency of control overhead on application module This is a general observation of reactive protocols that the MANET WG has understood more than a decade ago. Again, observations of current traffic patterns in [1] show that reactive protocols have far less control traffic in current use cases of AMI metering. Yes, in cases with lots of concurrent traffic lows, then the argument is correct (note that the amount of data does not really matter, as the route is only discovered once; so even sending gigabytes/second would not be an issue as long as there are limited amount of traffic flows). So this is another argument of the sort that MANET rejected long time ago. It really depends on the use case and the kind of traffic we are talking about. 5. Flooding issues in LLNs It is correct that flooding causes a lot of overhead and battery drain. But note that we also observed in [1] and [4] that RPL in downward mode also causes a lot of control traffic, more than LOADng for a similar scenario that is described in the draft. It again depends on the use case. For example, with the extension proposed in [2], the performance for such traffic in LOADng is at least as good as with RPL (see also [3]). Note that in the described scenario, RPL would require an equal amount of state (in storing mode), or lead to very long packets in non-storing mode and therefore potential fragmentation, such as described in [4]. 5.1. Impact of flooding in battery operated nodes "Note that there is a lot of experimental evidence supporting the claim that using flooding or scoped flooding to discover routes is ill-suited to low-power and lossy networks (LLNs)". Where? I prefer citations over assertions. Note that I am not claiming that flooding is not costly, but it -- again -- depends on the scenario how many different concurrent traffic flows are required and how long routes are stored. Also note that optimizations, such as MPR flooding, can optimize flooding compared to classic flooding. 6. Impact on memory This again depends on the use case. As we have described in [4], RPL in storing mode also requires a lot of state. In non-storing mode, packets may become very long and lead to fragmentation. With few concurrent traffic flows, LOADng largely outperforms RPL in terms of storage requirements (in many cases, a single route at a time may be sufficient). 7. Lack of support for routing based on node capability This argument is flawed. LOADng provides a very extensible and flexible definition of route metrics. It is easy to create a metric that reflects limitations of the nodes, such as energy and CPU/memory resource limitations. How is this different from RPL? 8. High delay for emergency traffic While it is true that reactive protocols have a higher delay requirement than proactive protocols, the argument is, again, flawed. The draft writes "*Some* data in an LLN are delay sensitive by nature". I agree. It further mentions industrial automation settings. Yes, in *some* LLNs, delay is indeed critical (e.g., light switch), but in others it is not as much (AMI metering). The draft argues that reactive protocols are bad for *all* LLNs, but provides evidence only for *some*. This is exactly what the MANET WG has agreed on in the 1990s that there is no one-size-fits-all. [1] U. Herberg, T. Clausen, "A Comparative Performance Study of the Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-power and Lossy Networks (LLN)", Proceedings of the 8th ACM International Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE-WASUN), October 2011 [2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight On-demand Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)", draft-yi-loadngct-01, Internet Draft (work in progress) [3] J. Yi, T. Clausen, and A. Colin de Verdiere. "Efficient Data Acquisition in Sensor Networks: Introducing (the) LOADng Collection Tree Protocol", Proceedings of the 8th IEEE International Conference on Wireless Communications, Networking and Mobile Computing - WiCom-2012, October 2012 [4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, =93Experiences with RPL: IP= v6 Routing Protocol for Low power and Lossy Networks=94, Internet Draft (work = in progress), draft-clausen-lln-rpl-experiences-06, February 2013. [5] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013 IEEE Conference on Wireless Sensors Best regards Ulrich On Mon, Jan 6, 2014 at 10:24 AM, JP Vasseur (jvasseur) wrote: > I can see two paths: (1) ROLL WG ID (not the easiest though, although > this could be seen as an applicability > ID) or (2) AD sponsored ? > > On Jan 6, 2014, at 7:10 PM, Ines Robles > wrote: > > > > > > * Hi, Thanks for this draft, > https://ietf.org/doc/draft-tripathi-roll-reactive-applicability/ > Abstra= ct > This document describes serious issues and shortcomings regarding the use > of reactive routing protocols in low power and lossy networks(LLNs). > Routing requirements for various LLN deployments are discussed in order t= o > judge how reactive routing may or may notadhere to the necessary criteria= . > We would like to know please, how is the intend for this document? how > this draft would be aligned with roll charter?, should we re-chartering?* > > *Thank you in advance,* > > Ines Robles > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --e89a8fb2082a36a53d04ef5642cd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Ines,

I object any form of publication of this draf= t. In my opinion, it is another attempt to discredit LOADng and reactive pr= otocols in general with false arguments. As has been mentioned before, reac= tive protocols (in particular LOADng) have been very successfully deployed = in large LLN deployments. So there is proof that in some LLN deployments, r= eactive protocols work very well. Note that I do not claim they work in all= such use cases, but the MANET WG has understood this more than a decade be= fore that reactive protocols can work in some scenarios, not in all. It is = possible to create scenarios where reactive protocols are better, and other= s where proactive protocols are better. Claiming that, in general, for LLNs= one is better than the other is incorrect in my opinion.

But let me argue why I think this draft is flawed by picking the argume= nts made in the draft:

3.1. Inability to support P2MP traffic patter= n

This very much depends on the use case. LOADng has been deployed i= n several scenarios where P2MP traffic is sparse, and where few concurrent = traffic flows are used. This is not a theoretic scenario, but a deployment = that is actually used by some utilities. We have shown in [1] that in this = case, LOADng outperforms RPL by far. See also [5] further evaluations. Not = only has LOADng orders of magnitude less control traffic than RPL in the in= vestigated scenarios, but also the state requirements are far smaller.

3.2. Inability to support MP2P traffic pattern

There is an easy-= to-implement extension to LOADng submitted as [2] that solves this. Perform= ance evaluations in [3] show the efficiency of the solution.

4. Depe= ndency of control overhead on application module

This is a general observation of reactive protocols that the MANET WG h= as understood more than a decade ago. Again, observations of current traffi= c patterns in [1] show that reactive protocols have far less control traffi= c in current use cases of AMI metering. Yes, in cases with lots of concurre= nt traffic lows, then the argument is correct (note that the amount of data= does not really matter, as the route is only discovered once; so even send= ing gigabytes/second would not be an issue as long as there are limited amo= unt of traffic flows). So this is another argument of the sort that MANET r= ejected long time ago. It really depends on the use case and the kind of tr= affic we are talking about.

5. Flooding issues in LLNs

It is correct that flooding causes a = lot of overhead and battery drain. But note that we also observed in [1] an= d [4] that RPL in downward mode also causes a lot of control traffic, more = than LOADng for a similar scenario that is described in the draft. It again= depends on the use case. For example, with the extension proposed in [2], = the performance for such traffic in LOADng is at least as good as with RPL = (see also [3]). Note that in the described scenario, RPL would require an e= qual amount of state (in storing mode), or lead to very long packets in non= -storing mode and therefore potential fragmentation, such as described in [= 4].

5.1. Impact of flooding in battery operated nodes

"Note tha= t there is a lot of experimental evidence supporting the claim that using f= looding or scoped flooding to discover routes is ill-suited to low-power an= d lossy networks (LLNs)". Where? I prefer citations over assertions. Note that I am not claiming that flooding is not costly, but it -- again --= depends on the scenario how many different concurrent traffic flows are re= quired and how long routes are stored. Also note that optimizations, such a= s MPR flooding, can optimize flooding compared to classic flooding.

6. Impact on memory

This again depends on the use case. As we ha= ve described in [4], RPL in storing mode also requires a lot of state. In n= on-storing mode, packets may become very long and lead to fragmentation. Wi= th few concurrent traffic flows, LOADng largely outperforms RPL in terms of= storage requirements (in many cases, a single route at a time may be suffi= cient).

7. Lack of support for routing based on node capability

This arg= ument is flawed. LOADng provides a very extensible and flexible definition = of route metrics. It is easy to create a metric that reflects limitations o= f the nodes, such as energy and CPU/memory resource limitations. How is thi= s different from RPL?

8. High delay for emergency traffic

While it is true that reacti= ve protocols have a higher delay requirement than proactive protocols, the = argument is, again, flawed. The draft writes "*Some* data in an LLN ar= e delay sensitive by nature". I agree. It further mentions industrial = automation settings. Yes, in *some* LLNs, delay is indeed critical (e.g., l= ight switch), but in others it is not as much (AMI metering). The draft arg= ues that reactive protocols are bad for *all* LLNs, but provides evidence o= nly for *some*. This is exactly what the MANET WG has agreed on in the 1990= s that there is no one-size-fits-all.


[1] U. Herberg, T. Clausen, "A Comparative Performance Study o= f the Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-pow= er and Lossy Networks (LLN)", Proceedings of the 8th ACM International= Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiqui= tous Networks (PE-WASUN), October 2011
[2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight On-de= mand Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)", dr= aft-yi-loadngct-01, Internet Draft (work in progress)
[3] J. Yi, T. Clau= sen, and A. Colin de Verdiere. "Efficient Data Acquisition in Sensor N= etworks: Introducing (the) LOADng Collection Tree Protocol", Proceedin= gs of the 8th IEEE International Conference on Wireless Communications, Net= working and Mobile Computing - WiCom-2012, October 2012
[4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, =93Experiences with RPL: IP= v6 Routing Protocol for Low power and Lossy Networks=94, Internet Draft (wo= rk in progress), draft-clausen-lln-rpl-experiences-06, February 2013.
[5= ] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for = Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013= IEEE Conference on Wireless Sensors

Best regards
Ulrich



=
On Mon, Jan 6, 2014 at 10:24 AM, JP Vasseur (jva= sseur) <jvasseur@cisco.com> wrote:
I can see two paths: (1) ROLL WG ID (not the easiest though, although this = could be seen as an applicability
ID) or (2) AD sponsored ?

On Jan 6, 2014, at 7:10 PM, Ines Robles <mariainesrobles@googlemail.com> wrote:

Hi,
Abstract

This document describes serious issue= s and shortcomings regarding the use of reactive routing protocols in low power and lossy networks(LLNs= ). Routing requirements for various LLN deployments are discussed in order = to judge how reactive routing may or may notadhere to the necessary criteri= a.

We would like to know please, =A0how is the intend for this document? how thi= s draft would be aligned with roll charter?, should we re-chartering?

Thank you in advance,

Ines Robles


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


--e89a8fb2082a36a53d04ef5642cd-- From mariainesrobles@googlemail.com Mon Jan 6 16:58: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 BFC491AE3AA for ; Mon, 6 Jan 2014 16:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_65=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 tAFWrKEUH71B for ; Mon, 6 Jan 2014 16:58:16 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C5D0A1AE39C for ; Mon, 6 Jan 2014 16:58:15 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so16127650wgh.26 for ; Mon, 06 Jan 2014 16:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rkrzcQdl5ft3at7FYaqRWsW3Lhp6sEnzYAENBhsgxIw=; b=QgLM5BE+R8jtVL2Ovlr5CuLF00zSII041pd0rbJYUmmxLiMNpH9lqEIdNAcCadLixM 6B7BmBH1xC66FVZAgXJWwUf6aD8R6Kw9ZEeiI7/Albj1lTQzj+viP2K54uRIXMbHq/nz sDfpXac/LgS3Akaux+QII+acx6dljUdEGRKIBDrB3vvV2uYmUZycMXCTyC/5L6yS29Pv gggvthGXv0r63f9xnQL+eVSWo49f2kOFUK7PsEjPHzCAUvk3pF1tRp4liHbyJ3WQorMq LzVWtsn0xlmYe8z/xXV6t3lbzARc3Dm1Rat2EuA8GRpDcipv0dA4I9n2QsxqvhzrGlKI 9lQA== MIME-Version: 1.0 X-Received: by 10.180.20.33 with SMTP id k1mr14506465wie.34.1389056286670; Mon, 06 Jan 2014 16:58:06 -0800 (PST) Received: by 10.216.44.144 with HTTP; Mon, 6 Jan 2014 16:58:06 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Jan 2014 22:58:06 -0200 Message-ID: From: Ines Robles To: Ulrich Herberg Content-Type: multipart/alternative; boundary=bcaec53d5ee18a451f04ef56de82 Cc: Michael Richardson , Routing Over Low power and Lossy networks , Joydeep Tripathi , "Jaudelice C. de Oliveira" Subject: Re: [Roll] Intend for draft-tripathi-roll-reactive-applicability 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, 07 Jan 2014 00:58:18 -0000 --bcaec53d5ee18a451f04ef56de82 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable *Hi Ulrich,Thank you very much for the detailed explanation and for the references as well, let me analyze them deeply and get back with comments. Kind Regards,Ines.* 2014/1/6 Ulrich Herberg > Ines, > > I object any form of publication of this draft. In my opinion, it is > another attempt to discredit LOADng and reactive protocols in general wit= h > false arguments. As has been mentioned before, reactive protocols (in > particular LOADng) have been very successfully deployed in large LLN > deployments. So there is proof that in some LLN deployments, reactive > protocols work very well. Note that I do not claim they work in all such > use cases, but the MANET WG has understood this more than a decade before > that reactive protocols can work in some scenarios, not in all. It is > possible to create scenarios where reactive protocols are better, and > others where proactive protocols are better. Claiming that, in general, f= or > LLNs one is better than the other is incorrect in my opinion. > > But let me argue why I think this draft is flawed by picking the argument= s > made in the draft: > > 3.1. Inability to support P2MP traffic pattern > > This very much depends on the use case. LOADng has been deployed in > several scenarios where P2MP traffic is sparse, and where few concurrent > traffic flows are used. This is not a theoretic scenario, but a deploymen= t > that is actually used by some utilities. We have shown in [1] that in thi= s > case, LOADng outperforms RPL by far. See also [5] further evaluations. No= t > only has LOADng orders of magnitude less control traffic than RPL in the > investigated scenarios, but also the state requirements are far smaller. > > 3.2. Inability to support MP2P traffic pattern > > There is an easy-to-implement extension to LOADng submitted as [2] that > solves this. Performance evaluations in [3] show the efficiency of the > solution. > > 4. Dependency of control overhead on application module > > This is a general observation of reactive protocols that the MANET WG has > understood more than a decade ago. Again, observations of current traffic > patterns in [1] show that reactive protocols have far less control traffi= c > in current use cases of AMI metering. Yes, in cases with lots of concurre= nt > traffic lows, then the argument is correct (note that the amount of data > does not really matter, as the route is only discovered once; so even > sending gigabytes/second would not be an issue as long as there are limit= ed > amount of traffic flows). So this is another argument of the sort that > MANET rejected long time ago. It really depends on the use case and the > kind of traffic we are talking about. > > 5. Flooding issues in LLNs > > It is correct that flooding causes a lot of overhead and battery drain. > But note that we also observed in [1] and [4] that RPL in downward mode > also causes a lot of control traffic, more than LOADng for a similar > scenario that is described in the draft. It again depends on the use case= . > For example, with the extension proposed in [2], the performance for such > traffic in LOADng is at least as good as with RPL (see also [3]). Note th= at > in the described scenario, RPL would require an equal amount of state (in > storing mode), or lead to very long packets in non-storing mode and > therefore potential fragmentation, such as described in [4]. > > 5.1. Impact of flooding in battery operated nodes > > "Note that there is a lot of experimental evidence supporting the claim > that using flooding or scoped flooding to discover routes is ill-suited t= o > low-power and lossy networks (LLNs)". Where? I prefer citations over > assertions. > Note that I am not claiming that flooding is not costly, but it -- again > -- depends on the scenario how many different concurrent traffic flows ar= e > required and how long routes are stored. Also note that optimizations, su= ch > as MPR flooding, can optimize flooding compared to classic flooding. > > 6. Impact on memory > > This again depends on the use case. As we have described in [4], RPL in > storing mode also requires a lot of state. In non-storing mode, packets m= ay > become very long and lead to fragmentation. With few concurrent traffic > flows, LOADng largely outperforms RPL in terms of storage requirements (i= n > many cases, a single route at a time may be sufficient). > > 7. Lack of support for routing based on node capability > > This argument is flawed. LOADng provides a very extensible and flexible > definition of route metrics. It is easy to create a metric that reflects > limitations of the nodes, such as energy and CPU/memory resource > limitations. How is this different from RPL? > > 8. High delay for emergency traffic > > While it is true that reactive protocols have a higher delay requirement > than proactive protocols, the argument is, again, flawed. The draft write= s > "*Some* data in an LLN are delay sensitive by nature". I agree. It furthe= r > mentions industrial automation settings. Yes, in *some* LLNs, delay is > indeed critical (e.g., light switch), but in others it is not as much (AM= I > metering). The draft argues that reactive protocols are bad for *all* LLN= s, > but provides evidence only for *some*. This is exactly what the MANET WG > has agreed on in the 1990s that there is no one-size-fits-all. > > > [1] U. Herberg, T. Clausen, "A Comparative Performance Study of the > Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-power a= nd > Lossy Networks (LLN)", Proceedings of the 8th ACM International Symposium > on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous > Networks (PE-WASUN), October 2011 > [2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight On-deman= d > Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)", > draft-yi-loadngct-01, Internet Draft (work in progress) > [3] J. Yi, T. Clausen, and A. Colin de Verdiere. "Efficient Data > Acquisition in Sensor Networks: Introducing (the) LOADng Collection Tree > Protocol", Proceedings of the 8th IEEE International Conference on Wirele= ss > Communications, Networking and Mobile Computing - WiCom-2012, October 201= 2 > [4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, =93Experiences with RPL: > IPv6 Routing Protocol for Low power and Lossy Networks=94, Internet Draft > (work in progress), draft-clausen-lln-rpl-experiences-06, February 2013. > [5] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for > Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013 IE= EE > Conference on Wireless Sensors > > Best regards > Ulrich > > > > On Mon, Jan 6, 2014 at 10:24 AM, JP Vasseur (jvasseur) > wrote: > >> I can see two paths: (1) ROLL WG ID (not the easiest though, although >> this could be seen as an applicability >> ID) or (2) AD sponsored ? >> >> On Jan 6, 2014, at 7:10 PM, Ines Robles >> wrote: >> >> >> >> >> >> * Hi, Thanks for this draft, >> https://ietf.org/doc/draft-tripathi-roll-reactive-applicability/ >> Abstr= act >> This document describes serious issues and shortcomings regarding the us= e >> of reactive routing protocols in low power and lossy networks(LLNs). >> Routing requirements for various LLN deployments are discussed in order = to >> judge how reactive routing may or may notadhere to the necessary criteri= a. >> We would like to know please, how is the intend for this document? how >> this draft would be aligned with roll charter?, should we re-chartering?= * >> >> *Thank you in advance,* >> >> Ines Robles >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > --bcaec53d5ee18a451f04ef56de82 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi= Ulrich,

Thank you very much for the detailed ex= planation and for the references as well, let me analyze them deeply and ge= t back with comments.

Kind Regards,

Ines.


2014/1/= 6 Ulrich Herberg <ulrich@herberg.name>
Ines,

I object any form of publication of this draf= t. In my opinion, it is another attempt to discredit LOADng and reactive pr= otocols in general with false arguments. As has been mentioned before, reac= tive protocols (in particular LOADng) have been very successfully deployed = in large LLN deployments. So there is proof that in some LLN deployments, r= eactive protocols work very well. Note that I do not claim they work in all= such use cases, but the MANET WG has understood this more than a decade be= fore that reactive protocols can work in some scenarios, not in all. It is = possible to create scenarios where reactive protocols are better, and other= s where proactive protocols are better. Claiming that, in general, for LLNs= one is better than the other is incorrect in my opinion.

But let me argue why I think this draft is flawed by picking the argume= nts made in the draft:

3.1. Inability to support P2MP traffic patter= n

This very much depends on the use case. LOADng has been deployed i= n several scenarios where P2MP traffic is sparse, and where few concurrent = traffic flows are used. This is not a theoretic scenario, but a deployment = that is actually used by some utilities. We have shown in [1] that in this = case, LOADng outperforms RPL by far. See also [5] further evaluations. Not = only has LOADng orders of magnitude less control traffic than RPL in the in= vestigated scenarios, but also the state requirements are far smaller.

3.2. Inability to support MP2P traffic pattern

There is an easy-= to-implement extension to LOADng submitted as [2] that solves this. Perform= ance evaluations in [3] show the efficiency of the solution.

4. Depe= ndency of control overhead on application module

This is a general observation of reactive protocols that the MANET WG h= as understood more than a decade ago. Again, observations of current traffi= c patterns in [1] show that reactive protocols have far less control traffi= c in current use cases of AMI metering. Yes, in cases with lots of concurre= nt traffic lows, then the argument is correct (note that the amount of data= does not really matter, as the route is only discovered once; so even send= ing gigabytes/second would not be an issue as long as there are limited amo= unt of traffic flows). So this is another argument of the sort that MANET r= ejected long time ago. It really depends on the use case and the kind of tr= affic we are talking about.

5. Flooding issues in LLNs

It is correct that flooding causes a = lot of overhead and battery drain. But note that we also observed in [1] an= d [4] that RPL in downward mode also causes a lot of control traffic, more = than LOADng for a similar scenario that is described in the draft. It again= depends on the use case. For example, with the extension proposed in [2], = the performance for such traffic in LOADng is at least as good as with RPL = (see also [3]). Note that in the described scenario, RPL would require an e= qual amount of state (in storing mode), or lead to very long packets in non= -storing mode and therefore potential fragmentation, such as described in [= 4].

5.1. Impact of flooding in battery operated nodes

"Note tha= t there is a lot of experimental evidence supporting the claim that using f= looding or scoped flooding to discover routes is ill-suited to low-power an= d lossy networks (LLNs)". Where? I prefer citations over assertions. Note that I am not claiming that flooding is not costly, but it -- again --= depends on the scenario how many different concurrent traffic flows are re= quired and how long routes are stored. Also note that optimizations, such a= s MPR flooding, can optimize flooding compared to classic flooding.

6. Impact on memory

This again depends on the use case. As we ha= ve described in [4], RPL in storing mode also requires a lot of state. In n= on-storing mode, packets may become very long and lead to fragmentation. Wi= th few concurrent traffic flows, LOADng largely outperforms RPL in terms of= storage requirements (in many cases, a single route at a time may be suffi= cient).

7. Lack of support for routing based on node capability

This arg= ument is flawed. LOADng provides a very extensible and flexible definition = of route metrics. It is easy to create a metric that reflects limitations o= f the nodes, such as energy and CPU/memory resource limitations. How is thi= s different from RPL?

8. High delay for emergency traffic

While it is true that reacti= ve protocols have a higher delay requirement than proactive protocols, the = argument is, again, flawed. The draft writes "*Some* data in an LLN ar= e delay sensitive by nature". I agree. It further mentions industrial = automation settings. Yes, in *some* LLNs, delay is indeed critical (e.g., l= ight switch), but in others it is not as much (AMI metering). The draft arg= ues that reactive protocols are bad for *all* LLNs, but provides evidence o= nly for *some*. This is exactly what the MANET WG has agreed on in the 1990= s that there is no one-size-fits-all.


[1] U. Herberg, T. Clausen, "A Comparative Performance Study o= f the Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-pow= er and Lossy Networks (LLN)", Proceedings of the 8th ACM International= Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiqui= tous Networks (PE-WASUN), October 2011
[2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight On-de= mand Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)", dr= aft-yi-loadngct-01, Internet Draft (work in progress)
[3] J. Yi, T. Clau= sen, and A. Colin de Verdiere. "Efficient Data Acquisition in Sensor N= etworks: Introducing (the) LOADng Collection Tree Protocol", Proceedin= gs of the 8th IEEE International Conference on Wireless Communications, Net= working and Mobile Computing - WiCom-2012, October 2012
[4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, =93Experiences with RPL: IP= v6 Routing Protocol for Low power and Lossy Networks=94, Internet Draft (wo= rk in progress), draft-clausen-lln-rpl-experiences-06, February 2013.
[5= ] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for = Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013= IEEE Conference on Wireless Sensors

Best regards
Ulrich



=
On Mon, Jan 6, 2014 at 10= :24 AM, JP Vasseur (jvasseur) <jvasseur@cisco.com> wrote:
I can see two paths: (1) ROLL WG ID (not the easiest though, although this = could be seen as an applicability
ID) or (2) AD sponsored ?

On Jan 6, 2014, at 7:10 PM, Ines Robles <mariainesrobles@googlemail.com> wrote:

Hi,
Abstract

This document describes serious issue= s and shortcomings regarding the use of reactive routing protocols in low power and lossy networks(LLNs= ). Routing requirements for various LLN deployments are discussed in order = to judge how reactive routing may or may notadhere to the necessary criteri= a.

We would like to know please, =A0how is the intend for this document? how thi= s draft would be aligned with roll charter?, should we re-chartering?

Thank you in advance,

Ines Robles


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



--bcaec53d5ee18a451f04ef56de82-- From ulrich@herberg.name Mon Jan 6 19:21: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 E07D21AE3F4 for ; Mon, 6 Jan 2014 19:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 uycPiJq_Kq-9 for ; Mon, 6 Jan 2014 19:21:18 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD921AE3EC for ; Mon, 6 Jan 2014 19:21:18 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id lf10so19535274pab.28 for ; Mon, 06 Jan 2014 19:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PigHdQyh5A3vm6cnfbCWE+0JILhO0MXBycEgjWeMVPo=; b=uc4ujREVB5xXGYL9ygv0A/MXmU82aZFK3Sh+ZnswaxAjuKGzPeK4gmfZGeRoYU/2fx btULfP9mCtJH7XkId7G2IN1FAhnF8Z29wIKYYC3+gqgwUMqGB2hyw12vRYGv2L7aUaiF 7CZ+hYMmeiQup3dvamt3VoaCwjm8oUQWqQ+No= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PigHdQyh5A3vm6cnfbCWE+0JILhO0MXBycEgjWeMVPo=; b=lS9Iq/Gh1Bbt6M7CgROTQ13419pU86Oy8KGNKXcl2Ak6fg9QibGrFOSCdAci6E4T0N VcJbv6sFLS0lWmras1ixyrKaVHganUhjWHslb0gcIRvmwmm8V5jWqbLW9Mzzbo7YcZhz OdGcZ/ca7Jm2gyIHV1hrRVfV1EFmdwvL5RFUX5dCTBODXs4om0RsiJRqJWZ6AHlWEISA 9vlpFp4DLgIqhoound8deJnL1ppdM3lBIYsMF0yrP5nzIkjPOfo6cSeFuuyhSjp7DBdu 28pydckhsXPgSD/+FOsgm4j2sa90+j77hnWpifQiKtvZ3yRCdI8Cfl2dsASpdEdGQyuK YqfA== X-Gm-Message-State: ALoCoQk13w4L58RsJpY01zabxY+2UFINLMqIQxpcyUylI7r+YL/s4Up9To2WEsqzv4f34pM+p8HE MIME-Version: 1.0 X-Received: by 10.66.136.71 with SMTP id py7mr2254107pab.2.1389064869927; Mon, 06 Jan 2014 19:21:09 -0800 (PST) Received: by 10.70.13.161 with HTTP; Mon, 6 Jan 2014 19:21:09 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Jan 2014 19:21:09 -0800 Message-ID: From: Ulrich Herberg To: Joydeep Tripathi Content-Type: multipart/alternative; boundary=001a11332dfc2476e604ef58ded5 Cc: Michael Richardson , Routing Over Low power and Lossy networks , Ines Robles , "Jaudelice C. de Oliveira" Subject: Re: [Roll] Intend for draft-tripathi-roll-reactive-applicability 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, 07 Jan 2014 03:21:24 -0000 --001a11332dfc2476e604ef58ded5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Joydeep, see below: On Mon, Jan 6, 2014 at 6:27 PM, Joydeep Tripathi wrote: > Hi Ulrich, > > Thanks for your comments and feedback. Let me respond inline. > > On Mon, Jan 6, 2014 at 7:14 PM, Ulrich Herberg wrote= : > >> Ines, >> >> I object any form of publication of this draft. In my opinion, it is >> another attempt to discredit LOADng and reactive protocols in general wi= th >> false arguments. >> > > Well LOADng is one recent example of reactive protocols. However, we are > not discussing about LOADng to *any* extent in this draft. > Yes, the draft is about reactive protocols in general, but explicitly and prominently cites LOADng. But this is not the point, so I will use the term "reactive protocol" below instead of LOADng. > > >> As has been mentioned before, reactive protocols (in particular LOADng) >> have been very successfully deployed in large LLN deployments. So there = is >> proof that in some LLN deployments, reactive protocols work very well. N= ote >> that I do not claim they work in all such use cases, but the MANET WG ha= s >> understood this more than a decade before that reactive protocols can wo= rk >> in some scenarios, not in all. It is possible to create scenarios where >> reactive protocols are better, and others where proactive protocols are >> better. >> > > We had tons of discussions on whether LLNs can be generalized as MANETs. > You are right to point out that "MANET WG has understood this more than a > decade before that reactive protocols can work in some scenarios, not in > all". Our argument through this draft is, LLNs in general come under the > scenario where reactive protocols suffer due to the points made out in th= e > draft. > And my counter-argument is that I can easily create LLN scenarios where all proactive protocols suffer compared to a reactive protocol. > Note that there may be example where a reactive protocol works for a > deployed LLN, but it does not mean it will work better than a proactive > counterpart for that deployment or for any other deployment. > That sounds like an assertion. And it also sounds like a performance comparison ("works better"), which you claim later in your reply this draft is not about. > > Claiming that, in general, for LLNs one is better than the other is >> incorrect in my opinion. >> >> But let me argue why I think this draft is flawed by picking the >> arguments made in the draft: >> >> 3.1. Inability to support P2MP traffic pattern >> >> This very much depends on the use case. LOADng has been deployed in >> several scenarios where P2MP traffic is sparse, and where few concurrent >> traffic flows are used. This is not a theoretic scenario, but a deployme= nt >> that is actually used by some utilities. >> > > Ability to support P2MP traffic pattern for routing protocols in LLN is > mandated by RFC 5548. Actually P2MP and MP2P traffics are pre-dominant fo= r > LLNs, and P2P traffic is considered rare. So for a protocol type to be > considered a candidate to be used in LLNs it is required to examine how i= t > fairs to handle P2MP traffic. > Yes, and I argued that there are mechanisms to extend reactive protocols (as shown by LOADng as example), so that exactly P2MP and MP2P are supported. > >> We have shown in [1] that in this case, LOADng outperforms RPL by far. >> See also [5] further evaluations. Not only has LOADng orders of magnitud= e >> less control traffic than RPL in the investigated scenarios, but also th= e >> state requirements are far smaller. >> > > At the same time, I wish to point out that this document, in no form is = a > comparison between RPL and LOADng. > I am not convinced about this. How is this not about performance? You say that proactive protocols work better than reactive. That seems like a performance comparison to me. > Simulation results in form of academic paper references are used to show > how a reactive protocol behaves in different scenarios in terms of > different metrics. Any protocol implementation can be done in an > non-optimized manner to show that performs poorly than another protocol. > Do you claim that the results obtained were due to a poor implementation of RPL? > There are many papers showing RPL outperforms LOADng, specially in large > networks. > Citations always appreciated. But again, give me a protocol and I give you a scenario where it does not perform well. This is the same discussion MANET had many years ago. There is just no one-size-fits-all. > But as I mentioned before, this document does not provide any performance > comparison. LOADng is used as an example. To my intuition, AODVv2 may > behave in a similar way as well. I do not think this WG is the right plac= e > to debate how LOADng or any other protocol performs compared to RPL. > What, if not for showing better general performance of proactive protocols (RPL), is then the intent for this draft? > This document shows in which areas reactive protocols in general suffer t= o > meet the routing requirements in LLNs, thus pointing out pitfalls to look > for / areas of improvement. > And I argued that this only applies to some LLNs, and that in other LLNs reactive protocols work better (as shown by experiments, as well as multiple big deployments of reactive protocols in AMI networks). > > >> >> 3.2. Inability to support MP2P traffic pattern >> >> There is an easy-to-implement extension to LOADng submitted as [2] that >> solves this. Performance evaluations in [3] show the efficiency of the >> solution. >> >> 4. Dependency of control overhead on application module >> >> This is a general observation of reactive protocols that the MANET WG ha= s >> understood more than a decade ago. Again, observations of current traffi= c >> patterns in [1] show that reactive protocols have far less control traff= ic >> in current use cases of AMI metering. >> > > I guess it is again a deployment and protocol specific example. For a > particular deployment and traffic pattern, one protocol may work and meet > the requirements. > Yes, absolutely. But your draft claims that reactive protocols work less good for *all* LLNs. That seems contradictory to what you just wrote in your previous two sentences. > That does not mean the protocol, or protocol-family in general, will be > suited to meet the routing requirements spelled out for LLNs in RFC 5548, > RFC 5673, RFC 5826, RFC 5867 etc. > > >> Yes, in cases with lots of concurrent traffic lows, then the argument is >> correct (note that the amount of data does not really matter, as the rou= te >> is only discovered once; so even sending gigabytes/second would not be a= n >> issue as long as there are limited amount of traffic flows). So this is >> another argument of the sort that MANET rejected long time ago. It reall= y >> depends on the use case and the kind of traffic we are talking about. >> > > The draft not does not even consider any application traffic rate or rang= e > of data traffic rate. It considers, as you pointed correctly, different > flows, and future installation of application modules. So I guess we both > agree, that number of traffic flows is a factor in generating control > overhead. > I agree that the number of traffic flows is a factor for the control traffic. > > >> 5. Flooding issues in LLNs >> >> It is correct that flooding causes a lot of overhead and battery drain. >> But note that we also observed in [1] and [4] that RPL in downward mode >> also causes a lot of control traffic, more than LOADng for a similar >> scenario that is described in the draft. It again depends on the use cas= e. >> For example, with the extension proposed in [2], the performance for suc= h >> traffic in LOADng is at least as good as with RPL (see also [3]). Note t= hat >> in the described scenario, RPL would require an equal amount of state (i= n >> storing mode), or lead to very long packets in non-storing mode and >> therefore potential fragmentation, such as described in [4]. >> > > I would again like to point out that this draft is not a performance > comparison between RPL and LOADng. However, I would also like to point ou= t > that `N' number of unicast control packets consume less energy than `N' > number of broadcast control packets. The reasoning is provided in next > subsection (5.1). In smaller deployments and light traffic scenario, > reactive protocols may incur less control overhead than a proactive > counterpart. However, most of these control packets are broadcast packets= , > thus consuming much more energy than a proactive counterpart even if the > proactive protocol shows more control packets in the simulation. > Yes, but proactive protocols have a constant periodic overhead, independent of the number of traffic flows and the number of data packets sent through the network. While flooding is expensive, it may occur only very infrequently (when a new flow starts or when a route changes). When there is no data traffic, there will be no control traffic either. Proactive protocols will always periodically send control traffic. So in scenarios with little data traffic, and few concurrent traffic flows, reactive protocols can be much better (see the cited papers for examples). Note that I am not saying that reactive protocols are generally better (I am co-author of the proactive MANET protocol OLSRv2 that has been approved by the IETF, so I really do see advantages of proactive protocols). I just say that I object that claim that reactive protocols are bad for *all* LLNs. > For deployments where reactive protocols create more control overhead, > they may require energy expense a magnitude larger, depending on the MAC > layer. > Yes, and for deployments where reactive protocols create less control overhead, proactive protocols may require energy expense a magnitude larger, depending on the MAC layer. > > >> 5.1. Impact of flooding in battery operated nodes >> >> "Note that there is a lot of experimental evidence supporting the claim >> that using flooding or scoped flooding to discover routes is ill-suited = to >> low-power and lossy networks (LLNs)". Where? I prefer citations over >> assertions. >> > > The reasoning why this is the case is provided with references is provide= d > i version-02 of the draft. For the detailed text, please refer to the > version 02, which we just posted. > > >> Note that I am not claiming that flooding is not costly, but it -- again >> -- depends on the scenario how many different concurrent traffic flows a= re >> required and how long routes are stored. Also note that optimizations, s= uch >> as MPR flooding, can optimize flooding compared to classic flooding. >> >> 6. Impact on memory >> >> This again depends on the use case. As we have described in [4], RPL in >> storing mode also requires a lot of state. In non-storing mode, packets = may >> become very long and lead to fragmentation. With few concurrent traffic >> flows, LOADng largely outperforms RPL in terms of storage requirements (= in >> many cases, a single route at a time may be sufficient). >> > > With the assertion one more time that this is not a performance compariso= n > draft, I would like to point out that with header compression, source > routing is very much feasible even over 802.15.4. > That depends on the topology. Long, chain-like topologies would suffer very much, even if you compress each address to a single byte (e.g., line of traffic lights along a long road). > And once again, you are comparing LOADng with *few concurrent flows*. The > argument will be invalid for nodes closer to a sink for a large scale > network. I agree it depends on use cases and traffic profiles. However th= is > document, as I mentioned, provides a general overview, and is intended to > consider superset of cases, and to guide implementors to look at the > probable pitfalls that reactive protocols may be subjected to. > That is not how I interpret the intent of this draft. Documenting a general overview and guidelines to implementers about reactive protocols seems 20 years too late. There are tons of papers discussing differences between proactive and reactive protocols, and it is well understood in which scenarios which protocol type is more suited. Your draft says "The aim of this document is not to discuss a specific reactive routing protocol but why reactive routing protocols in general are ill-suited for LLNs.". As I have argued, I strongly object this general assertion. > > I understand there is no one-size-fits-all for MANET, but this is not > MANET WG. > Yes, but properties of reactive and proactive protocols are the same, no matter whether they are discussed here or in MANET. > What we are really trying to show in this document is where reactive > protocols fail to meet the routing requirements for LLNs. > Again looking at the sentence I cited just above, this does not seem to be the intent, but rather to generally, and for all use cases of LLNs, to discourage the use of reactive protocols. Best regards Ulrich > I would appreciate further comments or feedback. > > Thanks & Regards, > Joydeep > > >> >> 7. Lack of support for routing based on node capability >> >> This argument is flawed. LOADng provides a very extensible and flexible >> definition of route metrics. It is easy to create a metric that reflects >> limitations of the nodes, such as energy and CPU/memory resource >> limitations. How is this different from RPL? >> >> 8. High delay for emergency traffic >> >> While it is true that reactive protocols have a higher delay requirement >> than proactive protocols, the argument is, again, flawed. The draft writ= es >> "*Some* data in an LLN are delay sensitive by nature". I agree. It furth= er >> mentions industrial automation settings. Yes, in *some* LLNs, delay is >> indeed critical (e.g., light switch), but in others it is not as much (A= MI >> metering). The draft argues that reactive protocols are bad for *all* LL= Ns, >> but provides evidence only for *some*. This is exactly what the MANET WG >> has agreed on in the 1990s that there is no one-size-fits-all. >> >> >> [1] U. Herberg, T. Clausen, "A Comparative Performance Study of the >> Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-power = and >> Lossy Networks (LLN)", Proceedings of the 8th ACM International Symposiu= m >> on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous >> Networks (PE-WASUN), October 2011 >> [2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight >> On-demand Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)", >> draft-yi-loadngct-01, Internet Draft (work in progress) >> [3] J. Yi, T. Clausen, and A. Colin de Verdiere. "Efficient Data >> Acquisition in Sensor Networks: Introducing (the) LOADng Collection Tree >> Protocol", Proceedings of the 8th IEEE International Conference on Wirel= ess >> Communications, Networking and Mobile Computing - WiCom-2012, October 20= 12 >> [4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, =93Experiences with RPL: >> IPv6 Routing Protocol for Low power and Lossy Networks=94, Internet Draf= t >> (work in progress), draft-clausen-lln-rpl-experiences-06, February 2013. >> [5] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for >> Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013 I= EEE >> Conference on Wireless Sensors >> >> Best regards >> Ulrich >> >> >> >> On Mon, Jan 6, 2014 at 10:24 AM, JP Vasseur (jvasseur) < >> jvasseur@cisco.com> wrote: >> >>> I can see two paths: (1) ROLL WG ID (not the easiest though, although >>> this could be seen as an applicability >>> ID) or (2) AD sponsored ? >>> >>> On Jan 6, 2014, at 7:10 PM, Ines Robles >>> wrote: >>> >>> >>> >>> >>> >>> * Hi, Thanks for this draft, >>> https://ietf.org/doc/draft-tripathi-roll-reactive-applicability/ >>> Abst= ract >>> This document describes serious issues and shortcomings regarding the u= se >>> of reactive routing protocols in low power and lossy networks(LLNs). >>> Routing requirements for various LLN deployments are discussed in order= to >>> judge how reactive routing may or may notadhere to the necessary criter= ia. >>> We would like to know please, how is the intend for this document? how >>> this draft would be aligned with roll charter?, should we re-chartering= ?* >>> >>> *Thank you in advance,* >>> >>> Ines Robles >>> >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >> > --001a11332dfc2476e604ef58ded5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Joydeep,

see below:


On Mon, Jan 6, 2014 at 6:27 PM, J= oydeep Tripathi <jt369@drexel.edu> wrote:
Hi Ulric= h,

Thanks for your comments and feedback. Let me respond= inline.

On Mon, Jan = 6, 2014 at 7:14 PM, Ulrich Herberg <ulrich@herberg.name> w= rote:
Ines,
I object any form of publication of this draft. In my opinion, it is a= nother attempt to discredit LOADng and reactive protocols in general with f= alse arguments.

Well LOADng is one recent example of= reactive protocols. However, we are not discussing about LOADng to *any* e= xtent in this draft.


Yes, the draft is about reactive protocols in general, but expli= citly and prominently cites LOADng.=A0 But this is not the point, so I will= use the term "reactive protocol" below instead of LOADng.

=A0
=A0
As has been mentioned before, reactive protocols (in parti= cular LOADng) have been very successfully deployed in large LLN deployments= . So there is proof that in some LLN deployments, reactive protocols work v= ery well. Note that I do not claim they work in all such use cases, but the= MANET WG has understood this more than a decade before that reactive proto= cols can work in some scenarios, not in all. It is possible to create scena= rios where reactive protocols are better, and others where proactive protoc= ols are better.

We had tons of discussions on whethe= r LLNs can be generalized as MANETs. You are right to point out that "= MANET WG has understood this more than a decade before that reactive protoc= ols can work in some scenarios, not in all". Our argument through this= draft is, LLNs in general come under the scenario where reactive protocols= suffer due to the points made out in the draft.

And my counter-argument = is that I can easily create LLN scenarios where all proactive protocols suf= fer compared to a reactive protocol.


=A0
Note that there may be e= xample where a reactive protocol works for a deployed LLN, but it does not = mean it will work better than a proactive counterpart for that deployment o= r for any other deployment.

That sounds like an asse= rtion. And it also sounds like a performance comparison ("works better= "), which you claim later in your reply this draft is not about.

=A0
<= div dir=3D"ltr">

Claiming that, in general, for LLNs one is better than the other i= s incorrect in my opinion.

But let me argue why I think this draft is flawed by picking the argume= nts made in the draft:

3.1. Inability to support P2MP traffic patter= n

This very much depends on the use case. LOADng has been deployed i= n several scenarios where P2MP traffic is sparse, and where few concurrent = traffic flows are used. This is not a theoretic scenario, but a deployment = that is actually used by some utilities.
=A0
Ability to support P2MP traffic patte= rn=A0for routing protocols in LLN is mandated by RFC 5548. Actually P2MP an= d MP2P traffics are pre-dominant for LLNs, and P2P traffic is considered ra= re. So for a protocol type to be considered a candidate to be used in LLNs = it is required to examine how it fairs to handle P2MP traffic.

Yes, and I argued that t= here are mechanisms to extend reactive protocols (as shown by LOADng as exa= mple), so that exactly P2MP and MP2P are supported.
=A0

=A0
We have shown in [1] that in this case, LOADng outperforms RPL by fa= r. See also [5] further evaluations. Not only has LOADng orders of magnitud= e less control traffic than RPL in the investigated scenarios, but also the= state requirements are far smaller.

=A0At the same time, I wish to= point out that this document, in no form is a comparison between RPL and L= OADng.

I am not co= nvinced about this. How is this not about performance? You say that proacti= ve protocols work better than reactive. That seems like a performance compa= rison to me.

=A0
<= div dir=3D"ltr">
= Simulation results in form of academic paper references are used to show ho= w a reactive protocol behaves in different scenarios in terms of different = metrics. Any protocol implementation can be done in an non-optimized manner= to show that performs poorly than another protocol.

Do you claim that the re= sults obtained were due to a poor implementation of RPL?

=A0
There are many papers showing RPL outperforms LOADng, specially in large n= etworks.

Citations= always appreciated. But again, give me a protocol and I give you a scenari= o where it does not perform well. This is the same discussion MANET had man= y years ago. There is just no one-size-fits-all.

=A0
<= div dir=3D"ltr">
= But as I mentioned before, this document does not provide any performance c= omparison. LOADng is used as an example. To my intuition, AODVv2 may behave= in a similar way as well. I do not think this WG is the right place to deb= ate how LOADng or any other protocol performs compared to RPL.

What, if not for showing= better general performance of proactive protocols (RPL), is then the inten= t for this draft?

=A0
This document shows in which areas reactive protocols in general suffer to= meet the routing requirements in LLNs, thus pointing out pitfalls to look = for / areas of improvement.

And I argued that this o= nly applies to some LLNs, and that in other LLNs reactive protocols work be= tter (as shown by experiments, as well as multiple big deployments of react= ive protocols in AMI networks).
=A0
=A0

3.2. Inability to support MP2P traffic pattern

There is an easy-= to-implement extension to LOADng submitted as [2] that solves this. Perform= ance evaluations in [3] show the efficiency of the solution.

4. Depe= ndency of control overhead on application module

This is a general observation of reactive protocols that the MANET WG h= as understood more than a decade ago. Again, observations of current traffi= c patterns in [1] show that reactive protocols have far less control traffi= c in current use cases of AMI metering.

I guess it is again a deployment and= protocol specific example. For a particular deployment and traffic pattern= , one protocol may work and meet the requirements.


Yes, absolutely. But your draft claims= that reactive protocols work less good for *all* LLNs. That seems contradi= ctory to what you just wrote in your previous two sentences.

=A0
That does= not mean the protocol, or protocol-family in general, will be suited to me= et the routing requirements spelled out for LLNs in RFC 5548, RFC 5673, RFC= 5826, RFC 5867 etc.=A0
=A0
Yes, in cases with lots of concurrent traffic lows, then the argument= is correct (note that the amount of data does not really matter, as the ro= ute is only discovered once; so even sending gigabytes/second would not be = an issue as long as there are limited amount of traffic flows). So this is = another argument of the sort that MANET rejected long time ago. It really d= epends on the use case and the kind of traffic we are talking about.

The draft not does not even co= nsider any application traffic rate or range of data traffic rate. It consi= ders, as you pointed correctly, different flows, and future installation of= application modules. So I guess we both agree, that number of traffic flow= s is a factor in generating control overhead.

I agree that the number = of traffic flows is a factor for the control traffic.
=A0


5. Flooding issues in LLNs

It is correct that flooding causes a = lot of overhead and battery drain. But note that we also observed in [1] an= d [4] that RPL in downward mode also causes a lot of control traffic, more = than LOADng for a similar scenario that is described in the draft. It again= depends on the use case. For example, with the extension proposed in [2], = the performance for such traffic in LOADng is at least as good as with RPL = (see also [3]). Note that in the described scenario, RPL would require an e= qual amount of state (in storing mode), or lead to very long packets in non= -storing mode and therefore potential fragmentation, such as described in [= 4].

I would again like to point ou= t that this draft is not a performance comparison between RPL and LOADng. H= owever, I would also like to point out that `N' number of unicast contr= ol packets consume less energy than `N' number of broadcast control pac= kets. The reasoning is provided in next subsection (5.1). In smaller deploy= ments and light traffic scenario, reactive protocols may incur less control= overhead than a proactive counterpart. However, most of these control pack= ets are broadcast packets, thus consuming much more energy than a proactive= counterpart even if the proactive protocol shows more control packets in t= he simulation.

Yes, but proactive proto= cols have a constant periodic overhead, independent of the number of traffi= c flows and the number of data packets sent through the network. While floo= ding is expensive, it may occur only very infrequently (when a new flow sta= rts or when a route changes). When there is no data traffic, there will be = no control traffic either. Proactive protocols will always periodically sen= d control traffic. So in scenarios with little data traffic, and few concur= rent traffic flows, reactive protocols can be much better (see the cited pa= pers for examples). Note that I am not saying that reactive protocols are g= enerally better (I am co-author of the proactive MANET protocol OLSRv2 that= has been approved by the IETF, so I really do see advantages of proactive = protocols). I just say that I object that claim that reactive protocols are= bad for *all* LLNs.
=A0
For = deployments where reactive protocols create more control overhead, they may= require energy expense a magnitude larger, depending on the MAC layer.

Yes, and for deployments= where reactive protocols create less control overhead, proactive protocols= may require energy expense a magnitude larger, depending on the MAC layer.=
=A0


5.1. Impact of flooding in battery operated nodes

"Note tha= t there is a lot of experimental evidence supporting the claim that using f= looding or scoped flooding to discover routes is ill-suited to low-power an= d lossy networks (LLNs)". Where? I prefer citations over assertions.

The reasoning why this is the = case is provided with references is provided i version-02 of the draft. For= the detailed text, please refer to the version 02, which we just posted.
=A0
Note that I am not claiming that flooding is not costly, but it -- again --= depends on the scenario how many different concurrent traffic flows are re= quired and how long routes are stored. Also note that optimizations, such a= s MPR flooding, can optimize flooding compared to classic flooding.

6. Impact on memory

This again depends on the use case. As we ha= ve described in [4], RPL in storing mode also requires a lot of state. In n= on-storing mode, packets may become very long and lead to fragmentation. Wi= th few concurrent traffic flows, LOADng largely outperforms RPL in terms of= storage requirements (in many cases, a single route at a time may be suffi= cient).

With the assertion one more ti= me that this is not a performance comparison draft, I would like to point o= ut that with header compression, source routing is very much feasible even = over 802.15.4.

That depends on the topo= logy. Long, chain-like topologies would suffer very much, even if you compr= ess each address to a single byte (e.g., line of traffic lights along a lon= g road).

=A0
<= div dir=3D"ltr">
= And once again, you are comparing LOADng with *few concurrent flows*. The a= rgument will be invalid for nodes closer to a sink for a large scale networ= k. I agree it depends on use cases and traffic profiles. However this docum= ent, as I mentioned, provides a general overview, and is intended to consid= er superset of cases, and to guide implementors to look at the probable pit= falls that reactive protocols may be subjected to.

That is not how I interp= ret the intent of this draft. Documenting a general overview and guidelines= to implementers about reactive protocols seems 20 years too late. There ar= e tons of papers discussing differences between proactive and reactive prot= ocols, and it is well understood in which scenarios which protocol type is = more suited. Your draft says "The aim of this document is not to discuss a specific reactive routing protocol but why reactive routing protocols in general are ill-suited for LLNs.". As= I have argued, I strongly object this general assertion.
=A0

I understand there is no=A0one-size-fits-all for MANET,= but this is not MANET WG.

Yes, but properties of reactive and proactive protocols are the sa= me, no matter whether they are discussed here or in MANET.

=A0
<= div dir=3D"ltr">
= What we are really trying to show in this document is where reactive protoc= ols fail to meet the routing requirements for LLNs.=A0

Again looking at the sen= tence I cited just above, this does not seem to be the intent, but rather t= o generally, and for all use cases of LLNs, to discourage the use of reacti= ve protocols.

Best regards
Ulrich
=A0


I would appreciate further comments or=A0feedback.

Thanks &=A0Regards,
Joydeep
=A0

7. Lack of support for routing based on node capability

This arg= ument is flawed. LOADng provides a very extensible and flexible definition = of route metrics. It is easy to create a metric that reflects limitations o= f the nodes, such as energy and CPU/memory resource limitations. How is thi= s different from RPL?

8. High delay for emergency traffic

While it is true that reacti= ve protocols have a higher delay requirement than proactive protocols, the = argument is, again, flawed. The draft writes "*Some* data in an LLN ar= e delay sensitive by nature". I agree. It further mentions industrial = automation settings. Yes, in *some* LLNs, delay is indeed critical (e.g., l= ight switch), but in others it is not as much (AMI metering). The draft arg= ues that reactive protocols are bad for *all* LLNs, but provides evidence o= nly for *some*. This is exactly what the MANET WG has agreed on in the 1990= s that there is no one-size-fits-all.


[1] U. Herberg, T. Clausen, "A Comparative Performance Study o= f the Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-pow= er and Lossy Networks (LLN)", Proceedings of the 8th ACM International= Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiqui= tous Networks (PE-WASUN), October 2011
[2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight On-de= mand Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)", dr= aft-yi-loadngct-01, Internet Draft (work in progress)
[3] J. Yi, T. Clau= sen, and A. Colin de Verdiere. "Efficient Data Acquisition in Sensor N= etworks: Introducing (the) LOADng Collection Tree Protocol", Proceedin= gs of the 8th IEEE International Conference on Wireless Communications, Net= working and Mobile Computing - WiCom-2012, October 2012
[4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, =93Experiences with RPL: IP= v6 Routing Protocol for Low power and Lossy Networks=94, Internet Draft (wo= rk in progress), draft-clausen-lln-rpl-experiences-06, February 2013.
[5= ] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for = Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013= IEEE Conference on Wireless Sensors

Best regards
Ulrich



=
On Mon, Jan 6, 2014 at 10:24 AM, JP Va= sseur (jvasseur) <jvasseur@cisco.com> wrote:
I can see two paths: (1) ROLL WG ID (not the easiest though, although this = could be seen as an applicability
ID) or (2) AD sponsored ?

On Jan 6, 2014, at 7:10 PM, Ines Robles <mariainesrobles@googlemail.com> wrote:

Hi,
Abstract

This document describes serious issue= s and shortcomings regarding the use of reactive routing protocols in low power and lossy networks(LLNs= ). Routing requirements for various LLN deployments are discussed in order = to judge how reactive routing may or may notadhere to the necessary criteri= a.

We would like to know please, =A0how is the intend for this document? how thi= s draft would be aligned with roll charter?, should we re-chartering?

Thank you in advance,

Ines Robles


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




--001a11332dfc2476e604ef58ded5-- From abdussalambaryun@gmail.com Tue Jan 7 20:48: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 4D6C91AE2CA for ; Tue, 7 Jan 2014 20:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iffw2iBPXV3Z for ; Tue, 7 Jan 2014 20:48:00 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 82AAA1AE2C6 for ; Tue, 7 Jan 2014 20:48:00 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id g10so1293358pdj.1 for ; Tue, 07 Jan 2014 20:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mqp1nP4Arj6c1LLTc8IfTdHy0nOzigYPIx44gCdjr5M=; b=MaVB+xDzCtbuC9ObeEXLw2Hruhv8u2Jb19NU1JCwmENSly5m+tyH2L2XKjP7Rw8Szc Ubh1VwEBw2aAZ+hTHE57OfYMuo/gm/pnxFr7r4rfDNpgo36nl78kyPfQgt5URYw4yPYx DbeeppFd8FOIsQvvEthydogX3fOsN2sBA4WAuRk1hSAbEsXNjzvFqsheZ0rZUJEW9xj6 tB8CgDBDcolXWqPrNcLsRnuDnGmC7dz9Yg6X2KJ96sNOgApHT4DSksLZVOLGKz4Kcuce QDimq5pRfGBgyFX/zVgIHXHpqWmR6BZ939gPny5FNRu3ZjGUMzhqrFvbRVexJhc6PcV2 8FAg== MIME-Version: 1.0 X-Received: by 10.68.224.34 with SMTP id qz2mr4913316pbc.84.1389156471579; Tue, 07 Jan 2014 20:47:51 -0800 (PST) Received: by 10.68.0.104 with HTTP; Tue, 7 Jan 2014 20:47:51 -0800 (PST) In-Reply-To: References: Date: Wed, 8 Jan 2014 05:47:51 +0100 Message-ID: From: Abdussalam Baryun To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7b2e07a706bc9904ef6e3253 Cc: Ines Robles Subject: Re: [Roll] Intend for draft-tripathi-roll-reactive-applicability 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, 08 Jan 2014 04:48:03 -0000 --047d7b2e07a706bc9904ef6e3253 Content-Type: text/plain; charset=ISO-8859-1 On Tuesday, January 7, 2014, Ulrich Herberg wrote: > MANET WG has understood this more than a decade before that reactive > protocols can work in some scenarios, not in all. It is possible to create > scenarios where reactive protocols are better, and others where proactive > protocols are better. Claiming that, in general, for LLNs one is better > than the other is incorrect in my opinion. > There are difference between MANETs and LLNs scenarios. I never like general drafts without applicability statements. In LLN we should not categorise protocols only as reactive or proactive (that is manet routing categorised). > > > 3.1. Inability to support P2MP traffic pattern > > This very much depends on the use case. LOADng has been deployed in > several scenarios where P2MP traffic is sparse, and where few concurrent > traffic flows are used. This is not a theoretic scenario, but a deployment > that is actually used by some utilities. We have shown in [1] that in this > case, LOADng outperforms RPL by far. See also [5] further evaluations. Not > only has LOADng orders of magnitude less control traffic than RPL in the > investigated scenarios, but also the state requirements are far smaller. > Both references 1 and 5 are similar to this draft still not adopted or published by IETF. Any document author will argue for their doc but did any specify all LLN scenarios in the doc. > > > > 3.2. Inability to support MP2P traffic pattern > > There is an easy-to-implement extension to LOADng submitted as [2] that > solves this. Performance evaluations in [3] show the efficiency of the > solution. > The draft does not evaluate that protocol or possible solutions but it was saying reactive. > > > 4. Dependency of control overhead on application module > > This is a general observation of reactive protocols that the MANET WG has > understood more than a decade ago. > In IETF MANET is not LLN. Even in many work published outside-IETF they are different with different protocols. > 5. Flooding issues in LLNs > > It is correct that flooding causes a lot of overhead and battery drain. > But note that we also observed in [1] and [4] that RPL in downward mode > also causes a lot of control traffic, more than LOADng for a similar > scenario that is described in the draft. It again depends on the use case. > For example, with the extension proposed in [2], the performance for such > traffic in LOADng is at least as good as with RPL (see also [3]). Note that > in the described scenario, RPL would require an equal amount of state (in > storing mode), or lead to very long packets in non-storing mode and > therefore potential fragmentation, such as described in [4]. > I don't think we are comparing protocols but we need to compare flooding techniques in specific use cases. I think your references don't cover all use cases as well. > > > 6. Impact on memory > > This again depends on the use case. > Depends on many issues not only use cases. > > 7. Lack of support for routing based on node capability > > This argument is flawed. LOADng provides a very extensible and flexible > definition of route metrics. It is easy to create a metric that reflects > limitations of the nodes, such as energy and CPU/memory resource > limitations. How is this different from RPL? > >> >> I think both protocols don't have that is why I wanted to do a protocol for node capability, NAP, but still work in progress. > > > 8. High delay for emergency traffic > > While it is true that reactive protocols have a higher delay requirement > than proactive protocols, the argument is, again, flawed. The draft writes > "*Some* data in an LLN are delay sensitive by nature". I agree. It further > mentions industrial automation settings. Yes, in *some* LLNs, delay is > indeed critical (e.g., light switch), but in others it is not as much (AMI > metering). The draft argues that reactive protocols are bad for *all* LLNs, > but provides evidence only for *some*. This is exactly what the MANET WG > has agreed on in the 1990s that there is no one-size-fits-all. > > The draft should say: manet reactive protocols are bad for most LLNs, because no one in IETF has published that reactive protocols are good for all LLNs or even all MANETs. AB > --047d7b2e07a706bc9904ef6e3253 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tuesday, January 7, 2014, Ulrich Herberg wrote:
MANET WG has understood this more than = a decade before that reactive protocols can work in some scenarios, not in = all. It is possible to create scenarios where reactive protocols are better= , and others where proactive protocols are better. Claiming that, in genera= l, for LLNs one is better than the other is incorrect in my opinion.
There are difference between MANETs=A0and LLNs scenarios.= I never like general drafts without applicability statements. In LLN we sh= ould not categorise protocols only as reactive or=A0proactive (that is=A0ma= net routing categorised).=A0


3.1. Inability to s= upport P2MP traffic pattern

This very much depends on the use case. = LOADng has been deployed in several scenarios where P2MP traffic is sparse,= and where few concurrent traffic flows are used. This is not a theoretic s= cenario, but a deployment that is actually used by some utilities. We have = shown in [1] that in this case, LOADng outperforms RPL by far. See also [5]= further evaluations. Not only has LOADng orders of magnitude less control = traffic than RPL in the investigated scenarios, but also the state requirem= ents are far smaller.
Both references 1 and 5=A0are similar to this draft still= not adopted or published by IETF.=A0=A0Any document author will argue for = their doc but did any specify all=A0LLN scenarios in the doc.=A0



3.2. Inability to support MP2P traffic pattern

There is an easy-= to-implement extension to LOADng submitted as [2] that solves this. Perform= ance evaluations in [3] show the efficiency of the solution.
The draft does not evaluate that protocol or possible solutions=A0but = it was saying reactive.=A0=A0


4. Dependency of control overhead on application module

This is a general observation of reactive protocols that the MANET WG h= as understood more than a decade ago.=A0
=A0
In IETF=A0MANET=A0is not LLN. Even in many work published outside-IETF= =A0=A0they are different with different protocols.=A0


5. Flood= ing issues in LLNs

It is correct that flooding causes a lot of overh= ead and battery drain. But note that we also observed in [1] and [4] that R= PL in downward mode also causes a lot of control traffic, more than LOADng = for a similar scenario that is described in the draft. It again depends on = the use case. For example, with the extension proposed in [2], the performa= nce for such traffic in LOADng is at least as good as with RPL (see also [3= ]). Note that in the described scenario, RPL would require an equal amount = of state (in storing mode), or lead to very long packets in non-storing mod= e and therefore potential fragmentation, such as described in [4].
I don't think we are comparing protocols but we need = to compare flooding techniques in specific use cases. I think your referenc= es don't cover all use cases as well.=A0=A0


6. Impact on memory

This again depends on t= he use case.
=A0
Depends on many issues no= t only use cases.=A0=A0
=A0
7. Lack of support for routing based on node capabi= lity

This argument is flawed. LOADng provides a very extensible and = flexible definition of route metrics. It is easy to create a metric that re= flects limitations of the nodes, such as energy and CPU/memory resource lim= itations. How is this different from RPL?

I think b= oth protocols don't have that is why I wanted to do a protocol for node= capability, NAP,=A0but still work in progress.=A0=A0


8. High delay for emergency traffic

While it is true that reacti= ve protocols have a higher delay requirement than proactive protocols, the = argument is, again, flawed. The draft writes "*Some* data in an LLN ar= e delay sensitive by nature". I agree. It further mentions industrial = automation settings. Yes, in *some* LLNs, delay is indeed critical (e.g., l= ight switch), but in others it is not as much (AMI metering). The draft arg= ues that reactive protocols are bad for *all* LLNs, but provides evidence o= nly for *some*. This is exactly what the MANET WG has agreed on in the 1990= s that there is no one-size-fits-all.

=A0The draft should say: manet=A0reactive protocols a= re bad for most LLNs, because no one in IETF has published that reactive pr= otocols are good for all LLNs or=A0even all MANETs.=A0
=A0
<= div>AB
=A0
=A0
=A0
--047d7b2e07a706bc9904ef6e3253-- From trac+roll@trac.tools.ietf.org Wed Jan 8 07:52: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 6A9261ADF35 for ; Wed, 8 Jan 2014 07:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 qNVaDeo5P7Cj for ; Wed, 8 Jan 2014 07:52:41 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A01571AD627 for ; Wed, 8 Jan 2014 07:52:41 -0800 (PST) Received: from localhost ([127.0.0.1]:48941 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W0vQZ-0007Q8-2J; Wed, 08 Jan 2014 16:52:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com X-Trac-Project: roll Date: Wed, 08 Jan 2014 15:52:18 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/142 Message-ID: <071.83a629a0f47b2e8cb70a862eb5b7f060@trac.tools.ietf.org> X-Trac-Ticket-ID: 142 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Cc: roll@ietf.org Subject: [Roll] [roll] #142: Clarification of secure key distribution 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, 08 Jan 2014 15:52:43 -0000 #142: Clarification of secure key distribution This document includes a section on Security Considerations for distribution of certificates required by RPL. It explains that for RPL the credential is a shared key, and then goes on to say: "Therefore, there MUST be a mechanism in place which allows secure distribution of a shared key and configuration of network identity. Both MAY be done using (i) pre-installation using an out-of-band method, (ii) delivered securely when a device is introduced into the network or (iii) delivered securely by a trusted neighboring device. The shared key MUST be stored in a secure fashion which makes it difficult to be read by an unauthorized party. An example of a method whereby this can be achieved is detailed in [SmartObj]" The wording of this paragraph is not always clear: 1. “this” in the last sentence can refer to the storage of a key in a secure fashion, and leave the reader wondering why there are no references to means of achieving secure key distribution. SmartOb reference is actually such a reference. This should be made more clear, e.g. "An example of a method whereby this secure key distribution can be achieved in detailed in [SmartObj]." 2. Also, it would be good to be more specific about what is meant by “securely” here. For example, writing if the key must be authenticated and kept secret between its intended users, must not be repeated (replay protection), etc. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: defect | building@tools.ietf.org Priority: minor | Status: new Component: applicability-home- | Milestone: building | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Jan 8 07:56: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 B522C1AE41F for ; Wed, 8 Jan 2014 07:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 6pMfs1CXAmnu for ; Wed, 8 Jan 2014 07:56:05 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D07EF1AE434 for ; Wed, 8 Jan 2014 07:56:03 -0800 (PST) Received: from localhost ([127.0.0.1]:49194 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W0vTs-0002tp-5N; Wed, 08 Jan 2014 16:55:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com X-Trac-Project: roll Date: Wed, 08 Jan 2014 15:55:44 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/143 Message-ID: <071.5be08847a6561b89ec88486a7dfc5102@trac.tools.ietf.org> X-Trac-Ticket-ID: 143 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Cc: roll@ietf.org Subject: [Roll] [roll] #143: Status of Reference [SmartObj] 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, 08 Jan 2014 15:56:06 -0000 #143: Status of Reference [SmartObj] [SmartObj] Jennings, C., "Transitive Trust Enrollment for Constrained Devices", Web http://www.lix.polytechnique.fr/hipercom/ SmartObjectSecurity/papers/CullenJennings.pdf, February 2012. This paper does not seem to be finished (there are several sections labeled TODO), and that it also appears to be intended as an Internet Draft. What is the status of it? Is it intended to be developed in tandem with this I-D? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: defect | building@tools.ietf.org Priority: major | Status: new Component: applicability-home- | Milestone: building | Version: Severity: Active WG Document | Keywords: Security Review -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Jan 8 07:58: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 AAAC21AE4DD for ; Wed, 8 Jan 2014 07:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 AYz0c3WWF9ag for ; Wed, 8 Jan 2014 07:58:21 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EB3851AE4D1 for ; Wed, 8 Jan 2014 07:58:20 -0800 (PST) Received: from localhost ([127.0.0.1]:49289 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W0vWB-0003wU-M0; Wed, 08 Jan 2014 16:58:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com X-Trac-Project: roll Date: Wed, 08 Jan 2014 15:58:07 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/144 Message-ID: <071.aa142153295054714a8b618b84a00f2b@trac.tools.ietf.org> X-Trac-Ticket-ID: 144 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building@tools.ietf.org, yvonneanne.pignolet@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: abr@sdesigns.dk, consultancy@vanderstok.org, emmanuel.baccelli@inria.fr, robert.cragie@gridmerge.com Cc: roll@ietf.org Subject: [Roll] [roll] #144: Missing discussion of link encryption and group keys 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, 08 Jan 2014 15:58:22 -0000 #144: Missing discussion of link encryption and group keys Add a discussion as to when it is more advantageous to use link encryption or group keys. In the case that a network consists of both highly security-relevant and well-protected devices (such as alarm systems), and non-security relevant and not so well-protected devices (such as TV remotes), group keying means that either the remote must be as well- protected as the alarm system, or the entire network must be rekeyed if the remote is lost. I don’t whether or not it would be necessary to give any MUST or SHOULD recommendations, but it would be helpful to give the reader an understanding of the issues involved when making decisions about link encryption versus group keys. This is not addressed in any of the documents cited at the beginning of the security considerations. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- yvonneanne.pignolet@gmail.com | applicability-home- Type: defect | building@tools.ietf.org Priority: major | Status: new Component: applicability-home- | Milestone: building | Version: Severity: Active WG Document | Keywords: Security Review -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Jan 8 10:54: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 DF4901AE076 for ; Wed, 8 Jan 2014 10:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 oVG-TPygF59Z for ; Wed, 8 Jan 2014 10:54:20 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 272BA1AE0AF for ; Wed, 8 Jan 2014 10:54:18 -0800 (PST) Received: from localhost ([127.0.0.1]:33101 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W0yGK-0004yE-EK; Wed, 08 Jan 2014 19:53:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Wed, 08 Jan 2014 18:53:56 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/103#comment:4 Message-ID: <073.7216cb83192049da06ce9f77986ed6d3@trac.tools.ietf.org> References: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-Trac-Ticket-ID: 103 In-Reply-To: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Cc: roll@ietf.org Subject: Re: [Roll] [roll] #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS 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, 08 Jan 2014 18:54:23 -0000 #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS Comment (by mariainesrobles@gmail.com): Source: [http://www.ietf.org/mail-archive/web/roll/current/msg08161.html] From: Michael Richardson Date: Fri, 13 Sep 2013 10:03:54 -0400 Don Sturek wrote: > 1) "- I have argued that to increase MPL's applicability, > PROACTIVE_FORWARDING should be a per-interface and not a per- forwarder > setting. I can imagine, for example, a router that has both LLN and “I think that the IETF *functional requirements* question is really: Can an implementer make it per-interface without having an impact on the implementation in other nodes? If the answer is, there is no impact, then it really doesn't matter. Other "ip-forwarding" settings have been described as per-router and generalized into per-interface many times before. I have added your comments to ticket #103, which I re-opened. I will close it again today --- I would appreciate comments in the mailing list as to whether there is anything to fix here.” ------------------------------------------------------------------------------------------------------------------------------------------ Source: [http://www.ietf.org/mail-archive/web/roll/current/msg08163.html] From: Kerry Lynn Date: Fri, 13 Sep 2013 13:02:03 -0400 “Experience shows that tuning parameters are not always exposed by a given implementation and even when they are, they are most likely left at their default value. My concern is that the suggested default for this parameter may lead to suboptimal behavior on non-LLN links (by ensuring straight flooding for some number of intervals). Even if there is "room for interpretation" on considering this a per- interface parameter, the correct default needs to be specified in this draft or else a BCP or something will be necessary. It would be good to hear Jonathan's opinion…” -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From mariainesrobles@googlemail.com Wed Jan 8 11:30:20 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 2706F1AE560 for ; Wed, 8 Jan 2014 11:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIVM7Y3B7pqf for ; Wed, 8 Jan 2014 11:30:19 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id C415E1AE55F for ; Wed, 8 Jan 2014 11:30:18 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so1857172wgg.28 for ; Wed, 08 Jan 2014 11:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=RsP/qVsI3E7w/ZP8VILuF/UVJdiax4PdLE8RE9ysOfY=; b=mMdBkveAgCWXHbF9DILzCs3cBNCh3+cyDC43tFADv2ZiE+Jqq5SOVOYDbogdA5ajTO jX7D9eGsI9sGF261YuSKU/EieHVmqFLz/RLeIUZb9U9kLIGW/vmi3BgK2S35qEnG13v0 TmwurjeTO3vnJQv6EWTDwqbr3IEif5O3+Ut6GLDIHryFhdTJNTHRhvwUIBM00WrK+VbL mlYtALpoA+6fGfVfeEKQl6zG+sb9+/mb67Tka3rofI3DcmiFCKI6UhXi+HP5IgapyrQG /NmJVhPUimvpRDxMdvl4DQVc8lxU/LYk66S3jQT9hyz/WlxO9UQAJz4xMqPjSYS6UcD/ cI+g== MIME-Version: 1.0 X-Received: by 10.194.222.38 with SMTP id qj6mr12515014wjc.66.1389209408963; Wed, 08 Jan 2014 11:30:08 -0800 (PST) Received: by 10.216.44.144 with HTTP; Wed, 8 Jan 2014 11:30:08 -0800 (PST) Date: Wed, 8 Jan 2014 17:30:08 -0200 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=001a11c1b73a570ec004ef7a8593 Cc: Michael Richardson , "Jonathan Hui \(johui\)" Subject: [Roll] Trickle-mcast - Proactive Forwarding - ticket #103 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, 08 Jan 2014 19:30:20 -0000 --001a11c1b73a570ec004ef7a8593 Content-Type: text/plain; charset=ISO-8859-1 Hello, We are clossing the issues for trickle-mcast draft, we have still this open issue, ticket #103 , please we would like to have your opinion about this suggestion: "...to increase MPL's applicability, PROACTIVE_FORWARDING should be a per-interface and not a per-forwarder setting..." [ http://www.ietf.org/mail-archive/web/roll/current/msg08156.html] Thank you in advance, Ines Robles. --001a11c1b73a570ec004ef7a8593 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

We are closs= ing the issues for trickle-mcast draft, we have still this open issue, tick= et=A0#103, please we would like to have your opinion about this = suggestion:

"...to increase MPL's= applicability, PROACTIVE_FORWARDING=A0 should be a per-interface and not a= per-forwarder setting..."=A0[http://www.ietf.org/m= ail-archive/web/roll/current/msg08156.html]

Thank you in advance,

<= /div>
Ines Robles.
<= /div>
--001a11c1b73a570ec004ef7a8593-- From d.sturek@att.net Wed Jan 8 11:45:34 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 417E81AE15F for ; Wed, 8 Jan 2014 11:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, 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 m225rVSPbN6z for ; Wed, 8 Jan 2014 11:45:29 -0800 (PST) Received: from nm24.access.bullet.mail.gq1.yahoo.com (nm24.access.bullet.mail.gq1.yahoo.com [216.39.62.55]) by ietfa.amsl.com (Postfix) with ESMTP id 166821AE14F for ; Wed, 8 Jan 2014 11:45:29 -0800 (PST) Received: from [216.39.60.169] by nm24.access.bullet.mail.gq1.yahoo.com with NNFMP; 08 Jan 2014 19:45:19 -0000 Received: from [67.195.22.116] by tm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 08 Jan 2014 19:45:19 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.gq1.yahoo.com with NNFMP; 08 Jan 2014 19:45:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1389210319; bh=0N6zHMi101Hhv2eLlnyYe9K4tJC0dLgV7S1pO8yXBN0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type; b=KevCEBgsxCUTLy17P1uPrJ6DEKao27zGovhLKHg2DXdY0WhhozcABTMUPgp5n2lNo/7XBqej9iYS2/ZU94SVjhEmGeFyH4f6RsiUKHRdJiDm2txLJlDDTXGrBxBPsZPb5TOENPQAeggTfbhRtZzsg2hr6pcJQBCSxv4iTl0gCHk= X-Yahoo-Newman-Id: 808678.70862.bm@smtp111.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: g27Vk5MVM1nyTTonGMLtipZPqg0YXx25MYMbkuHMEXnU5P0 W2LMs5IFbOEGX4tV8gy.ZGicKn0tbDvZL8sa5NaGlUG8fZjJRIVmfS3cFDMf SmqhMzu4JvZaXIpLDx1gQ7LOhM9.W9jvQxD80VdzX_WKVWg7nc7orFcy0krK uYnjrIOjXZxkGXg0pvWWexVrGnA5SZ_6JJDQ_mYKBhGkJqre9Tbyx5Nrxow9 q_1tf0TrhmO5VTTVpFVgwW.ei8.MQugJ8V9_h0WRmc53mAflJA5UZkpEipmm qv.5GwWpfjYDMsYobHO4xCjTiDeBaV04aRj_Cve2OriVc_iitHWJWC1WzzWZ BCpvVIhqZ1Tqf3oR.neBQlE4EZHiDLe4zCJnqBWvsf0Fd4gpS03G7xGgcxKV RTde5CuaPrV4BeXHiCXhT0EuYA0rcukkYfR5VYEw_kjuOdEFYEnGLD61_yvX XEXdDOxltPjLSVI0JuSCo74gE9UQAzx9y_XVbkxqsTSIWvI.G8a7JmxE_q8u rC8s941Ub5VajwzxeZXWU.xr8aDnB9kHgp8drrLq96TFxZSbPXqWA3GlDjeR GAA-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.1.1.116] (d.sturek@66.27.60.174 with plain [67.195.15.5]) by smtp111.sbc.mail.gq1.yahoo.com with SMTP; 08 Jan 2014 19:45:19 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Wed, 08 Jan 2014 11:45:14 -0800 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] Trickle-mcast - Proactive Forwarding - ticket #103 References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3472026318_253384" Cc: Michael Richardson , "Jonathan Hui \(johui\)" Subject: Re: [Roll] Trickle-mcast - Proactive Forwarding - ticket #103 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, 08 Jan 2014 19:45:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3472026318_253384 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Ines, I believe it would be useful to have PROACTIVE_FORWARDING per interface and not per forwarder. This would allow a device with multiple interfaces to operate off of different MPL settings (for example, a device that uses MPL in a HAN but also has an AMI interface as well in the area of smart metering) Don From: Ines Robles Reply-To: Routing Over Low power and Lossy networks Date: Wednesday, January 8, 2014 11:30 AM To: roll Cc: Michael Richardson , "Jonathan Hui (johui)" Subject: [Roll] Trickle-mcast - Proactive Forwarding - ticket #103 Hello, We are clossing the issues for trickle-mcast draft, we have still this open issue, ticket #103 , please we would like to have your opinion about this suggestion: "...to increase MPL's applicability, PROACTIVE_FORWARDING should be a per-interface and not a per-forwarder setting..." [http://www.ietf.org/mail-archive/web/roll/current/msg08156.html] Thank you in advance, Ines Robles. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --B_3472026318_253384 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Ines,

I believe it would be useful to have PROACTIVE_FORWARDING per interf= ace and not per forwarder.   This would allow a device with multiple in= terfaces to operate off of different MPL settings (for example, a device tha= t uses MPL in a HAN but also has an AMI interface as well in the area of sma= rt metering)

Don


From: Ines Robles <mariainesrobles@googlemail.com>
Reply-To: Routing Over Low power and Lo= ssy networks <roll@ietf.org>
Date: Wednesday, January 8, 2014 11:30 A= M
To: roll <roll@ietf.org>
Cc: Michael Richardson <mcr+ietf@s= andelman.ca>, "Jonathan Hui (johui)" <johui@cisco.com>
Subject: [Roll] Trickle-mcast - Proactive Forwarding - ticket #103
=
Hello,=

We are clossin= g the issues for trickle-mcast draft, we have still this open issue, ticket&= nbsp;#103, please we would like to have your opinion about this suggest= ion:

"...to increase MPL's a= pplicability, PROACTIVE_FORWARDING  should be a per-interface and not a= per-forwarder setting..." [http://www.ietf.org/mail-arch= ive/web/roll/current/msg08156.html]

Thank you in advance,

Ines Robles.
_______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll --B_3472026318_253384-- From trac+roll@trac.tools.ietf.org Wed Jan 8 12:13: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 3F40B1AE18E for ; Wed, 8 Jan 2014 12:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 NyZWTS857rf6 for ; Wed, 8 Jan 2014 12:13:48 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD11AE11F for ; Wed, 8 Jan 2014 12:13:48 -0800 (PST) Received: from localhost ([127.0.0.1]:38648 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W0zVC-00012T-7u; Wed, 08 Jan 2014 21:13:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Wed, 08 Jan 2014 20:13:22 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/103#comment:5 Message-ID: <073.9b7e7618fa2d73c6609ba5dc6ace0107@trac.tools.ietf.org> References: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-Trac-Ticket-ID: 103 In-Reply-To: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Cc: roll@ietf.org Subject: Re: [Roll] [roll] #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS 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, 08 Jan 2014 20:13:50 -0000 #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS Comment (by mariainesrobles@gmail.com): Source: [http://www.ietf.org/mail-archive/web/roll/current/msg08412.html] From: Don Sturek Date: Wed, 08 Jan 2014 11:45:14 -0800 “I believe it would be useful to have PROACTIVE_FORWARDING per interface and not per forwarder. This would allow a device with multiple interfaces to operate off of different MPL settings (for example, a device that uses MPL in a HAN but also has an AMI interface as well in the area of smart metering)” -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From joydeep.tripathi@gmail.com Wed Jan 8 12:19: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 809591AE176 for ; Wed, 8 Jan 2014 12:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-4sD9-6P6-z for ; Wed, 8 Jan 2014 12:19:45 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 501F51AE170 for ; Wed, 8 Jan 2014 12:19:45 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id x13so1904278wgg.15 for ; Wed, 08 Jan 2014 12:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8gVK12cHaQkc52g13BFAiikR9VVGEw9oonYJzr9z9o4=; b=iZKTVRLYELPa+WHWdW8Vym26mnQlqtxuAWXfs3uxWWXr0i/SYTcIE60j4/1XJi1xog MFSoXVdugdXH1BlJxGofcz0VURq9F4uwksSIYGZcsWbJfnJBwUDVBs/s7z6kZH58Rz7s nh8ctda4mL2UDK2KrUTWzLNmMQu+WpuoLaFQppxAXxgu3t9hU82a8jja6w5EyLzcteNS Ih+AcclA+FEBQ56YZOd5N5j4scWZvkN2m8OIdrog8GSUsGQKBrAk9TXFDubRSmpmOTTR flEIEFAIdIeXxK0JQw4oW3byj15dzUIl1kCA7DuUszg9dKUMqgjrpluiWSJpLH7HEhMO uFfQ== MIME-Version: 1.0 X-Received: by 10.180.228.8 with SMTP id se8mr22832238wic.29.1389212375243; Wed, 08 Jan 2014 12:19:35 -0800 (PST) Received: by 10.194.179.71 with HTTP; Wed, 8 Jan 2014 12:19:35 -0800 (PST) In-Reply-To: References: Date: Wed, 8 Jan 2014 15:19:35 -0500 Message-ID: From: Joydeep Tripathi To: ROLL WG Content-Type: multipart/alternative; boundary=001a1134db5424e16a04ef7b3676 Subject: [Roll] Fwd: Intend for draft-tripathi-roll-reactive-applicability 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, 08 Jan 2014 20:19:49 -0000 --001a1134db5424e16a04ef7b3676 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Somehow this email did not make it to the WG mailing list. Sorry if you get duplicate copy. Hi Ulrich, Thanks for your comments and feedback. Let me respond inline. On Mon, Jan 6, 2014 at 7:14 PM, Ulrich Herberg wrote: > Ines, > > I object any form of publication of this draft. In my opinion, it is > another attempt to discredit LOADng and reactive protocols in general wit= h > false arguments. > Well LOADng is one recent example of reactive protocols. However, we are not discussing about LOADng to *any* extent in this draft. > As has been mentioned before, reactive protocols (in particular LOADng) > have been very successfully deployed in large LLN deployments. So there i= s > proof that in some LLN deployments, reactive protocols work very well. No= te > that I do not claim they work in all such use cases, but the MANET WG has > understood this more than a decade before that reactive protocols can wor= k > in some scenarios, not in all. It is possible to create scenarios where > reactive protocols are better, and others where proactive protocols are > better. > We had tons of discussions on whether LLNs can be generalized as MANETs. You are right to point out that "MANET WG has understood this more than a decade before that reactive protocols can work in some scenarios, not in all". Our argument through this draft is, LLNs in general come under the scenario where reactive protocols suffer due to the points made out in the draft. Note that there may be example where a reactive protocol works for a deployed LLN, but it does not mean it will work better than a proactive counterpart for that deployment or for any other deployment. Claiming that, in general, for LLNs one is better than the other is > incorrect in my opinion. > > But let me argue why I think this draft is flawed by picking the argument= s > made in the draft: > > 3.1. Inability to support P2MP traffic pattern > > This very much depends on the use case. LOADng has been deployed in > several scenarios where P2MP traffic is sparse, and where few concurrent > traffic flows are used. This is not a theoretic scenario, but a deploymen= t > that is actually used by some utilities. > Ability to support P2MP traffic pattern for routing protocols in LLN is mandated by RFC 5548. Actually P2MP and MP2P traffics are pre-dominant for LLNs, and P2P traffic is considered rare. So for a protocol type to be considered a candidate to be used in LLNs it is required to examine how it fairs to handle P2MP traffic. > We have shown in [1] that in this case, LOADng outperforms RPL by far. Se= e > also [5] further evaluations. Not only has LOADng orders of magnitude les= s > control traffic than RPL in the investigated scenarios, but also the stat= e > requirements are far smaller. > At the same time, I wish to point out that this document, in no form is a comparison between RPL and LOADng. Simulation results in form of academic paper references are used to show how a reactive protocol behaves in different scenarios in terms of different metrics. Any protocol implementation can be done in an non-optimized manner to show that performs poorly than another protocol. There are many papers showing RPL outperforms LOADng, specially in large networks. But as I mentioned before, this document does not provide any performance comparison. LOADng is used as an example. To my intuition, AODVv2 may behave in a similar way as well. I do not think this WG is the right place to debate how LOADng or any other protocol performs compared to RPL. This document shows in which areas reactive protocols in general suffer to meet the routing requirements in LLNs, thus pointing out pitfalls to look for / areas of improvement. > > 3.2. Inability to support MP2P traffic pattern > > There is an easy-to-implement extension to LOADng submitted as [2] that > solves this. Performance evaluations in [3] show the efficiency of the > solution. > > 4. Dependency of control overhead on application module > > This is a general observation of reactive protocols that the MANET WG has > understood more than a decade ago. Again, observations of current traffic > patterns in [1] show that reactive protocols have far less control traffi= c > in current use cases of AMI metering. > I guess it is again a deployment and protocol specific example. For a particular deployment and traffic pattern, one protocol may work and meet the requirements. That does not mean the protocol, or protocol-family in general, will be suited to meet the routing requirements spelled out for LLNs in RFC 5548, RFC 5673, RFC 5826, RFC 5867 etc. > Yes, in cases with lots of concurrent traffic lows, then the argument is > correct (note that the amount of data does not really matter, as the rout= e > is only discovered once; so even sending gigabytes/second would not be an > issue as long as there are limited amount of traffic flows). So this is > another argument of the sort that MANET rejected long time ago. It really > depends on the use case and the kind of traffic we are talking about. > The draft not does not even consider any application traffic rate or range of data traffic rate. It considers, as you pointed correctly, different flows, and future installation of application modules. So I guess we both agree, that number of traffic flows is a factor in generating control overhead. > 5. Flooding issues in LLNs > > It is correct that flooding causes a lot of overhead and battery drain. > But note that we also observed in [1] and [4] that RPL in downward mode > also causes a lot of control traffic, more than LOADng for a similar > scenario that is described in the draft. It again depends on the use case= . > For example, with the extension proposed in [2], the performance for such > traffic in LOADng is at least as good as with RPL (see also [3]). Note th= at > in the described scenario, RPL would require an equal amount of state (in > storing mode), or lead to very long packets in non-storing mode and > therefore potential fragmentation, such as described in [4]. > I would again like to point out that this draft is not a performance comparison between RPL and LOADng. However, I would also like to point out that `N' number of unicast control packets consume less energy than `N' number of broadcast control packets. The reasoning is provided in next subsection (5.1). In smaller deployments and light traffic scenario, reactive protocols may incur less control overhead than a proactive counterpart. However, most of these control packets are broadcast packets, thus consuming much more energy than a proactive counterpart even if the proactive protocol shows more control packets in the simulation. For deployments where reactive protocols create more control overhead, they may require energy expense a magnitude larger, depending on the MAC layer. > 5.1. Impact of flooding in battery operated nodes > > "Note that there is a lot of experimental evidence supporting the claim > that using flooding or scoped flooding to discover routes is ill-suited t= o > low-power and lossy networks (LLNs)". Where? I prefer citations over > assertions. > The reasoning why this is the case is provided with references is provided i version-02 of the draft. For the detailed text, please refer to the version 02, which we just posted. > Note that I am not claiming that flooding is not costly, but it -- again > -- depends on the scenario how many different concurrent traffic flows ar= e > required and how long routes are stored. Also note that optimizations, su= ch > as MPR flooding, can optimize flooding compared to classic flooding. > > 6. Impact on memory > > This again depends on the use case. As we have described in [4], RPL in > storing mode also requires a lot of state. In non-storing mode, packets m= ay > become very long and lead to fragmentation. With few concurrent traffic > flows, LOADng largely outperforms RPL in terms of storage requirements (i= n > many cases, a single route at a time may be sufficient). > With the assertion one more time that this is not a performance comparison draft, I would like to point out that with header compression, source routing is very much feasible even over 802.15.4. And once again, you are comparing LOADng with *few concurrent flows*. The argument will be invalid for nodes closer to a sink for a large scale network. I agree it depends on use cases and traffic profiles. However this document, as I mentioned, provides a general overview, and is intended to consider superset of cases, and to guide implementors to look at the probable pitfalls that reactive protocols may be subjected to. I understand there is no one-size-fits-all for MANET, but this is not MANET WG. What we are really trying to show in this document is where reactive protocols fail to meet the routing requirements for LLNs. I would appreciate further comments or feedback. Thanks & Regards, Joydeep > > 7. Lack of support for routing based on node capability > > This argument is flawed. LOADng provides a very extensible and flexible > definition of route metrics. It is easy to create a metric that reflects > limitations of the nodes, such as energy and CPU/memory resource > limitations. How is this different from RPL? > > 8. High delay for emergency traffic > > While it is true that reactive protocols have a higher delay requirement > than proactive protocols, the argument is, again, flawed. The draft write= s > "*Some* data in an LLN are delay sensitive by nature". I agree. It furthe= r > mentions industrial automation settings. Yes, in *some* LLNs, delay is > indeed critical (e.g., light switch), but in others it is not as much (AM= I > metering). The draft argues that reactive protocols are bad for *all* LLN= s, > but provides evidence only for *some*. This is exactly what the MANET WG > has agreed on in the 1990s that there is no one-size-fits-all. > > > [1] U. Herberg, T. Clausen, "A Comparative Performance Study of the > Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-power a= nd > Lossy Networks (LLN)", Proceedings of the 8th ACM International Symposium > on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous > Networks (PE-WASUN), October 2011 > [2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight On-deman= d > Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)", > draft-yi-loadngct-01, Internet Draft (work in progress) > [3] J. Yi, T. Clausen, and A. Colin de Verdiere. "Efficient Data > Acquisition in Sensor Networks: Introducing (the) LOADng Collection Tree > Protocol", Proceedings of the 8th IEEE International Conference on Wirele= ss > Communications, Networking and Mobile Computing - WiCom-2012, October 201= 2 > [4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, =93Experiences with RPL: > IPv6 Routing Protocol for Low power and Lossy Networks=94, Internet Draft > (work in progress), draft-clausen-lln-rpl-experiences-06, February 2013. > [5] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for > Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013 IE= EE > Conference on Wireless Sensors > > Best regards > Ulrich > > > > On Mon, Jan 6, 2014 at 10:24 AM, JP Vasseur (jvasseur) > wrote: > >> I can see two paths: (1) ROLL WG ID (not the easiest though, although >> this could be seen as an applicability >> ID) or (2) AD sponsored ? >> >> On Jan 6, 2014, at 7:10 PM, Ines Robles >> wrote: >> >> >> >> >> >> * Hi, Thanks for this draft, >> https://ietf.org/doc/draft-tripathi-roll-reactive-applicability/ >> Abstr= act >> This document describes serious issues and shortcomings regarding the us= e >> of reactive routing protocols in low power and lossy networks(LLNs). >> Routing requirements for various LLN deployments are discussed in order = to >> judge how reactive routing may or may notadhere to the necessary criteri= a. >> We would like to know please, how is the intend for this document? how >> this draft would be aligned with roll charter?, should we re-chartering?= * >> >> *Thank you in advance,* >> >> Ines Robles >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > --001a1134db5424e16a04ef7b3676 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Somehow this email did not make it to the=A0WG mailing= list. Sorry if you get duplicate copy.

<= br>
Hi Ulrich,

Thanks for your comments = and feedback. Let me respond inline.

On Mon, Jan 6, 2014 at 7:14 PM, Ulrich Herberg <ulrich@herberg.name= > wrote:
Ines,

I object any form of publica= tion of this draft. In my opinion, it is another attempt to discredit LOADn= g and reactive protocols in general with false arguments.

Well LOADng is one recent example of= reactive protocols. However, we are not discussing about LOADng to *any* e= xtent in this draft.
=A0
As has been mentioned before, reactive protocols (in parti= cular LOADng) have been very successfully deployed in large LLN deployments= . So there is proof that in some LLN deployments, reactive protocols work v= ery well. Note that I do not claim they work in all such use cases, but the= MANET WG has understood this more than a decade before that reactive proto= cols can work in some scenarios, not in all. It is possible to create scena= rios where reactive protocols are better, and others where proactive protoc= ols are better.

We had tons of discussions on whethe= r LLNs can be generalized as MANETs. You are right to point out that "= MANET WG has understood this more than a decade before that reactive protoc= ols can work in some scenarios, not in all". Our argument through this= draft is, LLNs in general come under the scenario where reactive protocols= suffer due to the points made out in the draft. Note that there may be exa= mple where a reactive protocol works for a deployed LLN, but it does not me= an it will work better than a proactive counterpart for that deployment or = for any other deployment.

Claiming that, in general,= for LLNs one is better than the other is incorrect in my opinion.

But let me argue why I think this draft is flawed by picking the argume= nts made in the draft:

3.1. Inability to support P2MP traffic patter= n

This very much depends on the use case. LOADng has been deployed i= n several scenarios where P2MP traffic is sparse, and where few concurrent = traffic flows are used. This is not a theoretic scenario, but a deployment = that is actually used by some utilities.
=A0
Ability to support P2MP traffic patte= rn=A0for routing protocols in LLN is mandated by RFC 5548. Actually P2MP an= d MP2P traffics are pre-dominant for LLNs, and P2P traffic is considered ra= re. So for a protocol type to be considered a candidate to be used in LLNs = it is required to examine how it fairs to handle P2MP traffic.
=A0
We have shown in [1] that = in this case, LOADng outperforms RPL by far. See also [5] further evaluatio= ns. Not only has LOADng orders of magnitude less control traffic than RPL i= n the investigated scenarios, but also the state requirements are far small= er.

=A0At the same time, I wish to= point out that this document, in no form is a comparison between RPL and L= OADng. Simulation results in form of academic paper references are used to = show how a reactive protocol behaves in different scenarios in terms of dif= ferent metrics. Any protocol implementation can be done in an non-optimized= manner to show that performs poorly than another protocol. There are many = papers showing RPL outperforms LOADng, specially in large networks. But as = I mentioned before, this document does not provide any performance comparis= on. LOADng is used as an example. To my intuition, AODVv2 may behave in a s= imilar way as well. I do not think this WG is the right place to debate how= LOADng or any other protocol performs compared to RPL. This document shows= in which areas reactive protocols in general suffer to meet the routing re= quirements in LLNs, thus pointing out pitfalls to look for / areas of impro= vement.
=A0

3.2. Inability to support MP2P traffic pattern

There is an easy-= to-implement extension to LOADng submitted as [2] that solves this. Perform= ance evaluations in [3] show the efficiency of the solution.

4. Depe= ndency of control overhead on application module

This is a general observation of reactive protocols that the MANET WG h= as understood more than a decade ago. Again, observations of current traffi= c patterns in [1] show that reactive protocols have far less control traffi= c in current use cases of AMI metering.

I guess it is again a deployment and= protocol specific example. For a particular deployment and traffic pattern= , one protocol may work and meet the requirements. That does not mean the p= rotocol, or protocol-family in general, will be suited to meet the routing = requirements spelled out for LLNs in RFC 5548, RFC 5673, RFC 5826, RFC 5867= etc.=A0
=A0
Yes, in cases with lots of = concurrent traffic lows, then the argument is correct (note that the amount= of data does not really matter, as the route is only discovered once; so e= ven sending gigabytes/second would not be an issue as long as there are lim= ited amount of traffic flows). So this is another argument of the sort that= MANET rejected long time ago. It really depends on the use case and the ki= nd of traffic we are talking about.

The draft not does not even co= nsider any application traffic rate or range of data traffic rate. It consi= ders, as you pointed correctly, different flows, and future installation of= application modules. So I guess we both agree, that number of traffic flow= s is a factor in generating control overhead.


5. Flooding issues in LLNs

It is correct that flooding causes a = lot of overhead and battery drain. But note that we also observed in [1] an= d [4] that RPL in downward mode also causes a lot of control traffic, more = than LOADng for a similar scenario that is described in the draft. It again= depends on the use case. For example, with the extension proposed in [2], = the performance for such traffic in LOADng is at least as good as with RPL = (see also [3]). Note that in the described scenario, RPL would require an e= qual amount of state (in storing mode), or lead to very long packets in non= -storing mode and therefore potential fragmentation, such as described in [= 4].

I would again like to point ou= t that this draft is not a performance comparison between RPL and LOADng. H= owever, I would also like to point out that `N' number of unicast contr= ol packets consume less energy than `N' number of broadcast control pac= kets. The reasoning is provided in next subsection (5.1). In smaller deploy= ments and light traffic scenario, reactive protocols may incur less control= overhead than a proactive counterpart. However, most of these control pack= ets are broadcast packets, thus consuming much more energy than a proactive= counterpart even if the proactive protocol shows more control packets in t= he simulation. For deployments where reactive protocols create more control= overhead, they may require energy expense a magnitude larger, depending on= the MAC layer.


5.1. Impact of flooding in battery operated nodes

"Note tha= t there is a lot of experimental evidence supporting the claim that using f= looding or scoped flooding to discover routes is ill-suited to low-power an= d lossy networks (LLNs)". Where? I prefer citations over assertions.

The reasoning why this is the = case is provided with references is provided i version-02 of the draft. For= the detailed text, please refer to the version 02, which we just posted.
=A0
Note that I am not claiming that flooding is not costly, but it -- again --= depends on the scenario how many different concurrent traffic flows are re= quired and how long routes are stored. Also note that optimizations, such a= s MPR flooding, can optimize flooding compared to classic flooding.

6. Impact on memory

This again depends on the use case. As we ha= ve described in [4], RPL in storing mode also requires a lot of state. In n= on-storing mode, packets may become very long and lead to fragmentation. Wi= th few concurrent traffic flows, LOADng largely outperforms RPL in terms of= storage requirements (in many cases, a single route at a time may be suffi= cient).

With the assertion one more ti= me that this is not a performance comparison draft, I would like to point o= ut that with header compression, source routing is very much feasible even = over 802.15.4. And once again, you are comparing LOADng with *few concurren= t flows*. The argument will be invalid for nodes closer to a sink for a lar= ge scale network. I agree it depends on use cases and traffic profiles. How= ever this document, as I mentioned, provides a general overview, and is int= ended to consider superset of cases, and to guide implementors to look at t= he probable pitfalls that reactive protocols may be subjected to.

I understand there is no=A0one-size-fits-all for MANET,= but this is not MANET WG. What we are really trying to show in this docume= nt is where reactive protocols fail to meet the routing requirements for LL= Ns.=A0

I would appreciate further comments or=A0feedback.

Thanks &=A0Regards,
Joydeep
=A0

7. Lack of support for routing based on node capability

This arg= ument is flawed. LOADng provides a very extensible and flexible definition = of route metrics. It is easy to create a metric that reflects limitations o= f the nodes, such as energy and CPU/memory resource limitations. How is thi= s different from RPL?

8. High delay for emergency traffic

While it is true that reacti= ve protocols have a higher delay requirement than proactive protocols, the = argument is, again, flawed. The draft writes "*Some* data in an LLN ar= e delay sensitive by nature". I agree. It further mentions industrial = automation settings. Yes, in *some* LLNs, delay is indeed critical (e.g., l= ight switch), but in others it is not as much (AMI metering). The draft arg= ues that reactive protocols are bad for *all* LLNs, but provides evidence o= nly for *some*. This is exactly what the MANET WG has agreed on in the 1990= s that there is no one-size-fits-all.


[1] U. Herberg, T. Clausen, "A Comparative Performance Study o= f the Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-pow= er and Lossy Networks (LLN)", Proceedings of the 8th ACM International= Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiqui= tous Networks (PE-WASUN), October 2011
[2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight On-de= mand Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)", dr= aft-yi-loadngct-01, Internet Draft (work in progress)
[3] J. Yi, T. Clau= sen, and A. Colin de Verdiere. "Efficient Data Acquisition in Sensor N= etworks: Introducing (the) LOADng Collection Tree Protocol", Proceedin= gs of the 8th IEEE International Conference on Wireless Communications, Net= working and Mobile Computing - WiCom-2012, October 2012
[4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, =93Experiences with RPL: IP= v6 Routing Protocol for Low power and Lossy Networks=94, Internet Draft (wo= rk in progress), draft-clausen-lln-rpl-experiences-06, February 2013.
[5= ] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for = Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013= IEEE Conference on Wireless Sensors

Best regards
Ulrich



=
On Mon, Jan 6, 2014 at 10:24 AM, JP Va= sseur (jvasseur) <jvasseur@cisco.com> wrote:
I can see two paths: (1) ROLL WG ID (not the easiest though, although this = could be seen as an applicability
ID) or (2) AD sponsored ?

On Jan 6, 2014, at 7:10 PM, Ines Robles <mariainesrobles@googlemail.com> wrote:

Hi,
Abstract

This document describes serious issue= s and shortcomings regarding the use of reactive routing protocols in low power and lossy networks(LLNs= ). Routing requirements for various LLN deployments are discussed in order = to judge how reactive routing may or may notadhere to the necessary criteri= a.

We would like to know please, =A0how is the intend for this document? how thi= s draft would be aligned with roll charter?, should we re-chartering?

Thank you in advance,

Ines Robles


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




--001a1134db5424e16a04ef7b3676-- From stokcons@xs4all.nl Thu Jan 9 00:13: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 1893A1AE1C9 for ; Thu, 9 Jan 2014 00:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.007 X-Spam-Level: X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538] 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 LcBUObCpH6Wz for ; Thu, 9 Jan 2014 00:13:24 -0800 (PST) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by ietfa.amsl.com (Postfix) with ESMTP id D91791AE1DA for ; Thu, 9 Jan 2014 00:13:23 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube7.xs4all.net [194.109.20.205]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id s098DDI6099228 for ; Thu, 9 Jan 2014 09:13:13 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-67-41.w90-0.abo.wanadoo.fr ([90.0.42.41]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 09 Jan 2014 09:13:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 09 Jan 2014 09:13:13 +0100 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl (Wmn4zSxPviQr7PUjSNMJK3N+4zF02vuK) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] Trickle-mcast - Proactive Forwarding - ticket #103 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 08:13:26 -0000 Hi Don, Ines, I agree with Don's statement. It is pretty essential to get routers with multiple interfaces working and implement the concept of an admin -local scope policy implemented in an automatic fashion. Peter Don Sturek schreef op 2014-01-08 20:45: > Hi Ines, > > I believe it would be useful to have PROACTIVE_FORWARDING per > interface and not per forwarder. This would allow a device with > multiple interfaces to operate off of different MPL settings (for > example, a device that uses MPL in a HAN but also has an AMI interface > as well in the area of smart metering) > > Don > > From: Ines Robles > Reply-To: Routing Over Low power and Lossy networks > Date: Wednesday, January 8, 2014 11:30 AM > To: roll > Cc: Michael Richardson , "Jonathan Hui (johui)" > > Subject: [Roll] Trickle-mcast - Proactive Forwarding - ticket #103 > > Hello, > > We are clossing the issues for trickle-mcast draft, we have still this > open issue, ticket #103 [1], please we would like to have your opinion > about this suggestion: > > "...to increase MPL's applicability, PROACTIVE_FORWARDING should be a > per-interface and not a per-forwarder setting..." > [http://www.ietf.org/mail-archive/web/roll/current/msg08156.html [2]] > > Thank you in advance, > > Ines Robles. _______________________________________________ Roll > mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > [3] > > Links: > ------ > [1] http://trac.tools.ietf.org/wg/roll/trac/ticket/103 > [2] http://www.ietf.org/mail-archive/web/roll/current/msg08156.html > [3] https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac+roll@trac.tools.ietf.org Thu Jan 9 00:29: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 B93961AE1E7 for ; Thu, 9 Jan 2014 00:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 GYBnyl7omhlZ for ; Thu, 9 Jan 2014 00:29:26 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF021AE1D3 for ; Thu, 9 Jan 2014 00:29:26 -0800 (PST) Received: from localhost ([127.0.0.1]:48140 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W1AzD-0001ar-8B; Thu, 09 Jan 2014 09:29:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 09 Jan 2014 08:29:07 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/103#comment:6 Message-ID: <073.72f30d8f7737401aea0876322108cb63@trac.tools.ietf.org> References: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-Trac-Ticket-ID: 103 In-Reply-To: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Cc: roll@ietf.org Subject: Re: [Roll] [roll] #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS 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, 09 Jan 2014 08:29:28 -0000 #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS Comment (by mariainesrobles@gmail.com): Source: [http://www.ietf.org/mail-archive/web/roll/current/msg08415.html] From: peter van der Stok Date: Thu, 09 Jan 2014 09:13:13 +0100 I agree with Don's statement. It is pretty essential to get routers with multiple interfaces working and implement the concept of an admin -local scope policy implemented in an automatic fashion. Peter -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From esko.dijk@philips.com Thu Jan 9 02:33: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 CD6581AE24F for ; Thu, 9 Jan 2014 02:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 AHxb87ZVlJ2U for ; Thu, 9 Jan 2014 02:33:46 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7C72C1AE208 for ; Thu, 9 Jan 2014 02:33:45 -0800 (PST) Received: from mail139-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE026.bigfish.com (10.236.130.89) with Microsoft SMTP Server id 14.1.225.22; Thu, 9 Jan 2014 10:33:36 +0000 Received: from mail139-co9 (localhost [127.0.0.1]) by mail139-co9-R.bigfish.com (Postfix) with ESMTP id 2A26C2E02AB; Thu, 9 Jan 2014 10:33:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zz217bI15d6Oc85fhc540I9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh18c673h1de097h186068hz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2184h2216h22d0h2336h2438h1155h) Received: from mail139-co9 (localhost.localdomain [127.0.0.1]) by mail139-co9 (MessageSwitch) id 1389263614902200_25289; Thu, 9 Jan 2014 10:33:34 +0000 (UTC) Received: from CO9EHSMHS028.bigfish.com (unknown [10.236.132.227]) by mail139-co9.bigfish.com (Postfix) with ESMTP id D746F2C004A; Thu, 9 Jan 2014 10:33:34 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS028.bigfish.com (10.236.130.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 9 Jan 2014 10:33:34 +0000 Received: from 011-DB3MMR1-019.MGDPHG.emi.philips.com (10.128.28.106) by 011-DB3MMR1-009.MGDPHG.emi.philips.com (10.128.28.48) with Microsoft SMTP Server (TLS) id 14.3.158.2; Thu, 9 Jan 2014 10:32:49 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.51]) by 011-DB3MMR1-019.MGDPHG.emi.philips.com ([10.128.28.106]) with mapi id 14.03.0158.002; Thu, 9 Jan 2014 10:32:48 +0000 From: "Dijk, Esko" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Trickle-mcast - Proactive Forwarding - ticket #103 Thread-Index: AQHPDKgQLtw0SVXRcU6JAE0rn88KwJp8Mfag Date: Thu, 9 Jan 2014 10:32:47 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180CC5F00E@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED6180CC5F00E011DB3MPN2081MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Michael Richardson , "Jonathan Hui \(johui\)" Subject: Re: [Roll] Trickle-mcast - Proactive Forwarding - ticket #103 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, 09 Jan 2014 10:33:49 -0000 --_000_031DD135F9160444ABBE3B0C36CED6180CC5F00E011DB3MPN2081MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree that per-interface setting would be better; consider e.g. a 6LoWPAN b= order router as the MPL Forwarder. It has two interfaces e.g. LAN/802.15.4 = and may participate in a different MPL Domain per interface. Due to differe= nt properties of these technologies, a different setting for PROACTIVE_FORW= ARDING on these interfaces may be required. Esko From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Ines Robles Sent: Wednesday, January 08, 2014 20:30 To: roll Cc: Michael Richardson; Jonathan Hui (johui) Subject: [Roll] Trickle-mcast - Proactive Forwarding - ticket #103 Hello, We are clossing the issues for trickle-mcast draft, we have still this open= issue, ticket #103, pl= ease we would like to have your opinion about this suggestion: "...to increase MPL's applicability, PROACTIVE_FORWARDING should be a per-= interface and not a per-forwarder setting..." [http://www.ietf.org/mail-arc= hive/web/roll/current/msg08156.html] Thank you in advance, Ines Robles. ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED6180CC5F00E011DB3MPN2081MG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree that per-interfac= e setting would be better; consider e.g. a 6LoWPAN border router as the MPL= Forwarder. It has two interfaces e.g. LAN/802.15.4 and may participate in a different MPL Domain per interface. Due to different = properties of these technologies, a different setting for PROACTIVE_FORWARD= ING  on these interfaces may be required.

 

Esko

 

From: Roll [= mailto:roll-bounces@ietf.org] On Behalf Of Ines Robles
Sent: Wednesday, January 08, 2014 20:30
To: roll
Cc: Michael Richardson; Jonathan Hui (johui)
Subject: [Roll] Trickle-mcast - Proactive Forwarding - ticket #103

 

Hello,


We are clossing the issues for trickle-mcast draft, we have still this open= issue, ticket #103, please we would like to have your opini= on about this suggestion:

 

"...to increase MPL's applicability, PROACTIVE_FORWAR= DING  should be a per-interface and not a per-forwarder setting...&quo= t; [http://www.ietf.org/mail-archive/web/roll/curre= nt/msg08156.html]

 

Thank you in advance,

 

Ines Robles.


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED6180CC5F00E011DB3MPN2081MG_-- From trac+roll@trac.tools.ietf.org Thu Jan 9 03:21: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 08E5F1AE24A for ; Thu, 9 Jan 2014 03:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 Rm7TT5G4ZkNr for ; Thu, 9 Jan 2014 03:21:02 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E50E11AE157 for ; Thu, 9 Jan 2014 03:21:01 -0800 (PST) Received: from localhost ([127.0.0.1]:55786 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W1Df9-0001B2-G1; Thu, 09 Jan 2014 12:20:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 09 Jan 2014 11:20:35 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/103#comment:7 Message-ID: <073.79fd320fea308214dc62cb8b89b04624@trac.tools.ietf.org> References: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-Trac-Ticket-ID: 103 In-Reply-To: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Cc: roll@ietf.org Subject: Re: [Roll] [roll] #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS 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, 09 Jan 2014 11:21:04 -0000 #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS Comment (by mariainesrobles@gmail.com): Source: http://www.ietf.org/mail-archive/web/roll/current/msg08417.html From: "Dijk, Esko" Date: Thu, 9 Jan 2014 10:32:47 +0000 Agree that per-interface setting would be better; consider e.g. a 6LoWPAN border router as the MPL Forwarder. It has two interfaces e.g. LAN/802.15.4 and may participate in a different MPL Domain per interface. Due to different properties of these technologies, a different setting for PROACTIVE_FORWARDING on these interfaces may be required. Esko -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From mcr@sandelman.ca Fri Jan 10 05:51: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 B12ED1AE04B for ; Fri, 10 Jan 2014 05:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.136 X-Spam-Level: ** X-Spam-Status: No, score=2.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, LOCALPART_IN_SUBJECT=1.107, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_MIME_NO_TEXT=0.01, 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 j5K6hH4pUdMO for ; Fri, 10 Jan 2014 05:50:59 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id C14571AE015 for ; Fri, 10 Jan 2014 05:50:59 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3858E2002D; Fri, 10 Jan 2014 10:06:17 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id C853C64647; Fri, 10 Jan 2014 08:50:48 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B1C2F63AD7; Fri, 10 Jan 2014 08:50:48 -0500 (EST) From: Michael Richardson To: draft-do-roll-p2p-backup@tools.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 10 Jan 2014 08:50:48 -0500 Message-ID: <20098.1389361848@sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: [Roll] draft-do-roll-p2p-backup X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 13:51:03 -0000 --=-=-= http://tools.ietf.org/id/draft-do-roll-p2p-backup-01.txt recently expired. Abstract In this draft, a backup path setup mechanism is proposed for the P2P-RPL protocol in Low Power and Lossy Networks (LLNs). This mechanism allows sensor nodes to send packets over the backup path without rediscovering the p2p path in case of path failure, thus improving the reliability of p2p transmission. ==== I read the document prior to it expiring, and I can see how this could be useful in many networks. The document claims: Nodes utilize the interactive path as alternative to quickly recover from failure to send packets to the destination instead of recreating the path. It would be interesting to have feedback from deployments about how valuable having an alternative path would be. I did not yet understand how the backup nodes are used. Can this protocol be incrementally deployed? Is there interest in further discussion of this document? -- 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) iQCVAwUBUs/6toqHRg3pndX9AQKQeAQAwKBHBvBMfWrpUj/SbZfUozcxCT9etR0L gi0Fv6djSqx4o+EjDj4tFQtszo/XUAlicmMkhSjCpAJBnT8f12PHuTWwiUHOFuX5 aDDdQGb9/yXkSmvpCxyrvC4p/5gBQ6hHwN6vSzuzHBlRHSRS55sFB/zbTm6t31QY TBYEaVep44c= =AW73 -----END PGP SIGNATURE----- --=-=-=-- From pierre.roux@cea.fr Mon Jan 13 03:00: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 5CE0B1AE109 for ; Mon, 13 Jan 2014 03:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.089 X-Spam-Level: X-Spam-Status: No, score=-7.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 OzJQzJarRw0e for ; Mon, 13 Jan 2014 03:00:55 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF2F1AE05C for ; Mon, 13 Jan 2014 03:00:54 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0DB0gOt026696; Mon, 13 Jan 2014 12:00:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EA88B2073CF; Mon, 13 Jan 2014 12:01:48 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DAAC420763D; Mon, 13 Jan 2014 12:01:48 +0100 (CET) Received: from EXCAH-A0.intra.cea.fr (excah-a0.intra.cea.fr [132.166.88.74]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0DB0fQ7010016; Mon, 13 Jan 2014 12:00:41 +0100 Received: from EXDAG0-B1.intra.cea.fr ([fe80::c18e:d8e8:9a27:5b84]) by EXCAH-A0.intra.cea.fr ([fe80::446e:fe1a:2892:9de1%10]) with mapi id 14.02.0387.000; Mon, 13 Jan 2014 12:00:41 +0100 From: ROUX Pierre To: Michael Richardson Thread-Topic: [Roll] draft-roux-roll-mpl-eval-00.txt Thread-Index: AQHPAN8vHleayCjs60m9whfy9w8NC5qChAyg Date: Mon, 13 Jan 2014 11:00:41 +0000 Message-ID: <734BA99AFA6E0040A82152C6794C6D7D2ECA21DA@EXDAG0-B1.intra.cea.fr> References: <23888.1387913651@sandelman.ca> In-Reply-To: <23888.1387913651@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.105] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-20428.003 x-tm-as-result: No--61.599500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] draft-roux-roll-mpl-eval-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 11:00:58 -0000 Dear Michael, Sorry for being slow in answering. We did not catch your message when you s= ent it. And thanks for this feedback. >It would be interesting to have feedback from deployments about how accura= te the random placement matches real life:=20 >I think that real life won't be random at all! Yes.=20 Random placements inside open field area with no obstacle is not real life. However it provides some "neutral" ground to compare different algorithms. > Do you think that the additional work will occur prior to IETF90, and mig= ht be feedback into possible re-chartering of ROLL? This ID was just collecting preliminary results indeed.=20 Some additional results will be presented in a second version of this draft= for IETF90. A presentation could also be proposed depending on the time sc= hedule and need. Unfortunately it will remain far from an exhaustive evaluation at this date= . >Is the software used in this simulation available for others to play with? Currently it is just an internal java tool. However we don't expect issues in making the jar executable available. It may be a good way to obtain feedback, as the simulator provides graphica= l insight into algorithm behavior. We have to clarify that internally, as it should be provided with some kind= of license. >I'm concerned that this is a particularly academic paper, and might not ge= t the kind of peer review that I think it deserves as an ID (vs a submissio= n to a journal). Yes we understand your concern. This work may eventually be proposed to a j= ournal as well. Still, feedback is very welcome in this group. Regards, Pierre -----Message d'origine----- De=A0: Roll [mailto:roll-bounces@ietf.org] De la part de Michael Richardson Envoy=E9=A0: mardi 24 d=E9cembre 2013 20:34 =C0=A0: draft-roux-roll-mpl-eval@tools.ietf.org Cc=A0:=20 Objet=A0: [Roll] draft-roux-roll-mpl-eval-00.txt http://datatracker.ietf.org/doc/draft-roux-roll-mpl-eval/ was recently posted, with the abstract: Abstract This draft presents simulation work and first results related to MPL performance evaluation. The simulation makes it possible to evaluate MPL performances in the context of a large network. The simulated network introduces 500 nodes. The general principles of the simulator are described. Then reference settings are introduced, and evaluation indicators are proposed. Finally preliminary results are presented under the form of a few tables, that show the proposed indicator values depending on some specific parameter which is used as a variable argument. Among various results, the advantage of using reactive mode for MPL is shown in terms of the capability to maintain loss free diffusion in harsh radio conditions. =3D=3D=3D=3D I've read the document, and I like the direction which it is going. It would be interesting to have feedback from deployments about how accurat= e the random placement matches real life: I think that real life won't be r= andom at all! The ROLL charter hardly mentions MPL at all; so having an experience draft = on it, is neither here nor there. ** May I ask what the authors intend for this document? Do you think that the additional work will occur prior to IETF90, and might= be feedback into possible re-chartering of ROLL? I think that it is very useful for the technology to have a rigorous analys= is of MPL like this, and very useful for standardization to have some clear= advice on setting the parameters. Is the software used in this simulation available for others to play with? I'm concerned that this is a particularly academic paper, and might get the= kind of peer review that I think it deserves as an ID (vs a submission to = a journal). -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From mariainesrobles@googlemail.com Mon Jan 13 17:58: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 A93211ADFAE for ; Mon, 13 Jan 2014 17:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f24pfXcatS3 for ; Mon, 13 Jan 2014 17:58:20 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76D1AD8EA for ; Mon, 13 Jan 2014 17:58:20 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id d13so114012wiw.7 for ; Mon, 13 Jan 2014 17:58:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=rwAONDoQAbfaRxSgU3D9TJft5bei0K213nZbbrPVGfs=; b=fBw4RPCal6LYLWilGIiyLyBjd3btBFel5YmExvXywnOcWMxm5q0v/oQPiP9EmDglZd AwZDkrXujCM3887rINxm7NKyA0D4kW3epDiiW6tvnvtzrdvLXUEL6a344lyFztJRDNa9 4EXX9IajT/sN4DdaZ6rNt0+BmSVpzZpdITtOSoFc7fMbwZyljBD27e5XcnM9roaCux8v VCXWH/5cXAWE/I94Kn8wl8FT7iwbrvE4ki7Yu9AVmuwFoOqVbiWj1Rwa8J+YERZAYZgh /eGh9Wcu0Dvhf496Z3NlskWh/H0S2KfTZvAg9/Q+8Yrc2+6rdMHiRadzTTsF9HjetL4U sh4Q== MIME-Version: 1.0 X-Received: by 10.180.95.162 with SMTP id dl2mr282377wib.17.1389664688460; Mon, 13 Jan 2014 17:58:08 -0800 (PST) Received: by 10.216.44.144 with HTTP; Mon, 13 Jan 2014 17:58:08 -0800 (PST) Date: Mon, 13 Jan 2014 23:58:08 -0200 Message-ID: From: Ines Robles To: yusuke.doi@toshiba.co.jp, matthew.gillmore@itron.com Content-Type: multipart/alternative; boundary=f46d0444e9831cd93904efe486c5 Cc: Michael Richardson , roll , "Bernie Volz \(volz\)" Subject: [Roll] Fwd: DHCPv6 option for MPL parameter configuration 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, 14 Jan 2014 01:58:22 -0000 --f46d0444e9831cd93904efe486c5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, *Related to the draft-doi-roll-mpl-parameter-configuration , we asked for an opinion to DHC wg .Please read below for more detail. Any comments are very welcome.Thanks and Regards,Michael and Ines.* ---------- Forwarded message ---------- From: Bernie Volz (volz) Date: 2013/12/17 Subject: Re: DHCPv6 option for MPL parameter configuration To: Ines Robles , " tomasz.mrugalski@gmail.com" Cc: Michael Richardson Hi: Thanks for asking =85 I don't see any problems with the proposed option format. You will need to decide if using (what looks like) your own floating point format is worth it (perhaps saving what looks to me like 7*2 (=3D14) bytes to use 32-bit floating pointer numbers) is worth it. Please improve the IANA section to indicate which registry IANA should assign from =97 see SolMax draft for language? There have been mistakes mad= e by IANA in the past and it is important to be clear about the registry they must use!! I haven't studied the draft carefully and just looked at the option definition section mostly. May have other comments later as I hope to look at it more carefully. - Bernie From: Ines Robles Date: Monday, December 16, 2013 11:33 PM To: Cisco Employee , Tomek Mrugalski < tomasz.mrugalski@gmail.com> Cc: Michael Richardson Subject: DHCPv6 option for MPL parameter configuration * Hello Bernie and Tomek, The roll wg have a draft, which specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. Different parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. [draft-ietf-roll-trickle-mcast ] To define a way to distribute these MPL Parameter Configuration option, it is proposed uses a simple DHCPv6 option, which is defined in draft-doi-roll-mpl-parameter-configuration . Please, we would like to have your advice whether It would be ok use a DHCPv6 option to do that. Following draft-ietf-dhc-option-guidelines , which would be the best option format for short floating point (section 5)? should it use encapsulated options? Thank you very much in advance, Michael and Ines. * --f46d0444e9831cd93904efe486c5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

Related to the draft-doi-roll-mpl-parameter-configuratio= n, we asked for an opinion to DHC wg.


Please read below for more detail. Any comments are very welcome.


Thanks and Regards,


Michael and Ines.


<= /span>
---------- Forwarded message ---= -------
From: Bernie Volz (volz) <volz@cisco.com>
Da= te: 2013/12/17
Subject: Re: DHCPv6 option for MPL parameter configuratio= n
To: Ines Robles <maria= inesrobles@googlemail.com>, "tomasz.mrugalski@gmail.com" <tomasz.mrugalski@gmail.com>
Cc: Michael Richardson <mcr+i= etf@sandelman.ca>


Hi:

Thanks for asking =85

I don't see any problems with the proposed option format. You will= need to decide if using (what looks like) your own floating point format i= s worth it (perhaps saving what looks to me like 7*2 (=3D14) bytes to use 3= 2-bit floating pointer numbers) is worth it.

Please improve the IANA section to indicate which registry IANA should= assign from =97 see SolMax draft for language? There have been mistakes ma= de by IANA in the past and it is important to be clear about the registry t= hey must use!!

I haven't studied the draft carefully and just looked at the optio= n definition section mostly. May have other comments later as I hope to loo= k at it more carefully.

- Bernie

From: Ines Robles <mariainesrobles@goog= lemail.com>
Date: Monday, December 16, 2013 11:= 33 PM
To: Cisco Employee <volz@cisco.com>, Tomek Mruga= lski <to= masz.mrugalski@gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
Subject: DHCPv6 option for MPL para= meter configuration

= Hello =A0Bernie and Tomek,<= /span>

=

=

The=A0

roll

wg have a draft, which spec= ifies the Multicast Protocol for Low power and Lossy Networks (MPL) that pr= ovides IPv6 multicast forwarding in constrained networks. Different parameter configurations all= ow MPL to trade between dissemination latency and transmission efficiency. = [draft-ietf-roll-tr= ickle-mcast]

=

= To define a way to distribu= te these MPL Parameter Configuration option, it is proposed uses a simple DHCPv6 option, which is= defined in draft-= doi-roll-mpl-parameter-configuration.


= Please, we would like to ha= ve your advice whether It would be ok use a DHCPv6 option to do that.

= Following draft-ietf-dhc-option-guidelines,

which would be the best option format for short floating point (section 5)?

should it use encapsulated options?

=


= Thank you very much in adva= nce,


Michael and Ines.

--f46d0444e9831cd93904efe486c5-- From Daniel.Popa@itron.com Tue Jan 14 06:28: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 5E99C1AE0D5 for ; Tue, 14 Jan 2014 06:28:54 -0800 (PST) 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 E9U4CO5emb40 for ; Tue, 14 Jan 2014 06:28:52 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id DF2581ADBE5 for ; Tue, 14 Jan 2014 06:28:51 -0800 (PST) Received: from BY2PR04MB807.namprd04.prod.outlook.com (10.141.224.149) by BY2PR04MB806.namprd04.prod.outlook.com (10.141.224.147) with Microsoft SMTP Server (TLS) id 15.0.842.7; Tue, 14 Jan 2014 14:28:32 +0000 Received: from BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) by BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) with mapi id 15.00.0842.003; Tue, 14 Jan 2014 14:28:32 +0000 From: "Popa, Daniel" To: "roll@ietf.org" , "clonvick@cisco.com" , "mariainesrobles@gmail.com" Thread-Topic: [roll] #135: Point to the Security Considerations section of RFC 6550 Thread-Index: AQHO+utphYj6q9McHEuH0gg3MWexxpqEc2eA Date: Tue, 14 Jan 2014 14:28:31 +0000 Message-ID: <7368afb294714efd9faf5aef5dc13e18@BY2PR04MB807.namprd04.prod.outlook.com> References: <067.d2b714cc0ac70ebe3021413da1fe7ea3@trac.tools.ietf.org> In-Reply-To: <067.d2b714cc0ac70ebe3021413da1fe7ea3@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.2.132.2] x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(669001)(679001)(689001)(779001)(189002)(199002)(53754006)(288314003)(55784002)(54356001)(79102001)(53806001)(47736001)(54316002)(92566001)(49866001)(19580405001)(46102001)(50986001)(66066001)(65816001)(47976001)(63696002)(83322001)(80976001)(19580395003)(51856001)(2201001)(93136001)(81816001)(33646001)(76796001)(77982001)(56776001)(76482001)(59766001)(2656002)(76576001)(74876001)(87936001)(31966008)(4396001)(87266001)(81342001)(90146001)(85306002)(74662001)(81686001)(76786001)(80022001)(69226001)(56816005)(85852003)(15975445006)(83072002)(47446002)(15202345003)(74706001)(74366001)(74316001)(81542001)(74502001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR04MB806; H:BY2PR04MB807.namprd04.prod.outlook.com; CLIP:109.2.132.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: itron.com Cc: "draft-ietf-roll-applicability-ami.all@tools.ietf.org" Subject: Re: [Roll] [roll] #135: Point to the Security Considerations section of RFC 6550 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, 14 Jan 2014 14:28:54 -0000 SGVsbG8gYWxsLCANCg0KQ2hyaXMsIHRoYW5rIHlvdSBmb3IgZmVlZGJhY2suIA0KDQpXZSB3aWxs IHVwZGF0ZSB0aGUgbmV3IHJldmlzaW9uIG9mIHRoZSBkcmFmdCBhY2NvcmRpbmdseS4gDQoNClJl Z2FyZHMsDQpEYW5pZWwNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiByb2xs IGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjK3JvbGxAZ3JlbmFjaGUudG9vbHMuaWV0Zi5vcmdd IA0KRW52b3nDqcKgOiBtYXJkaSAxNyBkw6ljZW1icmUgMjAxMyAwNjo0NQ0Kw4DCoDogZHJhZnQt aWV0Zi1yb2xsLWFwcGxpY2FiaWxpdHktYW1pLmFsbEB0b29scy5pZXRmLm9yZzsgbWFyaWFpbmVz cm9ibGVzQGdtYWlsLmNvbQ0KQ2PCoDogcm9sbEBpZXRmLm9yZw0KT2JqZXTCoDogW3JvbGxdICMx MzU6IFBvaW50IHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIFJGQyA2 NTUwDQoNCiMxMzU6IFBvaW50IHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u IG9mIFJGQyA2NTUwDQoNCiBTb3VyY2U6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9zZWNkaXIvY3VycmVudC9tc2cwNDQ3Ny5odG1sDQoNCg0KIEZyb206IENocmlzIExvbnZp Y2sgPGNsb252aWNrIGF0IGNpc2NvLmNvbT4NCiBEYXRlOiBGcmksIDEzIERlYyAyMDEzIDExOjQx OjU0IC0wODAwIChQU1QpDQoNCg0KDQog4oCcVGhlIGRvY3VtZW50IGlzIGluY29tcGxldGUgYnV0 IGl0IGFwcGVhcnMgdGhhdCB0aGUgYXV0aG9ycyBrbm93IHdoZXJlICB0aGV5IHdhbnQgdG8gZ28g d2l0aCBpdC4NCiBJIHdvdWxkIHJlY29tbWVuZCB0aGF0IHRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uIHBvaW50IHRvIHRoZSAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlv biBvZiBSRkMgNjU1MCAoUlBMKSBhbmQgc2F5IHRoYXQgdGhlIHJvbGwtICBhcHBsaWNhYmlsaXR5 LWFtaSBkb2N1bWVudCBpcyBhIGRlc2NyaXB0aW9uIG9mIHRoZSBhcHBsaWNhYmlsaXR5IG9mIDY1 NTAgIHRvIHRoZSBhbWksIHRoZXJlZm9yZSB0aGUgY29uc2lkZXJhdGlvbnMgb2YgNjU1MCBhcHBs eS7igJ0NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tDQogUmVwb3J0ZXI6ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1yb2xsLQ0KICBtYXJpYWluZXNyb2JsZXNAZ21haWwuY29t ICAgICAgICAgIHwgIGFwcGxpY2FiaWxpdHktDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAg ICAgICAgICAgfCAgYW1pLmFsbEB0b29scy5pZXRmLm9yZw0KIFByaW9yaXR5OiAgbWFqb3IgICAg ICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czogIG5ldw0KQ29tcG9uZW50OiAgYXBwbGljYWJp bGl0eS1hbWkgICAgICAgIHwgIE1pbGVzdG9uZToNCiBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1 bWVudCAgICAgICB8ICAgIFZlcnNpb246DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvd2cvcm9sbC90cmFjL3RpY2tldC8xMzU+DQpyb2xsIDxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvd2cvcm9sbC8+DQoNCg== From Daniel.Popa@itron.com Tue Jan 14 06:49:00 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 3CCEC1AE0D6 for ; Tue, 14 Jan 2014 06:49:00 -0800 (PST) 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 tLdcX14HscXg for ; Tue, 14 Jan 2014 06:48:57 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3F27E1AE05F for ; Tue, 14 Jan 2014 06:48:57 -0800 (PST) Received: from BY2PR04MB807.namprd04.prod.outlook.com (10.141.224.149) by BY2PR04MB807.namprd04.prod.outlook.com (10.141.224.149) with Microsoft SMTP Server (TLS) id 15.0.842.7; Tue, 14 Jan 2014 14:48:44 +0000 Received: from BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) by BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) with mapi id 15.00.0842.003; Tue, 14 Jan 2014 14:48:44 +0000 From: "Popa, Daniel" To: "roll@ietf.org" , "'clonvick@cisco.com'" , "mariainesrobles@gmail.com" Thread-Topic: [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used Thread-Index: AQHO+uwD2eu7e2v53EymWeo4If1VDpqEdBng Date: Tue, 14 Jan 2014 14:48:44 +0000 Message-ID: <9546f1bf3d68401a8cdf837ca5528de4@BY2PR04MB807.namprd04.prod.outlook.com> References: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> In-Reply-To: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.2.132.2] x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(679001)(779001)(689001)(53754006)(288314003)(199002)(189002)(55784002)(85852003)(90146001)(56816005)(74316001)(83072002)(50986001)(31966008)(74662001)(47976001)(47446002)(33646001)(65816001)(56776001)(69226001)(81342001)(63696002)(79102001)(93136001)(54356001)(66066001)(77982001)(53806001)(74366001)(76482001)(51856001)(74502001)(81542001)(46102001)(59766001)(80022001)(54316002)(87936001)(80976001)(76796001)(87266001)(4396001)(19580405001)(19580395003)(83322001)(76786001)(47736001)(49866001)(2656002)(76576001)(74876001)(15202345003)(74706001)(81686001)(81816001)(85306002)(15975445006)(92566001)(24736002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR04MB807; H:BY2PR04MB807.namprd04.prod.outlook.com; CLIP:109.2.132.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: itron.com Cc: "draft-ietf-roll-applicability-ami.all@tools.ietf.org" Subject: Re: [Roll] [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used 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, 14 Jan 2014 14:49:00 -0000 SGVsbG8gYWxsLCANCg0KQ2hyaXM6DQoNCkp1c3QgdG8gY2xhcmlmeTogVGhlIGFwcGxpY2FiaWxp dHkgc3RhdGVtZW50IGZvciBBTUkgbmV0d29yayBmb2N1c2VzIG9uIHVzZSBvZiBSUEwgKCsgNkxv d1BBTi9JUHY2KSBvdmVyIHN0YW5kYXJkIElFRUUgd2lyZWxlc3MgYW5kIFBMQyBsaW5rLWxheWVy IHRlY2hub2xvZ2llcyAgKGkuZS4sIElFRUUgU3RkIDgwMi4xNS40Zy80ZSBhbmQgSUVFRSBTdGQg UDE5MDEuMiwgcmVzcGVjdGl2ZWx5KS4gRWFjaCBvZiB0aGVzZSBzdGFuZGFyZHMgaXMgY29taW5n IHdpdGggYSBsaW5rLWxheWVyIHNlY3VyaXR5IHNwZWNpZmljYXRpb24uIA0KDQpGb2xsb3dpbmcg eW91IHJlY29tbWVuZGF0aW9uOiB3ZSBjYW4gYWRkIGEgbmV3IHNlY3Rpb24gLSAiU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMiIC0gdG8gdGhlIHNlY3Rpb24gd2hlcmUgd2UgZGVzY3JpYmUgdGhlIGxp bmstbGF5ZXIgc2VjdXJpdHkgZmVhdHVyZXMgKGkuZS4sIHRvIHRoZSBTZWN0aW9uIDkuMi4zIGNh bGxlZCAiU2VjdXJpdHkgZmVhdHVyZXMgcHJvdmlkZWQgYnkgdGhlIE1BQyBzdWItbGF5ZXIiKS4g QWx0ZXJuYXRpdmVseSwgd2UgY2FuIGtlZXAgdGhlIFNlY3Rpb24gOS4yLjMgYXMgaXQgaXMgYW5k IGluIHRoZSBjb250ZW50IHRoYXQgd2lsbCBiZSBwcm92aWRlZCB3ZSBkZXNjcmliZSBob3cgdGhl IGxpbmstbGF5ZXIgc2VjdXJpdHkgZmVhdHVyZXMgd2lsbCBtZWV0IHRoZSByZXF1aXJlbWVudHMg b2YgdGhlIFJQTCBzZWN1cml0eSBzZXJ2aWNlcy4gIFdoaWNoIG9mIHRoZXNlIGFwcHJvYWNoZXMg d2lsbCBiZXR0ZXIgYW5zd2VyIHlvdXIgcmVxdWVzdD8NCg0KV291bGQgc3VjaCBjbGFyaWZpY2F0 aW9ucyBtZWV0IHlvdXIgZXhwZWN0YXRpb25zPyANCg0KUmVnYXJkcywNCkRhbmllbA0KDQotLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IHJvbGwgaXNzdWUgdHJhY2tlciBbbWFpbHRv OnRyYWMrcm9sbEBncmVuYWNoZS50b29scy5pZXRmLm9yZ10gDQpFbnZvecOpwqA6IG1hcmRpIDE3 IGTDqWNlbWJyZSAyMDEzIDA2OjUxDQrDgMKgOiBkcmFmdC1pZXRmLXJvbGwtYXBwbGljYWJpbGl0 eS1hbWkuYWxsQHRvb2xzLmlldGYub3JnOyBtYXJpYWluZXNyb2JsZXNAZ21haWwuY29tDQpDY8Kg OiByb2xsQGlldGYub3JnDQpPYmpldMKgOiBbcm9sbF0gIzEzNjogLSBkcmFmdC1pZXRmLXJvbGwt YXBwbGljYWJpbGl0eS1hbWkgLSBBZGQgYSBzZWN0aW9uIG9mIHRoZSBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyBmb3IgZWFjaCBpbnN0YW5jZSB3aGVyZSB0aGUgUlBMIHNlY3VyaXR5IG1lY2hhbmlz bSBhcmUgbm90IHRvIGJlIHVzZWQNCg0KIzEzNjogLSBkcmFmdC1pZXRmLXJvbGwtYXBwbGljYWJp bGl0eS1hbWkgLSBBZGQgYSBzZWN0aW9uIG9mIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBm b3IgZWFjaCBpbnN0YW5jZSB3aGVyZSB0aGUgUlBMIHNlY3VyaXR5IG1lY2hhbmlzbSBhcmUgbm90 IHRvIGJlIHVzZWQNCg0KIFNvdXJjZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3NlY2Rpci9jdXJyZW50L21zZzA0NDc3Lmh0bWwNCg0KDQogRnJvbTogQ2hyaXMgTG9udmlj ayA8Y2xvbnZpY2sgYXQgY2lzY28uY29tPg0KIERhdGU6IEZyaSwgMTMgRGVjIDIwMTMgMTE6NDE6 NTQgLTA4MDAgKFBTVCkNCg0KDQoNCiDigJxUaGUgYXV0aG9ycyBub3RlIHRoYXQgb3RoZXIgc2Vj dXJpdHkgbWVjaGFuaXNtcyBtYXkgYmUgdXNlZCwgd2hpY2ggd291bGQgIG1lYW4gdGhhdCB0aGUg c2VjdXJpdHkgZnVuY3Rpb25zIG9mIFJQTCB3b3VsZCBub3QgYmUgbmVlZGVkLiBJIHdvdWxkICBy ZWNvbW1lbmQgdGhhdCBhIHNlY3Rpb24gb2YgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGJl IGFkZGVkIGZvciBlYWNoICBpbnN0YW5jZSB3aGVyZSB0aGUgUlBMIHNlY3VyaXR5IG1lY2hhbmlz bSBhcmUgbm90IHRvIGJlIHVzZWQuIEVhY2ggb2YgIHRob3NlIHNlY3Rpb25zIHNob3VsZCBzaG93 IGhvdyB0aGUgcmVwbGFjZW1lbnQgbWVjaGFuaXNtcyB3aWxsIG1lZXQgdGhlICByZXF1aXJlbWVu dHMgb2YgdGhlIFJQTCBzZWN1cml0eSBzZXJ2aWNlcyB0aGF0IGFyZSBkZXNjcmliZWQgaW4gNjU1 MC7igJ0NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tDQogUmVwb3J0ZXI6ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1yb2xsLQ0KICBtYXJpYWluZXNyb2JsZXNAZ21haWwuY29t ICAgICAgICAgIHwgIGFwcGxpY2FiaWxpdHktDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAg ICAgICAgICAgfCAgYW1pLmFsbEB0b29scy5pZXRmLm9yZw0KIFByaW9yaXR5OiAgbWFqb3IgICAg ICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czogIG5ldw0KQ29tcG9uZW50OiAgYXBwbGljYWJp bGl0eS1hbWkgICAgICAgIHwgIE1pbGVzdG9uZToNCiBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1 bWVudCAgICAgICB8ICAgIFZlcnNpb246DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvd2cvcm9sbC90cmFjL3RpY2tldC8xMzY+DQpyb2xsIDxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvd2cvcm9sbC8+DQoNCg== From Daniel.Popa@itron.com Tue Jan 14 06:55:11 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6281AE0CC for ; Tue, 14 Jan 2014 06:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZLXEQBONAheS for ; Tue, 14 Jan 2014 06:55:08 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0761ADFB6 for ; Tue, 14 Jan 2014 06:55:08 -0800 (PST) Received: from BY2PR04MB807.namprd04.prod.outlook.com (10.141.224.149) by BY2PR04MB808.namprd04.prod.outlook.com (10.141.224.151) with Microsoft SMTP Server (TLS) id 15.0.842.7; Tue, 14 Jan 2014 14:54:55 +0000 Received: from BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) by BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) with mapi id 15.00.0842.003; Tue, 14 Jan 2014 14:54:55 +0000 From: "Popa, Daniel" To: "roll@ietf.org" , "'clonvick@cisco.com'" , "mariainesrobles@gmail.com" Thread-Topic: [roll] #137: - draft-ietf-roll-applicability-ami - Incorporate a model for initial and incremental deployments Thread-Index: AQHO+uxgFFQ6mXNOrE+60p6w3a/cBJqEegZg Date: Tue, 14 Jan 2014 14:54:54 +0000 Message-ID: <02cc57427b5d49d69502d5a295b3332e@BY2PR04MB807.namprd04.prod.outlook.com> References: <067.e03655bb677c0fb217ee063fe7daaa4a@trac.tools.ietf.org> In-Reply-To: <067.e03655bb677c0fb217ee063fe7daaa4a@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.2.132.2] x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(679001)(689001)(779001)(55784002)(53754006)(189002)(199002)(288314003)(76786001)(85306002)(76576001)(76796001)(81686001)(80976001)(50986001)(47976001)(74366001)(15202345003)(19580405001)(49866001)(4396001)(79102001)(63696002)(74316001)(33646001)(56776001)(46102001)(19580395003)(76482001)(74706001)(83322001)(47446002)(74876001)(74502001)(51856001)(54316002)(69226001)(54356001)(85852003)(53806001)(74662001)(31966008)(65816001)(56816005)(15975445006)(561944002)(90146001)(2656002)(87266001)(87936001)(66066001)(80022001)(59766001)(83072002)(81342001)(77982001)(81816001)(47736001)(81542001)(92566001)(93136001)(24736002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR04MB808; H:BY2PR04MB807.namprd04.prod.outlook.com; CLIP:109.2.132.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: itron.com Cc: "draft-ietf-roll-applicability-ami.all@tools.ietf.org" Subject: Re: [Roll] [roll] #137: - draft-ietf-roll-applicability-ami - Incorporate a model for initial and incremental deployments 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, 14 Jan 2014 14:55:11 -0000 SGVsbG8gYWxsLCANCg0KQ2hyaXM6IHdlIHdpbGwgY29uc2lkZXIgeW91ciByZWNvbW1lbmRhdGlv bi4gV2Ugd2lsbCBiZSBiYWNrIHdpdGggYSBwcm9wb3NhbCBmb3IgYSBwb3RlbnRpYWwgcmVzdHJ1 Y3R1cmF0aW9uIG9mIHRoZSBzZWN0aW9uICJTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIsIHRvIHNl ZSBpZiBpdCBtZWV0cyB5b3VyIHJlcXVlc3QuIA0KDQpSZWdhcmRzLA0KRGFuaWVsIA0KDQotLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IHJvbGwgaXNzdWUgdHJhY2tlciBbbWFpbHRv OnRyYWMrcm9sbEBncmVuYWNoZS50b29scy5pZXRmLm9yZ10gDQpFbnZvecOpwqA6IG1hcmRpIDE3 IGTDqWNlbWJyZSAyMDEzIDA2OjU0DQrDgMKgOiBkcmFmdC1pZXRmLXJvbGwtYXBwbGljYWJpbGl0 eS1hbWkuYWxsQHRvb2xzLmlldGYub3JnOyBtYXJpYWluZXNyb2JsZXNAZ21haWwuY29tDQpDY8Kg OiByb2xsQGlldGYub3JnDQpPYmpldMKgOiBbcm9sbF0gIzEzNzogLSBkcmFmdC1pZXRmLXJvbGwt YXBwbGljYWJpbGl0eS1hbWkgLSBJbmNvcnBvcmF0ZSBhIG1vZGVsIGZvciBpbml0aWFsIGFuZCBp bmNyZW1lbnRhbCBkZXBsb3ltZW50cw0KDQojMTM3OiAtIGRyYWZ0LWlldGYtcm9sbC1hcHBsaWNh YmlsaXR5LWFtaSAtIEluY29ycG9yYXRlIGEgbW9kZWwgZm9yIGluaXRpYWwgYW5kIGluY3JlbWVu dGFsIGRlcGxveW1lbnRzDQoNCiBTb3VyY2U6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9zZWNkaXIvY3VycmVudC9tc2cwNDQ3Ny5odG1sDQoNCiBGcm9tOiBDaHJpcyBMb252 aWNrIDxjbG9udmljayBhdCBjaXNjby5jb20+DQogRGF0ZTogRnJpLCAxMyBEZWMgMjAxMyAxMTo0 MTo1NCAtMDgwMCAoUFNUKQ0KDQog4oCcSSBhbHNvIHNlZSB0aGF0IHRoZSBhdXRob3JzIGFyZSBh bHNvIHRyeWluZyB0byBhZGRyZXNzIHRoZSBpbml0aWFsICBkZXBsb3ltZW50IGFuZCBpbmNyZW1l bnRhbCBkZXBsb3ltZW50cywgd2hpY2ggaXMgbGF1ZGFibGUuIFRoZSBhdXRob3JzIG1heSAgd2lz aCB0byBsb29rIGF0IHJlc3RydWN0dXJpbmcgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNl Y3Rpb24gdG8gIGFkZHJlc3MgdGhlc2UgdGhpbmdzIHRocm91Z2ggdGhlIEZDQVBTIG1vZGVsIG9y IHNvbWV0aGluZyBzaW1pbGFyLg0KIChodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0ZDQVBT KeKAnQ0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0NCiBSZXBvcnRlcjogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgT3duZXI6ICBkcmFmdC1pZXRmLXJvbGwtDQogIG1hcmlhaW5lc3JvYmxlc0BnbWFpbC5jb20g ICAgICAgICAgfCAgYXBwbGljYWJpbGl0eS0NCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAg ICAgICAgICB8ICBhbWkuYWxsQHRvb2xzLmlldGYub3JnDQogUHJpb3JpdHk6ICBtYWpvciAgICAg ICAgICAgICAgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQpDb21wb25lbnQ6ICBhcHBsaWNhYmls aXR5LWFtaSAgICAgICAgfCAgTWlsZXN0b25lOg0KIFNldmVyaXR5OiAgQWN0aXZlIFdHIERvY3Vt ZW50ICAgICAgIHwgICAgVmVyc2lvbjoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5p ZXRmLm9yZy93Zy9yb2xsL3RyYWMvdGlja2V0LzEzNz4NCnJvbGwgPGh0dHA6Ly90b29scy5pZXRm Lm9yZy93Zy9yb2xsLz4NCg0K From trac+roll@trac.tools.ietf.org Tue Jan 14 07:01: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 1AC3C1AE0E0 for ; Tue, 14 Jan 2014 07:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 rlCKc6lvtUxx for ; Tue, 14 Jan 2014 07:01:46 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 419871AE0A0 for ; Tue, 14 Jan 2014 07:01:44 -0800 (PST) Received: from localhost ([127.0.0.1]:58744 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W35US-0003kp-UK; Tue, 14 Jan 2014 16:01:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Tue, 14 Jan 2014 15:01:16 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/136#comment:1 Message-ID: <082.5929e48bfe8bcc7e95efdc6e2c02808a@trac.tools.ietf.org> References: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> X-Trac-Ticket-ID: 136 In-Reply-To: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: daniel.popa@itron.com, jonhui@cisco.com, jorjeta.jetcheva@itron.com, kazuya.monden.vw@hitachi.com, mariainesrobles@gmail.com, , mcr+ietf@sandelman.ca, nicolas.dejean@coronis.com, ruben.salazar@landisgyr.com Cc: roll@ietf.org Subject: Re: [Roll] [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:01:48 -0000 #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used Comment (by mariainesrobles@gmail.com): Thread: http://www.ietf.org/mail-archive/web/roll/current/msg08423.html From: "Popa, Daniel" Date: Tue, 14 Jan 2014 14:48:44 +0000 “Chris: Just to clarify: The applicability statement for AMI network focuses on use of RPL (+ 6LowPAN/IPv6) over standard IEEE wireless and PLC link-layer technologies (i.e., IEEE Std 802.15.4g/4e and IEEE Std P1901.2, respectively). Each of these standards is coming with a link-layer security specification. Following you recommendation: we can add a new section - "Security Considerations" - to the section where we describe the link-layer security features (i.e., to the Section 9.2.3 called "Security features provided by the MAC sub-layer"). Alternatively, we can keep the Section 9.2.3 as it is and in the content that will be provided we describe how the link-layer security features will meet the requirements of the RPL security services. Which of these approaches will better answer your request? Would such clarifications meet your expectations? “ -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability- Type: defect | ami.all@tools.ietf.org Priority: major | Status: new Component: applicability-ami | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: -------------------------------------+------------------------------------- Ticket URL: roll From mariainesrobles@googlemail.com Mon Jan 20 09:10: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 ACEFE1A01B4 for ; Mon, 20 Jan 2014 09:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Dj53CqgR90qv for ; Mon, 20 Jan 2014 09:09:59 -0800 (PST) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8781A0162 for ; Mon, 20 Jan 2014 09:09:59 -0800 (PST) Received: by mail-vb0-f53.google.com with SMTP id p17so2870284vbe.26 for ; Mon, 20 Jan 2014 09:09:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=BQTLq5CEoxJdNmo+EcvOiEskroM4ZJ/o3cnIJfiMg+c=; b=GqztqIUp+VNjBrSz2dlV/+82noPG5/uf2uUXLmeqV6oWAaLo5AgLtk/xmXRTs86FaB 1iElvBrguku/wWfurFzqbUVaoIxAj2SBvQbv1oPbZUWNyx+KCy+B6ubPDQzF/s7Im+aF zaSDGgZ6JWWFgjY+AK8y4Zn1aJEzfFDGE16SZVFKpRAIsenA69iRJyZYAz/UNWR2LkHw KtPlUyPNIycaPOppOvnjTA3AYkdMxWB8/xTSG+QU4pp5R41AejIhEGm15M6+tJRts8+m lV5ktUpQfwrJFGgw2FUpKh62XU25r/Xmaaf2GBq1G12+1wYipITkfBxphcGBwg/iVRe7 gdfw== MIME-Version: 1.0 X-Received: by 10.52.170.241 with SMTP id ap17mr9289673vdc.13.1390237798431; Mon, 20 Jan 2014 09:09:58 -0800 (PST) Received: by 10.220.49.68 with HTTP; Mon, 20 Jan 2014 09:09:58 -0800 (PST) Date: Mon, 20 Jan 2014 15:09:58 -0200 Message-ID: From: Ines Robles To: Antonio Junior , rute.sofia@ulusofona.pt Content-Type: multipart/alternative; boundary=047d7b33d05021019e04f069f643 Cc: Michael Richardson , roll Subject: [Roll] Intend for draft-ajunior-roll-energy-awareness 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, 20 Jan 2014 17:10:05 -0000 --047d7b33d05021019e04f069f643 Content-Type: text/plain; charset=ISO-8859-1 Hi, Thank you very much for this draft, We would like to know please how this draft is aligned with the roll charter, what is the intention of this draft? Maybe would three documents be better? Applicability Guidelines for RPL. AODV. OLSR.? Perhaps with a reference to a algorithm/analysis of. Please could you kindly inform if were possible the implementation of energy-aware metrics on RPL such as SimpleRPL, ContikiRPL or TinyRPL.? [ http://www.ietf.org/mail-archive/web/roll/current/msg08015.html] Thank you in advance, Michael and Ines. ------------------------------------------------------------------------------------------------------------------------------------------ Thread: http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55852.html A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Energy-awareness metrics global applicability guidelines Authors : Antonio Junior Rute Sofia Filename : draft-ajunior-roll-energy-awareness-01.txt Pages : 15 Date : 2014-01-09 Abstract: This document describes a new set of energy-awareness metrics which have been devised to be applicable to any multihop routing protocol having in mind LLNs, including the Routing for Low Power and Lossy Networks (RPL) protocol. The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ajunior-roll-energy-awareness/ There's also a htmlized version available at:http://tools.ietf.org/html/draft-ajunior-roll-energy-awareness-01 A diff from the previous version is available at:http://www.ietf.org/rfcdiff?url2=draft-ajunior-roll-energy-awareness-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ --047d7b33d05021019e04f069f643 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

Thank you very muc= h for this draft,



We would like to know please how this draft= is aligned with the roll charter, what is the intention of this draft? May= be would three documents be better? Applicability Guidelines for RPL. AODV.= OLSR.? Perhaps with a reference to a algorithm/analysis of.

=

Please could you kindly inform if w<= span style=3D"line-height:1.15;color:rgb(0,0,0);background-color:transparen= t;vertical-align:baseline;white-space:pre-wrap">ere possible the implementation of energy-aware = metrics on RPL=A0such as SimpleRPL, ContikiRPL or TinyRPL.? [http://www.ietf.org/mail-archive/web/roll/current/msg08015.ht= ml]


Thank you in advance,


Michael and= Ines.


---------------------------------------------= ---------------------------------------------------------------------------= ------------------
A New Internet-Draft is available from=
 the on-line Internet-Drafts directories.


        Title           : Energy-awareness metrics global applicability gui=
delines
        Authors         : Antonio Junior
                          Rute Sofia
	Filename        : draft-ajunior-roll-energy-awareness-01.txt
	Pages           : 15
	Date            : 2014-01-09

Abstract:
   This document describes a new set of energy-awareness metrics which
   have been devised to be applicable to any multihop routing protocol
   having in mind LLNs, including the Routing for Low Power and Lossy
   Networks (RPL) protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ajunior-roll=
-energy-awareness/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ajunior-roll-energy-aw=
areness-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ajunio=
r-roll-energy-awareness-01


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.=
ietf.org/internet-drafts/
--047d7b33d05021019e04f069f643-- From internet-drafts@ietf.org Tue Jan 21 13:22:35 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947EC1A0340; Tue, 21 Jan 2014 13:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9kb0Rjq4HSb; Tue, 21 Jan 2014 13:22:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 629891A0371; Tue, 21 Jan 2014 13:22:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140121212228.3248.30228.idtracker@ietfa.amsl.com> Date: Tue, 21 Jan 2014 13:22:28 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-06.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: Tue, 21 Jan 2014 21:22:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : Multicast Protocol for Low power and Lossy Networ= ks (MPL) Authors : Jonathan W. Hui Richard Kelsey Filename : draft-ietf-roll-trickle-mcast-06.txt Pages : 24 Date : 2014-01-21 Abstract: This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain. MPL uses the Trickle algorithm to manage message transmissions for both control and data-plane messages. Different Trickle parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-06 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 trac+roll@trac.tools.ietf.org Wed Jan 22 04:47: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 3E6091A00A5 for ; Wed, 22 Jan 2014 04:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 Vr3RxIDTsVas for ; Wed, 22 Jan 2014 04:47:23 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 66BCC1A00CA for ; Wed, 22 Jan 2014 04:47:22 -0800 (PST) Received: from localhost ([127.0.0.1]:54354 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W5xD8-0001c5-TU; Wed, 22 Jan 2014 13:47:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Wed, 22 Jan 2014 12:47:14 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/132#comment:19 Message-ID: <082.aa4afcc198d988b4cc76ace568b675ac@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 12:47:25 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Changes (by mariainesrobles@gmail.com): * status: reopened => closed * resolution: => fixed Comment: This issue is fixed, the solution was added in Section 4.1 of the draft- ietf-roll-trickle-mcast-06: "By default, an MPL Forwarder SHOULD participate in an MPL Domain identified by the ALL_MPL_FORWARDERS multicast address with a scope value of 3 (Realm-Local) [I-D.ietf-6man-multicast-scopes]. When MPL is used in deployments that use administratively defined scopes that cover, for example, multiple subnets based on different underlying network technologies, Admin-Local scope (scop value 4) and/or Site-Local scope (scop value 5) SHOULD be used." -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: closed Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Jan 22 04:52: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 784FF1A00CA for ; Wed, 22 Jan 2014 04:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 gXCUctr12cBX for ; Wed, 22 Jan 2014 04:52:07 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BF2C41A00C6 for ; Wed, 22 Jan 2014 04:52:04 -0800 (PST) Received: from localhost ([127.0.0.1]:54477 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W5xHj-00064m-Eo; Wed, 22 Jan 2014 13:51:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Wed, 22 Jan 2014 12:51:59 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/103#comment:8 Message-ID: <073.6fa46e70aaf904b71a2a964453d50368@trac.tools.ietf.org> References: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-Trac-Ticket-ID: 103 In-Reply-To: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Cc: roll@ietf.org Subject: Re: [Roll] [roll] #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS 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, 22 Jan 2014 12:52:09 -0000 #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS Changes (by mariainesrobles@gmail.com): * status: reopened => closed * resolution: => fixed Comment: This issue is fixed, the solution was added in Section 5.4 of the draft- ietf-roll-trickle-mcast-06: "PROACTIVE_FORWARDING A boolean value that indicates whether the MPL Forwarder schedules MPL Data Message transmissions after receiving them for the first time. It is RECOMMENDED that all MPL Interfaces attached to the same link of a given MPL Domain use the same value for PROACTIVE_FORWARDING and has a default value of TRUE. The mechanism for setting PROACTIVE_FORWARDING is not specified within this document." -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Jan 22 04:55: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 A93641A00C6 for ; Wed, 22 Jan 2014 04:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 UigzLRLY-5as for ; Wed, 22 Jan 2014 04:55:49 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9AB1A00C5 for ; Wed, 22 Jan 2014 04:55:49 -0800 (PST) Received: from localhost ([127.0.0.1]:54566 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W5xLP-0004EG-IX; Wed, 22 Jan 2014 13:55:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jonhui@cisco.com, mariainesrobles@gmail.com X-Trac-Project: roll Date: Wed, 22 Jan 2014 12:55:47 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/134#comment:2 Message-ID: <082.f37c25ccc36f2da00d5e6864c6ba4f45@trac.tools.ietf.org> References: <067.8ed0ad50c483043cf2b4bacef0279070@trac.tools.ietf.org> X-Trac-Ticket-ID: 134 In-Reply-To: <067.8ed0ad50c483043cf2b4bacef0279070@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jonhui@cisco.com, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #134: draft-ietf-roll-trickle-mcast-05 - Minor editorial comments 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, 22 Jan 2014 12:55:50 -0000 #134: draft-ietf-roll-trickle-mcast-05 - Minor editorial comments Changes (by mariainesrobles@gmail.com): * status: new => closed * resolution: => fixed Comment: This issue is fixed, the solution was added in draft-ietf-roll-trickle- mcast-06. This Issue is not valid: [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 to 14.2. -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: jonhui@cisco.com Type: defect | Status: closed Priority: minor | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From antoniocojr@gmail.com Thu Jan 23 06:11: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 909B51A0434 for ; Thu, 23 Jan 2014 06:11:52 -0800 (PST) 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 A_UwZWARPkPJ for ; Thu, 23 Jan 2014 06:11:50 -0800 (PST) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 266481A00CA for ; Thu, 23 Jan 2014 06:11:49 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id x13so2488359qcv.33 for ; Thu, 23 Jan 2014 06:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ud4/gwQCG5nZaBw7bo59mOYKt5VOr9YWd0l+mBdb3DY=; b=HIneBFv63x0WUUp2AHpF3UnDYlN6o1wYTf5Fmflkf6kVy6TJI6pVFzFYL2AWYKdR6s ilBX7+VdWDFfI8H05trHwGMQhRJFmH/OFhqdamI/KnL915QHdvxx7lR5/UcwZAhNVwFk UNhHKgkjO6xKsSKx1k64pm/eMvfX7fmoV7GK1b2U5dtNo9yFJ0sf6qzdtw0Dl/o0T0FN Pjh22CYqq1exovc+FNXcZPvLYqRr1By7SSuTo9QapwAyvNxM2LwVyKt4utwqW7eDRTQ9 pYaTXACNO/xfalJILoh4+GEk1vD7HuY83P2Z2D7WDzYvEL6LYM2HXw8a4evD64z0t7nB hLzw== MIME-Version: 1.0 X-Received: by 10.229.56.200 with SMTP id z8mr11792909qcg.1.1390486308893; Thu, 23 Jan 2014 06:11:48 -0800 (PST) Received: by 10.96.130.162 with HTTP; Thu, 23 Jan 2014 06:11:48 -0800 (PST) In-Reply-To: References: Date: Thu, 23 Jan 2014 12:11:48 -0200 Message-ID: From: Antonio Carlos de Oliveira Junior To: Ines Robles Content-Type: text/plain; charset=ISO-8859-1 Cc: Michael Richardson , roll Subject: Re: [Roll] Intend for draft-ajunior-roll-energy-awareness 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, 23 Jan 2014 14:11:52 -0000 Hi Ines, Welcome! The intention of this draft is to contribute with the ROLL WG regarding energy-aware metrics applicable to any multihop routing protocol having in mind LLNs. As the RPL is the protocol of the ROLL, we intend to perform a deep analysis of the metrics in RPL. We are working on implementation of energy-aware metrics on RPL (analysing SimpleRPL, ContikiRPL and TinyRPL). However, we are depending on students works and this process are still in progress. We hope to have feedback/results on the next draft (-02). In fact, we can separate the documents as the focus now is on RPL. Best Regards, Antonio On 20 January 2014 15:09, Ines Robles wrote: > Hi, > > Thank you very much for this draft, > > > > We would like to know please how this draft is aligned with the roll > charter, what is the intention of this draft? Maybe would three documents be > better? Applicability Guidelines for RPL. AODV. OLSR.? Perhaps with a > reference to a algorithm/analysis of. > > > Please could you kindly inform if were possible the implementation of > energy-aware metrics on RPL such as SimpleRPL, ContikiRPL or TinyRPL.? > [http://www.ietf.org/mail-archive/web/roll/current/msg08015.html] > > > Thank you in advance, > > > Michael and Ines. > > > ------------------------------------------------------------------------------------------------------------------------------------------ > Thread: > http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55852.html > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Energy-awareness metrics global applicability > guidelines > Authors : Antonio Junior > Rute Sofia > Filename : draft-ajunior-roll-energy-awareness-01.txt > Pages : 15 > Date : 2014-01-09 > > Abstract: > This document describes a new set of energy-awareness metrics which > have been devised to be applicable to any multihop routing protocol > having in mind LLNs, including the Routing for Low Power and Lossy > Networks (RPL) protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ajunior-roll-energy-awareness/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ajunior-roll-energy-awareness-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ajunior-roll-energy-awareness-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ -- Antonio Carlos de Oliveira Junior, PhD Student Computer Science MAP-i Doctoral Programme (www.map.edu.pt/i) Researcher at COPELABS (http://copelabs.ulusofona.pt) From mariainesrobles@googlemail.com Thu Jan 23 12:35: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 2D0851A018B for ; Thu, 23 Jan 2014 12:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG9C0AszmQT1 for ; Thu, 23 Jan 2014 12:35:11 -0800 (PST) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D12501A019A for ; Thu, 23 Jan 2014 12:35:08 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id m10so1349491vbh.18 for ; Thu, 23 Jan 2014 12:35:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SY/M+KZ0ok6Gpc0CNhrWdXX1bvyE9qci3PjhUktcUzo=; b=UakdSNuGlR3smDw12JU5OD8B3AvpriYD5t+k4ShG7NCYCWB/4iK2UnEt1FOxqHk3L/ O3GeCsyD6olV4Gxwo9XyTopsB6XUkFP7ajG+R629T9Cqpt8TzMZVSSTRG/4Q8YJQeNVc kkSmb8wFJoO5+eQvqI481ZQqCW8FVSF24WzyyJrSKhuPH9xFCQp3nA1jt3gkiswjMlAi 3YBtQnTauelSyK7bJbLyI2fbOcF9VnAtqzlfSSH2Q5Re1S7V3f1nQDNzeLjXBOZP8l5B AQfIGARdDSu45ywGeA/ZulpmWrHY1JMnvya2fgZoB1LL+8hhBImaRSmqnZdVt5jzUXdB eBRQ== MIME-Version: 1.0 X-Received: by 10.220.97.145 with SMTP id l17mr2590497vcn.35.1390509307734; Thu, 23 Jan 2014 12:35:07 -0800 (PST) Received: by 10.220.49.68 with HTTP; Thu, 23 Jan 2014 12:35:07 -0800 (PST) In-Reply-To: References: Date: Thu, 23 Jan 2014 18:35:07 -0200 Message-ID: From: Ines Robles To: Antonio Carlos de Oliveira Junior Content-Type: multipart/alternative; boundary=001a11c1dd02582e2b04f0a92d26 Cc: Michael Richardson , roll Subject: Re: [Roll] Intend for draft-ajunior-roll-energy-awareness 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, 23 Jan 2014 20:35:13 -0000 --001a11c1dd02582e2b04f0a92d26 Content-Type: text/plain; charset=ISO-8859-1 Hi Antonio, 2014/1/23 Antonio Carlos de Oliveira Junior > > The intention of this draft is to contribute with the ROLL WG > regarding energy-aware metrics applicable to any multihop routing > protocol having in mind LLNs. As the RPL is the protocol of the ROLL, > we intend to perform a deep analysis of the metrics in RPL. > > Thanks, we are going to analyze if we need a re-chartering or not. > We are working on implementation of energy-aware metrics on RPL > (analysing SimpleRPL, ContikiRPL and TinyRPL). However, we are > depending on students works and this process are still in progress. We > hope to have feedback/results on the next draft (-02). In fact, we can > separate the documents as the focus now is on RPL. > Ok, thank you. Kind Regards, > > Best Regards, > Antonio > > On 20 January 2014 15:09, Ines Robles > wrote: > > Hi, > > > > Thank you very much for this draft, > > > > > > > > We would like to know please how this draft is aligned with the roll > > charter, what is the intention of this draft? Maybe would three > documents be > > better? Applicability Guidelines for RPL. AODV. OLSR.? Perhaps with a > > reference to a algorithm/analysis of. > > > > > > Please could you kindly inform if were possible the implementation of > > energy-aware metrics on RPL such as SimpleRPL, ContikiRPL or TinyRPL.? > > [http://www.ietf.org/mail-archive/web/roll/current/msg08015.html] > > > > > > Thank you in advance, > > > > > > Michael and Ines. > > > > > > > ------------------------------------------------------------------------------------------------------------------------------------------ > > Thread: > > http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55852.html > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Energy-awareness metrics global applicability > > guidelines > > Authors : Antonio Junior > > Rute Sofia > > Filename : draft-ajunior-roll-energy-awareness-01.txt > > Pages : 15 > > Date : 2014-01-09 > > > > Abstract: > > This document describes a new set of energy-awareness metrics which > > have been devised to be applicable to any multihop routing protocol > > having in mind LLNs, including the Routing for Low Power and Lossy > > Networks (RPL) protocol. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ajunior-roll-energy-awareness/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ajunior-roll-energy-awareness-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ajunior-roll-energy-awareness-01 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > -- > Antonio Carlos de Oliveira Junior, PhD Student Computer Science > MAP-i Doctoral Programme (www.map.edu.pt/i) > Researcher at COPELABS (http://copelabs.ulusofona.pt) > --001a11c1dd02582e2b04f0a92d26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Antonio,

2014/1/23 Antonio Carlos de Oliveira Junior &l= t;antoniocojr@gm= ail.com>

The intention of this draft is to contribute with the ROLL WG
regarding energy-aware metrics applicable to any multihop routing
protocol having in mind LLNs. As the RPL is the protocol of the ROLL,
we intend to perform a deep analysis of the metrics in RPL.

Thanks, we are going to analyze if we need a re= -chartering or not.
=A0
We are working on implementation of energy-aware metrics on RPL
(analysing SimpleRPL, ContikiRPL and TinyRPL). However, we are
depending on students works and this process are still in progress. We
hope to have feedback/results on the next draft (-02). In fact, we can
separate the documents as the focus now is on RPL.
=A0=
Ok, thank you.=A0

Kind Regards,

Best Regards,
Antonio

On 20 January 2014 15:09, Ines =A0Robles <mariainesrobles@googlemail.com> wrote:
> Hi,
>
> Thank you very much for this draft,
>
>
>
> We would like to know please how this draft is aligned with the roll > charter, what is the intention of this draft? Maybe would three docume= nts be
> better? Applicability Guidelines for RPL. AODV. OLSR.? Perhaps with a<= br> > reference to a algorithm/analysis of.
>
>
> Please could you kindly inform if were possible the implementation of<= br> > energy-aware metrics on RPL such as SimpleRPL, ContikiRPL or TinyRPL.?=
> [http://www.ietf.org/mail-archive/web/roll/current/= msg08015.html]
>
>
> Thank you in advance,
>
>
> Michael and Ines.
>
>
> ----------------------------------------------------------------------= --------------------------------------------------------------------
> Thread:
> http://www.ietf.org/mail-archive/web/i-d-an= nounce/current/msg55852.html
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Energy-awareness metrics g= lobal applicability
> guidelines
> =A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Antonio Junior
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rute Sofia
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ajunior-roll-energy-awaren= ess-01.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 15
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-09
>
> Abstract:
> =A0 =A0This document describes a new set of energy-awareness metrics w= hich
> =A0 =A0have been devised to be applicable to any multihop routing prot= ocol
> =A0 =A0having in mind LLNs, including the Routing for Low Power and Lo= ssy
> =A0 =A0Networks (RPL) protocol.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ajunio= r-roll-energy-awareness/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ajunior-roll-ene= rgy-awareness-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-= ajunior-roll-energy-awareness-01
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/



--
Antonio Carlos de Oliveira Junior, PhD Student Computer Science
MAP-i Doctoral Programme (www.map.edu.pt/i)
Researcher at COPELABS (http://copelabs.ulusofona.pt)

--001a11c1dd02582e2b04f0a92d26-- From mariainesrobles@googlemail.com Thu Jan 23 14:03: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 13E571A043D for ; Thu, 23 Jan 2014 14:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.423 X-Spam-Level: X-Spam-Status: No, score=0.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_84=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 I3gP1OIB31KG for ; Thu, 23 Jan 2014 14:03:08 -0800 (PST) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id D9EEF1A038A for ; Thu, 23 Jan 2014 14:03:07 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id w8so1395490vbj.23 for ; Thu, 23 Jan 2014 14:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=F/8fU0xDtKw7cA84jknHqma+t0R2bQ8jtWpcuazGubE=; b=zlURHyhH3EZ95fmAeDOP7kwnIq7NUe9KXqUZJhlfzAzogEmc1Ljy0SEOLhzyxqTLiN ZcU4U858N8CCcC77OMMlki0pk+WJ+BvnZh5yXHfG0FZCJNIrbKcKT5fdGEGgUTrfCeVB 5r3hkg68ziUILiZL35Y7WCso9zsXmnPAMC83WpOaFri++BB5I5hQ+ar8wx2a9iOz1b92 MoAjv8aLBUUOY6kj0WcGb0URfRJg4wB+Fd8iXaRy3Si7NTcB/4RQfT4Ulbzpt28oOX0c ZtHTfhPIGDz9suc43WqjoEQG9hjeaXvIa/+RcFA2UavcCV3jyg1XSaN4H0fJPk/vegyL jUTw== MIME-Version: 1.0 X-Received: by 10.221.20.199 with SMTP id qp7mr5750180vcb.24.1390514586743; Thu, 23 Jan 2014 14:03:06 -0800 (PST) Received: by 10.220.49.68 with HTTP; Thu, 23 Jan 2014 14:03:06 -0800 (PST) Date: Thu, 23 Jan 2014 20:03:06 -0200 Message-ID: From: Ines Robles To: wanggang_uestc@163.com, Feng Gang Content-Type: multipart/alternative; boundary=001a11339e2eff7b6004f0aa672b Cc: Michael Richardson , roll Subject: [Roll] Intention for draft-wang-roll-data-robustness 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, 23 Jan 2014 22:03:09 -0000 --001a11339e2eff7b6004f0aa672b Content-Type: text/plain; charset=ISO-8859-1 *Hi Gang Wang and Gang Feng,Thank you very much for draft-wang-roll-data-robustness, Abstract:This document specifies a solution for improving the robustness of data transmission in multi-hop Low-Power and Lossy Networks (LLNs). It uses the network coding technique in conjunction with the Routing Protocol for LLNs (RPL) to increase the success rate of data collection at the sink node, with reasonable processing and traffic cost.We would like to know please how this draft is aligned with the roll charter, what is the intention of this draft? Do you know some implementation about it?Thank you in advance,Michael and Ines.* --001a11339e2eff7b6004f0aa672b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Gang Wang a= nd Gang Feng,


Thank you very much for draft-wang-roll-da= ta-robustness,


<= span style=3D"color:rgb(0,0,0);background-color:transparent;vertical-align:= baseline;white-space:pre-wrap">Abstract:


<= p style=3D"font-family:arial,helvetica,sans-serif;line-height:1.15;margin-t= op:0pt;margin-bottom:0pt"> 

Th=
is document specifies a solution for improving the robustness of data trans=
mission in multi-hop Low-Power and Lossy Networks (LLNs).
It uses the network coding technique in conjunction with the Routing Protoc=
ol for LLNs (RPL) to increase the success rate of data =



collection at the sink node, with reasonable processing=
 and traffic 
cost.

We would like to know please how this draft= is aligned with the roll charter, what is the intention of this draft? =A0= Do you know some implementation about it?


=


Thank you in advance,


Michael and Ines.
--001a11339e2eff7b6004f0aa672b-- From mariainesrobles@googlemail.com Thu Jan 23 14:44: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 831211A0462 for ; Thu, 23 Jan 2014 14:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNLvF-feoURu for ; Thu, 23 Jan 2014 14:44:00 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E5C7C1A045A for ; Thu, 23 Jan 2014 14:43:59 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id if11so1437119vcb.22 for ; Thu, 23 Jan 2014 14:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=hMs/dIXR7eOLH6Ls2U50+szQb0jotzqBKgqGbC0I3TA=; b=iirTIBCisRN6//BNjzOnpiEr8ylHdIw0bOxJ6VE2g6KHKZOXCZb6ImxC2HE9RJxUsw hLku0nFthOA+TXm+eWXKrFTnsmYMaiK4TlnDB0e/Ol5/2XnkcB9szD0SCLYR3DJ+0cp0 DABv2N6SEJGev7Iq3jEcQF2TAs3/vGc8dqZUZdwREGW7XZWxkD3HA/jf57+wFX2IlGw6 puPKejIWqEtkuaY4j0wgUCE0pvKZ08jKvx9YBKCPuudiu4EELMAY2WigE63j573BqoSs MF2yKCZczrypgTG4jIdiXwm7skHeVPpZ6+HseWwRPvkwLOTXHY/qiWCZpY67OG0jgoP0 gpQg== MIME-Version: 1.0 X-Received: by 10.58.123.70 with SMTP id ly6mr2595163veb.26.1390517038770; Thu, 23 Jan 2014 14:43:58 -0800 (PST) Received: by 10.220.49.68 with HTTP; Thu, 23 Jan 2014 14:43:58 -0800 (PST) Date: Thu, 23 Jan 2014 20:43:58 -0200 Message-ID: From: Ines Robles To: "Pascal Thubert (pthubert)" , "Jonathan Hui (johui)" Content-Type: multipart/alternative; boundary=089e0118490e266e9404f0aafa75 Cc: Michael Richardson , roll Subject: [Roll] Intention for draft-thubert-roll-forwarding-frags 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, 23 Jan 2014 22:44:01 -0000 --089e0118490e266e9404f0aafa75 Content-Type: text/plain; charset=ISO-8859-1 *Hi Pascal and Jonathan,Thank you very much for draft-thubert-roll-forwarding-frags-02,Abstract:In order to be routed, a fragmented packet must be reassembled at every hop of a multihop link where lower layer fragmentation occurs. Considering that the IPv6 minimum MTU is 1280 bytes and that an an 802.15.4 frame can have a payload limited to 74 bytes in the worst case, a packet might end up fragmented into as many as 18 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to forward and recover individual fragments that might be lost over multiple hops between 6LoWPAN endpoints.We would like to know please how you see that this draft is aligned with the roll charter, it seems that the intention is in this thread: http://www.ietf.org/mail-archive/web/roll/current/msg07784.html , is that correct? do you have some additional information for intention? Thank you in advance,Michael and Ines.* --089e0118490e266e9404f0aafa75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi= Pascal and Jonathan,


Thank you very much for draft-thubert-roll-forwarding-fr= ags-02,


= Abstract:<= /span>


= In order t= o be routed, a fragmented packet must be reassembled at
=A0=A0every hop of a multihop link where lower layer fragmentation occurs.=
=A0=A0Considering that the IPv6 minimum MTU is 1280 bytes a= nd that an an
=A0=A0802.15.4 frame can have a payload limite= d to 74 bytes in the worst
=A0=A0case, a packet might end up fragmented into as many as 18 fragments<= br class=3D""> =A0=A0at the 6LoWPAN shim layer. =A0If a single one of those= fragments is
=A0=A0lost in transmission, all fragments must= be resent, further
=A0=A0contributing to the congestion that might have caused the initial =A0=A0packet loss. =A0This draft introduces a simple protocol = to forward and
=A0=A0recover individual fragments that might= be lost over multiple hops
=A0=A0between 6LoWPAN endpoints.



We would l= ike to know please how you see that this draft is aligned with the roll cha= rter,

= it seems t= hat the intention is in this thread: = http://www.ietf.org/mail-archive/web/roll/current/msg07784.html<= span style=3D"font-size:13px;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;vertical-align:baseline;white-space:pre-wrap">, is that c= orrect? do you have some additional information for intention?


Thank you= in advance,


Michael a= nd Ines.
--089e0118490e266e9404f0aafa75-- From joao.p.taveira@gmail.com Fri Jan 24 02:54:35 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676031A0283 for ; Fri, 24 Jan 2014 02:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[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_8BIT_HEADER=0.3, 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 7cqjX-h2i4Yf for ; Fri, 24 Jan 2014 02:54:33 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id BAE951A01D1 for ; Fri, 24 Jan 2014 02:54:33 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id x10so2999733pdj.25 for ; Fri, 24 Jan 2014 02:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ls2NLM5qP89nPzWEy5abminuME7jdS7xM4fjrRlHkF8=; b=slSE1KQr5xes9xD/tefZuQbI6xzcFcSPSVx+Omhhj/RKasogx/0iUvCObd5+ye7lrU JH90NBJjv+G6fGwQfUoJJnfx4G9qXGOmOyHBP18j0sDU/n5s3e+PUi1F6l+wqvPpX3fy fQMXRvT9JTIv6r61TltTpjfvczNEIJEIxssAx3yqZp4QjdvyZkgBS+ejWrc5N0+UTnEZ q3Pv1kN9dHrcDbuZ4aFBGlFqP4kR7ebjqXGnq9LUR8BTnwLEpACDuEdHqyccPOBxGsDG F3Rz3pvluqNMIDVgqOuzZrNkZbQkpoLSH5aC/Q1LZeArSTHZGa8jiYF6PLDi9bL8knR3 kGrQ== MIME-Version: 1.0 X-Received: by 10.66.141.231 with SMTP id rr7mr13123587pab.41.1390560872794; Fri, 24 Jan 2014 02:54:32 -0800 (PST) Received: by 10.67.24.4 with HTTP; Fri, 24 Jan 2014 02:54:32 -0800 (PST) Date: Fri, 24 Jan 2014 10:54:32 +0000 Message-ID: From: =?ISO-8859-1?Q?Jo=E3o_Pedro_Taveira?= To: roll@ietf.org, =?ISO-8859-1?Q?Jo=E3o_Pedro_Taveira?= Content-Type: multipart/alternative; boundary=001a11331298dc8ea404f0b52e27 Subject: [Roll] RPL Linux implementation 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, 24 Jan 2014 10:54:35 -0000 --001a11331298dc8ea404f0b52e27 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi to all, I've been working with linux and contiki in order to get beaglebones and rpi communicating with contiki powered sensors. I started using SimpleRPL but I notice that it didn't handle NUD, so I started Linux RPL support. I've been cleaning up the code to linux kernel best practices and I'm trying to get some time to contact kernel network maintainers to know who to get RPL in kernel. I've been using RPL in linux with 6lowpan stack, but there some missing fixes in beaglebone and rpi official kernels which requires to merge a lot of patches from this and that repository to get everything working on my project requirements. Linux implementation worked pretty well with contiki implementation using 6lowpan stack. Notice that there's a lot of bugs and misbehavior integrating systems, but since there wasn't any RPL implementation of RPL in linux and integration of 6lowpan in linux with contki, by getting anything working was a great starting point. My rpl implementation supports namespaces which allow to test it with CORE emulator. RPL kernel implementation watches for NUD and acts if required. It's expected to allow multiple DODAGs. It also provides a OF API to allow future OF implementations. I only implemented 0OF for now. The rpl kernel implementation implements linux led trigger support to allow to bind beaglebones and rpi leds to kind-of "joined to any dag" feedback. To interact with RPL in linux, there's userland tool "rpl-ctl", which was based on the great "iz" tool. Using the tool, the user may setup RPL functionality, list internal state of RPL and trigger repairs. It's not implemented yet, but I hope to get time to implement userland events triggering based on what happens in RPL. If someone would like to give it a try, kernel patches are available here: https://github.com/joaopedrotaveira/linux-rpl Since I've been working with several versions of kernels to several features of RPi and BBW/B, it has been difficult to keep a single repository with RPL and others features I need for my projects all together= . If you find any issue or have any question on how to get this working, feel free to ask. If there's any process to test implementations features and capabilities, let me know. I'll try to give more time on sharing my work, but my time keeps not stretching lately. I hope my contribution be useful. Best Regards, Jo=E3o Pedro Taveira --001a11331298dc8ea404f0b52e27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi to all,

I've been working with l= inux and contiki in order to get beaglebones and rpi communicating with con= tiki powered sensors.

I started using SimpleRPL bu= t I notice that it didn't handle NUD, so I started Linux RPL support.

I've been cleaning up the code to linux kernel best= practices and I'm trying to get some time to contact kernel network ma= intainers to know who to get RPL in kernel.

I'= ve been using RPL in linux with 6lowpan stack, but there some missing fixes= in beaglebone and rpi official kernels which requires to merge a lot of pa= tches from this and that repository to get everything working on my project= requirements.

Linux implementation worked pretty well with contiki im= plementation using 6lowpan stack. Notice that there's a lot of bugs and= misbehavior integrating systems, but since there wasn't any RPL implem= entation of RPL in linux and integration of 6lowpan in linux with contki, b= y getting anything working was a great starting point.

My rpl implementation supports namespaces which allow t= o test it with CORE emulator. RPL kernel implementation watches for NUD and= acts if required. It's expected to allow multiple DODAGs. It also prov= ides a OF API to allow future OF implementations. I only implemented 0OF fo= r now. The rpl kernel implementation implements linux led trigger support t= o allow to bind beaglebones and rpi leds to kind-of "joined to any dag= " feedback.

To interact with RPL in linux, there's userland too= l "rpl-ctl", which was based on the great "iz" tool. Us= ing the tool, the user may setup RPL functionality, list internal state of = RPL and trigger repairs. It's not implemented yet, but I hope to get ti= me to implement userland events triggering based on what happens in RPL.

If someone would like to give it a try, kernel patches = are available here: https://github.com/joaopedrotaveira/linux-rpl

Since I've been working with several versions of kernels to severa= l features of RPi and BBW/B, it has been difficult to keep a single reposit= ory with RPL and others features I need for my projects all together.

If you find any issue or have any question on how to ge= t this working, feel free to ask. If there's any process to test implem= entations features and capabilities, let me know.

I'll try to give more time on sharing my work, but my time keeps not st= retching lately.

I hope my contribution be useful.=

Best Regards,
Jo=E3o Pedro Taveira
--001a11331298dc8ea404f0b52e27-- From mcr@sandelman.ca Fri Jan 24 08:36: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 8395A1A04D1 for ; Fri, 24 Jan 2014 08:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, 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 oEM9JGKGzBQa for ; Fri, 24 Jan 2014 08:36:16 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id B77921A0010 for ; Fri, 24 Jan 2014 08:36:16 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2F8E72002B; Fri, 24 Jan 2014 12:52:32 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id F41AC64647; Fri, 24 Jan 2014 11:36:14 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DB84263AB2; Fri, 24 Jan 2014 11:36:14 -0500 (EST) From: Michael Richardson To: roll 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 Cc: Antonio Carlos de Oliveira Junior Subject: Re: [Roll] Intend for draft-ajunior-roll-energy-awareness 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, 24 Jan 2014 16:36:18 -0000 --=-=-= > The intention of this draft is to contribute with the ROLL WG > regarding energy-aware metrics applicable to any multihop routing > protocol having in mind LLNs. As the RPL is the protocol of the ROLL, > we intend to perform a deep analysis of the metrics in RPL. RFC6551 says that if you want a new metric container type, and I think that you do, that you need to write a document, which you have. I think that we just need to have a single document for RPL, since we can not review/approve any AODV or OLSR extensions in this group. -- 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) iQCVAwUBUuKWfIqHRg3pndX9AQKj1AP/d19gsGOnKC/HkKkZM49dAa5kw+ISNpZa MKeyuaTDZXA7Z9nJtCESLDMnlsblG32iiDSodDbvY6qV1nSY5p6+FgNPpe5EbDS7 EWvWSEGqPmFnOWHbSfdXuO//AZvKIXJ5ma25ku6SvrrpwMmSE2NCHOZECDcW2C3T RL5sV0AZaNo= =cIUV -----END PGP SIGNATURE----- --=-=-=-- From Daniel.Popa@itron.com Fri Jan 24 10:10: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 BA8C41A00B8 for ; Fri, 24 Jan 2014 10:10:42 -0800 (PST) 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 nidYUx1KnOac for ; Fri, 24 Jan 2014 10:10:40 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0156.outbound.protection.outlook.com [207.46.163.156]) by ietfa.amsl.com (Postfix) with ESMTP id BC98D1A00C0 for ; Fri, 24 Jan 2014 10:10:39 -0800 (PST) Received: from BY2PR04MB807.namprd04.prod.outlook.com (10.141.224.149) by BY2PR04MB808.namprd04.prod.outlook.com (10.141.224.151) with Microsoft SMTP Server (TLS) id 15.0.859.15; Fri, 24 Jan 2014 18:10:37 +0000 Received: from BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) by BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) with mapi id 15.00.0859.013; Fri, 24 Jan 2014 18:10:37 +0000 From: "Popa, Daniel" To: Chris Lonvick Thread-Topic: [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used Thread-Index: AQHO+uwD2eu7e2v53EymWeo4If1VDpqEdBnggA/qn4CAAAqZ/w== Date: Fri, 24 Jan 2014 18:10:36 +0000 Message-ID: References: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> <9546f1bf3d68401a8cdf837ca5528de4@BY2PR04MB807.namprd04.prod.outlook.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: [193.253.170.230] x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(53754006)(55784002)(288314003)(129404003)(51704005)(24454002)(189002)(199002)(87936001)(94316002)(54356001)(36756003)(92726001)(2656002)(74876001)(47976001)(93516002)(4396001)(86362001)(87266001)(69226001)(50986001)(76482001)(74366001)(15202345003)(54316002)(85306002)(81686001)(56776001)(74706001)(81816001)(46102001)(51856001)(53806001)(80022001)(47736001)(49866001)(33656001)(83322001)(74502001)(74662001)(77982001)(66066001)(90146001)(31966008)(82746002)(59766001)(56816005)(63696002)(19580395003)(76786001)(76796001)(19580405001)(80976001)(81542001)(47446002)(15975445006)(81342001)(92566001)(83716003)(65816001)(93136001)(79102001)(83072002)(85852003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR04MB808; H:BY2PR04MB807.namprd04.prod.outlook.com; CLIP:193.253.170.230; FPR:; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: itron.com Cc: "draft-ietf-roll-applicability-ami.all@tools.ietf.org" , "roll@ietf.org" Subject: Re: [Roll] [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used 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, 24 Jan 2014 18:10:42 -0000 Thanks Chris for feedback. I believe what you advice it is more or less what we intend to do. The diff= erence is that we do not intend to explicitly use a security threat model a= nd show how IEEE works against it, but rather to explain how IEEE 802.15.4 = and IEEE p1901.2 security mechanisms can substitute to RPL-defined security= mechanisms to provide the same security services as those described in Sec= tion 19.1 of RFC 6550, while at the same time giving the system designers &= implementers the same degree of freedom to trade-off complexity against se= curity strength, in order to meet HW & cost constraints of such low power f= ield devices.=20 Would this be enough ?=20 Regards, Daniel Sent from my iPhone > On 24 janv. 2014, at 18:32, "Chris Lonvick" wrote: >=20 > Hi Daniel, >=20 > Has a threat model been defined for RPL? And do you know that the link-l= ayer security provided by the two IEEE mechanisms will thwart the threats? = This isn't meant to be an onerous exercise. :-) What has been done in se= veral WGs has been to define a simple threat model (usually taken from RFC = 3552) and then describe how the security mechanisms will thwart the threats= . For example, see sections 2 and 3 in RFC 5426 (TLS for syslog). >=20 > If you can point to the threat model for RPL then you can probably state = (just once in the Security Considerations section) how the IEEE link-layer = security mechanisms will address the threats so therefore the security mech= anisms already contained within RPL will not be needed. >=20 > Hope this helps, > Chris >=20 >> On Tue, 14 Jan 2014, Popa, Daniel wrote: >>=20 >> Hello all, >>=20 >> Chris: >>=20 >> Just to clarify: The applicability statement for AMI network focuses on = use of RPL (+ 6LowPAN/IPv6) over standard IEEE wireless and PLC link-layer = technologies (i.e., IEEE Std 802.15.4g/4e and IEEE Std P1901.2, respectivel= y). Each of these standards is coming with a link-layer security specificat= ion. >>=20 >> Following you recommendation: we can add a new section - "Security Consi= derations" - to the section where we describe the link-layer security featu= res (i.e., to the Section 9.2.3 called "Security features provided by the M= AC sub-layer"). Alternatively, we can keep the Section 9.2.3 as it is and i= n the content that will be provided we describe how the link-layer security= features will meet the requirements of the RPL security services. Which o= f these approaches will better answer your request? >>=20 >> Would such clarifications meet your expectations? >>=20 >> Regards, >> Daniel >>=20 >> -----Message d'origine----- >> De : roll issue tracker [mailto:trac+roll@grenache.tools.ietf.org] >> Envoy=E9 : mardi 17 d=E9cembre 2013 06:51 >> =C0 : draft-ietf-roll-applicability-ami.all@tools.ietf.org; mariainesrob= les@gmail.com >> Cc : roll@ietf.org >> Objet : [roll] #136: - draft-ietf-roll-applicability-ami - Add a section= of the Security Considerations for each instance where the RPL security me= chanism are not to be used >>=20 >> #136: - draft-ietf-roll-applicability-ami - Add a section of the Securit= y Considerations for each instance where the RPL security mechanism are not= to be used >>=20 >> Source: http://www.ietf.org/mail-archive/web/secdir/current/msg04477.htm= l >>=20 >>=20 >> From: Chris Lonvick >> Date: Fri, 13 Dec 2013 11:41:54 -0800 (PST) >>=20 >>=20 >>=20 >> =93The authors note that other security mechanisms may be used, which wo= uld mean that the security functions of RPL would not be needed. I would = recommend that a section of the Security Considerations be added for each = instance where the RPL security mechanism are not to be used. Each of thos= e sections should show how the replacement mechanisms will meet the requir= ements of the RPL security services that are described in 6550.=94 >>=20 >> --=20 >> -------------------------------------+---------------------------------- >> -------------------------------------+--- >> Reporter: | Owner: draft-ietf-roll- >> mariainesrobles@gmail.com | applicability- >> Type: defect | ami.all@tools.ietf.org >> Priority: major | Status: new >> Component: applicability-ami | Milestone: >> Severity: Active WG Document | Version: >> | Keywords: >> -------------------------------------+---------------------------------- >> -------------------------------------+--- >>=20 >> Ticket URL: >> roll >>=20 From iesg-secretary@ietf.org Fri Jan 24 12:16: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 539D11A00F4; Fri, 24 Jan 2014 12:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLfdnqSyrf_S; Fri, 24 Jan 2014 12:16:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9681A001A; Fri, 24 Jan 2014 12:16:38 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140124201637.988.3372.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 12:16:37 -0800 Cc: roll@ietf.org Subject: [Roll] Last Call: (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.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: Fri, 24 Jan 2014 20:16:39 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Multicast Protocol for Low power and Lossy Networks (MPL)' as Proposed Standard This is a second last call, the first one having been abandoned to send the document back to the working group. But the latest revision addresses comments that were received during the first last call. 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-02-07. 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 specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain. MPL uses the Trickle algorithm to manage message transmissions for both control and data-plane messages. Different Trickle parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1858/ From wwwrun@rfc-editor.org Fri Jan 24 16:35: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 9E74B1A023B; Fri, 24 Jan 2014 16:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-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 3Tp4PpF_GeFZ; Fri, 24 Jan 2014 16:35:36 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 6038F1A022B; Fri, 24 Jan 2014 16:35:36 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0EAB57FC158; Fri, 24 Jan 2014 16:35:34 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140125003534.0EAB57FC158@rfc-editor.org> Date: Fri, 24 Jan 2014 16:35:34 -0800 (PST) Cc: drafts-update-ref@iana.org, roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] RFC 7102 on Terms Used in Routing for Low-Power and Lossy Networks X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 00:35:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7102 Title: Terms Used in Routing for Low-Power and Lossy Networks Author: JP. Vasseur Status: Informational Stream: IETF Date: January 2014 Mailbox: jpv@cisco.com Pages: 8 Characters: 16444 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-terminology-13.txt URL: http://www.rfc-editor.org/rfc/rfc7102.txt This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration. This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From trac+roll@trac.tools.ietf.org Sat Jan 25 06:52: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 1546E1A0381 for ; Sat, 25 Jan 2014 06:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 3an_sne4MJO4 for ; Sat, 25 Jan 2014 06:52:22 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5EB1A026C for ; Sat, 25 Jan 2014 06:52:21 -0800 (PST) Received: from localhost ([127.0.0.1]:55840 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1W74ab-0005Gs-Ey; Sat, 25 Jan 2014 15:52:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Sat, 25 Jan 2014 14:52:05 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/136#comment:2 Message-ID: <082.03b3caf5937171f985370338449dabf1@trac.tools.ietf.org> References: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> X-Trac-Ticket-ID: 136 In-Reply-To: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami.all@tools.ietf.org, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: daniel.popa@itron.com, jonhui@cisco.com, jorjeta.jetcheva@itron.com, kazuya.monden.vw@hitachi.com, mariainesrobles@gmail.com, , mcr+ietf@sandelman.ca, nicolas.dejean@coronis.com, ruben.salazar@landisgyr.com Cc: roll@ietf.org Subject: Re: [Roll] [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used 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: Sat, 25 Jan 2014 14:52:24 -0000 #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used Comment (by mariainesrobles@gmail.com): Thread: http://www.ietf.org/mail-archive/web/roll/current/msg08437.html Date: Fri, 24 Jan 2014, at 18:32, "Chris Lonvick" wrote Has a threat model been defined for RPL? And do you know that the link- layer security provided by the two IEEE mechanisms will thwart the threats? This isn't meant to be an onerous exercise. :-) What has been done in several WGs has been to define a simple threat model (usually taken from RFC 3552) and then describe how the security mechanisms will thwart the threats. For example, see sections 2 and 3 in RFC 5426 (TLS for syslog). If you can point to the threat model for RPL then you can probably state (just once in the Security Considerations section) how the IEEE link-layer security mechanisms will address the threats so therefore the security mechanisms already contained within RPL will not be needed. ---------------------- From: "Popa, Daniel" Date: Fri, 24 Jan 2014 18:10:36 +0000 “Thanks Chris for feedback. I believe what you advice it is more or less what we intend to do. The difference is that we do not intend to explicitly use a security threat model and show how IEEE works against it, but rather to explain how IEEE 802.15.4 and IEEE p1901.2 security mechanisms can substitute to RPL- defined security mechanisms to provide the same security services as those described in Section 19.1 of RFC 6550, while at the same time giving the system designers & implementers the same degree of freedom to trade-off complexity against security strength, in order to meet HW & cost constraints of such low power field devices. Would this be enough ? ------------------------------------- Date: Fri, 24 Jan 2014, "Chris Lonvick" wrote Works for me. I was hoping that a threat model had already been written up - certainly you shouldn't be defining one now in this document. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability- Type: defect | ami.all@tools.ietf.org Priority: major | Status: new Component: applicability-ami | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: -------------------------------------+------------------------------------- Ticket URL: roll From mcr@sandelman.ca Sat Jan 25 07:06: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 212591A0254 for ; Sat, 25 Jan 2014 07:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.009 X-Spam-Level: * X-Spam-Status: No, score=1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] 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 fdbZGulKGHzZ for ; Sat, 25 Jan 2014 07:06:27 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 9B51D1A00E3 for ; Sat, 25 Jan 2014 07:06:27 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DE3402002F; Sat, 25 Jan 2014 11:22:45 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 6D6F964647; Sat, 25 Jan 2014 10:06:25 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 592BB63AB2; Sat, 25 Jan 2014 10:06:25 -0500 (EST) From: Michael Richardson To: Chris Lonvick In-Reply-To: References: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> <9546f1bf3d68401a8cdf837ca5528de4@BY2PR04MB807.namprd04.prod.outlook.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "draft-ietf-roll-applicability-ami.all@tools.ietf.org" , "roll@ietf.org" Subject: Re: [Roll] [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 15:06:29 -0000 Chris Lonvick wrote: > Has a threat model been defined for RPL? And do you know that the link-layer > security provided by the two IEEE mechanisms will thwart the threats? This > isn't meant to be an onerous exercise. :-) What has been done in several > WGs has been to define a simple threat model (usually taken from RFC 3552) > and then describe how the security mechanisms will thwart the threats. For > example, see sections 2 and 3 in RFC 5426 (TLS for syslog). > If you can point to the threat model for RPL then you can probably state > (just once in the Security Considerations section) how the IEEE link-layer > security mechanisms will address the threats so therefore the security > mechanisms already contained within RPL will not be needed. draft-ietf-roll-security-threats. -- Michael Richardson , Sandelman Software Works From mcr@sandelman.ca Sat Jan 25 08:37: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 EA0151A038C for ; Sat, 25 Jan 2014 08:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, 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 Fm7qd5GpkQNg for ; Sat, 25 Jan 2014 08:37:42 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 49CD81A0253 for ; Sat, 25 Jan 2014 08:37:42 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id ACCEF2002F; Sat, 25 Jan 2014 12:54:00 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id A489F64647; Sat, 25 Jan 2014 11:37:39 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 894CB63AB2; Sat, 25 Jan 2014 11:37:39 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <74c0ab9f632047febba938fe624a94e2@BY2PR04MB807.namprd04.prod.outlook.com> References: <7f3cf88e9e064bb28831d8b273e3169c@CO1PR04MB553.namprd04.prod.outlook.com> <13255.1389643159@sandelman.ca> <74c0ab9f632047febba938fe624a94e2@BY2PR04MB807.namprd04.prod.outlook.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] Questions on the RPL 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: Sat, 25 Jan 2014 16:37:44 -0000 --=-=-= Popa, Daniel wrote: > You're right. In our document the section numbers do not match the > section numbers from the template you proposed. > The questions we have are: > - What is the intent of the Section called "Other protocols"? I'm not sure. I don't have such a section. There are two sections that say, "Other Parameters". I've posted a -04 with some details of what I think belongs in the first of those sections. The diffs are below. > - In your template there are 2 (distinct) sections called "Layer 2 > applicability" and "Description of the Layer 2 features", > respectively. We wondering if these two sections are not somehow > redundant; what is the intent of having these 2 (distinct) sections? section 2.3, layer-2, details what layer-2 technologies are going to be used. This is at the high-level. So in your document, you would write: This applicability statement applies to deployments using IEEE 802.15.4g, 802.15.4e, and for PowerLine Communication (PLC) IEEE P1901.2. whereas in the home-building document it says: This document applies to [IEEE802.15.4] and [G.9959] which are adapted to IPv6 by the adaption layers [RFC4944] and [I-D.brandt-6man-lowpanz]. (and it goes on to explain how 6lowpan is applied to form a layer-3, which actually, I think should go in the other section) In the section of layer-2 features, I would expect to learn the significant details about each of the layer-2s being used.... if you are using the layer-2 security features, how they are configured (no security, per-network keying, per-node pair keying, bootstrapping of new nodes...) and what assumptions one might reasonably be able to make about layer-3 security from layer-2 features. This section will go a long long long way towards making the security review easier: if you claim that layer-2 guarantees no strangers on the network, then a whole bunch of threats go away. {I'm a bit upset at the security reviews that we have got... They have occured, actually, way too soon, and in the wrong direction. Still, all questions are important to answer} -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUuPoUIqHRg3pndX9AQKhKwP8Caj7UAXnYRy5ZI5UW/KlKB13PAEm+OlO cvJ6piyXOztIKAR2WT6IrZ7qVhufD2hvcy97s9TY1xZcdHVcBkGfa5x1VBIH4kcT 13kUVioKBBtbPsUQm+dHbFbAtA53RgqwHH2YadsWvYf53gYLBz8f7SkYf62OqJvk 0gZYdVb3qcE= =C6jN -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sat Jan 25 08:40: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 8132B1A03C4 for ; Sat, 25 Jan 2014 08:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, 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 80nL09L99U4R for ; Sat, 25 Jan 2014 08:40:36 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1431A03BF for ; Sat, 25 Jan 2014 08:40:36 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5AAC72002F for ; Sat, 25 Jan 2014 12:56:55 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id B763064647; Sat, 25 Jan 2014 11:40:34 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9FA7F63AB2 for ; Sat, 25 Jan 2014 11:40:34 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <74c0ab9f632047febba938fe624a94e2@BY2PR04MB807.namprd04.prod.outlook.com> References: <7f3cf88e9e064bb28831d8b273e3169c@CO1PR04MB553.namprd04.prod.outlook.com> <13255.1389643159@sandelman.ca> <74c0ab9f632047febba938fe624a94e2@BY2PR04MB807.namprd04.prod.outlook.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] Questions on the RPL 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: Sat, 25 Jan 2014 16:40:38 -0000 --=-=-= That diff of -03->-04 applicability template: 4.3.1. Trickle Parameters + This section is intended to document the specific value (or ranges) + appropriate for this kind of deployment. This includes trickle + specific parameters such as those of RFC6550, section 8.3.1: Imin + (DIOInternvalMin), Imax (DIOIntrevalDoublings), and k + (DIORedundancyConstant). While it is not necessary to hard code + these parameters into RPL nodes, as they are announced as part of the + DIO message, it is important for researchers who are trying to + validate the convergence properties of the resulting deployment to + understand what values have been selected. +4.3.2. Other Parameters + There are additional values which are present in the DODAG + Configuration option. The purpose of this section is to: a) document + what values are configured, b) if a default value is used, if it is + appropriate for this deployment. + These values include: MaxRankIncrease, MinHopRankIncrease, the + Objective Code Point to use, Default Lifetime, Lifetime Units... + In addition, the kinds of metrics which will be used (RFC6551) needs + to be specified. If Objective Function 0 (RFC6552) is used, then it + specifies a number of values, but also needs definitions of the + stretch_of_rank, and rank_factor. + If MRHOF (RFC6719) is used, then section 5 of this document requires + selection of: MAX_LINK_METRIC, MAX_PATH_COST, + PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT. -- 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) iQCVAwUBUuPpAIqHRg3pndX9AQKSIAQA6ThNEFpnH79kohav5etgZWA/L0C6NzrH wXabPSOnSSeptRgFIZ+ZQiC3l4v6XbPyoYZVrJE8yzS8+xEs9bT46MDmjvnuj/fS Kp6D18+oYBFPky/j96mva4lqoWbnAwDftt4qYMGnhXDbigUxYfZ0zEG4nB1ZpmNE gOY8x/CheiM= =Gsox -----END PGP SIGNATURE----- --=-=-=-- From jt369@drexel.edu Mon Jan 6 18:27: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 417D31AE3CE for ; Mon, 6 Jan 2014 18:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 z8h9p20c52Ju for ; Mon, 6 Jan 2014 18:27:32 -0800 (PST) Received: from smtp.mail.drexel.edu (pm3.irt.drexel.edu [144.118.29.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9121AE3C2 for ; Mon, 6 Jan 2014 18:27:32 -0800 (PST) Received: from esa5000-a.irt.drexel.edu (ace-smtp-nat.noc.drexel.edu [144.118.29.70]) by smtp.mail.drexel.edu (Postfix) with ESMTP id 60D561190677 for ; Mon, 6 Jan 2014 21:27:23 -0500 (EST) Received: from esa5000-a.irt.drexel.edu (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 58AF724A7C21_2CB660BB for ; Tue, 7 Jan 2014 02:27:23 +0000 (GMT) Received: from smtp.mail.drexel.edu (ace-smtp-nat.noc.drexel.edu [144.118.29.70]) by esa5000-a.irt.drexel.edu (Sophos Email Appliance) with ESMTP id 32F7424A7BD6_2CB660BF for ; Tue, 7 Jan 2014 02:27:23 +0000 (GMT) Received: from smtp.mail.drexel.edu (localhost.localdomain [127.0.0.1]) by smtp.mail.drexel.edu (Postfix) with SMTP id 1B7645C8879 for ; Mon, 6 Jan 2014 21:27:23 -0500 (EST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (Authenticated sender: jt369) by smtp.mail.drexel.edu (Postfix) with ESMTP id A35845C887F for ; Mon, 6 Jan 2014 21:27:22 -0500 (EST) Received: by mail-wi0-f180.google.com with SMTP id hm19so146610wib.13 for ; Mon, 06 Jan 2014 18:27:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OWfCAI2uAqbqF9krd/seKEHxPsdAjoapsND6lao+two=; b=mlW+TIAGaod9AejoisWcZMArR8Ef1nFuKCMw2+jL1rN/nIlBuxiQPSfS2QwNGwQZHO j9mnL0F7XT7P3aUAuBrXZoZi+XvWwn0hXyI9DjM442lXrhjH2wL889XdqxN/Pgt4IJ6d JTd+IHY9jvBTA61F62Ca9tXwrSz6w6pCH2N+NQ7KMr+N1VV4jgQ1aXGhQ7BmrsIksS/j XKVuRbiEoG/8uCTCyx7XQopkhBMN8DEJiLEVPpl5wwMUB5kO5XG9ZuatPA7GDbkVAyEG Udvkye5AcEh06sVVwxMAdoUcuN5Ggy3i8WZMa6TC2Tw5KTQkBXAdBjUVyDugh37Zcck9 93cg== MIME-Version: 1.0 X-Received: by 10.180.73.173 with SMTP id m13mr14777152wiv.28.1389061642027; Mon, 06 Jan 2014 18:27:22 -0800 (PST) Received: by 10.194.179.71 with HTTP; Mon, 6 Jan 2014 18:27:21 -0800 (PST) In-Reply-To: References: Message-ID: From: Joydeep Tripathi To: Ulrich Herberg Content-Type: multipart/alternative; boundary=f46d043c07e0be882804ef581d8f X-PerlMx-Authed: User SMTP Authed X-Mailman-Approved-At: Sat, 25 Jan 2014 08:51:51 -0800 Cc: Michael Richardson , Routing Over Low power and Lossy networks , Ines Robles , "Jaudelice C. de Oliveira" Subject: Re: [Roll] Intend for draft-tripathi-roll-reactive-applicability 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: , Date: Tue, 07 Jan 2014 02:27:37 -0000 X-Original-Date: Mon, 6 Jan 2014 21:27:21 -0500 X-List-Received-Date: Tue, 07 Jan 2014 02:27:37 -0000 --f46d043c07e0be882804ef581d8f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ulrich, Thanks for your comments and feedback. Let me respond inline. On Mon, Jan 6, 2014 at 7:14 PM, Ulrich Herberg wrote: > Ines, > > I object any form of publication of this draft. In my opinion, it is > another attempt to discredit LOADng and reactive protocols in general wit= h > false arguments. > Well LOADng is one recent example of reactive protocols. However, we are not discussing about LOADng to *any* extent in this draft. > As has been mentioned before, reactive protocols (in particular LOADng) > have been very successfully deployed in large LLN deployments. So there i= s > proof that in some LLN deployments, reactive protocols work very well. No= te > that I do not claim they work in all such use cases, but the MANET WG has > understood this more than a decade before that reactive protocols can wor= k > in some scenarios, not in all. It is possible to create scenarios where > reactive protocols are better, and others where proactive protocols are > better. > We had tons of discussions on whether LLNs can be generalized as MANETs. You are right to point out that "MANET WG has understood this more than a decade before that reactive protocols can work in some scenarios, not in all". Our argument through this draft is, LLNs in general come under the scenario where reactive protocols suffer due to the points made out in the draft. Note that there may be example where a reactive protocol works for a deployed LLN, but it does not mean it will work better than a proactive counterpart for that deployment or for any other deployment. Claiming that, in general, for LLNs one is better than the other is > incorrect in my opinion. > > But let me argue why I think this draft is flawed by picking the argument= s > made in the draft: > > 3.1. Inability to support P2MP traffic pattern > > This very much depends on the use case. LOADng has been deployed in > several scenarios where P2MP traffic is sparse, and where few concurrent > traffic flows are used. This is not a theoretic scenario, but a deploymen= t > that is actually used by some utilities. > Ability to support P2MP traffic pattern for routing protocols in LLN is mandated by RFC 5548. Actually P2MP and MP2P traffics are pre-dominant for LLNs, and P2P traffic is considered rare. So for a protocol type to be considered a candidate to be used in LLNs it is required to examine how it fairs to handle P2MP traffic. > We have shown in [1] that in this case, LOADng outperforms RPL by far. Se= e > also [5] further evaluations. Not only has LOADng orders of magnitude les= s > control traffic than RPL in the investigated scenarios, but also the stat= e > requirements are far smaller. > At the same time, I wish to point out that this document, in no form is a comparison between RPL and LOADng. Simulation results in form of academic paper references are used to show how a reactive protocol behaves in different scenarios in terms of different metrics. Any protocol implementation can be done in an non-optimized manner to show that performs poorly than another protocol. There are many papers showing RPL outperforms LOADng, specially in large networks. But as I mentioned before, this document does not provide any performance comparison. LOADng is used as an example. To my intuition, AODVv2 may behave in a similar way as well. I do not think this WG is the right place to debate how LOADng or any other protocol performs compared to RPL. This document shows in which areas reactive protocols in general suffer to meet the routing requirements in LLNs, thus pointing out pitfalls to look for / areas of improvement. > > 3.2. Inability to support MP2P traffic pattern > > There is an easy-to-implement extension to LOADng submitted as [2] that > solves this. Performance evaluations in [3] show the efficiency of the > solution. > > 4. Dependency of control overhead on application module > > This is a general observation of reactive protocols that the MANET WG has > understood more than a decade ago. Again, observations of current traffic > patterns in [1] show that reactive protocols have far less control traffi= c > in current use cases of AMI metering. > I guess it is again a deployment and protocol specific example. For a particular deployment and traffic pattern, one protocol may work and meet the requirements. That does not mean the protocol, or protocol-family in general, will be suited to meet the routing requirements spelled out for LLNs in RFC 5548, RFC 5673, RFC 5826, RFC 5867 etc. > Yes, in cases with lots of concurrent traffic lows, then the argument is > correct (note that the amount of data does not really matter, as the rout= e > is only discovered once; so even sending gigabytes/second would not be an > issue as long as there are limited amount of traffic flows). So this is > another argument of the sort that MANET rejected long time ago. It really > depends on the use case and the kind of traffic we are talking about. > The draft not does not even consider any application traffic rate or range of data traffic rate. It considers, as you pointed correctly, different flows, and future installation of application modules. So I guess we both agree, that number of traffic flows is a factor in generating control overhead. > 5. Flooding issues in LLNs > > It is correct that flooding causes a lot of overhead and battery drain. > But note that we also observed in [1] and [4] that RPL in downward mode > also causes a lot of control traffic, more than LOADng for a similar > scenario that is described in the draft. It again depends on the use case= . > For example, with the extension proposed in [2], the performance for such > traffic in LOADng is at least as good as with RPL (see also [3]). Note th= at > in the described scenario, RPL would require an equal amount of state (in > storing mode), or lead to very long packets in non-storing mode and > therefore potential fragmentation, such as described in [4]. > I would again like to point out that this draft is not a performance comparison between RPL and LOADng. However, I would also like to point out that `N' number of unicast control packets consume less energy than `N' number of broadcast control packets. The reasoning is provided in next subsection (5.1). In smaller deployments and light traffic scenario, reactive protocols may incur less control overhead than a proactive counterpart. However, most of these control packets are broadcast packets, thus consuming much more energy than a proactive counterpart even if the proactive protocol shows more control packets in the simulation. For deployments where reactive protocols create more control overhead, they may require energy expense a magnitude larger, depending on the MAC layer. > 5.1. Impact of flooding in battery operated nodes > > "Note that there is a lot of experimental evidence supporting the claim > that using flooding or scoped flooding to discover routes is ill-suited t= o > low-power and lossy networks (LLNs)". Where? I prefer citations over > assertions. > The reasoning why this is the case is provided with references is provided i version-02 of the draft. For the detailed text, please refer to the version 02, which we just posted. > Note that I am not claiming that flooding is not costly, but it -- again > -- depends on the scenario how many different concurrent traffic flows ar= e > required and how long routes are stored. Also note that optimizations, su= ch > as MPR flooding, can optimize flooding compared to classic flooding. > > 6. Impact on memory > > This again depends on the use case. As we have described in [4], RPL in > storing mode also requires a lot of state. In non-storing mode, packets m= ay > become very long and lead to fragmentation. With few concurrent traffic > flows, LOADng largely outperforms RPL in terms of storage requirements (i= n > many cases, a single route at a time may be sufficient). > With the assertion one more time that this is not a performance comparison draft, I would like to point out that with header compression, source routing is very much feasible even over 802.15.4. And once again, you are comparing LOADng with *few concurrent flows*. The argument will be invalid for nodes closer to a sink for a large scale network. I agree it depends on use cases and traffic profiles. However this document, as I mentioned, provides a general overview, and is intended to consider superset of cases, and to guide implementors to look at the probable pitfalls that reactive protocols may be subjected to. I understand there is no one-size-fits-all for MANET, but this is not MANET WG. What we are really trying to show in this document is where reactive protocols fail to meet the routing requirements for LLNs. I would appreciate further comments or feedback. Thanks & Regards, Joydeep > > 7. Lack of support for routing based on node capability > > This argument is flawed. LOADng provides a very extensible and flexible > definition of route metrics. It is easy to create a metric that reflects > limitations of the nodes, such as energy and CPU/memory resource > limitations. How is this different from RPL? > > 8. High delay for emergency traffic > > While it is true that reactive protocols have a higher delay requirement > than proactive protocols, the argument is, again, flawed. The draft write= s > "*Some* data in an LLN are delay sensitive by nature". I agree. It furthe= r > mentions industrial automation settings. Yes, in *some* LLNs, delay is > indeed critical (e.g., light switch), but in others it is not as much (AM= I > metering). The draft argues that reactive protocols are bad for *all* LLN= s, > but provides evidence only for *some*. This is exactly what the MANET WG > has agreed on in the 1990s that there is no one-size-fits-all. > > > [1] U. Herberg, T. Clausen, "A Comparative Performance Study of the > Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-power a= nd > Lossy Networks (LLN)", Proceedings of the 8th ACM International Symposium > on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous > Networks (PE-WASUN), October 2011 > [2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight On-deman= d > Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)", > draft-yi-loadngct-01, Internet Draft (work in progress) > [3] J. Yi, T. Clausen, and A. Colin de Verdiere. "Efficient Data > Acquisition in Sensor Networks: Introducing (the) LOADng Collection Tree > Protocol", Proceedings of the 8th IEEE International Conference on Wirele= ss > Communications, Networking and Mobile Computing - WiCom-2012, October 201= 2 > [4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, =93Experiences with RPL: > IPv6 Routing Protocol for Low power and Lossy Networks=94, Internet Draft > (work in progress), draft-clausen-lln-rpl-experiences-06, February 2013. > [5] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for > Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013 IE= EE > Conference on Wireless Sensors > > Best regards > Ulrich > > > > On Mon, Jan 6, 2014 at 10:24 AM, JP Vasseur (jvasseur) > wrote: > >> I can see two paths: (1) ROLL WG ID (not the easiest though, although >> this could be seen as an applicability >> ID) or (2) AD sponsored ? >> >> On Jan 6, 2014, at 7:10 PM, Ines Robles >> wrote: >> >> >> >> >> >> * Hi, Thanks for this draft, >> https://ietf.org/doc/draft-tripathi-roll-reactive-applicability/ >> Abstr= act >> This document describes serious issues and shortcomings regarding the us= e >> of reactive routing protocols in low power and lossy networks(LLNs). >> Routing requirements for various LLN deployments are discussed in order = to >> judge how reactive routing may or may notadhere to the necessary criteri= a. >> We would like to know please, how is the intend for this document? how >> this draft would be aligned with roll charter?, should we re-chartering?= * >> >> *Thank you in advance,* >> >> Ines Robles >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > --f46d043c07e0be882804ef581d8f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Ulrich,

Thanks for your commen= ts and feedback. Let me respond inline.
On Mon, Jan 6, 2014 at 7:14 PM, Ulrich Herberg = <ulrich@herberg.name> wrote:
Ines,

I object any form of publica= tion of this draft. In my opinion, it is another attempt to discredit LOADn= g and reactive protocols in general with false arguments.

Well LOADng is one recent example of= reactive protocols. However, we are not discussing about LOADng to *any* e= xtent in this draft.
=A0
As has been mentioned before, reactive protocols (in parti= cular LOADng) have been very successfully deployed in large LLN deployments= . So there is proof that in some LLN deployments, reactive protocols work v= ery well. Note that I do not claim they work in all such use cases, but the= MANET WG has understood this more than a decade before that reactive proto= cols can work in some scenarios, not in all. It is possible to create scena= rios where reactive protocols are better, and others where proactive protoc= ols are better.

We had tons of discussions on whethe= r LLNs can be generalized as MANETs. You are right to point out that "= MANET WG has understood this more than a decade before that reactive protoc= ols can work in some scenarios, not in all". Our argument through this= draft is, LLNs in general come under the scenario where reactive protocols= suffer due to the points made out in the draft. Note that there may be exa= mple where a reactive protocol works for a deployed LLN, but it does not me= an it will work better than a proactive counterpart for that deployment or = for any other deployment.

Claiming that, in ge= neral, for LLNs one is better than the other is incorrect in my opinion.
But let me argue why I think this draft is flawed by picking the argume= nts made in the draft:

3.1. Inability to support P2MP traffic patter= n

This very much depends on the use case. LOADng has been deployed i= n several scenarios where P2MP traffic is sparse, and where few concurrent = traffic flows are used. This is not a theoretic scenario, but a deployment = that is actually used by some utilities.
=A0
Ability to support P2MP traffic pattern=A0f= or routing protocols in LLN is mandated by RFC 5548. Actually P2MP and MP2P= traffics are pre-dominant for LLNs, and P2P traffic is considered rare. So= for a protocol type to be considered a candidate to be used in LLNs it is = required to examine how it fairs to handle P2MP traffic.
=A0
We have shown in [1] that = in this case, LOADng outperforms RPL by far. See also [5] further evaluatio= ns. Not only has LOADng orders of magnitude less control traffic than RPL i= n the investigated scenarios, but also the state requirements are far small= er.

=A0At the same time, I wish to= point out that this document, in no form is a comparison between RPL and L= OADng. Simulation results in form of academic paper references are used to = show how a reactive protocol behaves in different scenarios in terms of dif= ferent metrics. Any protocol implementation can be done in an non-optimized= manner to show that performs poorly than another protocol. There are many = papers showing RPL outperforms LOADng, specially in large networks. But as = I mentioned before, this document does not provide any performance comparis= on. LOADng is used as an example. To my intuition, AODVv2 may behave in a s= imilar way as well. I do not think this WG is the right place to debate how= LOADng or any other protocol performs compared to RPL. This document shows= in which areas reactive protocols in general suffer to meet the routing re= quirements in LLNs, thus pointing out pitfalls to look for / areas of impro= vement.
=A0

3.2. Inability to support MP2P traffic pattern

There is an easy-= to-implement extension to LOADng submitted as [2] that solves this. Perform= ance evaluations in [3] show the efficiency of the solution.

4. Depe= ndency of control overhead on application module

This is a general observation of reactive protocols that the MANET WG h= as understood more than a decade ago. Again, observations of current traffi= c patterns in [1] show that reactive protocols have far less control traffi= c in current use cases of AMI metering.

I guess it is again a deployment and= protocol specific example. For a particular deployment and traffic pattern= , one protocol may work and meet the requirements. That does not mean the p= rotocol, or protocol-family in general, will be suited to meet the routing = requirements spelled out for LLNs in RFC 5548, RFC 5673, RFC 5826, RFC 5867= etc.=A0
=A0
Yes, in cases with lo= ts of concurrent traffic lows, then the argument is correct (note that the = amount of data does not really matter, as the route is only discovered once= ; so even sending gigabytes/second would not be an issue as long as there a= re limited amount of traffic flows). So this is another argument of the sor= t that MANET rejected long time ago. It really depends on the use case and = the kind of traffic we are talking about.

The draft not does not even co= nsider any application traffic rate or range of data traffic rate. It consi= ders, as you pointed correctly, different flows, and future installation of= application modules. So I guess we both agree, that number of traffic flow= s is a factor in generating control overhead.


5. Flooding issues in LLNs

It is correct that flooding causes a = lot of overhead and battery drain. But note that we also observed in [1] an= d [4] that RPL in downward mode also causes a lot of control traffic, more = than LOADng for a similar scenario that is described in the draft. It again= depends on the use case. For example, with the extension proposed in [2], = the performance for such traffic in LOADng is at least as good as with RPL = (see also [3]). Note that in the described scenario, RPL would require an e= qual amount of state (in storing mode), or lead to very long packets in non= -storing mode and therefore potential fragmentation, such as described in [= 4].

I would again like to point ou= t that this draft is not a performance comparison between RPL and LOADng. H= owever, I would also like to point out that `N' number of unicast contr= ol packets consume less energy than `N' number of broadcast control pac= kets. The reasoning is provided in next subsection (5.1). In smaller deploy= ments and light traffic scenario, reactive protocols may incur less control= overhead than a proactive counterpart. However, most of these control pack= ets are broadcast packets, thus consuming much more energy than a proactive= counterpart even if the proactive protocol shows more control packets in t= he simulation. For deployments where reactive protocols create more control= overhead, they may require energy expense a magnitude larger, depending on= the MAC layer.


5.1. Impact of flooding in battery operated nodes

"Note tha= t there is a lot of experimental evidence supporting the claim that using f= looding or scoped flooding to discover routes is ill-suited to low-power an= d lossy networks (LLNs)". Where? I prefer citations over assertions.

The reasoning why this is the = case is provided with references is provided i version-02 of the draft. For= the detailed text, please refer to the version 02, which we just posted.
=A0
Note that I am not claiming that flooding is not costly, but it -- again --= depends on the scenario how many different concurrent traffic flows are re= quired and how long routes are stored. Also note that optimizations, such a= s MPR flooding, can optimize flooding compared to classic flooding.

6. Impact on memory

This again depends on the use case. As we ha= ve described in [4], RPL in storing mode also requires a lot of state. In n= on-storing mode, packets may become very long and lead to fragmentation. Wi= th few concurrent traffic flows, LOADng largely outperforms RPL in terms of= storage requirements (in many cases, a single route at a time may be suffi= cient).

With the assertion one more ti= me that this is not a performance comparison draft, I would like to point o= ut that with header compression, source routing is very much feasible even = over 802.15.4. And once again, you are comparing LOADng with *few concurren= t flows*. The argument will be invalid for nodes closer to a sink for a lar= ge scale network. I agree it depends on use cases and traffic profiles. How= ever this document, as I mentioned, provides a general overview, and is int= ended to consider superset of cases, and to guide implementors to look at t= he probable pitfalls that reactive protocols may be subjected to.

I understand there is no=A0one-size-fits-al= l for MANET, but this is not MANET WG. What we are really trying to show in= this document is where reactive protocols fail to meet the routing require= ments for LLNs.=A0

I would appreciate further comments or=A0fe= edback.

Thanks &=A0Regards,
<= div style>Joydeep
=A0

7. Lack of support for routing based on node capability

This arg= ument is flawed. LOADng provides a very extensible and flexible definition = of route metrics. It is easy to create a metric that reflects limitations o= f the nodes, such as energy and CPU/memory resource limitations. How is thi= s different from RPL?

8. High delay for emergency traffic

While it is true that reacti= ve protocols have a higher delay requirement than proactive protocols, the = argument is, again, flawed. The draft writes "*Some* data in an LLN ar= e delay sensitive by nature". I agree. It further mentions industrial = automation settings. Yes, in *some* LLNs, delay is indeed critical (e.g., l= ight switch), but in others it is not as much (AMI metering). The draft arg= ues that reactive protocols are bad for *all* LLNs, but provides evidence o= nly for *some*. This is exactly what the MANET WG has agreed on in the 1990= s that there is no one-size-fits-all.


[1] U. Herberg, T. Clausen, "A Comparative Performance Study o= f the Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-pow= er and Lossy Networks (LLN)", Proceedings of the 8th ACM International= Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiqui= tous Networks (PE-WASUN), October 2011
[2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight On-de= mand Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)", dr= aft-yi-loadngct-01, Internet Draft (work in progress)
[3] J. Yi, T. Clau= sen, and A. Colin de Verdiere. "Efficient Data Acquisition in Sensor N= etworks: Introducing (the) LOADng Collection Tree Protocol", Proceedin= gs of the 8th IEEE International Conference on Wireless Communications, Net= working and Mobile Computing - WiCom-2012, October 2012
[4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, =93Experiences with RPL: IP= v6 Routing Protocol for Low power and Lossy Networks=94, Internet Draft (wo= rk in progress), draft-clausen-lln-rpl-experiences-06, February 2013.
[5= ] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for = Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013= IEEE Conference on Wireless Sensors

Best regards
Ulrich



=
On Mon, Jan 6, 2014 at 10= :24 AM, JP Vasseur (jvasseur) <jvasseur@cisco.com> wrote:
I can see two paths: (1) ROLL WG ID (not the easiest though, although this = could be seen as an applicability
ID) or (2) AD sponsored ?

On Jan 6, 2014, at 7:10 PM, Ines Robles <mariainesrobles@googlemail.com> wrote:

Hi,
Abstract

This document describes serious issue= s and shortcomings regarding the use of reactive routing protocols in low power and lossy networks(LLNs= ). Routing requirements for various LLN deployments are discussed in order = to judge how reactive routing may or may notadhere to the necessary criteri= a.

We would like to know please, =A0how is the intend for this document? how thi= s draft would be aligned with roll charter?, should we re-chartering?

Thank you in advance,

Ines Robles


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



--f46d043c07e0be882804ef581d8f-- From jt369@drexel.edu Mon Jan 6 19:01: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 E6F831ADF35 for ; Mon, 6 Jan 2014 19:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 arMvfSTvPeD5 for ; Mon, 6 Jan 2014 19:01:21 -0800 (PST) Received: from smtp.mail.drexel.edu (pm3.irt.drexel.edu [144.118.29.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2471AE3E5 for ; Mon, 6 Jan 2014 19:01:20 -0800 (PST) Received: from esa5000-a.irt.drexel.edu (ace-smtp-nat.noc.drexel.edu [144.118.29.70]) by smtp.mail.drexel.edu (Postfix) with ESMTP id 866A011906F9 for ; Mon, 6 Jan 2014 22:01:11 -0500 (EST) Received: from esa5000-a.irt.drexel.edu (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 720A324A7C57_2CB6DF7B for ; Tue, 7 Jan 2014 03:01:11 +0000 (GMT) Received: from smtp.mail.drexel.edu (ace-smtp-nat.noc.drexel.edu [144.118.29.70]) by esa5000-a.irt.drexel.edu (Sophos Email Appliance) with ESMTP id 1DE8124A7C21_2CB6DF7F for ; Tue, 7 Jan 2014 03:01:11 +0000 (GMT) Received: from smtp.mail.drexel.edu (localhost.localdomain [127.0.0.1]) by smtp.mail.drexel.edu (Postfix) with SMTP id CBA885C85D1 for ; Mon, 6 Jan 2014 22:01:10 -0500 (EST) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (Authenticated sender: jt369) by smtp.mail.drexel.edu (Postfix) with ESMTP id C20B05C85DF for ; Mon, 6 Jan 2014 22:01:09 -0500 (EST) Received: by mail-we0-f175.google.com with SMTP id w62so62157wes.34 for ; Mon, 06 Jan 2014 19:01:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OLpPiCepIq3T68HIO8gUiLCr778ObVYO/pRPg7Soptg=; b=IFrdGv79Uj1lgaIMsD0yEX7Js/435FVYsi5bO4sgo2XbB9oaIw0F5K+qoselZnXno4 LcJPf76EyaQ7VkTrhaQj9PY24yQgYh1iW/I57AWs8AhMpliB/xJq0ONdY//R4pYlYfSk cfLJcrQaoZK2GuBwVJ1Iu+g95bboeDXCkNV+hg/jzoa/BYZ8PeHbiaVamulNK5wzVoWm oOgGTlCr+zlhR7WJycW5rKqPJGtXpNWzPrbFqsIlF+KQXXJQqsygMP4xYWgTgt/9S3uf qcLzQwyvZLl0NQ09mNwugPznP+OojFvmrxwvarMbndQsdGNGySYX8GHMXK6wpVij38Md ITWg== MIME-Version: 1.0 X-Received: by 10.194.60.103 with SMTP id g7mr74198797wjr.37.1389063669118; Mon, 06 Jan 2014 19:01:09 -0800 (PST) Received: by 10.194.179.71 with HTTP; Mon, 6 Jan 2014 19:01:08 -0800 (PST) In-Reply-To: References: Message-ID: From: Joydeep Tripathi To: ROLL WG Content-Type: multipart/alternative; boundary=047d7b86cfbc917dea04ef5896cb X-PerlMx-Authed: User SMTP Authed X-Mailman-Approved-At: Sat, 25 Jan 2014 08:51:51 -0800 Subject: [Roll] Fwd: Intend for draft-tripathi-roll-reactive-applicability 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: , Date: Tue, 07 Jan 2014 03:01:26 -0000 X-Original-Date: Mon, 6 Jan 2014 22:01:08 -0500 X-List-Received-Date: Tue, 07 Jan 2014 03:01:26 -0000 --047d7b86cfbc917dea04ef5896cb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ulrich, Thanks for your comments and feedback. Let me respond inline. On Mon, Jan 6, 2014 at 7:14 PM, Ulrich Herberg wrote: > Ines, > > I object any form of publication of this draft. In my opinion, it is > another attempt to discredit LOADng and reactive protocols in general wit= h > false arguments. > Well LOADng is one recent example of reactive protocols. However, we are not discussing about LOADng to *any* extent in this draft. > As has been mentioned before, reactive protocols (in particular LOADng) > have been very successfully deployed in large LLN deployments. So there i= s > proof that in some LLN deployments, reactive protocols work very well. No= te > that I do not claim they work in all such use cases, but the MANET WG has > understood this more than a decade before that reactive protocols can wor= k > in some scenarios, not in all. It is possible to create scenarios where > reactive protocols are better, and others where proactive protocols are > better. > We had tons of discussions on whether LLNs can be generalized as MANETs. You are right to point out that "MANET WG has understood this more than a decade before that reactive protocols can work in some scenarios, not in all". Our argument through this draft is, LLNs in general come under the scenario where reactive protocols suffer due to the points made out in the draft. Note that there may be example where a reactive protocol works for a deployed LLN, but it does not mean it will work better than a proactive counterpart for that deployment or for any other deployment. Claiming that, in general, for LLNs one is better than the other is > incorrect in my opinion. > > But let me argue why I think this draft is flawed by picking the argument= s > made in the draft: > > 3.1. Inability to support P2MP traffic pattern > > This very much depends on the use case. LOADng has been deployed in > several scenarios where P2MP traffic is sparse, and where few concurrent > traffic flows are used. This is not a theoretic scenario, but a deploymen= t > that is actually used by some utilities. > Ability to support P2MP traffic pattern for routing protocols in LLN is mandated by RFC 5548. Actually P2MP and MP2P traffics are pre-dominant for LLNs, and P2P traffic is considered rare. So for a protocol type to be considered a candidate to be used in LLNs it is required to examine how it fairs to handle P2MP traffic. > We have shown in [1] that in this case, LOADng outperforms RPL by far. Se= e > also [5] further evaluations. Not only has LOADng orders of magnitude les= s > control traffic than RPL in the investigated scenarios, but also the stat= e > requirements are far smaller. > At the same time, I wish to point out that this document, in no form is a comparison between RPL and LOADng. Simulation results in form of academic paper references are used to show how a reactive protocol behaves in different scenarios in terms of different metrics. Any protocol implementation can be done in an non-optimized manner to show that performs poorly than another protocol. There are many papers showing RPL outperforms LOADng, specially in large networks. But as I mentioned before, this document does not provide any performance comparison. LOADng is used as an example. To my intuition, AODVv2 may behave in a similar way as well. I do not think this WG is the right place to debate how LOADng or any other protocol performs compared to RPL. This document shows in which areas reactive protocols in general suffer to meet the routing requirements in LLNs, thus pointing out pitfalls to look for / areas of improvement. > > 3.2. Inability to support MP2P traffic pattern > > There is an easy-to-implement extension to LOADng submitted as [2] that > solves this. Performance evaluations in [3] show the efficiency of the > solution. > > 4. Dependency of control overhead on application module > > This is a general observation of reactive protocols that the MANET WG has > understood more than a decade ago. Again, observations of current traffic > patterns in [1] show that reactive protocols have far less control traffi= c > in current use cases of AMI metering. > I guess it is again a deployment and protocol specific example. For a particular deployment and traffic pattern, one protocol may work and meet the requirements. That does not mean the protocol, or protocol-family in general, will be suited to meet the routing requirements spelled out for LLNs in RFC 5548, RFC 5673, RFC 5826, RFC 5867 etc. > Yes, in cases with lots of concurrent traffic lows, then the argument is > correct (note that the amount of data does not really matter, as the rout= e > is only discovered once; so even sending gigabytes/second would not be an > issue as long as there are limited amount of traffic flows). So this is > another argument of the sort that MANET rejected long time ago. It really > depends on the use case and the kind of traffic we are talking about. > The draft not does not even consider any application traffic rate or range of data traffic rate. It considers, as you pointed correctly, different flows, and future installation of application modules. So I guess we both agree, that number of traffic flows is a factor in generating control overhead. > 5. Flooding issues in LLNs > > It is correct that flooding causes a lot of overhead and battery drain. > But note that we also observed in [1] and [4] that RPL in downward mode > also causes a lot of control traffic, more than LOADng for a similar > scenario that is described in the draft. It again depends on the use case= . > For example, with the extension proposed in [2], the performance for such > traffic in LOADng is at least as good as with RPL (see also [3]). Note th= at > in the described scenario, RPL would require an equal amount of state (in > storing mode), or lead to very long packets in non-storing mode and > therefore potential fragmentation, such as described in [4]. > I would again like to point out that this draft is not a performance comparison between RPL and LOADng. However, I would also like to point out that `N' number of unicast control packets consume less energy than `N' number of broadcast control packets. The reasoning is provided in next subsection (5.1). In smaller deployments and light traffic scenario, reactive protocols may incur less control overhead than a proactive counterpart. However, most of these control packets are broadcast packets, thus consuming much more energy than a proactive counterpart even if the proactive protocol shows more control packets in the simulation. For deployments where reactive protocols create more control overhead, they may require energy expense a magnitude larger, depending on the MAC layer. > 5.1. Impact of flooding in battery operated nodes > > "Note that there is a lot of experimental evidence supporting the claim > that using flooding or scoped flooding to discover routes is ill-suited t= o > low-power and lossy networks (LLNs)". Where? I prefer citations over > assertions. > The reasoning why this is the case is provided with references is provided i version-02 of the draft. For the detailed text, please refer to the version 02, which we just posted. > Note that I am not claiming that flooding is not costly, but it -- again > -- depends on the scenario how many different concurrent traffic flows ar= e > required and how long routes are stored. Also note that optimizations, su= ch > as MPR flooding, can optimize flooding compared to classic flooding. > > 6. Impact on memory > > This again depends on the use case. As we have described in [4], RPL in > storing mode also requires a lot of state. In non-storing mode, packets m= ay > become very long and lead to fragmentation. With few concurrent traffic > flows, LOADng largely outperforms RPL in terms of storage requirements (i= n > many cases, a single route at a time may be sufficient). > With the assertion one more time that this is not a performance comparison draft, I would like to point out that with header compression, source routing is very much feasible even over 802.15.4. And once again, you are comparing LOADng with *few concurrent flows*. The argument will be invalid for nodes closer to a sink for a large scale network. I agree it depends on use cases and traffic profiles. However this document, as I mentioned, provides a general overview, and is intended to consider superset of cases, and to guide implementors to look at the probable pitfalls that reactive protocols may be subjected to. I understand there is no one-size-fits-all for MANET, but this is not MANET WG. What we are really trying to show in this document is where reactive protocols fail to meet the routing requirements for LLNs. I would appreciate further comments or feedback. Thanks & Regards, Joydeep > > 7. Lack of support for routing based on node capability > > This argument is flawed. LOADng provides a very extensible and flexible > definition of route metrics. It is easy to create a metric that reflects > limitations of the nodes, such as energy and CPU/memory resource > limitations. How is this different from RPL? > > 8. High delay for emergency traffic > > While it is true that reactive protocols have a higher delay requirement > than proactive protocols, the argument is, again, flawed. The draft write= s > "*Some* data in an LLN are delay sensitive by nature". I agree. It furthe= r > mentions industrial automation settings. Yes, in *some* LLNs, delay is > indeed critical (e.g., light switch), but in others it is not as much (AM= I > metering). The draft argues that reactive protocols are bad for *all* LLN= s, > but provides evidence only for *some*. This is exactly what the MANET WG > has agreed on in the 1990s that there is no one-size-fits-all. > > > [1] U. Herberg, T. Clausen, "A Comparative Performance Study of the > Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-power a= nd > Lossy Networks (LLN)", Proceedings of the 8th ACM International Symposium > on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous > Networks (PE-WASUN), October 2011 > [2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight On-deman= d > Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)", > draft-yi-loadngct-01, Internet Draft (work in progress) > [3] J. Yi, T. Clausen, and A. Colin de Verdiere. "Efficient Data > Acquisition in Sensor Networks: Introducing (the) LOADng Collection Tree > Protocol", Proceedings of the 8th IEEE International Conference on Wirele= ss > Communications, Networking and Mobile Computing - WiCom-2012, October 201= 2 > [4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, =93Experiences with RPL: > IPv6 Routing Protocol for Low power and Lossy Networks=94, Internet Draft > (work in progress), draft-clausen-lln-rpl-experiences-06, February 2013. > [5] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for > Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013 IE= EE > Conference on Wireless Sensors > > Best regards > Ulrich > > > > On Mon, Jan 6, 2014 at 10:24 AM, JP Vasseur (jvasseur) > wrote: > >> I can see two paths: (1) ROLL WG ID (not the easiest though, although >> this could be seen as an applicability >> ID) or (2) AD sponsored ? >> >> On Jan 6, 2014, at 7:10 PM, Ines Robles >> wrote: >> >> >> >> >> >> * Hi, Thanks for this draft, >> https://ietf.org/doc/draft-tripathi-roll-reactive-applicability/ >> Abstr= act >> This document describes serious issues and shortcomings regarding the us= e >> of reactive routing protocols in low power and lossy networks(LLNs). >> Routing requirements for various LLN deployments are discussed in order = to >> judge how reactive routing may or may notadhere to the necessary criteri= a. >> We would like to know please, how is the intend for this document? how >> this draft would be aligned with roll charter?, should we re-chartering?= * >> >> *Thank you in advance,* >> >> Ines Robles >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > --047d7b86cfbc917dea04ef5896cb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Ulrich,=

Thanks for your comments and feedback. Let me respond i= nline.

On Mon, Jan 6, 2014 at 7:14 PM, Ulrich Herberg <ulrich@herberg.name&= gt; wrote:
Ines,

I object any form of publica= tion of this draft. In my opinion, it is another attempt to discredit LOADn= g and reactive protocols in general with false arguments.

Well LOADng is one recent example of= reactive protocols. However, we are not discussing about LOADng to *any* e= xtent in this draft.
=A0
As has been mentioned before, reactive protocols (in parti= cular LOADng) have been very successfully deployed in large LLN deployments= . So there is proof that in some LLN deployments, reactive protocols work v= ery well. Note that I do not claim they work in all such use cases, but the= MANET WG has understood this more than a decade before that reactive proto= cols can work in some scenarios, not in all. It is possible to create scena= rios where reactive protocols are better, and others where proactive protoc= ols are better.

We had tons of discussions on whethe= r LLNs can be generalized as MANETs. You are right to point out that "= MANET WG has understood this more than a decade before that reactive protoc= ols can work in some scenarios, not in all". Our argument through this= draft is, LLNs in general come under the scenario where reactive protocols= suffer due to the points made out in the draft. Note that there may be exa= mple where a reactive protocol works for a deployed LLN, but it does not me= an it will work better than a proactive counterpart for that deployment or = for any other deployment.

Claiming that, in general,= for LLNs one is better than the other is incorrect in my opinion.

But let me argue why I think this draft is flawed by picking the argume= nts made in the draft:

3.1. Inability to support P2MP traffic patter= n

This very much depends on the use case. LOADng has been deployed i= n several scenarios where P2MP traffic is sparse, and where few concurrent = traffic flows are used. This is not a theoretic scenario, but a deployment = that is actually used by some utilities.
=A0
Ability to support P2MP traffic patte= rn=A0for routing protocols in LLN is mandated by RFC 5548. Actually P2MP an= d MP2P traffics are pre-dominant for LLNs, and P2P traffic is considered ra= re. So for a protocol type to be considered a candidate to be used in LLNs = it is required to examine how it fairs to handle P2MP traffic.
=A0
We have shown in [1] that = in this case, LOADng outperforms RPL by far. See also [5] further evaluatio= ns. Not only has LOADng orders of magnitude less control traffic than RPL i= n the investigated scenarios, but also the state requirements are far small= er.

=A0At the same time, I wish to= point out that this document, in no form is a comparison between RPL and L= OADng. Simulation results in form of academic paper references are used to = show how a reactive protocol behaves in different scenarios in terms of dif= ferent metrics. Any protocol implementation can be done in an non-optimized= manner to show that performs poorly than another protocol. There are many = papers showing RPL outperforms LOADng, specially in large networks. But as = I mentioned before, this document does not provide any performance comparis= on. LOADng is used as an example. To my intuition, AODVv2 may behave in a s= imilar way as well. I do not think this WG is the right place to debate how= LOADng or any other protocol performs compared to RPL. This document shows= in which areas reactive protocols in general suffer to meet the routing re= quirements in LLNs, thus pointing out pitfalls to look for / areas of impro= vement.
=A0

3.2. Inability to support MP2P traffic pattern

There is an easy-= to-implement extension to LOADng submitted as [2] that solves this. Perform= ance evaluations in [3] show the efficiency of the solution.

4. Depe= ndency of control overhead on application module

This is a general observation of reactive protocols that the MANET WG h= as understood more than a decade ago. Again, observations of current traffi= c patterns in [1] show that reactive protocols have far less control traffi= c in current use cases of AMI metering.

I guess it is again a deployment and= protocol specific example. For a particular deployment and traffic pattern= , one protocol may work and meet the requirements. That does not mean the p= rotocol, or protocol-family in general, will be suited to meet the routing = requirements spelled out for LLNs in RFC 5548, RFC 5673, RFC 5826, RFC 5867= etc.=A0
=A0
Yes, in cases with lots of = concurrent traffic lows, then the argument is correct (note that the amount= of data does not really matter, as the route is only discovered once; so e= ven sending gigabytes/second would not be an issue as long as there are lim= ited amount of traffic flows). So this is another argument of the sort that= MANET rejected long time ago. It really depends on the use case and the ki= nd of traffic we are talking about.

The draft not does not even co= nsider any application traffic rate or range of data traffic rate. It consi= ders, as you pointed correctly, different flows, and future installation of= application modules. So I guess we both agree, that number of traffic flow= s is a factor in generating control overhead.


5. Flooding issues in LLNs

It is correct that flooding causes a = lot of overhead and battery drain. But note that we also observed in [1] an= d [4] that RPL in downward mode also causes a lot of control traffic, more = than LOADng for a similar scenario that is described in the draft. It again= depends on the use case. For example, with the extension proposed in [2], = the performance for such traffic in LOADng is at least as good as with RPL = (see also [3]). Note that in the described scenario, RPL would require an e= qual amount of state (in storing mode), or lead to very long packets in non= -storing mode and therefore potential fragmentation, such as described in [= 4].

I would again like to point ou= t that this draft is not a performance comparison between RPL and LOADng. H= owever, I would also like to point out that `N' number of unicast contr= ol packets consume less energy than `N' number of broadcast control pac= kets. The reasoning is provided in next subsection (5.1). In smaller deploy= ments and light traffic scenario, reactive protocols may incur less control= overhead than a proactive counterpart. However, most of these control pack= ets are broadcast packets, thus consuming much more energy than a proactive= counterpart even if the proactive protocol shows more control packets in t= he simulation. For deployments where reactive protocols create more control= overhead, they may require energy expense a magnitude larger, depending on= the MAC layer.


5.1. Impact of flooding in battery operated nodes

"Note tha= t there is a lot of experimental evidence supporting the claim that using f= looding or scoped flooding to discover routes is ill-suited to low-power an= d lossy networks (LLNs)". Where? I prefer citations over assertions.

The reasoning why this is the = case is provided with references is provided i version-02 of the draft. For= the detailed text, please refer to the version 02, which we just posted.
=A0
Note that I am not claiming that flooding is not costly, but it -- again --= depends on the scenario how many different concurrent traffic flows are re= quired and how long routes are stored. Also note that optimizations, such a= s MPR flooding, can optimize flooding compared to classic flooding.

6. Impact on memory

This again depends on the use case. As we ha= ve described in [4], RPL in storing mode also requires a lot of state. In n= on-storing mode, packets may become very long and lead to fragmentation. Wi= th few concurrent traffic flows, LOADng largely outperforms RPL in terms of= storage requirements (in many cases, a single route at a time may be suffi= cient).

With the assertion one more ti= me that this is not a performance comparison draft, I would like to point o= ut that with header compression, source routing is very much feasible even = over 802.15.4. And once again, you are comparing LOADng with *few concurren= t flows*. The argument will be invalid for nodes closer to a sink for a lar= ge scale network. I agree it depends on use cases and traffic profiles. How= ever this document, as I mentioned, provides a general overview, and is int= ended to consider superset of cases, and to guide implementors to look at t= he probable pitfalls that reactive protocols may be subjected to.

I understand there is no=A0one-size-fits-all for MANET,= but this is not MANET WG. What we are really trying to show in this docume= nt is where reactive protocols fail to meet the routing requirements for LL= Ns.=A0

I would appreciate further comments or=A0feedback.

Thanks &=A0Regards,
Joydeep
=A0

7. Lack of support for routing based on node capability

This arg= ument is flawed. LOADng provides a very extensible and flexible definition = of route metrics. It is easy to create a metric that reflects limitations o= f the nodes, such as energy and CPU/memory resource limitations. How is thi= s different from RPL?

8. High delay for emergency traffic

While it is true that reacti= ve protocols have a higher delay requirement than proactive protocols, the = argument is, again, flawed. The draft writes "*Some* data in an LLN ar= e delay sensitive by nature". I agree. It further mentions industrial = automation settings. Yes, in *some* LLNs, delay is indeed critical (e.g., l= ight switch), but in others it is not as much (AMI metering). The draft arg= ues that reactive protocols are bad for *all* LLNs, but provides evidence o= nly for *some*. This is exactly what the MANET WG has agreed on in the 1990= s that there is no one-size-fits-all.


[1] U. Herberg, T. Clausen, "A Comparative Performance Study o= f the Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-pow= er and Lossy Networks (LLN)", Proceedings of the 8th ACM International= Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiqui= tous Networks (PE-WASUN), October 2011
[2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight On-de= mand Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)", dr= aft-yi-loadngct-01, Internet Draft (work in progress)
[3] J. Yi, T. Clau= sen, and A. Colin de Verdiere. "Efficient Data Acquisition in Sensor N= etworks: Introducing (the) LOADng Collection Tree Protocol", Proceedin= gs of the 8th IEEE International Conference on Wireless Communications, Net= working and Mobile Computing - WiCom-2012, October 2012
[4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, =93Experiences with RPL: IP= v6 Routing Protocol for Low power and Lossy Networks=94, Internet Draft (wo= rk in progress), draft-clausen-lln-rpl-experiences-06, February 2013.
[5= ] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for = Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013= IEEE Conference on Wireless Sensors

Best regards
Ulrich



=
On Mon, Jan 6, 2014 at 10:24 AM, JP Va= sseur (jvasseur) <jvasseur@cisco.com> wrote:
I can see two paths: (1) ROLL WG ID (not the easiest though, although this = could be seen as an applicability
ID) or (2) AD sponsored ?

On Jan 6, 2014, at 7:10 PM, Ines Robles <mariainesrobles@googlemail.com> wrote:

Hi,
Abstract

This document describes serious issue= s and shortcomings regarding the use of reactive routing protocols in low power and lossy networks(LLNs= ). Routing requirements for various LLN deployments are discussed in order = to judge how reactive routing may or may notadhere to the necessary criteri= a.

We would like to know please, =A0how is the intend for this document? how thi= s draft would be aligned with roll charter?, should we re-chartering?

Thank you in advance,

Ines Robles


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




--047d7b86cfbc917dea04ef5896cb-- From clonvick@cisco.com Fri Jan 24 09:32:47 2014 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB5D1A0069 for ; Fri, 24 Jan 2014 09:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 fz6vvv34HzNL for ; Fri, 24 Jan 2014 09:32:44 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1A71A0036 for ; Fri, 24 Jan 2014 09:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4216; q=dns/txt; s=iport; t=1390584763; x=1391794363; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version:content-id; bh=zl6P/AZEku9gRAX5flplOREAPRO3QYdvl2C9zuaXJjo=; b=JCr6cZLOA3s8Y0GywdUys8FFOwAVridw+oxQ0gtwytpCk2+gfrTzRyr2 xq70ku/riYbGi0E2cIz+KZDfcPodHn4HiqE86uqx6xem6GTjw3SMJRKKW no91Ogf0OboB33gd29xzbBDy4xSoWNrvVaiHOf1JzBtNJ/W9BJRXHYOBr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAHOi4lKrRDoI/2dsb2JhbABagww4g1S4HUtPgQ0WdIIlAQEBAwEjVgULCxQBJgQDAgIhJREGEwmHaAMJBw6rUZcADYVWF4x2gUUBAQo0EQeCL0CBSQSJSIxzgx6LK4VBgW+BX4FQ X-IronPort-AV: E=Sophos;i="4.95,713,1384300800"; d="scan'208";a="100552612" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 24 Jan 2014 17:32:42 +0000 Received: from sjc-xdm-112 (sjc-xdm-112.cisco.com [171.71.188.44]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0OHWfva031175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jan 2014 17:32:42 GMT Date: Fri, 24 Jan 2014 09:32:41 -0800 (PST) From: Chris Lonvick To: "Popa, Daniel" In-Reply-To: <9546f1bf3d68401a8cdf837ca5528de4@BY2PR04MB807.namprd04.prod.outlook.com> Message-ID: References: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> <9546f1bf3d68401a8cdf837ca5528de4@BY2PR04MB807.namprd04.prod.outlook.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="1202400444-1128537802-1390584669=:20137" Content-ID: X-Mailman-Approved-At: Sat, 25 Jan 2014 08:51:51 -0800 Cc: "draft-ietf-roll-applicability-ami.all@tools.ietf.org" , "roll@ietf.org" Subject: Re: [Roll] [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used 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, 24 Jan 2014 17:32:47 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1202400444-1128537802-1390584669=:20137 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Hi Daniel, Has a threat model been defined for RPL? And do you know that the link-layer security provided by the two IEEE mechanisms will thwart the threats? This isn't meant to be an onerous exercise. :-) What has been done in several WGs has been to define a simple threat model (usually taken from RFC 3552) and then describe how the security mechanisms will thwart the threats. For example, see sections 2 and 3 in RFC 5426 (TLS for syslog). If you can point to the threat model for RPL then you can probably state (just once in the Security Considerations section) how the IEEE link-layer security mechanisms will address the threats so therefore the security mechanisms already contained within RPL will not be needed. Hope this helps, Chris On Tue, 14 Jan 2014, Popa, Daniel wrote: > Hello all, > > Chris: > > Just to clarify: The applicability statement for AMI network focuses on > use of RPL (+ 6LowPAN/IPv6) over standard IEEE wireless and PLC > link-layer technologies (i.e., IEEE Std 802.15.4g/4e and IEEE Std > P1901.2, respectively). Each of these standards is coming with a > link-layer security specification. > > Following you recommendation: we can add a new section - "Security > Considerations" - to the section where we describe the link-layer > security features (i.e., to the Section 9.2.3 called "Security features > provided by the MAC sub-layer"). Alternatively, we can keep the Section > 9.2.3 as it is and in the content that will be provided we describe how > the link-layer security features will meet the requirements of the RPL > security services. Which of these approaches will better answer your > request? > > Would such clarifications meet your expectations? > > Regards, > Daniel > > -----Message d'origine----- > De : roll issue tracker [mailto:trac+roll@grenache.tools.ietf.org] > Envoyé : mardi 17 décembre 2013 06:51 > À : draft-ietf-roll-applicability-ami.all@tools.ietf.org; mariainesrobles@gmail.com > Cc : roll@ietf.org > Objet : [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used > > #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used > > Source: http://www.ietf.org/mail-archive/web/secdir/current/msg04477.html > > > From: Chris Lonvick > Date: Fri, 13 Dec 2013 11:41:54 -0800 (PST) > > > > “The authors note that other security mechanisms may be used, which would mean that the security functions of RPL would not be needed. I would recommend that a section of the Security Considerations be added for each instance where the RPL security mechanism are not to be used. Each of those sections should show how the replacement mechanisms will meet the requirements of the RPL security services that are described in 6550.” > > -- > -------------------------------------+---------------------------------- > -------------------------------------+--- > Reporter: | Owner: draft-ietf-roll- > mariainesrobles@gmail.com | applicability- > Type: defect | ami.all@tools.ietf.org > Priority: major | Status: new > Component: applicability-ami | Milestone: > Severity: Active WG Document | Version: > | Keywords: > -------------------------------------+---------------------------------- > -------------------------------------+--- > > Ticket URL: > roll > > --1202400444-1128537802-1390584669=:20137-- From clonvick@cisco.com Fri Jan 24 12:20: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 00E701A012D for ; Fri, 24 Jan 2014 12:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 a2BN_cPMO03Q for ; Fri, 24 Jan 2014 12:20:20 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7456B1A0191 for ; Fri, 24 Jan 2014 12:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5238; q=dns/txt; s=iport; t=1390594819; x=1391804419; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=Rtmx/fym38w0p8n8HNmMxMuOFN7jA3AkxJ5YqQKUviI=; b=YsvLWK6PS9P5tSOBTwb6mvEXqTO2T26OxqwmqOnNcf1/b5lVjyHmoVsR KAr/YNHpUX1dCUd5rQDH5r0GYrgSi/s9E2xlBTN8DfR9YGCUD35mG/MjF KiPdVFo8RXse7rxPy+Zbs/PEyxvdesLZ8S5RijO3CNe87AbRI8nKzvGzI E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAEnK4lKrRDoH/2dsb2JhbABagww4u3FLT4ENFnSCJQEBAQMBeQULCxQBAyMEByElEQYTCYdoAwkHDsJ7DYVWF4x2gUUBAQEJNBEHhDgEiUiKd4F8gx6LK4VBgW+BX4FQ X-IronPort-AV: E=Sophos;i="4.95,714,1384300800"; d="scan'208";a="100563277" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 24 Jan 2014 20:20:18 +0000 Received: from sjc-xdm-112 (sjc-xdm-112.cisco.com [171.71.188.44]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0OKKCFM003931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jan 2014 20:20:14 GMT Date: Fri, 24 Jan 2014 12:20:12 -0800 (PST) From: Chris Lonvick To: "Popa, Daniel" In-Reply-To: Message-ID: References: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> <9546f1bf3d68401a8cdf837ca5528de4@BY2PR04MB807.namprd04.prod.outlook.com>, User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1202400444-1050087809-1390594814=:20137" X-Mailman-Approved-At: Sat, 25 Jan 2014 08:51:51 -0800 Cc: "draft-ietf-roll-applicability-ami.all@tools.ietf.org" , "roll@ietf.org" Subject: Re: [Roll] [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used 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, 24 Jan 2014 20:20:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1202400444-1050087809-1390594814=:20137 Content-Type: TEXT/PLAIN; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Hi Daniel, Works for me. I was hoping that a threat model had already been written up - certainly you shouldn't be defining one now in this document. Best regards, Chris On Fri, 24 Jan 2014, Popa, Daniel wrote: > Thanks Chris for feedback. > > I believe what you advice it is more or less what we intend to do. The difference is that we do not intend to explicitly use a security threat model and show how IEEE works against it, but rather to explain how IEEE 802.15.4 and IEEE p1901.2 security mechanisms can substitute to RPL-defined security mechanisms to provide the same security services as those described in Section 19.1 of RFC 6550, while at the same time giving the system designers & implementers the same degree of freedom to trade-off complexity against security strength, in order to meet HW & cost constraints of such low power field devices. > > Would this be enough ? > > Regards, > Daniel > > Sent from my iPhone > >> On 24 janv. 2014, at 18:32, "Chris Lonvick" wrote: >> >> Hi Daniel, >> >> Has a threat model been defined for RPL? And do you know that the link-layer security provided by the two IEEE mechanisms will thwart the threats? This isn't meant to be an onerous exercise. :-) What has been done in several WGs has been to define a simple threat model (usually taken from RFC 3552) and then describe how the security mechanisms will thwart the threats. For example, see sections 2 and 3 in RFC 5426 (TLS for syslog). >> >> If you can point to the threat model for RPL then you can probably state (just once in the Security Considerations section) how the IEEE link-layer security mechanisms will address the threats so therefore the security mechanisms already contained within RPL will not be needed. >> >> Hope this helps, >> Chris >> >>> On Tue, 14 Jan 2014, Popa, Daniel wrote: >>> >>> Hello all, >>> >>> Chris: >>> >>> Just to clarify: The applicability statement for AMI network focuses on use of RPL (+ 6LowPAN/IPv6) over standard IEEE wireless and PLC link-layer technologies (i.e., IEEE Std 802.15.4g/4e and IEEE Std P1901.2, respectively). Each of these standards is coming with a link-layer security specification. >>> >>> Following you recommendation: we can add a new section - "Security Considerations" - to the section where we describe the link-layer security features (i.e., to the Section 9.2.3 called "Security features provided by the MAC sub-layer"). Alternatively, we can keep the Section 9.2.3 as it is and in the content that will be provided we describe how the link-layer security features will meet the requirements of the RPL security services. Which of these approaches will better answer your request? >>> >>> Would such clarifications meet your expectations? >>> >>> Regards, >>> Daniel >>> >>> -----Message d'origine----- >>> De : roll issue tracker [mailto:trac+roll@grenache.tools.ietf.org] >>> Envoy : mardi 17 dcembre 2013 06:51 >>> : draft-ietf-roll-applicability-ami.all@tools.ietf.org; mariainesrobles@gmail.com >>> Cc : roll@ietf.org >>> Objet : [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used >>> >>> #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used >>> >>> Source: http://www.ietf.org/mail-archive/web/secdir/current/msg04477.html >>> >>> >>> From: Chris Lonvick >>> Date: Fri, 13 Dec 2013 11:41:54 -0800 (PST) >>> >>> >>> >>> The authors note that other security mechanisms may be used, which would mean that the security functions of RPL would not be needed. I would recommend that a section of the Security Considerations be added for each instance where the RPL security mechanism are not to be used. Each of those sections should show how the replacement mechanisms will meet the requirements of the RPL security services that are described in 6550. >>> >>> -- >>> -------------------------------------+---------------------------------- >>> -------------------------------------+--- >>> Reporter: | Owner: draft-ietf-roll- >>> mariainesrobles@gmail.com | applicability- >>> Type: defect | ami.all@tools.ietf.org >>> Priority: major | Status: new >>> Component: applicability-ami | Milestone: >>> Severity: Active WG Document | Version: >>> | Keywords: >>> -------------------------------------+---------------------------------- >>> -------------------------------------+--- >>> >>> Ticket URL: >>> roll >>> > --1202400444-1050087809-1390594814=:20137-- From internet-drafts@ietf.org Sat Jan 25 08:52: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 8D7D61A0012; Sat, 25 Jan 2014 08:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HXESZBdYbdQ; Sat, 25 Jan 2014 08:52:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AD11A002D; Sat, 25 Jan 2014 08:52:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140125165245.23143.72230.idtracker@ietfa.amsl.com> Date: Sat, 25 Jan 2014 08:52:45 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-template-04.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: Sat, 25 Jan 2014 16:52:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : ROLL Applicability Statement Template Author : Michael C. Richardson Filename : draft-ietf-roll-applicability-template-04.txt Pages : 9 Date : 2014-01-25 Abstract: This document is a template applicability statement for the Routing over Low-power and Lossy Networks (ROLL) WG. This document is not for publication, but rather is to be used as a template. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-applicability-template-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-applicability-template-04 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 rdroms.ietf@gmail.com Mon Jan 27 07:58: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 EE5681A02B3; Mon, 27 Jan 2014 07:58:27 -0800 (PST) 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 QBsWDFYo5GeJ; Mon, 27 Jan 2014 07:58:26 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFBD1A027C; Mon, 27 Jan 2014 07:58:26 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id w8so7379470qac.22 for ; Mon, 27 Jan 2014 07:58:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L3MAeMhzScFfm4/v5q/RgAlbRPh5GGW8EJbvSfBJzuc=; b=HARCeHxEQa+RbKRVts3wJ/1C7OoUQaWfDQNgDm56N1e+AFNbadknfp7psIod+FyZBW bS2TB/39ZVhDmF2ePHwGE432WSq72xeEzncrzM8YB36po1RN93AmzmDLERLRfkLxyUwG rXiq2wKYcpFdoc3OHsHbkLKlnMx4m3j2Dck+S/EFzJcr2Kl/KarP03ZYOh3sQneRi/lu WUQ8dzCdl6E8js2GEeji1+xRMOjCKogzgTPYg1Gf1efRYmrpT+4t3dpz/35ZV8U2c0hw CefqNGcfud95P727vZk5SjXd/UN1zQA0fDeqUAssdXgan/xWKWBLmrhU/39RUeSDSv+Z orVQ== X-Received: by 10.140.46.119 with SMTP id j110mr41723062qga.32.1390838303786; Mon, 27 Jan 2014 07:58:23 -0800 (PST) Received: from [161.44.68.171] ([161.44.68.171]) by mx.google.com with ESMTPSA id 72sm8722607qgv.19.2014.01.27.07.58.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 07:58:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ralph Droms In-Reply-To: <20140124201637.988.3372.idtracker@ietfa.amsl.com> Date: Mon, 27 Jan 2014 10:58:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4C62FB50-C8E8-4CEA-BD42-B64076883379@gmail.com> References: <20140124201637.988.3372.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1510) Cc: roll@ietf.org, "roll-ads@tools.ietf.org" Subject: Re: [Roll] Last Call: (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 15:58:28 -0000 I've reviewed draft-ietf-roll-trickle-mcast-06.txt. The issues I raised = during the WG last call have been addressed and, in my opinion, the = document is now ready for publication. - Ralph On Jan 24, 2014, at 3:16 PM 1/24/14, The IESG = wrote: > The IESG has received a request from the Routing Over Low power and = Lossy > networks WG (roll) to consider the following document: > - 'Multicast Protocol for Low power and Lossy Networks (MPL)' > as Proposed Standard >=20 > This is a second last call, the first one having been abandoned to = send > the document back to the working group. But the latest revision = addresses > comments that were received during the first last call. >=20 > 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-02-07. 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. >=20 > Abstract >=20 > This document specifies the Multicast Protocol for Low power and > Lossy Networks (MPL) that provides IPv6 multicast forwarding in > constrained networks. MPL avoids the need to construct or maintain > any multicast forwarding topology, disseminating messages to all MPL > Forwarders in an MPL Domain. MPL uses the Trickle algorithm to > manage message transmissions for both control and data-plane > messages. Different Trickle parameter configurations allow MPL to > trade between dissemination latency and transmission efficiency. >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ballot/ >=20 >=20 > The following IPR Declarations may be related to this I-D: >=20 > http://datatracker.ietf.org/ipr/1858/ >=20 >=20 >=20 From Daniel.Popa@itron.com Tue Jan 28 07:57:00 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 8BB611A023D for ; Tue, 28 Jan 2014 07:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rYgBkOBJKbBj for ; Tue, 28 Jan 2014 07:56:57 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id 853771A0227 for ; Tue, 28 Jan 2014 07:56:57 -0800 (PST) Received: from BY2PR04MB807.namprd04.prod.outlook.com (10.141.224.149) by BN1PR04MB552.namprd04.prod.outlook.com (10.141.65.152) with Microsoft SMTP Server (TLS) id 15.0.859.15; Tue, 28 Jan 2014 15:56:53 +0000 Received: from BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) by BY2PR04MB807.namprd04.prod.outlook.com ([10.141.224.149]) with mapi id 15.00.0859.020; Tue, 28 Jan 2014 15:56:52 +0000 From: "Popa, Daniel" To: Michael Richardson , "roll@ietf.org" Thread-Topic: Questions on the RPL applicability statement Thread-Index: Ac8QdsnmrNUmVHo9RCm3bx7++6R1qQAIyfqAACZMC6ACLigogACVVz7w Date: Tue, 28 Jan 2014 15:56:51 +0000 Message-ID: References: <7f3cf88e9e064bb28831d8b273e3169c@CO1PR04MB553.namprd04.prod.outlook.com> <13255.1389643159@sandelman.ca> <74c0ab9f632047febba938fe624a94e2@BY2PR04MB807.namprd04.prod.outlook.com> <1530.1390667859@sandelman.ca> In-Reply-To: <1530.1390667859@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.2.132.3] x-forefront-prvs: 0105DAA385 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(24454002)(55784002)(52604005)(243025003)(189002)(199002)(79102001)(76482001)(54356001)(74662001)(31966008)(87936001)(74502001)(66066001)(80022001)(85852003)(47446002)(65816001)(2656002)(94316002)(15202345003)(56776001)(83072002)(87266001)(46102001)(54316002)(81542001)(53806001)(59766001)(51856001)(76576001)(69226001)(56816005)(15975445006)(81686001)(81816001)(74876001)(90146001)(76796001)(85306002)(76786001)(74366001)(80976001)(86362001)(4396001)(81342001)(33646001)(63696002)(74316001)(93516002)(92566001)(77982001)(19580395003)(50986001)(47976001)(47736001)(93136001)(49866001)(74706001)(83322001)(19580405001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB552; H:BY2PR04MB807.namprd04.prod.outlook.com; CLIP:109.2.132.3; FPR:; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: itron.com Subject: Re: [Roll] Questions on the RPL 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: Tue, 28 Jan 2014 15:57:00 -0000 Hi Michael,=20 Thanks for clarifying our questions.=20 The remaining question is related to Section 8 " Other Related Protocols" a= s per " draft-ietf-roll-applicability-template-04": What is the intent of = this section?=20 http://tools.ietf.org/pdf/draft-ietf-roll-applicability-template-04.pdf Regards, Daniel -----Message d'origine----- De=A0: mcr@sandelman.ca [mailto:mcr@sandelman.ca] De la part de Michael Ric= hardson Envoy=E9=A0: samedi 25 janvier 2014 17:38 =C0=A0: roll@ietf.org Cc=A0: Popa, Daniel; Gillmore, Matthew Objet=A0: Re: Questions on the RPL applicability statement Popa, Daniel wrote: > You're right. In our document the section numbers do not match the > section numbers from the template you proposed. > The questions we have are: > - What is the intent of the Section called "Other protocols"? I'm not sure. I don't have such a section. There are two sections that say, "Other Parameters". I've posted a -04 with some details of what I think belongs in the first of= those sections. The diffs are below. > - In your template there are 2 (distinct) sections called "Layer 2 > applicability" and "Description of the Layer 2 features", > respectively. We wondering if these two sections are not somehow > redundant; what is the intent of having these 2 (distinct) sections? section 2.3, layer-2, details what layer-2 technologies are going to be use= d. This is at the high-level. So in your document, you would write: This applicability statement applies to deployments using IEEE 802.15.4g, 802.15.4e, and for PowerLine Communication (PLC) IEEE = P1901.2. whereas in the home-building document it says: This document applies to [IEEE802.15.4] and [G.9959] which are adapted to IPv6 by the adaption layers [RFC4944] and [I-D.brandt-6man-lowpanz]. (and it goes on to explain how 6lowpan is applied to form a layer-3, whi= ch actually, I think should go in the other section) In the section of layer-2 features, I would expect to learn the significant= details about each of the layer-2s being used.... if you are using the lay= er-2 security features, how they are configured (no security, per-network k= eying, per-node pair keying, bootstrapping of new nodes...) and what assum= ptions one might reasonably be able to make about layer-3 security from layer-2 features. This section will go a long long long way towards making the security review easier: if you claim that layer-2 guara= ntees no strangers on the network, then a whole bunch of threats go away. {I'm a bit upset at the security reviews that we have got... They have occu= red, actually, way too soon, and in the wrong direction. Still, all questi= ons are important to answer} -- Michael Richardson , Sandelman Software Works From mariainesrobles@googlemail.com Tue Jan 28 22:16: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 657651A036D for ; Tue, 28 Jan 2014 22:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 10Xye9O02Las for ; Tue, 28 Jan 2014 22:16:52 -0800 (PST) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4AE1A0193 for ; Tue, 28 Jan 2014 22:16:51 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id lh14so873565vcb.24 for ; Tue, 28 Jan 2014 22:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=LuoTTCagxjwpAtzOZMFqMHQrA9NHGRBuH0lY/BVUvGI=; b=Y0r6BwCiPJaIcYN/MBAk+vMTK9eBIt7l6uTnHeuFB88bkxXTX4YgRXildNrTCsgcCo ZTBtP6NR5jg5pwbYhKE4h/iqL6k3Bn0L0a9L9cnqhWG4dkIxZfOlbWo8OQrmk2me4YBy o2Gm9dZnEMSNHzhtCCVnmKQRAC/cM7R/V88LRzTjNpRqs9MmEK0aG1TnZU/13C0zEMdo RfdgKVU+kGn3+SBY5AQTLmcPI7lwWWs4g9LPiyGFA8Zw1JZYFj0B2yrZsw16kpODi5+e NQ27lmQthJ3IncWDXCLDjmdk2wBfXs/W8Veep7PKXTRYdboLF/Qm/GFn5LMQ/hY2oLSu f59g== MIME-Version: 1.0 X-Received: by 10.52.166.9 with SMTP id zc9mr4166055vdb.16.1390976208938; Tue, 28 Jan 2014 22:16:48 -0800 (PST) Received: by 10.220.49.68 with HTTP; Tue, 28 Jan 2014 22:16:48 -0800 (PST) Date: Wed, 29 Jan 2014 04:16:48 -0200 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=001a11c2d992d32d4f04f115e2b1 Cc: Michael Richardson Subject: [Roll] IETF 89 - London - Draft to be presented - Slides in advance 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, 29 Jan 2014 06:16:53 -0000 --001a11c2d992d32d4f04f115e2b1 Content-Type: text/plain; charset=ISO-8859-1 *Hello,We would like to know please, which draft desire be presented in the Next Meeting: IETF 89, March 2-7, 2014. Due to the limited duration of the meeting (1 hour more or less), we require please the slides in advance, to decide if the draft will be presented or not.( Please try to send the slides before Friday of the next week (02/07/2014) ).After the decision (based on the slides obtained), we will let you know about which drafts will be included in the meeting.To improve the quality of our drafts, we will have in London a Document language editing session on the Saturday prior to the IETF meeting, please let us know who desire to meet to have this session, specifically destined for non-native english speakers.Thank you very much in advance,Michael & Ines.* --001a11c2d992d32d4f04f115e2b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

He= llo,


We would = like to know please, which draft desire be presented in the Next Meeting: I= ETF 89, March 2-7, 2014.


Due to th= e limited duration of the meeting (1 hour more or less), we require please = the slides in advance, to decide if the draft will be presented or not.( Pl= ease try to send the slides before Friday of the next week (02/07/2014) ).<= /span>


After the= decision (based on the slides obtained), we will let you know about which = =A0drafts will be included in the meeting.


To improv= e the quality of our drafts, we will have in London a Document language edi= ting session on the Saturday prior to the IETF meeting, please let us know = who desire to meet to have this session, specifically destined for non-nati= ve english speakers.


Thank you= very much in advance,


Michael & Ines.=
--001a11c2d992d32d4f04f115e2b1-- From mariainesrobles@googlemail.com Tue Jan 28 22:38: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 7AD8B1A0371 for ; Tue, 28 Jan 2014 22:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw75DGL15ZPU for ; Tue, 28 Jan 2014 22:38:26 -0800 (PST) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC2F1A0193 for ; Tue, 28 Jan 2014 22:38:26 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id pa12so956674veb.30 for ; Tue, 28 Jan 2014 22:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=q8ri4NoEWFqsxwzV9yBZ1adnnMmaLzfesjSc61tnLxc=; b=hcuoqfxvah4HURy7j1lBHdG8aoxGXzvWtkdtCRnJ0vUUhKwnwkeLCYX4e7JUpTnKwR /88p3Cq9urvyJ5nxM6vGdwtt2o9LQynWv0h290uUs9/u5sxtNvkjkMt2Gvp4ef6/J3wm 2KWb1Ii9EQex4fmYDUgQHbggHYQVR08lp04FsJcx7IUjHI+QFM8g61nOVaK0aSNkZEV7 GAR7M9+qDkhQJXP/gksV4Gr/wHFpSwIM6gnBlT8qI+KtgQy5OC29wWH0sF3Vv5QhUvKB xq20t9oba9LSvMPCr5VnQg39GbsYhtiKVM8+kWc2amEoSX5Bw/+8Li4agnqAOh8Zt5mF G7GQ== MIME-Version: 1.0 X-Received: by 10.52.89.230 with SMTP id br6mr4292476vdb.20.1390977503352; Tue, 28 Jan 2014 22:38:23 -0800 (PST) Received: by 10.220.49.68 with HTTP; Tue, 28 Jan 2014 22:38:23 -0800 (PST) Date: Wed, 29 Jan 2014 04:38:23 -0200 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=20cf307f3766fa5af004f1162fc3 Subject: Re: [Roll] Request for IETF Mentoring Program Volunteers 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, 29 Jan 2014 06:38:28 -0000 --20cf307f3766fa5af004f1162fc3 Content-Type: text/plain; charset=ISO-8859-1 It would be great if you could participate in the IETF Mentoring Program. Best Regards, ----------------------------------------------------------------------------------------------- Thread: http://www.ietf.org/mail-archive/web/ietf/current/msg85824.html Message: 2 Date: Tue, 28 Jan 2014 09:21:38 -0800 From: IETF Chair To: IETF Announcement List Cc: 89-1st-timers@ietf.org, ietf@ietf.org Subject: Invitation to Participate in Mentoring Program Message-ID: <20140128172138.28200.99163.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8" All, At IETF 89 we will once again offer the IETF Mentoring Program. The goal of the IETF Mentoring Program is to match IETF participants who may be new or otherwise in need of guidance with experienced IETF mentors. As a mentoring participant, your mentor will personally introduce you to the IETF community, help you find your way around the IETF & the meeting, explain things, and introduce you to other attendees you might like to meet. Basically, your mentor will be your personal buddy during the meeting week, and possibly afterwards. Unlike in the past, at IETF 89 we will accept requests for mentors from anyone who wants one, regardless of how many meetings they have attended previously. We cannot guarantee that every request will be honored, but we will do our best. If you wish to participate in the IETF Mentoring Program, you can follow the sign-up procedures described in the program FAQ: https://www.ietf.org/resources/mentoring-program.html After you follow the sign-up procedure, we will introduce you to your mentor by email prior to IETF 89, and invite you to meet up in person at the IETF Meet & Greet event on Sunday afternoon in London. From there on, you and your mentor decide on when and where to meet during the rest of the week and afterwards. You are of course free to withdraw from the program at any time and for any reason, no questions asked, should a need arise. But I sincerely believe the IETF Mentoring Program will be a great way for new participants to get introduced to the IETF by an experienced participant with matching interest. Regards, Jari Arkko IETF Chair --20cf307f3766fa5af004f1162fc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It would be great if you could participate in t= he=A0IETF Mentoring Program.

Best Rega= rds,

-------------------------------------------------------------= ----------------------------------

Message: 2
Date: Tue, 28 Jan 2014 09:21:38 -0800
From: IETF Chair <chair@ietf.org&g= t;
To: IETF Announcement List <ie= tf-announce@ietf.org>
Cc: 89-1st-timers@ietf.org, <= a href=3D"mailto:ietf@ietf.org">ietf@ietf.org
Subject: Invitation to Participate in Mentoring Program
Message-ID: <20140128172138.28200.99163.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"

All,

At IETF 89 we will once again offer the IETF Mentoring Program. The goal of the IETF Mentoring Program is to match IETF participants who may be new<= br> or otherwise in need of guidance with experienced IETF mentors. As a
mentoring participant, your mentor will personally introduce you to the
IETF community, help you find your way around the IETF & the meeting, explain things, and introduce you to other attendees you might like to
meet. Basically, your mentor will be your personal buddy during the
meeting week, and possibly afterwards.

Unlike in the past, at IETF 89 we will accept requests for mentors from
anyone who wants one, regardless of how many meetings they have attended previously. We cannot guarantee that every request will be honored, but we<= br> will do our best.

If you wish to participate in the IETF Mentoring Program, you can follow the sign-up procedures described in the program FAQ:

https://www.ietf.org/resources/mentoring-program.html

After you follow the sign-up procedure, we will introduce you to your
mentor by email prior to IETF 89, and invite you to meet up in person at the IETF Meet & Greet event on Sunday afternoon in London. From there o= n,
you and your mentor decide on when and where to meet during the rest of
the week and afterwards.

You are of course free to withdraw from the program at any time and for
any reason, no questions asked, should a need arise. But I sincerely
believe the IETF Mentoring Program will be a great way for new
participants to get introduced to the IETF by an experienced participant with matching interest.

Regards,
Jari Arkko
IETF Chair


--20cf307f3766fa5af004f1162fc3--