From nobody Mon May 2 12:25:39 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A61F12D186 for ; Mon, 2 May 2016 12:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Xt70SB8Tjo_E for ; Mon, 2 May 2016 12:25:35 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164ED12D17A for ; Mon, 2 May 2016 12:25:35 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id a17so2598804wme.0 for ; Mon, 02 May 2016 12:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=17LNWhFTx2nEpMulCRWCEn0D7EBrTfsKesQtpdemAQY=; b=t+yqtA3IdrKYKUPPvbQQ/2MnCj0kfoLDTgnaF0HcQLrzJ1I8EvFOGu5atMkE2b+5CM FbRiZkHCpcHgCdRTM1kooteVcNn7rqAgShgd+VL1QLzbiOOxg+JvJ7S5qP7P9rGsSPPj x4E2xHRekRFiAYZfnzIPjCrt03dLUUHWK7Ii5zgIkJNKEtT16dTLKn+v7RmatL3juPtZ vc8uAKNKWf9GruhaK+zPxOGtaJKjtJVu4xcgyoAf7oJWWEUoZXGqgPO3pOxvyW+mrzAb 0aVHpfLlUJuug3XuvizwkbxWd5qiy3AnUcokNmLXBR7ufUN2Modm8kA/lbIs38UCRy1O uioQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=17LNWhFTx2nEpMulCRWCEn0D7EBrTfsKesQtpdemAQY=; b=KZnaQyN7YW4tRMzTAe2HYx7mRxzpMJfF5MvzyX/oRJnQX311dzQJh5brYBKdjazMp9 mviZ9hpQ4sYG/rOF96+z73UKTtZngHiDifuPQfqsARczSqB4UVBC4lnBmNVGwCtWBjgE CpLMtoSOqLHfHMWeI0KsSMwMOoVMlJP5jvzQJYmLSFTNAl8y2pBeaoerb2UEzF1V2Lpg v8dS9om4JN4OC6XNBQm8qdU36iL51WjISoQUdPxs/dCHBHmjD4X53ZCjJtL6zd+aX+Lz GvKBzrLwq5AKeCimPKQJHHtUmPZ2TwAuM/DvjEFk4gCQT8WNlh3l+xqONwFLzSFh1+Pb c9GQ== X-Gm-Message-State: AOPr4FVM5Y0W9uzBuiSPICaS6kScZ28VpbozECYJjXwzTTCkSYwSuuz4TEQyubtxdHJx1g== X-Received: by 10.194.171.194 with SMTP id aw2mr16281744wjc.113.1462217133594; Mon, 02 May 2016 12:25:33 -0700 (PDT) Received: from ?IPv6:2a02:8109:8680:45c:221:ccff:fe67:d847? ([2a02:8109:8680:45c:221:ccff:fe67:d847]) by smtp.googlemail.com with ESMTPSA id c4sm32002677wjm.24.2016.05.02.12.25.32 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 12:25:32 -0700 (PDT) To: roll From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= Message-ID: <2591c152-29fd-ce24-d4c2-27fc23a9a034@gmail.com> Date: Mon, 2 May 2016 21:25:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Roll] How to react if Trickle Interval > Default Lifetime X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 02 May 2016 19:25:37 -0000 Dear RPL Veterans, I recently came across the question of how a RPL router may react, if a parent's default lifetime (and unit -- specified in the DODAG Conf. Opt.) is surpassed by the parent's continuously rising trickle interval? Without any action from the children, I would assume that the upward link to the parent would time out before the next DIO arrives to refresh the lifetime, hence breaking the child -> parent relation. Implementations seem to handle this case very differently.. * The RPL implementation of RIOT uses unicast DIS messages to request a one-shot DIO from a parent that has a link which is about to expire. * From what I could gather in [1], Contiki also seems to send unicast DIS messages randomly in an interval of 30~55 seconds (Please correct me if I am wrong). * In an off-list discussion with Michael, I learned that unstrung is e.g. handling this case by not letting the Trickle interval exceed the default lifetime (Again, please correct me if I am wrong). I couldn't find any hints regarding this situation in RFC6550. Is there actually an obvious way to handle this, but I am just not seeing it? Best, Cenk Gündoğan [1] https://github.com/contiki-os/contiki/blob/master/core/net/rpl/rpl-timers.c From nobody Mon May 2 12:55:17 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4127212D189 for ; Mon, 2 May 2016 12:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com header.b=cQAKAhZX; dkim=pass (2048-bit key) header.d=sics-se.20150623.gappssmtp.com header.b=rKYAz5FV 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 SOrNw-nkdtV7 for ; Mon, 2 May 2016 12:55:13 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AF112D0BC for ; Mon, 2 May 2016 12:55:12 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id g17so3703885wme.1 for ; Mon, 02 May 2016 12:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=ZooowSNoKBaVSxTXLQIZhfeSyQshK3pI8ZOpF8pO9Os=; b=cQAKAhZXqoY8xGAXfHw0pup2ccwos2BqXydpNYEIR29YDODv9x6Jgztdm69JBI68/+ PRsIzoRTRxgdbeSDkfZKP0xNoEgXviBSaL+mZjkLH44DrVuUCEXQx6xvqvDpsmk5vy9g Y7o8xyTt/9YbxSYnmRhlS+3OvqsbxcZQc21fUe409IAYjZ7q4U8F+2DX2fBRT+NbQWl8 QeTjx/VCqC4pxul02XzVDfwdMZerMj5HbIszjrvVnHQsZuuXT8qhXrfHsWIPe+X5Aoig +2eTAt7Yf1Dx7+bKVKJv+wkx1liU93D+RyF7mdH7WMbjgyOivrlNnhbJCT2mpICpcuF5 195g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=ZooowSNoKBaVSxTXLQIZhfeSyQshK3pI8ZOpF8pO9Os=; b=rKYAz5FVjwjR6JQ68Q+JOu4RjglKmBv51EdNcehbxyBky7Dua98BYrWlfZuzM4se2r jGne5tDnK/c0Ux8zyHo7sOyy/MIgZPz8+CenFdh1k5S4fSlKcc9s8H0poC2hkDQGRVAf 46prcoRyyBwEerEmMiJk2nLeOVUuj2BP/g1B0jtjDaRmBzaq/o16YUKg6Oqmz13ZNhlV Ow8PtGE9EUdJEBjBk6ZHsZce415j5B5iv6h4OcfMLryobi1APYb4Ax8MdJJL3a4wjych RPjnHE7ZYHhGsV8jTILK55ifb5yZ7b7xmXKaZJ3cLX3pLm/1qUKkxb9BnIWi2De58JnX 7qLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=ZooowSNoKBaVSxTXLQIZhfeSyQshK3pI8ZOpF8pO9Os=; b=SEiOMriHRPpRb+f8gRTgf/hZfLdzcSOStLIHs/aNnkf6OpS/sKHInQnnhlGOZ4tJWb XEfKt9KU0dQRkRUJi0HzBfSrH/OPVOnoYwwecMo67QTmJxjL7dkoRwNfJFlpSxGE4C2C lbz3pfcVoIFBKlIIjiqF5lxw9d/EVNKXTlM4rmfjIJEn32nSx2nJDLhRgUFUXvL3hoaV ZVsmKiEDUEgGz6SwYQ38vopWJ561rWybPNgS7y4buymIRwaYX6xVJvpbYqvfiNb8D/kF rZrlBayc74ryvqhNweaHQF9Gw0bjyZtCarvTT2JWUkxwXd7bAMxQMZiQ6k76uiXtWDfi Q3Cw== X-Gm-Message-State: AOPr4FWVViUE7OH47s1qRFzFsqZdO5rlrXdTNhalZw0DQ+mvyRgSPApqGBtob/e/7o8T+GlEu11wd8ef/HMbUg== MIME-Version: 1.0 X-Received: by 10.28.130.6 with SMTP id e6mr21985292wmd.94.1462218911335; Mon, 02 May 2016 12:55:11 -0700 (PDT) Sender: simon.duquennoy@gmail.com Received: by 10.194.101.70 with HTTP; Mon, 2 May 2016 12:55:11 -0700 (PDT) In-Reply-To: <2591c152-29fd-ce24-d4c2-27fc23a9a034@gmail.com> References: <2591c152-29fd-ce24-d4c2-27fc23a9a034@gmail.com> Date: Mon, 2 May 2016 21:55:11 +0200 X-Google-Sender-Auth: BsNeAOAKxfO84RE83DKgEE8ygHU Message-ID: From: Simon Duquennoy To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11442614cb5c750531e15edb Archived-At: Subject: Re: [Roll] How to react if Trickle Interval > Default Lifetime X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 02 May 2016 19:55:15 -0000 --001a11442614cb5c750531e15edb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Cenk, In Contiki we send periodic multicast DIS until the node has joined any DAG= . After that, one thing you can do if enable "probing", which will periodically send a unicast DIS to your preferred parent (and also cover other candidates neighbors, to keep link estimates up-to-date). In general wouldn't it be the expected practice to advertise trickle parameters that never surpass the default lifetime? Simon On Mon, May 2, 2016 at 9:25 PM, Cenk G=C3=BCndogan wro= te: > Dear RPL Veterans, > > I recently came across the question of how a RPL router may react, > if a parent's default lifetime (and unit -- specified in the DODAG Conf. > Opt.) > is surpassed by the parent's continuously rising trickle interval? > > Without any action from the children, I would assume that the upward link > to > the parent would time out before the next DIO arrives to refresh the > lifetime, > hence breaking the child -> parent relation. > > Implementations seem to handle this case very differently.. > > * The RPL implementation of RIOT uses unicast DIS messages to request a > one-shot DIO > from a parent that has a link which is about to expire. > * From what I could gather in [1], Contiki also seems to send unicast DIS > messages randomly in an interval of 30~55 seconds (Please correct me if I > am wrong). > * In an off-list discussion with Michael, I learned that unstrung is e.g. > handling > this case by not letting the Trickle interval exceed the default lifetime > (Again, please correct me if I am wrong). > > I couldn't find any hints regarding this situation in RFC6550. > Is there actually an obvious way to handle this, but I am just not seeing > it? > > Best, > Cenk G=C3=BCndo=C4=9Fan > > [1] > https://github.com/contiki-os/contiki/blob/master/core/net/rpl/rpl-timers= .c > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a11442614cb5c750531e15edb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Cenk,

In Contiki we send periodic = multicast DIS until the node has joined any DAG.
After that, one = thing you can do if enable "probing", which will periodically sen= d a unicast DIS to your preferred parent (and also cover other candidates n= eighbors, to keep link estimates up-to-date).

In g= eneral wouldn't it be the expected practice to advertise trickle parame= ters that never surpass the default lifetime?

Simo= n


On Mon, May 2, 2016 at 9:25 PM, Cenk G=C3=BCndogan <cnkgndgn@g= mail.com> wrote:
Dear RPL= Veterans,

I recently came across the question of how a RPL router may react,
if a parent's default lifetime (and unit -- specified in the DODAG Conf= . Opt.)
is surpassed by the parent's continuously rising trickle interval?

Without any action from the children, I would assume that the upward link t= o
the parent would time out before the next DIO arrives to refresh the lifeti= me,
hence breaking the child -> parent relation.

Implementations seem to handle this case very differently..

* The RPL implementation of RIOT uses unicast DIS messages to request a one= -shot DIO
from a parent that has a link which is about to expire.
* From what I could gather in [1], Contiki also seems to send unicast DIS messages randomly in an interval of 30~55 seconds (Please correct me if I a= m wrong).
* In an off-list discussion with Michael, I learned that unstrung is e.g. h= andling
this case by not letting the Trickle interval exceed the default lifetime (Again, please correct me if I am wrong).

I couldn't find any hints regarding this situation in RFC6550.
Is there actually an obvious way to handle this, but I am just not seeing i= t?

Best,
Cenk G=C3=BCndo=C4=9Fan

[1] https://github.com/co= ntiki-os/contiki/blob/master/core/net/rpl/rpl-timers.c

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

--001a11442614cb5c750531e15edb-- From nobody Mon May 2 13:00:35 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676D212D165 for ; Mon, 2 May 2016 13:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics-se.20150623.gappssmtp.com 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 UEZZzImM7p03 for ; Mon, 2 May 2016 13:00:31 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5655C12D61E for ; Mon, 2 May 2016 13:00:31 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id y84so200502621lfc.0 for ; Mon, 02 May 2016 13:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=LMXznkb8c+LRNLb37zUOCxniT8mZFztIvfzI07hiBOs=; b=CK37pBHIzSD+lnz9mAKoeOh2MXQ2LRfwvrajrCAEaLjTLxI/mOitfZx1MbIoDHlV+g 0Hqm7ESqNYTqOYtqMvA+eD9SM2Gd72hYvlj7hkMMIOIQE/8ghYUtyzgVyDH9YP48HFDN X7ItrJU/tXzBZBorwYtH910f/KS8LcjlIboWzRFAuIf2X5NGpwspR/C63t+v6ApC4mJC dHwZMzLlWD9Jv9Z9Ss0N8tdJ/AlALlWfXA7SQsbkR2Q+wetiqYxRQ8k8WRRxZsaX3jhG mzBAqp2c52iIuqV8F6zErVAt/bvj2hG/bFws6SkxNzNp7OYOPBMlgR/2FlkEqfCgoQLC 1gfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LMXznkb8c+LRNLb37zUOCxniT8mZFztIvfzI07hiBOs=; b=Sz62NwqLiTWwld8t9KNP0Eja7GJWPdpInUOQTBqyQ4xrZFA5CUczUtRFBdnMIkJ15K UYLRqGmbx7+9v3ipJ4XB68UYibgZTQwbmQuYNE/+yubH16rKsbZXgvPXCa2hG+vZK4UR JxY4Grk2h9x5jA/xbCUZsCZ3d3OmB2bEQuzGNaTJ9vF2slI9Q7wq0/1sz7btpm590XaP s8lUm4cQ3YLbgAtzqYmUBLbiHAF4FL0gO5Bp1uzsLsDzl8966iVYslzn+h61AgqYjURO ug2j8pky1XwleB2qHO3DH1dx0YJcVmvxG2+tzFGZF0hmiJ75LYK7C4bigGi8VYl+L3gP dCbg== X-Gm-Message-State: AOPr4FW3XCrDXz2AkJ0m3HdbCaHXd981LYosb6EOzdtqOFzTDiAYwzu9OeQuu3ECpyv8Hy1J X-Received: by 10.112.134.229 with SMTP id pn5mr14895735lbb.36.1462219229553; Mon, 02 May 2016 13:00:29 -0700 (PDT) Received: from [192.168.1.102] (195-67-245-31-no175.tbcn.telia.com. [195.67.245.31]) by smtp.gmail.com with ESMTPSA id sa9sm4370013lbb.38.2016.05.02.13.00.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 13:00:28 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4DC5084-C4A1-4156-B166-33FFC0C44C83" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Joakim Eriksson In-Reply-To: Date: Mon, 2 May 2016 22:00:27 +0200 Message-Id: <466CD3E8-6DC3-4EF1-80B8-333F6FB1E4E2@sics.se> References: <2591c152-29fd-ce24-d4c2-27fc23a9a034@gmail.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Roll] How to react if Trickle Interval > Default Lifetime X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 02 May 2016 20:00:34 -0000 --Apple-Mail=_C4DC5084-C4A1-4156-B166-33FFC0C44C83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, In Contiki I do think we are typically using infinite lifetime on the = installed route between the child to parent. If the child needs a downward route it would register that via DAO and = keep that re-sent at less than default lifetime as specified by the DIO (default lifetime and lifetime unit). Best regards, =E2=80=94 Joakim > On 02 May 2016, at 21:55, Simon Duquennoy wrote: >=20 > Dear Cenk, >=20 > In Contiki we send periodic multicast DIS until the node has joined = any DAG. > After that, one thing you can do if enable "probing", which will = periodically send a unicast DIS to your preferred parent (and also cover = other candidates neighbors, to keep link estimates up-to-date). >=20 > In general wouldn't it be the expected practice to advertise trickle = parameters that never surpass the default lifetime? >=20 > Simon >=20 >=20 > On Mon, May 2, 2016 at 9:25 PM, Cenk G=C3=BCndogan > wrote: > Dear RPL Veterans, >=20 > I recently came across the question of how a RPL router may react, > if a parent's default lifetime (and unit -- specified in the DODAG = Conf. Opt.) > is surpassed by the parent's continuously rising trickle interval? >=20 > Without any action from the children, I would assume that the upward = link to > the parent would time out before the next DIO arrives to refresh the = lifetime, > hence breaking the child -> parent relation. >=20 > Implementations seem to handle this case very differently.. >=20 > * The RPL implementation of RIOT uses unicast DIS messages to request = a one-shot DIO > from a parent that has a link which is about to expire. > * =46rom what I could gather in [1], Contiki also seems to send = unicast DIS > messages randomly in an interval of 30~55 seconds (Please correct me = if I am wrong). > * In an off-list discussion with Michael, I learned that unstrung is = e.g. handling > this case by not letting the Trickle interval exceed the default = lifetime > (Again, please correct me if I am wrong). >=20 > I couldn't find any hints regarding this situation in RFC6550. > Is there actually an obvious way to handle this, but I am just not = seeing it? >=20 > Best, > Cenk G=C3=BCndo=C4=9Fan >=20 > [1] = https://github.com/contiki-os/contiki/blob/master/core/net/rpl/rpl-timers.= c = >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll = >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_C4DC5084-C4A1-4156-B166-33FFC0C44C83 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

In = Contiki I do think we are typically using infinite lifetime on the = installed route between the child to parent.
If the = child needs a downward route it would register that via DAO and keep = that re-sent at less than default lifetime as specified
by = the DIO (default lifetime and lifetime unit).

Best regards,
=E2=80= =94 Joakim



On 02 May 2016, at 21:55, = Simon Duquennoy <simonduq@sics.se> wrote:

Dear Cenk,

In Contiki we send periodic multicast DIS until the node has = joined any DAG.
After that, one thing you can do if = enable "probing", which will periodically send a unicast DIS to your = preferred parent (and also cover other candidates neighbors, to keep = link estimates up-to-date).

In general wouldn't it be the expected practice to advertise = trickle parameters that never surpass the default lifetime?

Simon


On Mon, May 2, 2016 at 9:25 PM, = Cenk G=C3=BCndogan <cnkgndgn@gmail.com> wrote:
Dear RPL Veterans,

I recently came across the question of how a RPL router may react,
if a parent's default lifetime (and unit -- specified in the DODAG Conf. = Opt.)
is surpassed by the parent's continuously rising trickle interval?

Without any action from the children, I would assume that the upward = link to
the parent would time out before the next DIO arrives to refresh the = lifetime,
hence breaking the child -> parent relation.

Implementations seem to handle this case very differently..
=
* The RPL implementation of RIOT uses unicast DIS messages to request a = one-shot DIO
from a parent that has a link which is about to expire.
* =46rom what I could gather in [1], Contiki also seems to send unicast = DIS
messages randomly in an interval of 30~55 seconds (Please correct me if = I am wrong).
* In an off-list discussion with Michael, I learned that unstrung is = e.g. handling
this case by not letting the Trickle interval exceed the default = lifetime
(Again, please correct me if I am wrong).

I couldn't find any hints regarding this situation in RFC6550.
Is there actually an obvious way to handle this, but I am just not = seeing it?

Best,
Cenk G=C3=BCndo=C4=9Fan

[1] https://github.com/contiki-os/contiki/blob/master/core/net/rpl/= rpl-timers.c

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

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

= --Apple-Mail=_C4DC5084-C4A1-4156-B166-33FFC0C44C83-- From nobody Mon May 2 13:47:01 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB77212D19F for ; Mon, 2 May 2016 13:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hN8npY9nFlvz for ; Mon, 2 May 2016 13:46:56 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1803612B074 for ; Mon, 2 May 2016 13:46:56 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id a17so5813237wme.0 for ; Mon, 02 May 2016 13:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=ujaWqE34sEPVG7TxN6eSln3ahzDGK9rhQ80vsv9joZs=; b=MZLPNPVwgJxvGw0sZZXxyjoN7JP0e1Knnot6HeO1PMrEGKaeT7O5BGZUzlj8eeDs+k 5eGWUnpA6JRASkCjaXnFlQNwhCNLFZwoPAwOBTU5stpFFi6pX7dPXCq2uS6ijcryi4SU okqQORKbrJaWWpwa5AtIYOdALF43OhsEmF/pQUv/4f+RQFAI0w2RM1xfhNFeEAXc5EMp mdW69IBpV3uotv4EWRA4GNXLb0poRFL2W/6SAuYcypcN6kOOENDRiroqfNkBekcIB1I+ pSvGjRqPmnsyzjZB2baLRbV8uwQYBxMKgIBEkELAFjWo0Cr4gW/Kd+L7pski2mLdKNOM EXqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=ujaWqE34sEPVG7TxN6eSln3ahzDGK9rhQ80vsv9joZs=; b=k9DJ0cp59u6oUt5GV9KKGGtVT/R8vimrCGfp8fGxCPz77sp5ZsMEJ0anecCoAdX5Dc ObO2qzOLe2CkJOiCrIRGc3arGM4yhWL0327+k7B+Eqb9/xr0hCCvIIKjorsXeKicleCY NU4uN0LR+2+RUU+k4jMgTll8pPv5uP9XG322pQnrEHHkTt9HYiC0U9c9UCQnhFXk+P8c 1zug05S9hm0WzE+Ck3Ny9+FyFXTCrK/KljwVQPltajL6QfqiPetZVDFtxV56pZA3DaO0 VdyKiPCkXjQp30518Ef3/U6E1UB/7JhSqhUcOrW3XZZIlpp3Dq1QZbFaxiZRKpS3+tWo 855w== X-Gm-Message-State: AOPr4FXjaazrD9Em+HS5DN7wRu5JMoUE3hy/m1YtxZupjiRlKpymM+VRAQEI+nt8S+fLDw== X-Received: by 10.194.166.3 with SMTP id zc3mr39023858wjb.104.1462222014637; Mon, 02 May 2016 13:46:54 -0700 (PDT) Received: from ?IPv6:2a02:8109:8680:45c:221:ccff:fe67:d847? ([2a02:8109:8680:45c:221:ccff:fe67:d847]) by smtp.googlemail.com with ESMTPSA id c4sm32319826wjm.24.2016.05.02.13.46.53 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 13:46:53 -0700 (PDT) To: roll@ietf.org References: <2591c152-29fd-ce24-d4c2-27fc23a9a034@gmail.com> From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= Message-ID: Date: Mon, 2 May 2016 22:46:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4E3B72B318D9F5774DA39F53" Archived-At: Subject: Re: [Roll] How to react if Trickle Interval > Default Lifetime X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 02 May 2016 20:46:59 -0000 This is a multi-part message in MIME format. --------------4E3B72B318D9F5774DA39F53 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Simon, Joakim, Thank you for the quick reponses! On 05/02/2016 09:55 PM, Simon Duquennoy wrote: > Dear Cenk, > > In Contiki we send periodic multicast DIS until the node has joined > any DAG. > After that, one thing you can do if enable "probing", which will > periodically send a unicast DIS to your preferred parent (and also > cover other candidates neighbors, to keep link estimates up-to-date). > In general wouldn't it be the expected practice to advertise trickle > parameters that never surpass the default lifetime? I would actually expect to find expected practices in the RFC. The default values of the trickle timer as defined in RFC6550 can result in intervals of up to 2.3 hours. If I am bound to use lifetimes > 2.3 hours (or even infinite), then it's not really possible to notice defunct parents within that time span (apart from checking DAO-ACKs and signaling of other layers..). By restricting the lifetimes to such intervals, we basically increase the convergence time of the routing protocol to the same amount of time (worst case). As a matter of fact, I considered the DIS solution to request a DIO before a timeout occurs as an expected practice and I was a little bit surprised to see that implementations are handling this differently. However, it seems that there are some degrees of freedom in this matter, and I am wondering if this can affect interoperability of different implementations used in the same network? Best, Cenk > Simon > > > On Mon, May 2, 2016 at 9:25 PM, Cenk Gündogan > wrote: > > Dear RPL Veterans, > > I recently came across the question of how a RPL router may react, > if a parent's default lifetime (and unit -- specified in the DODAG > Conf. Opt.) > is surpassed by the parent's continuously rising trickle interval? > > Without any action from the children, I would assume that the > upward link to > the parent would time out before the next DIO arrives to refresh > the lifetime, > hence breaking the child -> parent relation. > > Implementations seem to handle this case very differently.. > > * The RPL implementation of RIOT uses unicast DIS messages to > request a one-shot DIO > from a parent that has a link which is about to expire. > * From what I could gather in [1], Contiki also seems to send > unicast DIS > messages randomly in an interval of 30~55 seconds (Please correct > me if I am wrong). > * In an off-list discussion with Michael, I learned that unstrung > is e.g. handling > this case by not letting the Trickle interval exceed the default > lifetime > (Again, please correct me if I am wrong). > > I couldn't find any hints regarding this situation in RFC6550. > Is there actually an obvious way to handle this, but I am just not > seeing it? > > Best, > Cenk Gündoğan > > [1] > https://github.com/contiki-os/contiki/blob/master/core/net/rpl/rpl-timers.c > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------4E3B72B318D9F5774DA39F53 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello Simon, Joakim,

Thank you for the quick reponses!

On 05/02/2016 09:55 PM, Simon Duquennoy wrote:
Dear Cenk,

In Contiki we send periodic multicast DIS until the node has joined any DAG.
After that, one thing you can do if enable "probing", which will periodically send a unicast DIS to your preferred parent (and also cover other candidates neighbors, to keep link estimates up-to-date).
In general wouldn't it be the expected practice to advertise trickle parameters that never surpass the default lifetime?
I would actually expect to find expected practices in the RFC.

The default values of the trickle timer as defined in RFC6550 can result in intervals of up to
2.3 hours. If I am bound to use lifetimes > 2.3 hours (or even infinite), then it's not really possible to notice
defunct parents within that time span (apart from checking DAO-ACKs and signaling of other layers..).
By restricting the lifetimes to such intervals, we basically increase the convergence time
of the routing protocol to the same amount of time (worst case).

As a matter of fact, I considered the DIS solution to request a DIO before a timeout occurs
as an expected practice and I was a little bit surprised to see that implementations are handling
this differently.

However, it seems that there are some degrees of freedom in this matter,
and I am wondering if this can affect interoperability of different implementations used in the same network?

Best,
Cenk

Simon


On Mon, May 2, 2016 at 9:25 PM, Cenk Gündogan <cnkgndgn@gmail.com> wrote:
Dear RPL Veterans,

I recently came across the question of how a RPL router may react,
if a parent's default lifetime (and unit -- specified in the DODAG Conf. Opt.)
is surpassed by the parent's continuously rising trickle interval?

Without any action from the children, I would assume that the upward link to
the parent would time out before the next DIO arrives to refresh the lifetime,
hence breaking the child -> parent relation.

Implementations seem to handle this case very differently..

* The RPL implementation of RIOT uses unicast DIS messages to request a one-shot DIO
from a parent that has a link which is about to expire.
* From what I could gather in [1], Contiki also seems to send unicast DIS
messages randomly in an interval of 30~55 seconds (Please correct me if I am wrong).
* In an off-list discussion with Michael, I learned that unstrung is e.g. handling
this case by not letting the Trickle interval exceed the default lifetime
(Again, please correct me if I am wrong).

I couldn't find any hints regarding this situation in RFC6550.
Is there actually an obvious way to handle this, but I am just not seeing it?

Best,
Cenk Gündoğan

[1] https://github.com/contiki-os/contiki/blob/master/core/net/rpl/rpl-timers.c

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



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

--------------4E3B72B318D9F5774DA39F53-- From nobody Mon May 2 14:06:28 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC95812D63C for ; Mon, 2 May 2016 14:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics-se.20150623.gappssmtp.com 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 zvwbvz53ov-z for ; Mon, 2 May 2016 14:06:24 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240D312D115 for ; Mon, 2 May 2016 14:06:24 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id y84so620757lfc.0 for ; Mon, 02 May 2016 14:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=KWMylkUDhsgm+umqIphEhkbtWk6k9LaafxtrdG3Cgpk=; b=NV38g1fa2he1NJANEAIRpU6F7+JHqDIlKOTiV4hEiNRWo2iLwcmLM0nKsHMSNkS03l xW7HpHjHk6A8iwoVAiT21JKj2b1tKHcnkUAPKhBXh1/qLT7g9co95jDZ5cPnjqUqDMTh kwY1s/I0GeGv8Y9OnttDC0OfH/t4Y1zLKxS3gnvcRyGUXVLwPgXwE7Tf0+kX6bSV02sp 0Q86I5d/MEQfJJ3YGruefCN0g6cKk1OXudf+n1gHrj1V7gyfPQPpw1myhHXR1eHO+712 +05jqf5X7J2T37r5bEan/Z0A1aJWvLqnINKairKtS/PD0oM7y88zZiftiAQkaBnVnsHN 5Trg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KWMylkUDhsgm+umqIphEhkbtWk6k9LaafxtrdG3Cgpk=; b=XSjIP6opGxboRCTysKmP9LWa8Mvo+hcsNoGgR/mEUKrRQPTe83J8M2cJubb9EbET1K Y6O91L7YBMEr61oGAdPYrpwxthm0f41pmZO+36GrAZeW90yB/5U25xTQTjR4oPE0psN5 D1nn5VcRHhbvAfgmStSDH/IkmKy3JmrChcm1rormj+LTNNVqFaIuFU5FmKnqyndwuOOX 414+1LsbQMYQgn8sBXMm2DF9BpuCLjJDT5J5xPhxso3MABzo+Bvrw2JFRD8S3+7TX0tz T56tJQPMf5Q0Ttl4IqHcVIanSnzh0Z8ub95O92RFXHwO/vhWAppevH26mdoiMBE1ZCLC CcvA== X-Gm-Message-State: AOPr4FXa54YV9Vmp1aJ7WlpLuv+GOqHl7SSjxPBVkbvG2Fx+UR2Gz3TQ651komjsVn31DD9H X-Received: by 10.25.160.13 with SMTP id j13mr13024513lfe.57.1462223182192; Mon, 02 May 2016 14:06:22 -0700 (PDT) Received: from [192.168.1.102] (195-67-245-31-no175.tbcn.telia.com. [195.67.245.31]) by smtp.gmail.com with ESMTPSA id q13sm7669lfi.21.2016.05.02.14.06.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 14:06:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7087BDE4-F649-42B6-9084-C47C16D6553D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Joakim Eriksson In-Reply-To: Date: Mon, 2 May 2016 23:06:20 +0200 Message-Id: References: <2591c152-29fd-ce24-d4c2-27fc23a9a034@gmail.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Roll] How to react if Trickle Interval > Default Lifetime X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 02 May 2016 21:06:27 -0000 --Apple-Mail=_7087BDE4-F649-42B6-9084-C47C16D6553D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, > On 02 May 2016, at 22:46, Cenk G=C3=BCndogan = wrote: >=20 > Hello Simon, Joakim, >=20 > Thank you for the quick reponses! > On 05/02/2016 09:55 PM, Simon Duquennoy wrote: >> Dear Cenk, >>=20 >> In Contiki we send periodic multicast DIS until the node has joined = any DAG. >> After that, one thing you can do if enable "probing", which will = periodically send a unicast DIS to your preferred parent (and also cover = other candidates neighbors, to keep link estimates up-to-date). >> In general wouldn't it be the expected practice to advertise trickle = parameters that never surpass the default lifetime? > I would actually expect to find expected practices in the RFC. >=20 > The default values of the trickle timer as defined in RFC6550 can = result in intervals of up to > 2.3 hours. If I am bound to use lifetimes > 2.3 hours (or even = infinite), then it's not really possible to notice > defunct parents within that time span (apart from checking DAO-ACKs = and signaling of other layers..). > By restricting the lifetimes to such intervals, we basically increase = the convergence time > of the routing protocol to the same amount of time (worst case). Typically the RPL parent will get lots of data from the children which = will cause the link-metric to change so it is not always the case that a defunct parent (at least not any of = the actively used ones) will be just kept for 2.3 hours but rather be switched out since it=E2=80=99s link is = detected to be really bad. > As a matter of fact, I considered the DIS solution to request a DIO = before a timeout occurs > as an expected practice and I was a little bit surprised to see that = implementations are handling > this differently. Yes, a regular unicast DIS is a good way to keep both link metrics and = other important liveliness information up to date. >=20 > However, it seems that there are some degrees of freedom in this = matter, > and I am wondering if this can affect interoperability of different = implementations used in the same network? It might affect something, but I would guess there are many other things = that might be worse when it comes to impact on interoperability between implementations. Especially DAO / = DAO ACK feels underspecified in the RFC. Best regards, =E2=80=94 Joakim=20 > Best, > Cenk >=20 >> Simon >>=20 >>=20 >> On Mon, May 2, 2016 at 9:25 PM, Cenk G=C3=BCndogan = > wrote: >> Dear RPL Veterans, >>=20 >> I recently came across the question of how a RPL router may react, >> if a parent's default lifetime (and unit -- specified in the DODAG = Conf. Opt.) >> is surpassed by the parent's continuously rising trickle interval? >>=20 >> Without any action from the children, I would assume that the upward = link to >> the parent would time out before the next DIO arrives to refresh the = lifetime, >> hence breaking the child -> parent relation. >>=20 >> Implementations seem to handle this case very differently.. >>=20 >> * The RPL implementation of RIOT uses unicast DIS messages to request = a one-shot DIO >> from a parent that has a link which is about to expire. >> * =46rom what I could gather in [1], Contiki also seems to send = unicast DIS >> messages randomly in an interval of 30~55 seconds (Please correct me = if I am wrong). >> * In an off-list discussion with Michael, I learned that unstrung is = e.g. handling >> this case by not letting the Trickle interval exceed the default = lifetime >> (Again, please correct me if I am wrong). >>=20 >> I couldn't find any hints regarding this situation in RFC6550. >> Is there actually an obvious way to handle this, but I am just not = seeing it? >>=20 >> Best, >> Cenk G=C3=BCndo=C4=9Fan >>=20 >> [1] = https://github.com/contiki-os/contiki/blob/master/core/net/rpl/rpl-timers.= c = >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll = >>=20 >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll = >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_7087BDE4-F649-42B6-9084-C47C16D6553D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

On 02 May 2016, at 22:46, Cenk = G=C3=BCndogan <cnkgndgn@gmail.com> wrote:

=20 =20

Hello= Simon, Joakim,

Thank you for the quick reponses!

On 05/02/2016 09:55 PM, Simon Duquennoy wrote:
Dear Cenk,

In Contiki we send periodic multicast DIS until = the node has joined any DAG.
After that, one thing you can do if enable = "probing", which will periodically send a unicast DIS to your preferred parent (and also cover other candidates neighbors, to keep link estimates up-to-date).
In general wouldn't it be the expected practice = to advertise trickle parameters that never surpass the default lifetime?
I would actually expect to find expected practices in the RFC.

The default values of the trickle timer as defined in RFC6550 can result in intervals of up to
2.3 hours. If I am bound to use lifetimes > 2.3 hours (or even infinite), then it's not really possible to notice
defunct parents within that time span (apart from checking DAO-ACKs and signaling of other layers..).
By restricting the lifetimes to such intervals, we basically increase the convergence time
of the routing protocol to the same amount of time (worst case).

Typically the RPL parent will get lots of data = from the children which will cause the link-metric to = change
so it is not always the case that a defunct parent (at = least not any of the actively used ones) will be just
kept for = 2.3 hours but rather be switched out since it=E2=80=99s link is detected = to be really bad.

As a matter of fact, I considered the DIS solution to request a DIO before a timeout occurs
as an expected practice and I was a little bit surprised to see that implementations are handling
this differently.

Yes, a regular unicast DIS is a good way to keep = both link metrics and other important liveliness
information = up to date.


However, it seems that there are some degrees of freedom in this matter,
and I am wondering if this can affect interoperability of different implementations used in the same network?

It might = affect something, but I would guess there are many other things that = might be worse when it comes
to impact on interoperability = between implementations. Especially DAO / DAO ACK feels underspecified = in
the RFC.

Best = regards,
=E2=80=94 Joakim 

Best,
Cenk

Simon


On Mon, May 2, 2016 at 9:25 PM, Cenk G=C3=BCndogan <cnkgndgn@gmail.com> wrote:
Dear RPL Veterans,

I recently came across the question of how a RPL router may react,
if a parent's default lifetime (and unit -- specified in the DODAG Conf. Opt.)
is surpassed by the parent's continuously rising trickle interval?

Without any action from the children, I would assume that the upward link to
the parent would time out before the next DIO arrives to refresh the lifetime,
hence breaking the child -> parent relation.
=
Implementations seem to handle this case very = differently..

* The RPL implementation of RIOT uses unicast DIS messages to request a one-shot DIO
from a parent that has a link which is about to expire.
* =46rom what I could gather in [1], Contiki also seems to send unicast DIS
messages randomly in an interval of 30~55 seconds (Please correct me if I am wrong).
* In an off-list discussion with Michael, I learned that unstrung is e.g. handling
this case by not letting the Trickle interval exceed the default lifetime
(Again, please correct me if I am wrong).

I couldn't find any hints regarding this situation in RFC6550.
Is there actually an obvious way to handle this, but I am just not seeing it?

Best,
Cenk G=C3=BCndo=C4=9Fan

[1] https://github.com/contiki-os/contiki/blob/master/core/net/rpl/= rpl-timers.c

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



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

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

= --Apple-Mail=_7087BDE4-F649-42B6-9084-C47C16D6553D-- From nobody Tue May 3 06:51:41 2016 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3127212D823; Tue, 3 May 2016 06:51:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503135137.8206.362.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 06:51:37 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-template-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 13:51:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks of the IETF. Title : ROLL Applicability Statement Template Author : Michael C. Richardson Filename : draft-ietf-roll-applicability-template-09.txt Pages : 10 Date : 2016-05-03 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: https://tools.ietf.org/html/draft-ietf-roll-applicability-template-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-template-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 3 11:42:39 2016 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0201012D157; Tue, 3 May 2016 11:42:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503184237.8197.30865.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 11:42:38 -0700 Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-ami@ietf.org, mcr+ietf@sandelman.ca Subject: [Roll] Suresh Krishnan's No Objection on draft-ietf-roll-applicability-ami-13: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 18:42:38 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-roll-applicability-ami-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1.2: Required reading - Why is the item [surveySG] in required reading not part of the normative references? Section 1.3: Please expand RPL before first use and add a reference to RFC6550 Section 2: Is this section really required? Seems like a summarization of the RPL RFC. At least consider removing the part that starts with "RPL was designed to meet the following application requirements:" and mentions a list of requirement RFCs. This list does not seem relevant here and is also covered in the RPL spec itself. Section 4.1: This does not sound right. Isn't the periodic meter read traffic going the other direction? " The traffic generated by the head-end server and destined to metering devices is dominated by periodic meter reads," Section 7.4.1: Please add a reference the trickle algorithm at first use. e.g. "Trickle [RFC6206] was designed to be..." From nobody Tue May 3 12:19:50 2016 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E192312D0C0; Tue, 3 May 2016 12:19:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503191946.8201.87854.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 12:19:46 -0700 Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-ami@ietf.org, mcr+ietf@sandelman.ca Subject: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-ami-13: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 19:19:47 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-roll-applicability-ami-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have two things I'd like to chat about, given that these applicability documents are where the roll WG has iirc said it'd address security and privacy issues with RPL: (1) 7.1.7: Don't you need to turn that "may not need" around and say that AMI deployments of RPL REQUIRE implementation (and maybe use) of link layer and higher layer security features? (You almost say that in 9.3 I think, so it'd maybe be good to be crystal clear. (2) Why are there no privacy considerations? I think this document needs that. For example, an AMI mesh based purely on link layer security could be a total privacy nightmare. And part of that is down to RPL - if I can cause lots of folks' traffic to be sent to me, that is RPL's issue. That I can then see the application layer content is not RPL's fault, but is still relevant. I think this section is important to include because the authors here are presumably the ones who know the application layer information. And the sensitive information might not only be readings, it could include packet size, if larger packets are caused by activity such as turning on heating, then larger packets indicate presence and smaller ones absence, depending on weather. I am also concerned that there may be privacy issues arising from the various identifiers in use here. Did the WG consider these issues and their potential impact on how it is or is not safe to use RPL? (While the analysis might sound complex, I'd bet that not much new text would be needed, but who knows until the analysis has been done.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 1.3: what's the 3rd bullet mean? It's worded very ambiguously. With s/(vs. non-storing)// it'd be clear. - section 3: "a potentially significant portion of which is taken up by protocol and encryption overhead" seems overstated to me - are there numbers to back that up? - 5.1, last sentence: why is it important to note that? explaining would be good - 7.2.3: I don't get what you're telling me here that assists in security or interop? - section 9: please provide references to back up the assertion that "many available security mechanisms are not practical for use in such networks" for some relevant security mechanisms. The problem is that such assertions are used to justify doing nothing at all so they ought not be blithely made. - 9.1: "are unique per device" etc is the only sensible thing and would be nice if always true, but that is often not the case - why state what's known to not be true? Or are you trying to say something else? - 9.2: "it is replaced" - again that's not true, only devices known to be compromised would be replaced, which is by no means all compromised devices - 9.3: "already existing" - you really should have a reference there. From nobody Tue May 3 14:27:24 2016 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BED2512D923; Tue, 3 May 2016 14:27:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503212720.8196.78900.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 14:27:20 -0700 Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-ami@ietf.org, mcr+ietf@sandelman.ca Subject: [Roll] Alissa Cooper's No Objection on draft-ietf-roll-applicability-ami-13: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 21:27:21 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-roll-applicability-ami-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Stephen's DISCUSS. From nobody Tue May 3 14:38:59 2016 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD4E12D926; Tue, 3 May 2016 14:38:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503213856.8370.20077.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 14:38:56 -0700 Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-ami@ietf.org, mcr+ietf@sandelman.ca Subject: [Roll] Kathleen Moriarty's No Objection on draft-ietf-roll-applicability-ami-13: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 21:38:56 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-roll-applicability-ami-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Stephen's discuss points and would also like to see more on privacy. From nobody Tue May 3 18:19:52 2016 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F08CD12D6B5; Tue, 3 May 2016 18:19:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504011950.8325.77862.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 18:19:50 -0700 Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-ami@ietf.org, mcr+ietf@sandelman.ca Subject: [Roll] Ben Campbell's No Objection on draft-ietf-roll-applicability-ami-13: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 01:19:51 -0000 Ben Campbell has entered the following ballot position for draft-ietf-roll-applicability-ami-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It's been covered enough already, but I also agree with Stephen's discuss points. From nobody Thu May 5 01:46:09 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A6E12B021; Thu, 5 May 2016 01:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=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 VH1e04HQwHy2; Thu, 5 May 2016 01:46:06 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D449412B011; Thu, 5 May 2016 01:46:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: Date: Thu, 5 May 2016 04:46:06 -0400 Message-ID: <062801d1a6aa$90bd9610$b238c230$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0629_01D1A689.09AE18F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGmqH7WmWhHfPgZSnu7SCibp9ncZA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Joel jaeggli' , 'Gunter Van De Velde' , ops-dir@ietf.org, 'Benoit Claise' , roll@ietf.org Subject: [Roll] draft-ietf-roll-applicability-ami-13.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 08:46:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0629_01D1A689.09AE18F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nancy, Jonathan, Daniel: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Status of draft: Ready for publication. A few editorial nits found Editorial nits: #1 p 7 in 4.1 paragraph 1 Old/the frequency of large file transfers, e.g., firmware download of all metering devices, is typically much lower than the frequency of sending configuration messages or queries. / New / Old/the frequency of large file transfers (e.g., firmware download of all metering devices) is typically much lower than the frequency of sending configuration messages or queries. / Why: use of the (e.g... ) should be common across paragraph. #2 p. 11 Concerned about RFCs text in 7.1.3 "Additional metrics may be defined in companion RFCs." Editorial comment: Is this really a statement for an RFCs? This sentence may be sufficient, but it seemed a bit odd. #3 p. 12 section 7.1.4 - same statement as in 7.1.3 #4 p. 14 section 7.2.2 paragraph 3 Starting with "These include: Timetimeslotslotted channel. " Editorial comment: It would be wiser to use a hanging text for this list. Old/ These include: Timetimeslotslotted channel hopping (TSCH), specifically designed for application domains such as process automation, Low latency deterministic networks (LLDN), for application domains such as factory automation, Deterministic and synchronous multi-channel extension (DSME), for general industrial and commercial application domains that includes Channel diversity to increase network robustness, and Asynchronous multi-channel adaptation (AMCA), for large infrastructure application domains. / New These include: . Timetimeslotslotted channel hopping (TSCH): specifically designed for application domains such as process automation, . Low latency deterministic networks (LLDN): for application domains such as factory automation, . Deterministic and synchronous multi-channel extension (DSME): for general industrial and commercial application domains that includes Channel diversity to increase network robustness, and . Asynchronous multi-channel adaptation (AMCA): for large infrastructure application domains. / ------=_NextPart_000_0629_01D1A689.09AE18F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nancy, = Jonathan, Daniel:

 

I have = reviewed this document as part of the Operational directorate's ongoing = effort to review all IETF documents being processed by the IESG.  = These  comments were written with the intent of improving the = operational aspects of the

IETF = drafts. Comments that are not addressed in last call may be included in = AD reviews during the IESG review.  Document editors and WG chairs = should treat these comments just like any other last call = comments.

 

Status of draft:  Ready for publication.  =  A few editorial nits found

 

Editorial nits:

 

#1 p 7 in = 4.1 paragraph 1

 

Old/the = frequency of large file transfers, e.g., firmware download of all = metering devices, is typically much lower than the frequency of sending = configuration messages or queries. /

 

New / = Old/the frequency of large file transfers (e.g., firmware download of = all metering devices) is typically much lower than the frequency of = sending configuration messages or queries. /

 

Why: use of = the (e.g….. ) should be common across paragraph.

 

#2 p. 11 = Concerned about RFCs text in 7.1.3

 

“Additional metrics may be defined in companion = RFCs.”

Editorial = comment:  Is this really a statement for an RFCs?  This = sentence may be sufficient, but it seemed a bit odd.

 

#3 p. 12 = section 7.1.4 – same statement as in 7.1.3

 

#4 p. 14 = section 7.2.2 paragraph 3

 

Starting = with “These include: Timetimeslotslotted channel… “ =

 

Editorial comment: It would be wiser to use a hanging = text for this list.

 

Old/

   These include: Timetimeslotslotted = channel hopping

   (TSCH), specifically designed for = application domains such as process

   automation, Low latency deterministic = networks (LLDN), for

   application domains such as factory = automation, Deterministic and

   synchronous multi-channel extension = (DSME), for general industrial

   and commercial application domains that = includes Channel diversity to

   increase network robustness, and = Asynchronous multi-channel

   adaptation (AMCA), for large = infrastructure application domains.

/

New

These include: =

·         = Timetimeslotslotted channel hopping =  (TSCH):   specifically designed for application domains = such as process

automation, =

·         = Low latency deterministic networks = (LLDN):   for   application domains such as factory = automation,

·         =  Deterministic and synchronous = multi-channel extension (DSME):  for general industrial and = commercial application domains that includes Channel diversity to = increase network robustness, and

·         = Asynchronous multi-channel adaptation = (AMCA):  for large infrastructure application = domains.

/

 

 

=

 

------=_NextPart_000_0629_01D1A689.09AE18F0-- From nobody Thu May 5 13:10:18 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED9E12D11B for ; Thu, 5 May 2016 13:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HxXH1KOQhHXU for ; Thu, 5 May 2016 13:10:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EB312D0A7 for ; Thu, 5 May 2016 13:10:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8D0982002A for ; Thu, 5 May 2016 16:15:26 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E7448637DF for ; Thu, 5 May 2016 16:10:12 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <062801d1a6aa$90bd9610$b238c230$@ndzh.com> References: <062801d1a6aa$90bd9610$b238c230$@ndzh.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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 Date: Thu, 05 May 2016 16:10:12 -0400 Message-ID: <1995.1462479012@obiwan.sandelman.ca> Archived-At: Subject: Re: [Roll] draft-ietf-roll-applicability-ami-13.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 20:10:16 -0000 Thanks Sue! -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Fri May 6 06:41:02 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA3B12B034 for ; Fri, 6 May 2016 06:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ig7Z3Z-SO4lX for ; Fri, 6 May 2016 06:40:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0B512B056 for ; Fri, 6 May 2016 06:40:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EA7F02002A for ; Fri, 6 May 2016 09:46:12 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C5794637DF for ; Fri, 6 May 2016 09:40:56 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <2591c152-29fd-ce24-d4c2-27fc23a9a034@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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 Archived-At: Subject: Re: [Roll] How to react if Trickle Interval > Default Lifetime X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 06 May 2016 13:41:00 -0000 --=-=-= Content-Type: text/plain Joakim Eriksson wrote: > Typically the RPL parent will get lots of data from the children which > will > cause the link-metric to change > so it is not always the case that a defunct parent (at least not any of > the > actively used ones) will be just In many networks (metering for instance), there can be very little traffic for hours at a time, then a dozen packets down that part of the tree a few times a day. One answer that I like though: if there is no traffic, then it doesn't matter if the routes are good or not. The question is, when traffic does show up, can we handle it in a timely fashion. > Yes, a regular unicast DIS is a good way to keep both link metrics and > other important liveliness > information up to date. There is a document on unicast DIS. Does it provide useful advice to you? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVyye5YCLcPvd0N1lAQIeHAgAgHmV9NvKhie+L0B7qtGa0WqadqIbk3EH LLRpBfYIwWHA5KKW2Qnc18pHk5qrOdD4y3vv7U42nXQEdPADLO+H16HPRP9TsMot C6GFo/lM6Z8NPwDn3LQ6uwtQZNJ+YtuvH/gjO2E+M3Y8xdrEgOlw6723Xu2fAJFS fxk5DyCWSFyBk2EERwbvwPqu3TG6Dc81RfpFBQGm1c85yEwC1b161eDRX+q1Hxoo fpyzzwMRe8Vq0c0Br5LUOGCcvlXQ2qbl9rAFsbPfoyi6CabSSBoNy/V/d/mUdBBK KwEbXwohlbwdIkcKSFVMkuWTBKxVDSzo3DVhy1cMnEyPiRCVswp40Q== =aVfY -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 9 07:25:33 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3126712D1DB; Mon, 9 May 2016 07:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.915 X-Spam-Level: X-Spam-Status: No, score=-7.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 Y5VeafitNbfP; Mon, 9 May 2016 07:25:23 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D1212D1DF; Mon, 9 May 2016 07:25:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,601,1454972400"; d="scan'208,217";a="177115026" Received: from mail-lf0-f52.google.com ([209.85.215.52]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 09 May 2016 16:25:18 +0200 Received: by mail-lf0-f52.google.com with SMTP id m64so201625519lfd.1; Mon, 09 May 2016 07:25:18 -0700 (PDT) X-Gm-Message-State: AOPr4FUsCUgP3XAKVm+CA09Pr52eklszPWr6EfvRSsbv50vq9wR0Bl4wgUlE78HtH963mT62ZjdBNVDCySprmw== X-Received: by 10.112.72.193 with SMTP id f1mr14879932lbv.114.1462803918260; Mon, 09 May 2016 07:25:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.149.195 with HTTP; Mon, 9 May 2016 07:24:58 -0700 (PDT) In-Reply-To: <1789787799.3163737.1461858490879.JavaMail.yahoo@mail.yahoo.com> References: <1789787799.3163737.1461858490879.JavaMail.yahoo@mail.yahoo.com> From: Thomas Watteyne Date: Mon, 9 May 2016 16:24:58 +0200 X-Gmail-Original-Message-ID: Message-ID: To: nalini.elkins@insidethestack.com Content-Type: multipart/alternative; boundary=001a11c33d9eec95390532699350 Archived-At: Cc: Routing Over Low Power and Lossy Networks , "6lo@ietf.org" <6lo@ietf.org>, Alexa Morris , "6tisch@ietf.org" <6tisch@ietf.org>, "mentoring-coordinators@ietf.org" Subject: Re: [Roll] [6lo] [6tisch] Remote Mentoring: Internet Draft Review Team: 6tisch: Portugese / English X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 14:25:27 -0000 --001a11c33d9eec95390532699350 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nalini, Thanks for putting this together, this is great. Please do encourage them to post comments also on the IETF MLs. Although I'm in the Paris timezone and I don't speak Portuguese, feel free to have me CC'ed on their discussion with Diego. Thomas On Thu, Apr 28, 2016 at 5:48 PM, wrote: > Diego, > > Thanks very much for your help. > > I will make the introduction. > > Nalini Elkins > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > ------------------------------ > *From:* Prof. Diego Dujovne > *To:* Nalini Elkins > *Cc:* Routing Over Low Power and Lossy Networks ; Jari > Arkko ; "6lo@ietf.org" <6lo@ietf.org>; Alexa Morris > ; "6tisch@ietf.org" <6tisch@ietf.org>; " > mentoring-coordinators@ietf.org" > *Sent:* Thursday, April 28, 2016 8:24 AM > *Subject:* Re: [6tisch] Remote Mentoring: Internet Draft Review Team: > 6tisch: Portugese / English > > Nalini, > I can help with this draft, you can send them > my email address to start the discussion. I'm not in > Brazil (I'm in Chile), but we may be able to arrange > a videoconf if necessary, given that we do not have > a huge time difference. > Regards, > > Diego Dujovne > > 2016-04-28 11:46 GMT-03:00 : > > Roll / 6tisch / 6lo People, > > We are forming teams of new-ish people to start working together to revie= w > drafts and pose comments on the list. > > The second team in this set of WGs to be formed is comprised of 2 people > from Brazil. They wish to study drafts in the 6lo/ 6tisch/ roll WGs. Th= e > discussions will be conducted in Portugese or English. > > The first draft they are reading is: > > > draft-ietf-6tisch-minimal-15. > > They are to read the draft and have 5 questions ready for discussion. > (They have started.) The questions can be either things they do not > understand, things they think need to be clearer in the draft or need to = be > fixed. > > I will take either of the following, please let me know. > > 1. If you will be able to help them in Brazil time zone in a webinar in > Portugese / English. Commitment is one hour per month live and some emai= l > contact. > > 2. If you will be able to help them via email support only. > > Please help, if you can. > > BTW, the Spanish DNSOP team has a mentor & is started. > > Thank you all very much. > > > Nalini Elkins > IETF Mentoring Team > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > > -- > DIEGO DUJOVNE > Acad=C3=A9mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y Telecomun= icaciones > Facultad de Ingenier=C3=ADa UDP > www.ingenieria.udp.cl > (56 2) 676 8125 > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > > --=20 _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a11c33d9eec95390532699350 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nalini,

Thanks for putting this togethe= r, this is great. Please do encourage them to post comments also on the IET= F MLs.

Although I'm in the Paris timezone and = I don't speak Portuguese, feel free to have me CC'ed on their discu= ssion with Diego.

Thomas

On Thu, Apr 28, 2016 at 5:48 PM= , <nalini.elkins@insidethestack.com> wrote:<= br>
Die= go,

Thanks very much for= your help.
=C2=A0
I will make t= he introduction.

Nalini Elkins
Inside Products, Inc.


=
From: = Prof. Diego Dujovne <diego.dujovne@mail.udp.cl>
To: Nalini Elkins <nalini.elkins@insidethestack.com= >
Cc: Routing Over Lo= w Power and Lossy Networks <roll@ietf.org>; Jari Arkko <jari.arkko@piuha.net>; "6lo@ietf.org" <6lo@ietf.org>; Alexa Morr= is <amorris@amsl.c= om>; "6tis= ch@ietf.org" <6tisch@ietf.org>; "mentoring-coordinators@ietf.org" <= mentor= ing-coordinators@ietf.org>
S= ent: Thursday, April 28, 2016 8:24 AM
Subject: Re: [6tisch] Remote Mentoring: Internet D= raft Review Team: 6tisch: Portugese / English

<= div>Nalini,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 I can help with this draft, you can send them
<= /div>my email address to start the discussion. I'm not in
Brazil (I'm in Chile), but we may be able to arrange
a videoconf if necessary, given that we do not have
a huge time difference.
=C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diego Dujovne <= br clear=3D"none">

2016-04-28 11:46 GMT-0= 3:00 <nalini.elkins@inside= thestack.com>:
Roll / 6tisch = / 6lo People,

We are forming teams of new-ish people to start working together to review = drafts and pose comments on the list.

The second team in this set of WGs to be formed is comprised of 2 people fr= om Brazil.=C2=A0 They wish to study drafts in the 6lo/ 6tisch/ roll WGs.=C2= =A0 The discussions will be conducted in Portugese or English.

The first draft they are reading is:


draft-ietf-6tisch-minimal-15.

They are to read the draft and have 5 questions ready for discussion.=C2=A0= (They have started.) The questions can be either things they do not unders= tand, things they think need to be clearer in the draft or need to be fixed= .

I will take either of the following, please let me know.

1.=C2=A0 If you will be able to help them in Brazil time zone in a webinar = in Portugese / English.=C2=A0 Commitment is one hour per month live and som= e email contact.

2.=C2=A0 If you will be able to help them via email support only.

Please help, if you can.

BTW, the Spanish DNSOP team has a mentor & is started.

Thank you all very much.


Nalini Elkins
IETF Mentoring Team
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisc= h



--
DIEGO DUJOVNE
Acad=C3=A9= mico Escuela de Ingenier=C3=ADa en Inform=C3=A1tica y TelecomunicacionesFacultad de Ingenier=C3=ADa UDP
www.ingenieria.udp.cl
(56 2) 676 8125

_______________________________________________<= br clear=3D"none">6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch=



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




--
_______________= ________________________

Thomas Watteyne, PhD
Research Sci= entist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH
<= br>
_______________________________________
--001a11c33d9eec95390532699350-- From nobody Wed May 11 02:41:37 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C000112D599 for ; Wed, 11 May 2016 02:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4oWS5y7fVgxi for ; Wed, 11 May 2016 02:41:35 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23ACD12D5E2 for ; Wed, 11 May 2016 02:41:35 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id s184so49730551vkb.3 for ; Wed, 11 May 2016 02:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=z040NrJIrL7lyL68oYGS6YfYGxZBXYXkvy053OVyOHk=; b=owAqxvhKYAnJ1kboJVlj5JvSf+iSSDQ9I2ofuStoHhC2rKxH41WVpiVX0cltrZHU+O zThG2+y02y7QxhQ42h8KCTcoZXL00JsJEPBMzNCBdRqfygoIgXqvlR3OsUMq+XWH97ZV 9AhqN1FfCvl7yoQy9gvwmdrokpZgXTPpxmwlN5oGmbDPNIlvtKHmIVq1RD6oT3s2ucWC +JYuNwKn84dvB2yRhzb4IF5ETDl5tTNLtgJ4JPB4DGYkBmcKAjBN+ksD/JjatdjrpSXG 5pdWqLbKrZIHPtdU7RrlBWzRIM3r5bqVmIEEtEg4CAybDRJguPTXUNkGEhX+74gww1Fm WR1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=z040NrJIrL7lyL68oYGS6YfYGxZBXYXkvy053OVyOHk=; b=OcLVVd6zQst2MG8oav6KGhfAyt4ApUO11ox0gISqF78nM02gasuS7iasoFQoQytljy mGHMHteZpUW07lacPkiFjZftH525NlRBn9mCYYBFyPTxuJLPKj/aJ3M7rVnR2xIPCjiM W8dbKUyUgVl6vJz9gUCOZAzkcZvReMhbBnlsJrsTgjSqZ3MJOmmHPHVB8BiDe7poaBJi TcjKHDJq15Zt0Ej1H5NqXzxEiDcZ5KIeXH0Jcm8SYrToCVKV9uXYVemtffgdr6GgyTsy 8BABQfVme5iBLdwsqzRYJExLw2hxJmgvxwkfwyjdoM72i1ee8Z97FYYrTc5CXv11Dpi7 HVpA== X-Gm-Message-State: AOPr4FVQhHcPDFoJDMnJAJkQhmTKsKx+AHPwe7uL/J/gR1U2j+7Gp0sZplium6SS7cNkSv4hM0fzRJVd2pkLBA== MIME-Version: 1.0 X-Received: by 10.31.210.65 with SMTP id j62mr1140553vkg.133.1462959694284; Wed, 11 May 2016 02:41:34 -0700 (PDT) Received: by 10.176.2.40 with HTTP; Wed, 11 May 2016 02:41:34 -0700 (PDT) Date: Wed, 11 May 2016 15:11:34 +0530 Message-ID: From: Shobhit To: roll@ietf.org Content-Type: multipart/alternative; boundary=001a114bc2d4e60c3f05328dd88f Archived-At: Subject: [Roll] DIS Multicast behaviour X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 09:41:37 -0000 --001a114bc2d4e60c3f05328dd88f Content-Type: text/plain; charset=UTF-8 Hi, I have requirement to receive multicast DIS messages from any node without resetting the trickle timer. As standard indicates that if any node will receive the multicast DIS message , it will be considered as inconsistency with respect to trickle timer of recipient(RFC 6550 ,Sec 8.3). It also indicates this behavior can be controlled by DIS flag. But after checking the DIS flag option , it is mentioned that it is unused filed (Sec 6.2.1). "Flags: 8-bit unused field reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver." Please suggest if there is any way to stop the reset of trickle timer in case of reception of multicast DIS message. -- Regards, Shobhit --001a114bc2d4e60c3f05328dd88f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have requiremen= t to receive multicast DIS messages from any node without resetting the tri= ckle timer.

As standard indicates that if any node= will receive the multicast DIS message , it will be considered as inconsis= tency with respect to trickle timer of recipient(RFC 6550 ,Sec 8.3).
<= div>It also indicates this behavior can be controlled by DIS flag.=C2=A0

But after checking the DIS flag option , it is menti= oned that it is unused filed (Sec 6.2.1).
"Flags: 8-bit unus= ed field reserved for flags.=C2=A0 The field MUST be
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0initialized to zero by the sender and MUST be ignor= ed by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0receiver."
=

Please suggest if there is any way to stop the reset of= trickle timer in case of reception of multicast DIS message.

--
Regards,
Shobhit
--001a114bc2d4e60c3f05328dd88f-- From nobody Wed May 11 02:51:39 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D812212D62D for ; Wed, 11 May 2016 02:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=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 XFhKyUHX1_aX for ; Wed, 11 May 2016 02:51:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BB412D626 for ; Wed, 11 May 2016 02:51:34 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 0854218C1E4; Wed, 11 May 2016 11:51:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D981127C079; Wed, 11 May 2016 11:51:32 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0294.000; Wed, 11 May 2016 11:51:32 +0200 From: To: "shobhit.bits@gmail.com" Thread-Topic: [Roll] DIS Multicast behaviour Thread-Index: AQHRq2lTOe9rymTJOk+YV0e4eg7AEZ+zfpcA Date: Wed, 11 May 2016 09:51:32 +0000 Message-ID: <10723_1462960292_573300A4_10723_17072_1_D358CBB2.32C78%dominique.barthel@orange.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_D358CBB232C78dominiquebarthelorangecom_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.11.91516 Archived-At: Cc: =?iso-8859-1?Q?Cenk_G=FCndogan?= , Routing Over Low power and Lossy networks Subject: Re: [Roll] DIS Multicast behaviour X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 09:51:39 -0000 --_000_D358CBB232C78dominiquebarthelorangecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Shobbit, Thank you so much for your interest in more diverse responses to DIS recept= ion. The DIS flag mentioned in RFC6550 and its interpretation is still work in p= rogress. You can see the most recent proposal in draft-zhong-roll-dis-modifications = that expired just a few days ago. https://tools.ietf.org/html/draft-zhong-roll-dis-modifications-00 I would very much appreciate if you could describe to us the kind of deploy= ment that prompts for your stated requirement. This would help up in finalising the draft. With best regards Dominique De : Roll > on behalf o= f Shobhit > R=E9pondre =E0 : "roll@ietf.org" > Date : Wednesday 11 May 2016 11:41 =C0 : "roll@ietf.org" > Objet : [Roll] DIS Multicast behaviour Hi, I have requirement to receive multicast DIS messages from any node without = resetting the trickle timer. As standard indicates that if any node will receive the multicast DIS messa= ge , it will be considered as inconsistency with respect to trickle timer o= f recipient(RFC 6550 ,Sec 8.3). It also indicates this behavior can be controlled by DIS flag. But after checking the DIS flag option , it is mentioned that it is unused = filed (Sec 6.2.1). "Flags: 8-bit unused field reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver." Please suggest if there is any way to stop the reset of trickle timer in ca= se of reception of multicast DIS message. -- Regards, Shobhit ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_D358CBB232C78dominiquebarthelorangecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Shobbit,

Thank you so much for your interest in more diverse responses to DIS r= eception.
The DIS flag mentioned in RFC6550 and its interpretation is still work= in progress.
You can see the most recent proposal in draft-zhong-roll-dis-modifications that expired just a few days= ago.
I would very much appreciate if you could describe to us the kind of d= eployment that prompts for your stated requirement.
This would help up in finalising the draft.
With best regards

Dominique

De : Roll <roll-bounces@ietf.org> on behalf of Shobhit= <shobhit.bits@gmail.com&g= t;
R=E9pondre =E0 : "roll@ietf.org" <roll@ietf.org>
Date : Wednesday 11 May 2016 1= 1:41
=C0 : "roll@ietf.org" <roll@ietf.org>
Objet : [Roll] DIS Multicast b= ehaviour

Hi,

I have requirement to receive multicast DIS messages from any node wit= hout resetting the trickle timer.

As standard indicates that if any node will receive the multicast DIS = message , it will be considered as inconsistency with respect to trickle ti= mer of recipient(RFC 6550 ,Sec 8.3).
It also indicates this behavior can be controlled by DIS flag. 

But after checking the DIS flag option , it is mentioned that it is un= used filed (Sec 6.2.1).
"Flags: 8-bit unused field reserved for flags.  The field MU= ST be
         initialized to zero by the sender an= d MUST be ignored by the
         receiver."

Please suggest if there is any way to stop the reset of trickle timer = in case of reception of multicast DIS message.

--
Regards,
Shobhit
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_D358CBB232C78dominiquebarthelorangecom_-- From nobody Thu May 12 11:26:02 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A8712D538; Thu, 12 May 2016 11:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 3jaLGGxaVWaW; Thu, 12 May 2016 11:25:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9826B12D0CD; Thu, 12 May 2016 11:25:56 -0700 (PDT) Received: from localhost ([::1]:54061 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1b0vJ3-0001RR-D0; Thu, 12 May 2016 11:25:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com, otroan@employees.org X-Trac-Project: 6man Date: Thu, 12 May 2016 18:25:53 -0000 X-URL: https://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/6man/trac/ticket/5#comment:2 Message-ID: <083.fe55df1fad9ab941136b0fb2c6542e30@trac.tools.ietf.org> References: <068.671f8aa582afbd91ce328299dcfe05a4@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <068.671f8aa582afbd91ce328299dcfe05a4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, otroan@employees.org, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: roll@ietf.org, 6man@ietf.org Subject: Re: [Roll] [6man] #5 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 18:25:58 -0000 #5: draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption Changes (by otroan@employees.org): * status: new => closed * resolution: => wontfix -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: closed Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Resolution: wontfix Keywords: | -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Thu May 12 11:26:37 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C070212D6F8; Thu, 12 May 2016 11:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 C75ekjSD75El; Thu, 12 May 2016 11:26:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B0D12D0F4; Thu, 12 May 2016 11:26:34 -0700 (PDT) Received: from localhost ([::1]:54124 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1b0vJh-00033N-4Z; Thu, 12 May 2016 11:26:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com, otroan@employees.org X-Trac-Project: 6man Date: Thu, 12 May 2016 18:26:33 -0000 X-URL: https://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/6man/trac/ticket/6#comment:3 Message-ID: <083.55569b714435894d84343c022c8e07a8@trac.tools.ietf.org> References: <068.3c73dacb1b9363819387808aa499fc8b@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <068.3c73dacb1b9363819387808aa499fc8b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, otroan@employees.org, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: roll@ietf.org, 6man@ietf.org Subject: Re: [Roll] [6man] #6 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 18:26:37 -0000 #6: draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation Changes (by otroan@employees.org): * status: new => closed * resolution: => wontfix -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: closed Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Resolution: wontfix Keywords: | -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Thu May 12 11:27:03 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155E712D0F4; Thu, 12 May 2016 11:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 e3Ec0xSecLA2; Thu, 12 May 2016 11:27:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2795C12D538; Thu, 12 May 2016 11:26:59 -0700 (PDT) Received: from localhost ([::1]:54154 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1b0vK6-0004Jb-Hx; Thu, 12 May 2016 11:26:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com, otroan@employees.org X-Trac-Project: 6man Date: Thu, 12 May 2016 18:26:58 -0000 X-URL: https://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/6man/trac/ticket/7#comment:2 Message-ID: <083.aa1e3373e7d67f531b2e6cda3ed0cceb@trac.tools.ietf.org> References: <068.c7869b2e34ac214af78bf24f1219b6f8@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <068.c7869b2e34ac214af78bf24f1219b6f8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, otroan@employees.org, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: roll@ietf.org, 6man@ietf.org Subject: Re: [Roll] [6man] #7 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Relation with RFC 6294 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 18:27:02 -0000 #7: draft-thubert-6man-flow-label-for-rpl-03 Relation with RFC 6294 Changes (by otroan@employees.org): * status: new => closed * resolution: => wontfix -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: closed Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Resolution: wontfix Keywords: | -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Thu May 12 11:27:28 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E41212D814; Thu, 12 May 2016 11:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 dP3Nx-be3bdL; Thu, 12 May 2016 11:27:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F3412D701; Thu, 12 May 2016 11:27:20 -0700 (PDT) Received: from localhost ([::1]:54186 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1b0vKR-00052Y-Aa; Thu, 12 May 2016 11:27:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: pthubert@cisco.com, mariainesrobles@gmail.com, otroan@employees.org X-Trac-Project: 6man Date: Thu, 12 May 2016 18:27:19 -0000 X-URL: https://tools.ietf.org/wg/6man/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/6man/trac/ticket/8#comment:2 Message-ID: <083.e51efa13cfbd74a0abd112fb718d17da@trac.tools.ietf.org> References: <068.d868eca75329b76a18c979179b2bface@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <068.d868eca75329b76a18c979179b2bface@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, otroan@employees.org, roll@ietf.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: roll@ietf.org, 6man@ietf.org Subject: Re: [Roll] [6man] #8 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 relation with draft-bormann-6lo-rpl-mesh-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 18:27:24 -0000 #8: draft-thubert-6man-flow-label-for-rpl-03 relation with draft-bormann-6lo- rpl-mesh-00 Changes (by otroan@employees.org): * status: new => closed * resolution: => wontfix -- -------------------------------------------------+------------------------- Reporter: mariainesrobles@gmail.com | Owner: Type: defect | pthubert@cisco.com Priority: major | Status: closed Component: draft-thubert-6man-flow-label-for- | Milestone: rpl | Version: Severity: In WG Last Call | Resolution: wontfix Keywords: | -------------------------------------------------+------------------------- Ticket URL: 6man From nobody Fri May 13 02:15:02 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0070712D15A for ; Fri, 13 May 2016 02:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iKrO42Lt-610 for ; Fri, 13 May 2016 02:14:54 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C5412D133 for ; Fri, 13 May 2016 02:14:53 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id tlEr1s00C4Hiz6i01lErmQ; Fri, 13 May 2016 11:14:52 +0200 Received: from AMontpellier-654-1-128-219.w90-0.abo.wanadoo.fr ([90.0.215.219]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 13 May 2016 11:14:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 13 May 2016 11:14:51 +0200 From: peter van der Stok To: Roll Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl> X-Sender: stokcons@xs4all.nl (zCdz/c9tmzVslTdaDKMBkNwWaPqM1Ad8) User-Agent: XS4ALL Webmail Archived-At: Subject: [Roll] RPLinfo review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 09:15:01 -0000 Dear authors, Thanks for your document. In my opinion the document is very useful. Although many things are well explained, I am still left with questions and possible ambiguities in my understanding. Consequently, my review goes up to section 5.8. Continuing the review becomes more effective when my current questions are answered. Line numbers are with respect to page or to section header; hope this is clear. Below my review: ____________________________________________________________________________ Page 3, section1, line1: the first use of RPL please write in full. Section 2: please provide the reader with a list of terms from RFC7102 that is used in the document. Page 4: ICMPv6 may need a reference? DIS, DIO, and DAO are not provided by RFC7102. Please write in full or provide reference in section 2. Page 5 I like figure 2, and use it as a reference throughout the document. Page 5, line 2: I assume that 6LN is not RPI aware. Page 5: The phrase: “Advertisement, 6lowPAN … network” may need reference to RFC. Page 5 2nd al. write 6tisch in full? Page 5, 3rd al; write LLN in full (first occurrence) Page 6, Figure 3 and architecture text is informative, but please clarify how the use cases of section 4 map to figure 3. For example where does Internet start/end: at border router or at backbone router? And how does flow from one mesh over the backbone to the next mesh map to the use cases. I also did not see a mapping of flow from one RPL instance to another instance. Page 8, line 3: route -> root. Page 8, line 8: RPL-SN and RPL-NSN should that not be RPL-SM and RPL-NSM, otherwise explain the meaning of the N. Page 8, Please align terminology of table 1 with terminology of Figure 2 I would suggest to move table 1 and its concluding text to a last summary section of section 5. At the beginning of section 5, the import of the text is far from clear. I would recommend to write down at the beginning of section 5 the characteristics of storing mode for this document; e.g. root and 6lr do not know if a destination is part of RPL DODAG; and thus needs IP over IP header in all cases. Page 9 , section 5.1 line 1: states -> stated Page 9, line 7: is suitable -> is compulsory; or use SHOULD in different kind of phrase “in storing mode …….information”. suggestion to move section to start of section 5 Page9, Line 10: RPL-aware-leaf (6LN) in figure 2 it is called 6LR, I recommend to use 6LR throughout. According to figure 2, 6LN stands for something else. This is relevant for whole section 5. “Note:….root node”. Remove this phrase is already done in section 3. Page9 line13: send -> sends Line14: decrement -> decrements; send -> sends Line 15 arrives to 6LBR -> arrives at 6LBR Line 20: “The RPI header …DIO messages” -> The 6LR recognizes the address of the 6LBR (root?) from earlier received DIO messages, and can thus insert RPI directly in the header. The 6LBR receives the packet and accepts the payload. NB: In the whole document root and 6LBR is freely exchanged. May be good to say something about this in section 3. Section 5.2 Everywhere: 6LN -> 6LR Page10, line 1: insert -> inserts; send -> sends This is weird. According to the intro, 6LBR does not know if destination is a 6LR or a 6LN. In my opinion treatment, described in 5.2 and 5.3, by 6LBR and 6LR should be identical. Section 5.3 Put the alinea “ The question…. To leaf” up front of section 5.3. Section 5.3, Line 3: It includes -> The root (6LBR) uses Section 5.3 line 6: “the header ….node” -> the header before it passes the packet to 6LN. IPv6 is a new term not introduced earlier. Section 5.4 I assume IPv6 node is 6LN. How can the RPI header be encapsulated in the IP-IP header. I thought the encapsulating IPIP header contains RPI. Section 5.4, line 6: process -> processes. Section 5.5 6LN -> 6LR in whole section It would help the reader to explain that 6LR knows the destination is Internet because the prefixes differ. Why should it be done hop by hop? Interoperability requires that it is done in one way. So one IPIP encapsulation with RPI, with encapsulation removed by 6LBR. Section 5.6 6LN ->6LR for whole section Section 5.6, line 4: send -> sent Section 5.6, line 5: When the packet arrives at 6LR, the … Why is this not done in a hop by hop fashion as in section 5.2 modelled on section 5.3, because also here the root does not know whether the destination is 6LR or 6LN node. Page 13, line 1 Why two fashions: direct root, and hop by hop to root. Section 5.8 Can refer to section 5.3 directly, and remove text. ----------------------------------------------------------------------------------------------------------------------------------------- I stop here because I made too many assumptions about the text, and the validity of the rest of the review becomes more and more questionable. I hope this helps; and my misinterpretations may lead to better text. Greetings, peter From nobody Fri May 13 04:25:06 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E711D12D146; Fri, 13 May 2016 04:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 x3Zhw8Q_Pdoo; Fri, 13 May 2016 04:25:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C76712D14C; Fri, 13 May 2016 04:25:03 -0700 (PDT) Received: from localhost ([::1]:40449 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1b1BDK-0000nU-Io; Fri, 13 May 2016 04:25:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-roll-applicability-ami@ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Fri, 13 May 2016 11:25:02 -0000 X-URL: https://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/176 Message-ID: <068.f82ce53591c9bd896c9f7c9c9ddf7e60@trac.tools.ietf.org> X-Trac-Ticket-ID: 176 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-roll-applicability-ami@ietf.org Resent-Message-Id: <20160513112503.2C76712D14C@ietfa.amsl.com> Resent-Date: Fri, 13 May 2016 04:25:03 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Archived-At: Cc: roll@ietf.org Subject: [Roll] [roll] #176 (applicability-ami): Security items to consider for applicability-ami draft - IESG Evaluation- X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 11:25:05 -0000 #176: Security items to consider for applicability-ami draft - IESG Evaluation- I have two things I'd like to chat about, given that these applicability documents are where the roll WG has iirc said it'd address security and privacy issues with RPL: (1) 7.1.7: Don't you need to turn that "may not need" around and say that AMI deployments of RPL REQUIRE implementation (and maybe use) of link layer and higher layer security features? (You almost say that in 9.3 I think, so it'd maybe be good to be crystal clear. (2) Why are there no privacy considerations? I think this document needs that. For example, an AMI mesh based purely on link layer security could be a total privacy nightmare. And part of that is down to RPL - if I can cause lots of folks' traffic to be sent to me, that is RPL's issue. That I can then see the application layer content is not RPL's fault, but is still relevant. I think this section is important to include because the authors here are presumably the ones who know the application layer information. And the sensitive information might not only be readings, it could include packet size, if larger packets are caused by activity such as turning on heating, then larger packets indicate presence and smaller ones absence, depending on weather. I am also concerned that there may be privacy issues arising from the various identifiers in use here. Did the WG consider these issues and their potential impact on how it is or is not safe to use RPL? (While the analysis might sound complex, I'd bet that not much new text would be needed, but who knows until the analysis has been done.) - 1.3: what's the 3rd bullet mean? It's worded very ambiguously. With s/(vs. non-storing)// it'd be clear. - section 3: "a potentially significant portion of which is taken up by protocol and encryption overhead" seems overstated to me - are there numbers to back that up? - 5.1, last sentence: why is it important to note that? explaining would be good - 7.2.3: I don't get what you're telling me here that assists in security or interop? - section 9: please provide references to back up the assertion that "many available security mechanisms are not practical for use in such networks" for some relevant security mechanisms. The problem is that such assertions are used to justify doing nothing at all so they ought not be blithely made. - 9.1: "are unique per device" etc is the only sensible thing and would be nice if always true, but that is often not the case - why state what's known to not be true? Or are you trying to say something else? - 9.2: "it is replaced" - again that's not true, only devices known to be compromised would be replaced, which is by no means all compromised devices - 9.3: "already existing" - you really should have a reference there. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability-ami@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: applicability-ami | Version: Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Fri May 13 04:27:26 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AB712D165; Fri, 13 May 2016 04:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_YrcLrqUYx7; Fri, 13 May 2016 04:27:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F16A12D108; Fri, 13 May 2016 04:27:22 -0700 (PDT) Received: from localhost ([::1]:40540 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1b1BFZ-0000PN-Pw; Fri, 13 May 2016 04:27:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-roll-applicability-ami@ietf.org, mariainesrobles@gmail.com X-Trac-Project: roll Date: Fri, 13 May 2016 11:27:21 -0000 X-URL: https://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/177 Message-ID: <068.18bd6acfbeca2f3d8e7d30f64ac6ed8f@trac.tools.ietf.org> X-Trac-Ticket-ID: 177 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-ami@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-roll-applicability-ami@ietf.org Resent-Message-Id: <20160513112722.5F16A12D108@ietfa.amsl.com> Resent-Date: Fri, 13 May 2016 04:27:22 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Archived-At: Cc: roll@ietf.org Subject: [Roll] [roll] #177 (applicability-ami): Editorial Comments for ami draft - IESG Evaluation- X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 11:27:24 -0000 #177: Editorial Comments for ami draft - IESG Evaluation- Comments by Suresh Krishnan (Comment (2016-05-03)) https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/ballot/ Section 1.2: Required reading - Why is the item [surveySG] in required reading not part of the normative references? Section 1.3: Please expand RPL before first use and add a reference to RFC6550 Section 2: Is this section really required? Seems like a summarization of the RPL RFC. At least consider removing the part that starts with "RPL was designed to meet the following application requirements:" and mentions a list of requirement RFCs. This list does not seem relevant here and is also covered in the RPL spec itself. Section 4.1: This does not sound right. Isn't the periodic meter read traffic going the other direction? " The traffic generated by the head-end server and destined to metering devices is dominated by periodic meter reads," Section 7.4.1: Please add a reference the trickle algorithm at first use. e.g. "Trickle [RFC6206] was designed to be..." -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-roll- mariainesrobles@gmail.com | applicability-ami@ietf.org Type: defect | Status: new Priority: major | Milestone: Component: applicability-ami | Version: Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: roll From nobody Fri May 13 06:17:33 2016 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F94412D51F; Fri, 13 May 2016 06:17:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160513131732.10537.55597.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2016 06:17:32 -0700 Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com Subject: [Roll] roll - New Meeting Session Request for IETF 96 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 13 May 2016 13:17:32 -0000 A new meeting session request has just been submitted by Ines Robles, a Chair of the roll working group. --------------------------------------------------------- Working Group Name: Routing Over Low power and Lossy networks Area Name: Routing Area Session Requester: Ines Robles Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: 6lo core 6tisch Second Priority: rtgarea ace anima Third Priority: t2trg pce manet rtgwg lwig intarea Special Requests: Conflicts to Avoid: First Priority: 6lo core 6tisch Second Priority: rtgarea ace anima Third Priority: t2trg pce manet rtgwg lwig intarea --------------------------------------------------------- From nobody Fri May 13 08:53:19 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0DB12D5A5; Fri, 13 May 2016 08:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 WJ4IEz410T9H; Fri, 13 May 2016 08:53:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DF912D187; Fri, 13 May 2016 08:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1366; q=dns/txt; s=iport; t=1463154795; x=1464364395; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=H/7XYZi+vByKmiPoVTBbVH3g9++3zHhfkUkirQKN/Uo=; b=h71bBv8Kpk45DGjWCj7ZyHoR9Bxn/p/man5UTYMhpkHJGsY0DEtxqgQP WJCfy9dyT7zHn73eBV+NDK4Gs48TofcHJyRbAaB6geklMqYj+iWXWoeab +uQscfikIwmu+znu+IeFxsUzWSMWEt0ncfPwL6K3uwdNayj2N+N3PlmWP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AAD19zVX/51dJa1EFwODN1V+BrlQA?= =?us-ascii?q?Q2BDQVkJIVtAoEsOBQBAQEBAQEBZSeEQwEBAgI6LCECAgEILAQGBgobFxsBBgI?= =?us-ascii?q?BAgEDARKILw4stHGLeAEBAQEBAQEBAQEBAQEBAQEBAQEBARwFhiCETYE5gncwJ?= =?us-ascii?q?geFCwWYJwGFfYVlgjuBaRc3hAGIYY9AAR4BAUKCBg0OgQBLbgGHWn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208";a="104048535" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2016 15:53:09 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u4DFr9Rk030040 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2016 15:53:09 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 May 2016 10:53:08 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Fri, 13 May 2016 10:53:09 -0500 From: "Alvaro Retana (aretana)" To: "roll@ietf.org" , "manet@ietf.org" Thread-Topic: ITS BOF Virtual Interim Meeting: May 31, 2016 Thread-Index: AQHRrKXjwfV0xiFjKkys13IvOeBLRp+3FoWA Date: Fri, 13 May 2016 15:53:09 +0000 Message-ID: References: <20160512232644.31516.82715.idtracker@ietfa.amsl.com> In-Reply-To: <20160512232644.31516.82715.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Roll] FW: ITS BOF Virtual Interim Meeting: May 31, 2016 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 13 May 2016 15:53:17 -0000 FYI.. On 5/12/16, 7:26 PM, "IETF-Announce on behalf of IESG Secretary" wrote: >The Intelligent Transportation Systems (its) BOF will hold a virtual >interim meeting on May 31, 2016 at 1000 EDT (1400 UTC). > >ITS Virtual BOF Session >Tuesday, May 31, 2016 >10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr > >JOIN WEBEX MEETING >https://ietf.webex.com/ietf/j.php?MTID=3Dm6a2426507fd79ed99642514b3c75c149 >Meeting number: 644 158 525 >Meeting password: may31st > >JOIN BY PHONE >1-877-668-4493 Call-in toll free number (US/Canada) >1-650-479-3208 Call-in toll number (US/Canada) >Access code: 644 158 525 > >Toll-free dialing restrictions: >https://www.webex.com/pdf/tollfree_restrictions.pdf > >Add this meeting to your calendar (Cannot add from mobile devices): >https://ietf.webex.com/ietf/j.php?MTID=3Dm5f3d256232517f6c2e17acdeca317f3f > >Need help? Go to: >http://help.webex.com > >IMPORTANT NOTICE: Please note that this WebEx service allows audio and >other information sent during the session to be recorded, which may be >discoverable in a legal matter. By joining this session, you >automatically consent to such recordings. If you do not consent to being >recorded, discuss your concerns with the host or do not join the >session. > From nobody Tue May 24 01:50:47 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6887E12D1A5 for ; Tue, 24 May 2016 01:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 wxnV2KCxkin3 for ; Tue, 24 May 2016 01:50:42 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C984C12D0BA for ; Tue, 24 May 2016 01:50:41 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id c189so12823903vkb.1 for ; Tue, 24 May 2016 01:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=rkflsXxoWZbcivEAeYsQcDnVYESzsYUTgKsQxgczWEo=; b=0uTGDlBIRJ41LI5lFvUzuWKutOBT0vFhCQ5Gzr5/ez4w3Y6zQbx5jUCbN/Um9na1dB ShiStsTMrKXQXietAuX6o0/EP10hcCgblX0dwg0BJmizE+yQijyBuVRuzDK/7EYXSiTK 1FcTzfub/NBTpAtTQavJlIvZ25M0zmTrAuJil/hksxO7v/n+aw8vGkbPjQqpcsd0y+Yj 7Ek3q+r/8rn4d9Ivq6wbZVV8Tkv6Tps/RXDxGpP/Xfa8cGJMqEexfPZ6qd2MazZmPCb/ r4v1DTtmiwmi8icNJA727Fo2GCqHrwu6emSu0GZBdZzy0FnizjysAMyGZbSA31VqNPGS /J5A== 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; bh=rkflsXxoWZbcivEAeYsQcDnVYESzsYUTgKsQxgczWEo=; b=PBFteaC57WiUq3ueDDNVSQfgIQmn8s1mzNTEvnptwR2CFQB9QPgDXCsMy5momS7bB0 OupxYaDpyHiq3xQvZAtbWQuTkYu00YBKF68KYS5XhWVn8gjm5KrUDSisCyvfLrRKU892 jy0vjT5FKOMiMzNyNA+sseW23w8P/3635cZlqQByBItdeAX5ZwRO5iqGHTLefgDqYz4p pEryvUmz4VZzWWLzogwRjkU/CJmqK6Ii9XcGyKEFemzpEi1cninEmGPxIbNdHRfuChRb gUd7d7X3JPjgZDUfP1uj2gDc3q/llztcB0YoLDOeELy9sWhNsJBZpXL0Ob4CV3GY8era k4Xw== X-Gm-Message-State: ALyK8tK++Kax0gP50Cv013Y4oURd/VKKs0wY8jnzwMhcwZ9CYRjb9VJBcJvC25ioFC7FYvpqEIgRXATDv8GLeQ== MIME-Version: 1.0 X-Received: by 10.31.158.1 with SMTP id h1mr1857839vke.5.1464079840679; Tue, 24 May 2016 01:50:40 -0700 (PDT) Received: by 10.159.37.98 with HTTP; Tue, 24 May 2016 01:50:40 -0700 (PDT) In-Reply-To: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl> References: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl> Date: Tue, 24 May 2016 11:50:40 +0300 Message-ID: From: Ines Robles To: "consultancy@vanderstok.org" , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11425eecd39e40053392a66f Archived-At: Subject: Re: [Roll] RPLinfo review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 24 May 2016 08:50:44 -0000 --001a11425eecd39e40053392a66f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Peter, Thanks for your comments, please find comments below. 2016-05-13 12:14 GMT+03:00 peter van der Stok : > Dear authors, > > Thanks for your document. In my opinion the document is very useful. > Although many things are well explained, I am still left with questions a= nd > possible ambiguities in my understanding. Consequently, my review goes up > to section 5.8. Continuing the review becomes more effective when my > current questions are answered. > Line numbers are with respect to page or to section header; hope this is > clear. > Below my review: > > _________________________________________________________________________= ___ > Page 3, section1, line1: the first use of RPL please write in full. > Section 2: please provide the reader with a list of terms from RFC7102 that > is used in the document. > Page 4: ICMPv6 may need a reference? > DIS, DIO, and DAO are not provided by RFC7102. Please write in full or > provide reference in section 2. > Page 5 I like figure 2, and use it as a reference throughout the document= . > OK, we are addressing all of above editorial issues Page 5, line 2: I assume that 6LN is not RPI aware. > Yes > Page 5: The phrase: =E2=80=9CAdvertisement, 6lowPAN =E2=80=A6 network= =E2=80=9D may need > reference to RFC. > Page 5 2nd al. write 6tisch in full? > Page 5, 3rd al; write LLN in full (first occurrence) > Page 6, Figure 3 and architecture text is informative, but please clarify > how the use cases of section 4 map to figure 3. For example where does > Internet start/end: at border router or at backbone router? And how does > flow from one mesh over the backbone to the next mesh map to the use case= s. > Ok, we will clarify the figure. I also did not see a mapping of flow from one RPL instance to another > instance. > I do not understand this. Could you please clarify? > Page 8, line 3: route -> root. > Page 8, line 8: RPL-SN and RPL-NSN should that not be RPL-SM and RPL-NSM, > otherwise explain the meaning of the N. > Page 8, Please align terminology of table 1 with terminology of Figure 2 > I would suggest to move table 1 and its concluding text to a last summary > section of section 5. At the beginning of section 5, the import of the te= xt > is far from clear. > I would recommend to write down at the beginning of section 5 the > characteristics of storing mode for this document; e.g. root and 6lr do n= ot > know if a destination is part of RPL DODAG; and thus needs IP over IP > header in all cases. > Page 9 , section 5.1 line 1: states -> stated > Page 9, line 7: is suitable -> is compulsory; or use SHOULD in different > kind of phrase > =E2=80=9Cin storing mode =E2=80=A6=E2=80=A6.information=E2=80=9D. suggest= ion to move section to start of > section 5 > Page9, Line 10: RPL-aware-leaf (6LN) in figure 2 it is called 6LR, I > recommend to use 6LR throughout. According to figure 2, 6LN stands for > something else. This is relevant for whole section 5. > =E2=80=9CNote:=E2=80=A6.root node=E2=80=9D. Remove this phrase is already= done in section 3. > Page9 line13: send -> sends > Line14: decrement -> decrements; send -> sends > Line 15 arrives to 6LBR -> arrives at 6LBR > Line 20: =E2=80=9CThe RPI header =E2=80=A6DIO messages=E2=80=9D -> The 6L= R recognizes the address > of the 6LBR (root?) from earlier received DIO messages, and can thus inse= rt > RPI directly in the header. The 6LBR receives the packet and accepts the > payload. > Ok, thanks for the suggestions. > NB: In the whole document root and 6LBR is freely exchanged. May be good > to say something about this in section 3. > Section 5.2 > Everywhere: 6LN -> 6LR > We use 6LN as leaf, and not as router, we are going to clarify this. Page10, line 1: insert -> inserts; send -> sends > This is weird. According to the intro, 6LBR does not know if destination > is a 6LR or a 6LN. In my opinion treatment, described in 5.2 and 5.3, by > 6LBR and 6LR should be identical. > Section 5.3 > Put the alinea =E2=80=9C The question=E2=80=A6. To leaf=E2=80=9D up front= of section 5.3. > Section 5.3, Line 3: It includes -> The root (6LBR) uses > Section 5.3 line 6: =E2=80=9Cthe header =E2=80=A6.node=E2=80=9D -> the he= ader before it passes the > packet to 6LN. > IPv6 is a new term not introduced earlier. > Section 5.4 > I assume IPv6 node is 6LN. > How can the RPI header be encapsulated in the IP-IP header. I thought the > encapsulating IPIP header contains RPI. > We are going to clarify the text with your suggestions. Section 5.4, line 6: process -> processes. > Section 5.5 6LN -> 6LR in whole section > It would help the reader to explain that 6LR knows the destination is > Internet because the prefixes differ. > Why should it be done hop by hop? Interoperability requires that it is > done in one way. So one IPIP encapsulation with RPI, with encapsulation > removed by 6LBR. > The simplest fully general situation for storing mode is to always put in hop-by-hop IPIP headers. > Section 5.6 > 6LN ->6LR for whole section > Section 5.6, line 4: send -> sent > Section 5.6, line 5: When the packet arrives at 6LR, the =E2=80=A6 > Why is this not done in a hop by hop fashion as in section 5.2 modelled o= n > section 5.3, because also here the root does not know whether the > destination is 6LR or 6LN node. > Yes, it is hop-by-hop, we will clarify the text. > Page 13, line 1 Why two fashions: direct root, and hop by hop to root. > For direct root, the 6LR can know the address of the root because it knows the address of the root via the DODAGID in the DIO messages, and In all cases hop by hop can be used > Section 5.8 > Can refer to section 5.3 directly, and remove text. > I would prefer leave the text for a better understanding. Many thanks again to help to clarify the draft. :-) Cheers, ---------------------------------------------------------------------------= -------------------------------------------------------------- > I stop here because I made too many assumptions about the text, and the > validity of the rest of the review becomes more and more questionable. > I hope this helps; and my misinterpretations may lead to better text. > Greetings, > peter > > > > --001a11425eecd39e40053392a66f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Peter,

Thanks for your comments, ple= ase find comments below.

2016-05-13 12:14 GMT+03:0= 0 peter van der Stok <stokcons@xs4all.nl>:
Dear author= s,

Thanks for your document. In my opinion the document is very useful. Althou= gh many things are well explained, I am still left with questions and possi= ble ambiguities in my understanding. Consequently, my review goes up to sec= tion 5.8. Continuing the review becomes more effective when my current ques= tions are answered.
Line numbers are with respect to page or to section header; hope this is cl= ear.
Below my review:
___________________________________________________________________________= _
Page 3, section1, line1: the first use of RPL please write in full.
Section 2: please provide the reader with a list = of terms from RFC7102 that is used in the document.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">Page 4: ICMPv6 may need a reference?
DIS, DIO, and DAO are not provided by RFC7102. Please write in full or prov= ide reference in section 2.
Page 5 I like figure 2, and use it as a reference throughout the document.<= br>
OK, we are addressing all of above editorial issues

Page 5, line 2: I assume that 6LN is not RPI aware.
Ye= s=C2=A0
Page 5: The phrase:=C2=A0 =E2=80=9CAdvertisement, 6lowPAN=C2=A0 =E2=80=A6 n= etwork=E2=80=9D may need reference to RFC.
Page 5 2nd al. write 6tisch in full?
Page 5, 3rd al; write LLN in full (first occurrence)
Page 6, Figure 3 and architecture text is informative, but please clarify h= ow the use cases of section 4 map to figure 3. For example where does Inter= net start/end: at border router or at backbone router?=C2=A0And how does fl= ow from one mesh over the backbone to the next mesh map to the use cases.
=C2=A0
Ok, we will clarify the figure.=C2=A0<= /div>

I also did not see a mapping of flow f= rom one RPL instance to another instance.
=C2=A0
=
I do not understand this. Could you please clarify?
=C2=A0
Page 8, line 3: route -> root.
Page 8, line 8: RPL-SN and RPL-NSN should that not be RPL-SM and RPL-NSM, o= therwise explain the meaning of the N.
Page 8, Please align terminology of table 1 with terminology of Figure 2 I would suggest to move table 1 and its concluding text to a last summary s= ection of section 5. At the beginning of section 5, the import of the text = is far from clear.
I would recommend to write down at the beginning of section 5 the character= istics of storing mode for this document; e.g. root and 6lr do not know if = a destination is part of RPL DODAG; and thus needs IP over IP header in all= cases.
Page 9 , section 5.1 line 1: states -> stated
Page 9, line 7: is suitable -> is compulsory; or use SHOULD in different= kind of phrase
=E2=80=9Cin storing mode =E2=80=A6=E2=80=A6.information=E2=80=9D. suggestio= n to move section to start of section 5
Page9, Line 10: RPL-aware-leaf (6LN) in figure 2 it is called 6LR, I recomm= end to use 6LR throughout. According to figure 2, 6LN stands for something = else. This is relevant for whole section 5.
=E2=80=9CNote:=E2=80=A6.root node=E2=80=9D. Remove this phrase is already d= one in section 3.
Page9 line13: send -> sends
Line14: decrement -> decrements; send -> sends
Line 15 arrives to 6LBR -> arrives at 6LBR
Line 20: =E2=80=9CThe RPI header =E2=80=A6DIO messages=E2=80=9D -> The 6= LR recognizes the address of the 6LBR (root?) from earlier received DIO mes= sages, and can thus insert RPI directly in the header. The 6LBR receives th= e packet and accepts the payload.

Ok, t= hanks for the suggestions.
=C2=A0
NB: In the whole document root and 6LBR is freely exchanged. May be good to= say something about this in section 3.
Section 5.2
Everywhere: 6LN -> 6LR
=C2=A0
We use 6LN = as leaf, and not as router, we are going to clarify this.=C2=A0
<= br>
Page10, line 1: insert -> inserts; send -> sends
This is weird. According to the intro, 6LBR does not know if destination is= a 6LR or a 6LN. In my opinion treatment, described in 5.2 and 5.3, by 6LBR= and 6LR should be identical.
Section 5.3
Put the alinea =E2=80=9C The question=E2=80=A6. To leaf=E2=80=9D up front o= f section 5.3.
Section 5.3, Line 3: It includes -> The root (6LBR) uses
Section 5.3 line 6: =E2=80=9Cthe header =E2=80=A6.node=E2=80=9D -> the h= eader before it passes the packet to 6LN.
IPv6 is a new term not introduced earlier.
Section 5.4
I assume IPv6 node is 6LN.
How can the RPI header be encapsulated in the IP-IP header. I thought the e= ncapsulating IPIP header contains RPI.

= We are going to clarify the text with your suggestions.

Section 5.4, line 6: process -> processes.
Section 5.5 6LN -> 6LR in whole section
It would help the reader to explain that 6LR knows the destination is Inter= net because the prefixes differ.
Why should it be done hop by hop? Interoperability requires that it is done= in one way. So one IPIP encapsulation with RPI, with encapsulation removed= by 6LBR.
=C2=A0
The simplest fully gen= eral situation for storing mode is to always put in hop-by-hop IPIP headers= .
=C2=A0
Section 5.6
6LN ->6LR for whole section
Section 5.6, line 4: send -> sent
Section 5.6, line 5: When the packet arrives at 6LR, the =E2=80=A6
Why is this not done in a hop by hop fashion as in section 5.2 modelled on = section 5.3, because also here the root does not know whether the destinati= on is 6LR or 6LN node.

Yes, it is hop-b= y-hop, we will clarify the text.
=C2=A0
Page 13, line 1 Why two fashions: direct root, and hop by hop to root.
<= /blockquote>

For direct root, the 6LR can know the addre= ss of the root because it knows the address of the root via the DODAGID in = the DIO messages, and In all cases hop by hop can be used
=C2=A0<= br>
Section 5.8
Can refer to section 5.3 directly, and remove text.
I would prefer leave the text for a better understanding.=C2= =A0

Many thanks again to help to clarify the draft= . :-)

Cheers,

---------------------------------------------------------------------------= --------------------------------------------------------------
I stop here because I made too many assumptions about the text, and the val= idity of the rest of the review becomes more and more questionable.
I hope this helps; and my misinterpretations may lead to better text.
Greetings,
peter



--001a11425eecd39e40053392a66f-- From nobody Tue May 24 02:17:24 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E4312B006 for ; Tue, 24 May 2016 02:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HC3f9fv8eRSJ for ; Tue, 24 May 2016 02:17:21 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E266B12D1EB for ; Tue, 24 May 2016 02:17:20 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud2.xs4all.net with ESMTP id y9HH1s00g4h15BW019HHup; Tue, 24 May 2016 11:17:19 +0200 Received: from AMontpellier-654-1-65-44.w90-0.abo.wanadoo.fr ([90.0.40.44]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 24 May 2016 11:17:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 24 May 2016 11:17:17 +0200 From: peter van der Stok To: Ines Robles Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (B96/f9VODHnw7VY8PJ5XTNoQM0u07wn+) User-Agent: XS4ALL Webmail Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] RPLinfo review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 09:17:23 -0000 > >> I also did not see a mapping of flow from one RPL instance to >> another instance. > > I do not understand this. Could you please clarify? > A node belonging to one RPL instance sends a message to a node belonging to another RPL instance. This seems possible in Figure 3, with 3 RPL instances? If possible, it means an additional use case. Peter From nobody Tue May 24 03:16:11 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C2A12D0C3 for ; Tue, 24 May 2016 03:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 9qpFOPj1oH9b for ; Tue, 24 May 2016 03:16:08 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D854D12B05C for ; Tue, 24 May 2016 03:16:07 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id y2so15092101vka.3 for ; Tue, 24 May 2016 03:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ubkL883bvgd5ZBone2sbVHd4HNuCy7UBCgDnyAK1PSc=; b=zVXHbQJlrPmEmuC5unW7Pl5FbRlbw1583dbnmj5XUPwJcBXyQCoiSlu6Gqs798jvwE VZ0GkpxWCPkv+j83axndZ59U8zG08iplRx4J/6xuSmo4itR/Cw7x9GKfaLQzoFwLQJYP gVlLyql33gVs0PyHjQR+bgwBHOMHMjI9/ND33BPKORYi6VAi37QBRE/La5MGD5AwWVZB 7LdjS+zHbqUDATgaD5cjyHHSQmjP0wxrpDmd+JAkf8mF14N83NN0OVshlpBg4tkKHRzS II04EueOMfPoZ9UKa4k+cV8hG4td2Mqw5b7R7uYHpoWHYZhF+u5zvdqXH6CNj23jZKyr xPAw== 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; bh=ubkL883bvgd5ZBone2sbVHd4HNuCy7UBCgDnyAK1PSc=; b=kdO3s41ME/fg6DX8b4ai4M3KAfzF78H4U99dW55JXcERMmSSfk8f+31bY1XDWpYyqo 1hgBjzM0rgVJjPNHZCyia5OL7fSuUr31o9z9Z2sCtOOy9pgAuZQ2Ayh3jMjdcHjkp/HR jy6QRgonb5cFP4cZynh0ff1CZpJGlrGu2mIqN7j1JIyP4QdOq8nynhQIOnd/fn0IfT+w bi6IkdlR5rvq+DOjm5SsXZaGa1tHmbEve+2HO3MpF+LL40KG/AoeEvGOf0+gEUdMS0jN YL+cTxbn0AI8kjkc5egovVHdg7cAoW8j330RyyHAg83BFHMizbR3X/6J/DJlz6jf1vLu enpQ== X-Gm-Message-State: ALyK8tJLPp1TwNASOgtdOJCs+p0GPjBxrX852MUk/7lWC2p2ZVaq5JlOoKc2os1lj6Yv49ZWb2NLXkAmY4XyOg== MIME-Version: 1.0 X-Received: by 10.31.158.1 with SMTP id h1mr2030671vke.5.1464084966585; Tue, 24 May 2016 03:16:06 -0700 (PDT) Received: by 10.159.37.98 with HTTP; Tue, 24 May 2016 03:16:06 -0700 (PDT) In-Reply-To: References: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl> Date: Tue, 24 May 2016 13:16:06 +0300 Message-ID: From: Ines Robles To: "consultancy@vanderstok.org" Content-Type: multipart/alternative; boundary=001a11425eec5abfa8053393d8a9 Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] RPLinfo review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 24 May 2016 10:16:09 -0000 --001a11425eec5abfa8053393d8a9 Content-Type: text/plain; charset=UTF-8 Hi, Thanks for the clarification. We are just considering here one RPLInstance. Working with different RPLInstances, involves deeply analysis, which we could do in the future. But, actually I dont know if it is possible/useful to send a message from one RPL Instance to another one , since for example a RPL node may belong to multiple RPL Instances, and it may act as a router in some and as a leaf in others[1], for this reason it does not make sense to me sending packet from one RPLInstance to other RPLInstance. Besides the control messages has one field for RPLInstanceID, it does not have RPLInstanceID origen or RPLInstanceID dst. What do you think? Thank you, Ines [1] RFC6550. Section 5. RFC 6550 describes only how a single instance behaves 2016-05-24 12:17 GMT+03:00 peter van der Stok : > > >> I also did not see a mapping of flow from one RPL instance to >>> another instance. >>> >> >> I do not understand this. Could you please clarify? >> >> > A node belonging to one RPL instance sends a message to a node belonging > to another RPL instance. > This seems possible in Figure 3, with 3 RPL instances? > > If possible, it means an additional use case. > > Peter > --001a11425eec5abfa8053393d8a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
Thanks for the clarification.

We are just considering here one RPLInstance.=C2=A0

<= div>Working with different RPLInstances, involves deeply analysis, which we= could do in the future. But, actually I dont know if it is possible/useful= to send a message from one RPL Instance to another one=C2=A0, since for ex= ample a=C2=A0= RPL node may belong to multiple RPL Instances, and it=C2=A0may act as a router in= some and as a leaf in others[1], for this reason it does not make sense to= me sending packet from one RPLInstance to other RPLInstance. Besides the c= ontrol messages has one field for RPLInstanceID, it does not have RPLInstan= ceID origen or RPLInstanceID dst.

What do you think?

<= /span>
Thank you,

Ines

[1] RFC6550. Section 5. RFC 6550=C2=A0describes only how a single instance behaves

2016-05-24 12:17 GMT+03:00 peter van der Stok <stokcons@xs4all.nl= >:


I also did not see a mapping of flow from one RPL instance to
another instance.

I do not understand this. Could you please clarify?


 A node belonging to one RPL instance sends a message to a node belonging to= another RPL instance.
This seems possible in Figure 3, with 3 RPL instances?

If possible, it means an additional use case.

Peter

--001a11425eec5abfa8053393d8a9-- From nobody Tue May 24 03:23:28 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A9A12B057 for ; Tue, 24 May 2016 03:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 afJrmd_6M7WI for ; Tue, 24 May 2016 03:23:24 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9256C12B014 for ; Tue, 24 May 2016 03:23:23 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud2.xs4all.net with ESMTP id yANt1s00B4h15BW01ANt3a; Tue, 24 May 2016 12:22:53 +0200 Received: from AMontpellier-654-1-65-44.w90-0.abo.wanadoo.fr ([90.0.40.44]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 24 May 2016 12:22:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 24 May 2016 12:22:53 +0200 From: peter van der Stok To: Ines Robles Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl> Message-ID: <1747ba1478659868c3b715ff8b807c6c@xs4all.nl> X-Sender: stokcons@xs4all.nl (SZ+Z11pKN1A415Z1qlvEH+ahlfvyd+Tj) User-Agent: XS4ALL Webmail Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] RPLinfo review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 10:23:26 -0000 Hi, that means writing "one RPL instance" in figure 3 in stead of "RPL instance" to remove that ambiguity. Writing in the use case section a phrase as the one below will be more than sufficient for me. peter Ines Robles schreef op 2016-05-24 12:16: > Hi, > > Thanks for the clarification. > > We are just considering here one RPLInstance. > > Working with different RPLInstances, involves deeply analysis, which > we could do in the future. But, actually I dont know if it is > possible/useful to send a message from one RPL Instance to another one > , since for example a RPL node may belong to multiple RPL Instances, > and it may act as a router in some and as a leaf in others[1], for > this reason it does not make sense to me sending packet from one > RPLInstance to other RPLInstance. Besides the control messages has one > field for RPLInstanceID, it does not have RPLInstanceID origen or > RPLInstanceID dst. > > What do you think? > > Thank you, > > Ines > > [1] RFC6550. Section 5. RFC 6550 describes only how a single instance > behaves > > 2016-05-24 12:17 GMT+03:00 peter van der Stok : > >> I also did not see a mapping of flow from one RPL instance to >> another instance. >> >> I do not understand this. Could you please clarify? > > A node belonging to one RPL instance sends a message to a node > belonging to another RPL instance. > This seems possible in Figure 3, with 3 RPL instances? > > If possible, it means an additional use case. > > Peter From nobody Tue May 24 03:26:54 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A00A12DCD2 for ; Tue, 24 May 2016 03:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 LfF5THFZrsvF for ; Tue, 24 May 2016 03:26:51 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55FD12D0C3 for ; Tue, 24 May 2016 03:26:51 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id r140so15513564vkf.0 for ; Tue, 24 May 2016 03:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=HEGbbDKmpsQJPSGLXyDlV4VuwiE94cwaQc6wRXxcJPg=; b=xuG8XR2uz3z50WDzoK3k4tqtEy605aRYUl5yvzBZ040Uesmn76q4ekRTkCAO/qcTYh g11zhmprYM3AmyEBBSU3YzMoN0wyfGL80tFiUrCf5BbIVxSFlTzhPVaZDSTqNknzBSEd 2JuQeJhDBHIVPvwB50wfI82aVmG9vRm4OB9lv13jeK+oF5BpoCVnRGM+A+gCk4XfGuKK mFj2MsmGFtMyYjnl0zBQ/XTjLtpGrLS5kAT/8CiwSnnkUxClVSiScOvQ5FeHDGqMacVn KSmQdSVhE2CwIs7k/PhyBEM4lc+z2SdblTrdZKXM6eajNACIoT1Oxb5wefzDbAiJ8djq JClg== 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; bh=HEGbbDKmpsQJPSGLXyDlV4VuwiE94cwaQc6wRXxcJPg=; b=LiF0VQK2spSL+OjoDXm497ckD+R8T5yLXfCwV05SMPZgeO5SFK0sVECihOX4WaOqim hCLD8nByQ6AK9s6x74XXtfkMN/Z9UV5XbHpfgLBQLml7kf3Aof9zSUMihAFo1rJp808E mbClboycGUOk8a0vBDJJOElPkb3+DgFIsm4ycInFxvgFnXvg9ocgMB5hFzJ7B1Z6e+ha /XHfoPQbZBV0b1PYdDiI7WvUmGH3CRoSebJQHcvyPryc8rQiyUu8m/A3+czvFeBqQ89W 6wpAVbxDHIv97xX34UOVzCb1YalT3lmaJf8k7FwIQBPAcVRbcf7d2q+oK5dOXXGN6Ftg rqSQ== X-Gm-Message-State: ALyK8tJQODPz/CAfvTeD3XDIvAW2fvcfdUKEpOSCulpuEoZjNk/mm/cIBPH8a2dOsfk2MslA97UVbIJxRQ+kIA== MIME-Version: 1.0 X-Received: by 10.159.36.86 with SMTP id 80mr1983295uaq.71.1464085610861; Tue, 24 May 2016 03:26:50 -0700 (PDT) Received: by 10.159.37.98 with HTTP; Tue, 24 May 2016 03:26:50 -0700 (PDT) In-Reply-To: <1747ba1478659868c3b715ff8b807c6c@xs4all.nl> References: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl> <1747ba1478659868c3b715ff8b807c6c@xs4all.nl> Date: Tue, 24 May 2016 13:26:50 +0300 Message-ID: From: Ines Robles To: "consultancy@vanderstok.org" Content-Type: multipart/alternative; boundary=001a11495c50c19cda053393fe0a Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] RPLinfo review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 24 May 2016 10:26:53 -0000 --001a11495c50c19cda053393fe0a Content-Type: text/plain; charset=UTF-8 Ah, got it, thank you very much. Ines 2016-05-24 13:22 GMT+03:00 peter van der Stok : > Hi, > > that means writing "one RPL instance" in figure 3 in stead of "RPL > instance" to remove that ambiguity. > Writing in the use case section a phrase as the one below will be more > than sufficient for me. > > peter > > Ines Robles schreef op 2016-05-24 12:16: > > Hi, >> >> Thanks for the clarification. >> >> We are just considering here one RPLInstance. >> >> Working with different RPLInstances, involves deeply analysis, which >> we could do in the future. But, actually I dont know if it is >> possible/useful to send a message from one RPL Instance to another one >> , since for example a RPL node may belong to multiple RPL Instances, >> and it may act as a router in some and as a leaf in others[1], for >> this reason it does not make sense to me sending packet from one >> RPLInstance to other RPLInstance. Besides the control messages has one >> field for RPLInstanceID, it does not have RPLInstanceID origen or >> RPLInstanceID dst. >> >> What do you think? >> >> Thank you, >> >> Ines >> >> [1] RFC6550. Section 5. RFC 6550 describes only how a single instance >> behaves >> >> 2016-05-24 12:17 GMT+03:00 peter van der Stok : >> >> I also did not see a mapping of flow from one RPL instance to >>> another instance. >>> >>> I do not understand this. Could you please clarify? >>> >> >> A node belonging to one RPL instance sends a message to a node >> belonging to another RPL instance. >> This seems possible in Figure 3, with 3 RPL instances? >> >> If possible, it means an additional use case. >> >> Peter >> > --001a11495c50c19cda053393fe0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, got it, thank you very much.

Ines

2016-05= -24 13:22 GMT+03:00 peter van der Stok <stokcons@xs4all.nl>= :
Hi,

that means writing "one RPL instance" in figure 3 in stead of &qu= ot;RPL instance" to remove that ambiguity.
Writing in the use case section a phrase as the one below will be more than= sufficient for me.

peter

Ines=C2=A0 Robles schreef op 2016-05-24 12:16:

Hi,

Thanks for the clarification.

We are just considering here one RPLInstance.

Working with different RPLInstances, involves deeply analysis, which
we could do in the future. But, actually I dont know if it is
possible/useful to send a message from one RPL Instance to another one
, since for example a RPL node may belong to multiple RPL Instances,
and it may act as a router in some and as a leaf in others[1], for
this reason it does not make sense to me sending packet from one
RPLInstance to other RPLInstance. Besides the control messages has one
field for RPLInstanceID, it does not have RPLInstanceID origen or
RPLInstanceID dst.

What do you think?

Thank you,

Ines

[1] RFC6550. Section 5. RFC 6550 describes only how a single instance
behaves

2016-05-24 12:17 GMT+03:00 peter van der Stok <stokcons@xs4all.nl>:

I also did not see a mapping of flow from one RPL instance to
another instance.

I do not understand this. Could you please clarify?

=C2=A0A node belonging to one RPL instance sends a message to a node
belonging to another RPL instance.
This seems possible in Figure 3, with 3 RPL instances?

If possible, it means an additional use case.

Peter

--001a11495c50c19cda053393fe0a-- From nobody Tue May 24 03:43:01 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C66012D8E1 for ; Tue, 24 May 2016 03:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 cYnLOeu83gBG for ; Tue, 24 May 2016 03:42:59 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6942A12DCD3 for ; Tue, 24 May 2016 03:42:58 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id r140so15942532vkf.0 for ; Tue, 24 May 2016 03:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xKINg5b2UxEGx14pVs4uAPiAJN20IDw+HpjpiMntfDg=; b=Z2adDuC9vFfQ7ayKcR3b8JLQFilsn2/5TEeJpFDSMraQuG43MO2yhrud2hUv4JRoBQ DBYMuci0uiCgkuiGHs+rSkcaJxfnP0cwZERWK0zy3U932LYCAFb/Sj54kPWR4rGkfX0/ Kgx4qN0gORFUaMvnlmlqog6B3sDmCB8fkqaSXCQuUFQPy2hHyd3AjDxVeUwogyTXuqQ5 pLqWln1CaTWsLNUjGqt9I1T1akHsyp9SE900iiPZoX/0K5i/0cJwupL9VNDzUd+J857g 7yKXGZpdgyRqoXo8JssyjGNqLw1BaRJItFU4kt7jcjRRMmrky74+a9ajQiAaGcCqu1AB iUMA== 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; bh=xKINg5b2UxEGx14pVs4uAPiAJN20IDw+HpjpiMntfDg=; b=FxieO3CBNLTrhfGQjyDOLDGexUMEu14YVP6G2s47Ih0zpTRv3Nwk+NFC7zZSqJP2xd GxFvqmMk37TD/dQzzfUMGgUcWSC9HPLukNc5rTBSqLifWhMsgCPmj4CUdF337hLHULua LjlHotCHwk0PzDwf5ndcOPHpTzaUs+uNYr9c4RIqUuWfvBh4C49W9udNLFUw727JHH76 N+Q7CO2uRB2B97H0V3mtyT5sOv0LNF3dVXv0m/RNgCW/DgfrL1GAiA0PqEwsCBV258iq WCKJ2mo8Q8IAP0EmhaUd38opJywUhq5k1+uYDV+a5Pn3fmWr/PnKKGpjNZwqKobzKz51 ufjw== X-Gm-Message-State: ALyK8tIbgfsOPQnY/Mv6Tm9ro41Nphh4SznMgV7xbhzm18v0NK16QzXD7CiM7v95aAy+zml5oh2KdyltBYF5kw== MIME-Version: 1.0 X-Received: by 10.159.40.225 with SMTP id d88mr2099082uad.73.1464086577536; Tue, 24 May 2016 03:42:57 -0700 (PDT) Received: by 10.159.37.98 with HTTP; Tue, 24 May 2016 03:42:57 -0700 (PDT) In-Reply-To: References: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl> <1747ba1478659868c3b715ff8b807c6c@xs4all.nl> Date: Tue, 24 May 2016 13:42:57 +0300 Message-ID: From: Ines Robles To: "consultancy@vanderstok.org" Content-Type: multipart/alternative; boundary=94eb2c122be85fe8a50533943860 Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] RPLinfo review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 24 May 2016 10:43:01 -0000 --94eb2c122be85fe8a50533943860 Content-Type: text/plain; charset=UTF-8 btw, I just found a proposed approach for interaction between RPL Instances Barcelo, Marc, Alejandro Correa, Jose Lopez Vicario, and Antoni Morell. "Cooperative interaction among multiple RPL instances in wireless sensor networks." *Computer Communications* (2015). Cheers, Ines. 2016-05-24 13:26 GMT+03:00 Ines Robles : > Ah, got it, thank you very much. > > Ines > > 2016-05-24 13:22 GMT+03:00 peter van der Stok : > >> Hi, >> >> that means writing "one RPL instance" in figure 3 in stead of "RPL >> instance" to remove that ambiguity. >> Writing in the use case section a phrase as the one below will be more >> than sufficient for me. >> >> peter >> >> Ines Robles schreef op 2016-05-24 12:16: >> >> Hi, >>> >>> Thanks for the clarification. >>> >>> We are just considering here one RPLInstance. >>> >>> Working with different RPLInstances, involves deeply analysis, which >>> we could do in the future. But, actually I dont know if it is >>> possible/useful to send a message from one RPL Instance to another one >>> , since for example a RPL node may belong to multiple RPL Instances, >>> and it may act as a router in some and as a leaf in others[1], for >>> this reason it does not make sense to me sending packet from one >>> RPLInstance to other RPLInstance. Besides the control messages has one >>> field for RPLInstanceID, it does not have RPLInstanceID origen or >>> RPLInstanceID dst. >>> >>> What do you think? >>> >>> Thank you, >>> >>> Ines >>> >>> [1] RFC6550. Section 5. RFC 6550 describes only how a single instance >>> behaves >>> >>> 2016-05-24 12:17 GMT+03:00 peter van der Stok : >>> >>> I also did not see a mapping of flow from one RPL instance to >>>> another instance. >>>> >>>> I do not understand this. Could you please clarify? >>>> >>> >>> A node belonging to one RPL instance sends a message to a node >>> belonging to another RPL instance. >>> This seems possible in Figure 3, with 3 RPL instances? >>> >>> If possible, it means an additional use case. >>> >>> Peter >>> >> > --94eb2c122be85fe8a50533943860 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
btw, I just found a proposed approach for interaction betw= een RPL Instances

Barcelo, Marc, Alejand= ro Correa, Jose Lopez Vicario, and Antoni Morell. "Cooperative interac= tion among multiple RPL instances in wireless sensor networks."=C2=A0<= /span>Computer Communications=C2=A0(2015).=

Cheers,

Ines.

2016-05-24 13:26 GMT+03:00 Ines Robles <<= a href=3D"mailto:mariainesrobles@googlemail.com" target=3D"_blank">mariaine= srobles@googlemail.com>:
Ah, got it, thank you very much.

Ines

2016-05-24 13:22 GMT+03:00 peter van der Stok <stokcons@= xs4all.nl>:
Hi,

that means writing "one RPL instance" in figure 3 in stead of &qu= ot;RPL instance" to remove that ambiguity.
Writing in the use case section a phrase as the one below will be more than= sufficient for me.

peter

Ines=C2=A0 Robles schreef op 2016-05-24 12:16:

Hi,

Thanks for the clarification.

We are just considering here one RPLInstance.

Working with different RPLInstances, involves deeply analysis, which
we could do in the future. But, actually I dont know if it is
possible/useful to send a message from one RPL Instance to another one
, since for example a RPL node may belong to multiple RPL Instances,
and it may act as a router in some and as a leaf in others[1], for
this reason it does not make sense to me sending packet from one
RPLInstance to other RPLInstance. Besides the control messages has one
field for RPLInstanceID, it does not have RPLInstanceID origen or
RPLInstanceID dst.

What do you think?

Thank you,

Ines

[1] RFC6550. Section 5. RFC 6550 describes only how a single instance
behaves

2016-05-24 12:17 GMT+03:00 peter van der Stok <stokcons@xs4all.nl>:

I also did not see a mapping of flow from one RPL instance to
another instance.

I do not understand this. Could you please clarify?

=C2=A0A node belonging to one RPL instance sends a message to a node
belonging to another RPL instance.
This seems possible in Figure 3, with 3 RPL instances?

If possible, it means an additional use case.

Peter


--94eb2c122be85fe8a50533943860-- From nobody Wed May 25 12:43:49 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDF412DC53 for ; Wed, 25 May 2016 12:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 uP2Coex2JqQI for ; Wed, 25 May 2016 12:43:45 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 103FA12DC07 for ; Wed, 25 May 2016 12:43:02 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 0776423CAB3 for ; Wed, 25 May 2016 14:12:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0GDg8iy0YFH for ; Wed, 25 May 2016 14:12:40 -0500 (CDT) Received: from it.cs.uh.edu (unknown [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id CCA2B23CAB1 for ; Wed, 25 May 2016 14:12:40 -0500 (CDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) by it.cs.uh.edu (Postfix) with ESMTP id 1AA992A280BD for ; Wed, 25 May 2016 14:59:15 -0500 (CDT) Received: by mail-ig0-f172.google.com with SMTP id fh2so34154066igd.1 for ; Wed, 25 May 2016 12:12:40 -0700 (PDT) X-Gm-Message-State: ALyK8tLvOQqCdI0FuDk1TIempQrHoYbPQjVFEvau7ydieKnjB4OPUWkqOSEr9pDMgvvwI/etS8e5dbS85yC5Ng== X-Received: by 10.50.56.13 with SMTP id w13mr5182627igp.19.1464203560335; Wed, 25 May 2016 12:12:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.8.157 with HTTP; Wed, 25 May 2016 12:12:20 -0700 (PDT) From: Omprakash Gnawali Date: Wed, 25 May 2016 14:12:20 -0500 X-Gmail-Original-Message-ID: Message-ID: To: ROLL Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Roll] CFP EWSN 2017 Deadline 19 Sept 2016 Intl Conf Embedded Wireless Systems & Networks X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 25 May 2016 19:43:48 -0000 Dear all, Please see below the Call for Papers for International Conference on Embedded Wireless Systems and Networks (EWSN) 2017. We look forward to your paper submissions. - om_p --- -*= International Conference on Embedded Wireless Systems and Networks (EWSN) =*- Uppsala, Sweden, February 20-22, 2017 http://www.ewsn2017.org/ *Call for Papers* The International Conference on Embedded Wireless Systems and Networks (EWSN) is a highly selective single-track international conference focusing on premier research results at the intersection of embedded systems and wireless networking - an area of highest relevance for visionary technologies such as the Internet of Things and Cyber-Physical Systems as well as applications such as Industry 4.0, Smart Production, Smart Cities, and Connected Cars. The featured topic of the 2017 edition of EWSN is dependability in systems such as Cyber-Physical Systems, Internet of Things, industrial wireless control networks, smart vehicles, and robots. We specifically welcome contributions that aim at making these systems more reliable, predictable, safe, and secure to enable critical applications that require guaranteed performance. Topics not related to dependability are equally welcome as long as they fall into scope of the conference, as described below. The conference solicits both full technical papers, and short papers describing validated early ideas. As it happened for EWSN 2016, we will be seeking collaboration with and support from ACM/SIGBED and plan to make the proceedings appear in the ACM digital library. New this year is that a specialized committee will select a subset of the papers appearing at the conference to be fast-tracked to ACM Transactions on Sensor Networks. EWSN 2017 welcomes contributions describing original ideas, promising new concepts, and practical experiences (experimental validation, rebuttal, and/or comparison of existing approaches) in all relevant areas of networked embedded systems such as Internet of Things, Cyber-Physical Systems, and Wireless Sensor Networks and their applications in domains such as Smart Cities, Industry 4.0 and Smart Factories, Smart Cars, and Smart Health. Specific topics of interest include but are not limited to: Dependability (real-time, reliability, availability, safety, security) Embedded wireless networking from physical to application layer Wireless embedded computing platforms Operating systems, middleware, and services Programming paradigms, languages, and tools Distributed and embedded computing for networked systems Applications, deployment, management, and debugging Sensing and actuation Networked embedded sensing in robots and drones Mobility, localization, tracking Embedded data management and processing Interaction with humans Cloud, back-end integration, and analytics Please ask the program chairs if you are uncertain if your topic fits. *Submission instructions* EWSN 2017 is a highly selective conference. We will only accept for review original papers that have not been previously published and are not currently under review by any other conference or journal. We will adopt a double-blind review process, where the names of authors and their affiliations are unknown to reviewers until the end of the review process. We will also provide authors the possibility of a rebuttal before final decisions are made. Full paper submissions must have at least 8 and at most 12 pages. Short paper submissions must have at least 4 and at most 6 pages. Pages must have 8.5" x 11" (letter) two-column format, using 10-point type on 11-point leading, with a maximum text block of 7" wide x 9" deep with an inter-column spacing of .25". The page limits include figures, tables, and references. Authors must make a good faith effort to anonymize their submissions such that the author identities are not disclosed to the reviewers. Papers that do not meet the size, formatting, and anonymization requirements may not be reviewed. *Important dates* Paper registration: September 12th, 2016 Paper submission: September 19th, 2016 Authors rebuttal deadline: November 19th, 2016 Notification: December 1st, 2016 Camera-ready: December 21st, 2016 From nobody Fri May 27 06:50:48 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2821B12B019 for ; Fri, 27 May 2016 06:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 O3C-yVX5X5hw for ; Fri, 27 May 2016 06:50:44 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2814712D19B for ; Fri, 27 May 2016 06:50:44 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.203]) by smtp-cloud6.xs4all.net with ESMTP id zRqg1s00D4NtgTm01RqgXy; Fri, 27 May 2016 15:50:42 +0200 Received: from AMontpellier-654-1-65-44.w90-0.abo.wanadoo.fr ([90.0.40.44]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 27 May 2016 15:50:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2016 15:50:40 +0200 From: peter van der Stok To: Roll Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl (mbkOwdxryLtSlX5vMbGQ+2FDbqRGFIlp) User-Agent: XS4ALL Webmail Archived-At: Subject: [Roll] Distribution of Call for papers on the ROLL mailing list. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 13:50:47 -0000 Hi all, Ines and I think that the ROLL mailing list should be used for ROLL subjects such as discussions of drafts and ROLL related topics. We do not think that the sending of CfP for conferences, workshops, or Journals, independent of their relevance or quality, is to be encouraged. When you want to use the ROLL mailing list for the distribution of not-directly-ROLL-related information, please ask the permission of the co-chairs. The probability that we will authorize the distribution is really low. We think it is good policy, to impose this authorization rule, to reduce the amount of unwanted information received by the ROLL WG members many thanks for your understanding, Ines and Peter -- Peter van der Stok vanderstok consultancy From nobody Mon May 30 19:52:45 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D866712D145 for ; Mon, 30 May 2016 19:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vh1xiraRtVpK for ; Mon, 30 May 2016 19:52:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02B012D12C for ; Mon, 30 May 2016 19:52:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ECF4F2009E; Mon, 30 May 2016 22:59:21 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8FC98638BE; Mon, 30 May 2016 22:52:41 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Subject: Re: [Roll] RPLinfo review X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 31 May 2016 02:52:45 -0000 --=-=-= Content-Type: text/plain Ines Robles wrote: > Thanks for the clarification. > We are just considering here one RPLInstance. > Working with different RPLInstances, involves deeply analysis, which we > could do in the future. But, actually I dont know if it is In general, you have to leave one instance (popping all artifacts as if going out to the Internet), and then enter the new instance. It matters not if these are two RPLinstances (by instanceID), or two different LLNs seperated by the Internet. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV0z8doCLcPvd0N1lAQIdpwf/dE9pbBNEEZqnOZ3REpavQK90cVP/jnmJ FvED9kuvX0ix5IlCiEyAq6YeFQ+lwum3Sq53Jw05S/eyXaMCLfV3uOJlIDk+kQVq jNaKlkQoniwtYrqdbP2DB0mUUzgIalSafRwjSiAXGEYb9A6gjRtAE2vqDKB8M9Pg fURH3c3vsHkbK6YhVdvST4jHlxJMCK/yI+k2j5LHgwrkdY6Pu3TL2yR4ndLwElUU ea3gbTLUBi/vZdLR+GV6BGv2dec++8Dkj3gIAv8XMfdyqKvCxuo3UsMbRpDT9L2X gAnF95jCMzvubKtaofDA50+4l2CD2AljGYgeV1kkhIeEGvdszZPwYw== =vID2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 31 08:24:18 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE43F12D600 for ; Tue, 31 May 2016 08:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Y0AT3GM-Mr8W for ; Tue, 31 May 2016 08:24:15 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9687A12D7CC for ; Tue, 31 May 2016 08:24:14 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id n129so113058219wmn.1 for ; Tue, 31 May 2016 08:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=ZIuyqfn9s8b4r7PerQJysV7seE9O/U3r0rFFV/VUiLI=; b=dqXqvFPpJLDNPp882jXnPEXbMSwanuImVQlaNlA/s+nQSkLvcv3TiSK3ob+GCdCk8b ZjA+7QnjFappQUUINuJCg6h96MdtWsjLYnkh0oHN1J5zJ1usvhU2lZDtXaoWs0SfFuxw LpMI/M/jEf9/Bk9TthRBXPfKhN7wGy/EJK3V6fB8HlTdTIJvg7LVSfb1cspJNA8psPxR JdTIWQyGWAZiXcvg3Aeisp1EchzSJzBbK90omt5e29hc0c/RwQ3uwsrvd7cn/Ou/Cqks MA14bYQzPTLADLHrr1Fhdoxobi3S3TpHPvnB0CcXLqIrJbet4buI/qQkMTEE6ecAY2OQ yZWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=ZIuyqfn9s8b4r7PerQJysV7seE9O/U3r0rFFV/VUiLI=; b=RzpMHDQt92D/Hzac15fgr+yW40vLBT96mAQdVxvyHm5xqkKi0FO/KGigUuUO2s6BDw wOejk7epE2SbbecP0LZfDGsn2aOXiEe0GYKK9K26rf2aYHHMge9mnhBO8EZ5EHWsj+Eg hgIV46nqPkHmNaTmjNMtLcZFBOmzgHlQXDf+mJGhpqAeA8GgfsB1P1+1gLSsF4XmA0ZS Lb7ybM/ogdghMXfEHfsgGmvurpmt+MKciRn624Qjflwokp9RdfUPGtJRior7Bavoj7jF GV22rng4Bi3opbQIYQx21gmVFmU0ma2WzuwLp07r0n4thdF0+PKvo/IrioorsdvGhLyI 0SPA== X-Gm-Message-State: ALyK8tL0EKE6MIdlTuAKnRuifO76w1xr1ttpUadH4W2Dx/eVRGJNRzU5u8wHIVN+vxmoFg== X-Received: by 10.28.21.204 with SMTP id 195mr6474061wmv.64.1464708253103; Tue, 31 May 2016 08:24:13 -0700 (PDT) Received: from [10.92.124.3] (z5c7c.pia.fu-berlin.de. [87.77.92.124]) by smtp.googlemail.com with ESMTPSA id f1sm29139659wmf.22.2016.05.31.08.24.12 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2016 08:24:12 -0700 (PDT) To: Routing Over Low power and Lossy networks From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= Message-ID: Date: Tue, 31 May 2016 17:22:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Roll] P2P-RPL (RFC6997) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.17 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, 31 May 2016 15:24:17 -0000 Dear Roll and authors of RFC6997, I would like to bring to your attention that I provided an open source implementation of P2P-RPL (RFC6997) a while back, supporting a minimal set of the specified functionalities. (Currently, only supporting the reactive discovery of hop-by-hop routes, not source routes). The implementation resides in RIOT's [1,2] network stack and I plan to continue working on / fleshing out the implementation probably in late summer. As I also implemented and contributed the dissector to parse P2P-RPL control traffic for wireshark, I would actually like to test my understanding of P2P-RPL against different implementations. Is anybody aware of another implementation that I can test interop. against? Thanks! Best, Cenk [1] http://riot-os.org/ [2] https://github.com/RIOT-OS/RIOT