From roll-bounces@ietf.org Thu May 8 16:12:14 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EB873A6F11; Thu, 8 May 2008 16:12:14 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AF503A6F11 for ; Thu, 8 May 2008 16:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8CR1MHcHIJ7 for ; Thu, 8 May 2008 16:12:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 410473A6ED2 for ; Thu, 8 May 2008 16:12:11 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 08 May 2008 16:12:09 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m48NC9Qv018116 for ; Thu, 8 May 2008 16:12:09 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m48NC8mO000616 for ; Thu, 8 May 2008 23:12:09 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 May 2008 19:12:08 -0400 Received: from 10.86.104.178 ([10.86.104.178]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 May 2008 23:12:08 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Thu, 08 May 2008 19:12:04 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: I-D ACTION:draft-levis-roll-protocols-survey-00.txt Thread-Index: AcixYO2F/DZN3eCNm0SsjVoFCH4wBw== In-Reply-To: <20080508220001.57C1328C2F6@core3.amsl.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3293118726_32152989" X-OriginalArrivalTime: 08 May 2008 23:12:08.0771 (UTC) FILETIME=[F05DB930:01C8B160] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2794; t=1210288329; x=1211152329; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20FW=3A=20I-D=20ACTION=3Adraft-levis-roll-protoco ls-survey-00.txt=20 |Sender:=20; bh=ITXdqmhXtUtipfKUTJm23MbKQvkF9KKkYcyPaNUMaP4=; b=bK2nDsYbd+AFahcm421u8L2LP+MiIAjYvv0vHFVL+pkaEqsprNvhvONAQv IDZrQ5b7CgQ7J5u8zo8Td1NR0+dNELordGUhxv5gujwqMye93DZZt/m9zc5d wRzgPeWaSD; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Roll] FW: I-D ACTION:draft-levis-roll-protocols-survey-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3293118726_32152989 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit No change other than the name of the document. We're planning to have a major revision before Dublin. Thanks. JP. ------ Forwarded Message From: Reply-To: Date: Thu, 8 May 2008 15:00:01 -0700 (PDT) To: Subject: I-D ACTION:draft-levis-roll-protocols-survey-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Overview of Existing Routing Protocols for Low Power and Lossy Networks Author(s) : P. Levis, J. Vasseur, D. Culler Filename : draft-levis-roll-protocols-survey-00.txt Pages : 23 Date : 2008-5-6 Networks of low power wireless devices introduce novel IP routing issues. Low-power wireless devices, such as sensors, actuators and smart objects, have difficult constraints: very limited memory, little processing power, and long sleep periods. As most of these devices are battery-powered, energy efficiency is critically important. Wireless link qualities can vary significantly over time, requiring protocols to make agile decisions yet minimize topology change energy costs. Such low power and lossy networks (L2Ns) have routing requirements that existing mesh protocols only partially address. This document provides a brief survey of the strengths and weaknesses of existing protocols with respect to L2Ns. It provides guidance on how lessons from existing and prior efforts can be leveraged in future protocol design. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------ End of Forwarded Message --B_3293118726_32152989 Content-type: application/octet-stream; name="draft-levis-roll-protocols-survey-00.txt" Content-disposition: attachment; filename="draft-levis-roll-protocols-survey-00.txt" Content-transfer-encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA4LTUtODE0NTkzMC5J LURAaWV0Zi5vcmc+DQ0= --B_3293118726_32152989 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --B_3293118726_32152989-- From roll-bounces@ietf.org Thu May 15 07:04:50 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D225D3A695F; Thu, 15 May 2008 07:04:48 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386D63A695F for ; Thu, 15 May 2008 07:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.997 X-Spam-Level: X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwNVhMynxMyR for ; Thu, 15 May 2008 07:04:29 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id 713413A6940 for ; Thu, 15 May 2008 07:04:24 -0700 (PDT) Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 May 2008 16:03:42 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 May 2008 16:03:42 +0200 Received: from GRFMBX706BA020.griffon.local ([10.188.101.19]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Thu, 15 May 2008 16:03:41 +0200 From: Porcu Giorgio To: "roll@ietf.org" Date: Thu, 15 May 2008 16:03:40 +0200 Thread-Topic: Version 01 of draft-brandt-roll-home-routing-reqs posted Thread-Index: AQHItpR66zu5QMELiEGc0C3cqa4IWA== Message-ID: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US MIME-Version: 1.0 X-OriginalArrivalTime: 15 May 2008 14:03:42.0384 (UTC) FILETIME=[7B85CB00:01C8B694] Subject: [Roll] Version 01 of draft-brandt-roll-home-routing-reqs posted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Gentlemen, A new version of the home control draft has been published. Changes from version 00: * Removed MUST, SHOULD, etc. from use case sections * Removed requirements statements that were stronger than needed * Added section on health care * Added section on alarm systems; merged with previous section on networked smoke alarms * Tried to get rid of the term "constrained" after objections from routing gurus in Philadelphia More remains to be done on this task. * Various editorial clarifications * Added co-author Giorgio Porcu, Telecom Italia - welcome! br. Anders Brandt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 15 13:41:52 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195253A68C3; Thu, 15 May 2008 13:41:52 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB833A688B for ; Thu, 15 May 2008 13:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.283 X-Spam-Level: X-Spam-Status: No, score=-5.283 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia5c308ifb4v for ; Thu, 15 May 2008 13:41:48 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6270C3A684C for ; Thu, 15 May 2008 13:41:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,493,1204531200"; d="scan'208,217";a="47303590" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 15 May 2008 13:41:43 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m4FKfhGa010028 for ; Thu, 15 May 2008 13:41:43 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4FKfVTu021715 for ; Thu, 15 May 2008 20:41:43 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 May 2008 16:41:37 -0400 Received: from 10.86.104.179 ([10.86.104.179]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 May 2008 20:41:37 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Thu, 15 May 2008 16:41:36 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? Thread-Index: Aci2zBFOkmEiPwCzpUuia/ew5usrXQ== Mime-version: 1.0 X-OriginalArrivalTime: 15 May 2008 20:41:37.0462 (UTC) FILETIME=[122D9560:01C8B6CC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1078; t=1210884103; x=1211748103; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Adoption=20of=20draft-brandt-roll-home-routing- reqs=20as=20a=20ROLL=20WG=20document=0A=20? |Sender:=20; bh=hXVjL0tPJe1QmVyR9rKnOo4QNfV0XiIWV3VoyyNuKrw=; b=r5j/oeMu2OPRgG/5jjQvdzqn8GYn4ylXDzHJ6ItrPJeBBdScZ31206cBWf emKQE3ZeJaw2iT8sRC5Tq+x2KqC4RNxJEyPqAQCo87NLcVIEyZHH8JJT6wOU 7xyT3wLjUL; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1887017787==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1887017787== Content-type: multipart/alternative; boundary="B_3293714497_47322389" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3293714497_47322389 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-01.t xt as a ROLL WG document ? Thanks. JP. --B_3293714497_47322389 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG documen= t ? Dear WG,

Do you support the adoption of http://www.ietf.org/internet-dr= afts/draft-brandt-roll-home-routing-reqs-01.txt as a ROLL WG document ?<= BR>
Thanks.

JP. --B_3293714497_47322389-- --===============1887017787== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1887017787==-- From roll-bounces@ietf.org Thu May 15 15:23:45 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206773A6882; Thu, 15 May 2008 15:23:45 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28F363A681B for ; Thu, 15 May 2008 15:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajSJBUaNoX9f for ; Thu, 15 May 2008 15:23:33 -0700 (PDT) Received: from auswood.securesites.net (auswood.securesites.net [128.121.62.173]) by core3.amsl.com (Postfix) with ESMTP id 540A83A6A96 for ; Thu, 15 May 2008 15:22:21 -0700 (PDT) Received: from [192.168.1.2] (dsl081-241-245.sfo1.dsl.speakeasy.net [64.81.241.245]) (authenticated bits=0) by auswood.securesites.net (8.13.6.20060614/8.13.6) with ESMTP id m4FMMBT3065330; Thu, 15 May 2008 22:22:11 GMT Message-Id: <2AB78622-C686-4431-A794-6EF5A28CB561@daintree.net> From: Zachary Smith To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 15 May 2008 15:22:05 -0700 References: X-Mailer: Apple Mail (2.919.2) Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1932583424==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1932583424== Content-Type: multipart/alternative; boundary=Apple-Mail-1-654691540 --Apple-Mail-1-654691540 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Yes, Although there is a point that probably bears discussion. In a multi- application network with sleeping end devices and resource-constrained routers, there is an end device management problem that is related to routing and might be considered as part of the routing solution. In short, it doesn't really make sense to rely on nearby routers to buffer arbitrary traffic for sleeping end devices. There are a number of possible solutions to this problem and not all of them involve the network layer but, if we are talking about "resource aware" routing then we might want to put in a requirement or two around this. My $0.02US, z On May 15, 2008, at 1:41 PM, JP Vasseur wrote: > Dear WG, > > Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-01.txt > as a ROLL WG document ? > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll Zachary Smith - CTO http://www.daintree.net/ zsmith@daintree.net --Apple-Mail-1-654691540 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

My = $0.02US,

  z

On= May 15, 2008, at 1:41 PM, JP Vasseur wrote:

= Dear WG,

Do you support the adoption = of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-r= outing-reqs-01.txt as a ROLL WG document ?

Thanks.

= JP.
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

Zachary Smith - = CTO
<= a = href=3D"mailto:zsmith@daintree.net">zsmith@daintree.net


 =

= --Apple-Mail-1-654691540-- --===============1932583424== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1932583424==-- From roll-bounces@ietf.org Thu May 15 15:46:52 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2143A6821; Thu, 15 May 2008 15:46:52 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344D03A6821 for ; Thu, 15 May 2008 15:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.222 X-Spam-Level: X-Spam-Status: No, score=-5.222 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eOmCEF8puEL for ; Thu, 15 May 2008 15:46:50 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CA95D3A67A3 for ; Thu, 15 May 2008 15:46:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,493,1204520400"; d="scan'208,217";a="8386466" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 May 2008 18:46:44 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4FMki7a019263; Thu, 15 May 2008 18:46:44 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4FMkiCO015935; Thu, 15 May 2008 22:46:44 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 May 2008 18:46:44 -0400 Received: from 10.86.104.179 ([10.86.104.179]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 May 2008 22:46:43 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Thu, 15 May 2008 18:46:40 -0400 From: JP Vasseur To: Zachary Smith Message-ID: Thread-Topic: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? Thread-Index: Aci23YoKjgog+RtsLky7lRE3k3mh4g== In-Reply-To: <2AB78622-C686-4431-A794-6EF5A28CB561@daintree.net> Mime-version: 1.0 X-OriginalArrivalTime: 15 May 2008 22:46:44.0486 (UTC) FILETIME=[8CB68A60:01C8B6DD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4642; t=1210891604; x=1211755604; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Adoption=20of=20draft-brandt-r oll-home-routing-reqs=20as=20a=20ROLL=0A=20WG=20document=20? |Sender:=20 |To:=20Zachary=20Smith=20; bh=OGAKesqo++mE4WCkKCxBCkVT4Vlo+I37Usj4W3vdiQk=; b=dzSwi1xdwFZpQ5dc9c6I7UCAvmY6OpKWB2liZO3Hi+KZiOr0iS3m5GlpUG jmzqN8L47swIbp6ukn91X7Js2B4D1uC4ysnveAd+kW7JzPykOtHfI7VXdPiV 7Y0NAWsZbV; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0634226460==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0634226460== Content-type: multipart/alternative; boundary="B_3293722003_47794537" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3293722003_47794537 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thanks for your reply. ps: that gives me the opportunity to clarify one thing though: by all means, adopting a document as a WG document does not mean that the document is ready for publication ! It just means that the WG agrees to take it as the base document to address a WG item. Thanks. JP. On 5/15/08 6:22 PM, "Zachary Smith" wrote: > Yes, > > Although there is a point that probably bears discussion. In a > multi-application network with sleeping end devices and resource-constrained > routers, there is an end device management problem that is related to routing > and might be considered as part of the routing solution. In short, it doesn't > really make sense to rely on nearby routers to buffer arbitrary traffic for > sleeping end devices. There are a number of possible solutions to this problem > and not all of them involve the network layer but, if we are talking about > "resource aware" routing then we might want to put in a requirement or two > around this. > > My $0.02US, > > z > > On May 15, 2008, at 1:41 PM, JP Vasseur wrote: > >> Dear WG, >> >> Do you support the adoption of >> http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-01.tx >> t as a ROLL WG document ? >> >> Thanks. >> >> JP. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> Zachary Smith - CTO >> http://www.daintree.net/ >> zsmith@daintree.net >> >> >> >> >> --B_3293722003_47794537 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL= WG document ? Thanks for your reply.

ps: that gives me the opportunity to clarify one thing though: by all means= , adopting a document as a WG document does not mean that the document is re= ady for publication ! It just means that the WG agrees to take it as = the base document to address a WG item.

Thanks.

JP.


On 5/15/08 6:22 PM, "Zachary Smith" <zsmith@daintree.net> w= rote:

Yes,

Although there is a point that probably bears discussion. In a multi-applic= ation network with sleeping end devices and resource-constrained routers, th= ere is an end device management problem that is related to routing and might= be considered as part of the routing solution. In short, it doesn't really = make sense to rely on nearby routers to buffer arbitrary traffic for sleepin= g end devices. There are a number of possible solutions to this problem and = not all of them involve the network layer but, if we are talking about "= ;resource aware" routing then we might want to put in a requirement or = two around this.

My $0.02US,

  z

On May 15, 2008, at 1:41 PM, JP Vasseur wrote:

Dear WG,
 
 Do you support the adoption of http://www.ietf.org/inter= net-drafts/draft-brandt-roll-home-routing-reqs-01.txt as a ROLL WG docum= ent ?
 
 Thanks.
 
 JP.
  _______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

 
= Zachary Smith - CTO
http://www.daintree.net/
zsmith@daintree.net


 


--B_3293722003_47794537-- --===============0634226460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0634226460==-- From roll-bounces@ietf.org Thu May 15 21:57:29 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9B73A6925; Thu, 15 May 2008 21:57:29 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D683A685E for ; Thu, 15 May 2008 21:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxUM1W1j9t+c for ; Thu, 15 May 2008 21:57:25 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 5C0573A682F for ; Thu, 15 May 2008 21:57:22 -0700 (PDT) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m4G4v0nk024825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 May 2008 21:57:01 -0700 (PDT) Message-ID: <482D149F.6000400@eecs.berkeley.edu> Date: Thu, 15 May 2008 21:59:11 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Yes. ksjp JP Vasseur wrote: > Dear WG, > > Do you support the adoption of > http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-01.txt > as a ROLL WG document ? > > Thanks. > > JP. > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 15 22:44:34 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5133A69E1; Thu, 15 May 2008 22:44:34 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE323A6850 for ; Thu, 15 May 2008 22:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MChPUmrRu5q4 for ; Thu, 15 May 2008 22:44:31 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 648363A67AA for ; Thu, 15 May 2008 22:44:31 -0700 (PDT) Received: from leo (postfix@leo.cttc.es [84.88.62.208]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id m4G5glbM017571 for ; Fri, 16 May 2008 07:42:47 +0200 Received: from CTTCPCMDOHLER (pcmdohler.cttc.es [84.88.61.89]) by leo (Postfix) with ESMTP id EEED810C026 for ; Fri, 16 May 2008 07:42:46 +0200 (CEST) From: "Mischa Dohler" To: Date: Fri, 16 May 2008 07:41:28 +0200 Organization: CTTC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aci2zBFOkmEiPwCzpUuia/ew5usrXQASmFMQ Message-Id: <20080516054246.EEED810C026@leo> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (leo); Fri, 16 May 2008 07:42:47 +0200 (CEST) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mischa.dohler@cttc.es List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0540672864==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0540672864== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01C8B728.4036D7D0" This is a multi-part message in MIME format. ------=_NextPart_000_0097_01C8B728.4036D7D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes. Mischa. _____ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Thursday, May 15, 2008 10:42 PM To: roll@ietf.org Subject: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? Dear WG, Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-01.t xt as a ROLL WG document ? Thanks. JP. ------=_NextPart_000_0097_01C8B728.4036D7D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG = document ?

Yes. Mischa.

 

From: = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = Behalf Of JP Vasseur
Sent: Thursday, May 15, = 2008 10:42 PM
To: roll@ietf.org
Subject: [Roll] Adoption = of draft-brandt-roll-home-routing-reqs as a ROLL WG document = ?

 

Dear WG,

Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home= -routing-reqs-01.txt as a ROLL WG document ?

Thanks.

JP.

------=_NextPart_000_0097_01C8B728.4036D7D0-- --===============0540672864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0540672864==-- From roll-bounces@ietf.org Fri May 16 01:18:35 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489843A68E7; Fri, 16 May 2008 01:18:35 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359AD3A68E7 for ; Fri, 16 May 2008 01:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHtF7artZg82 for ; Fri, 16 May 2008 01:18:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8E5CF28C166 for ; Fri, 16 May 2008 01:18:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,496,1204498800"; d="scan'208,217";a="9059144" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 May 2008 10:17:47 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4G8HlpR025952 for ; Fri, 16 May 2008 10:17:47 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4G8HkES016504 for ; Fri, 16 May 2008 08:17:47 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 May 2008 10:17:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 May 2008 10:17:46 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05AFD38C@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? Thread-Index: Aci2zBFOkmEiPwCzpUuia/ew5usrXQAX/YQQ References: From: "Pascal Thubert (pthubert)" To: "Jean Philippe Vasseur (jvasseur)" , X-OriginalArrivalTime: 16 May 2008 08:17:46.0903 (UTC) FILETIME=[52B47A70:01C8B72D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6364; t=1210925867; x=1211789867; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20Adoption=20of=20draft-brandt-r oll-home-routing-reqs=20as=20a=20ROLL=20WG=20document=20? |Sender:=20; bh=UvzRGpxUC4p2cFYhC+1oOnuhCbWHtspGri82rS72JSU=; b=sAG87cto8jUNP/2z11Oeyn7S2oBRAIungT0p6DFbn5SRzyr+8QIRerC5zY UZbp+y0HZLY3677CpGXRe80VBHaPSfLm6a3tZm3MqVvlswvDbJpVT1XbKcPS sp5RuDeYLx; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2086730287==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============2086730287== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B72D.5291C265" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B72D.5291C265 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this adoption. In particular, chapter 4 brings up requirement quite clearly. In the future, I'd like to see more about how the home routing interacts with the service provider and utilities networks for remote management and metering.=20 I'm counting on Giorgio for this, and I'd love to see if some power utility people have a word to say about this. =20 Pascal ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur (jvasseur) Sent: jeudi 15 mai 2008 22:42 To: roll@ietf.org Subject: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? =20 Dear WG, Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs- 01.txt as a ROLL WG document ? Thanks. JP.=20 ------_=_NextPart_001_01C8B72D.5291C265 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG = document ?

I support this = adoption.

In particular, chapter 4 brings up requirement quite clearly.

In the future, I’d like to = see more about how the home routing interacts with the service provider and = utilities networks for remote management and metering. =

I’m counting on Giorgio for = this, and I’d love to see if some power utility people have a word to = say about this.

 

Pascal

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe = Vasseur (jvasseur)
Sent: jeudi 15 mai 2008 = 22:42
To: roll@ietf.org
Subject: [Roll] Adoption = of draft-brandt-roll-home-routing-reqs as a ROLL WG document = ?

 

Dear WG,

Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home= -routing-reqs-01.txt as a ROLL WG document ?

Thanks.

JP.

------_=_NextPart_001_01C8B72D.5291C265-- --===============2086730287== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============2086730287==-- From roll-bounces@ietf.org Fri May 16 04:55:50 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6756728C170; Fri, 16 May 2008 04:55:50 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D1B3A6A3F; Fri, 16 May 2008 04:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42, SARE_SUB_OBFU_Q1=0.227, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfz5S+S885r0; Fri, 16 May 2008 04:55:41 -0700 (PDT) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 5AC0F3A67A1; Fri, 16 May 2008 04:55:41 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2008051613553781-12346 ; Fri, 16 May 2008 13:55:37 +0200 In-Reply-To: To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: pierre.colle@fr.schneider-electric.com Date: Fri, 16 May 2008 13:55:27 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 16/05/2008 13:55:35, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 05/16/2008 01:55:37 PM, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 05/16/2008 01:55:39 PM Cc: roll@ietf.org, roll-bounces@ietf.org Subject: [Roll] RE Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0454828816==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0454828816== Content-type: multipart/related; Boundary="0__=4EBBFED8DFD30A738f9e8a93df938690918c4EBBFED8DFD30A73" --0__=4EBBFED8DFD30A738f9e8a93df938690918c4EBBFED8DFD30A73 Content-type: multipart/alternative; Boundary="1__=4EBBFED8DFD30A738f9e8a93df938690918c4EBBFED8DFD30A73" --1__=4EBBFED8DFD30A738f9e8a93df938690918c4EBBFED8DFD30A73 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Hello, I still need to debrief with Nicolas Riou, but I support this document.= If possible, I think it could be nice to have an addition about QoS (probably not as a MUST, but maybe as a SHOULD). I think it would make sense to be able to manage different flow priorit= ies to guarantee latency or even saftety. For example, a lighting command should have a higher priority than an o= ver the air firmware upgrade or maybe video monitoring flow. As routers might have limited memory and might have to keep in memory s= ome messages (e.g fire alarm, health alarm), they should handle QoS. Best regards, Pierre Schneider-Electric - TIC / DInnov Technopole 38TEC T3 37 quai Paul-Louis Merlin FR - 38050 Grenoble Cedex 9 +33 (0)4 76 57 30 19 / 34 30 19 pierre.colle@schneider-electric.com = JP Vasseur = = A Envoy=E9 par : = roll-bounces@ietf = cc .org = Ob= jet [Roll] Adoption of = 15/05/2008 22:41 draft-brandt-roll-home-routing-r= eqs as a ROLL WG document ? = = = = = = = Dear WG, Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs= -01.txt as a ROLL WG document ? Thanks. JP. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll = --1__=4EBBFED8DFD30A738f9e8a93df938690918c4EBBFED8DFD30A73 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Hello,

I still need to debrief with Nicolas Riou, but I support this document.=

If possible, I think it could be nice to have an addition about QoS (pr= obably not as a MUST, but maybe as a SHOULD).
I think it would make sense to be able to manage different flow priorit= ies to guarantee latency or even saftety.
For example, a lighting command should have a higher priority than an o= ver the air firmware upgrade or maybe video monitoring flow.
As routers might have limited memory and might have to keep in memory s= ome messages (e.g fire alarm, health alarm), they should handle QoS.
Best regards,

Pierre
Schnei= der-Electric - TIC / DInnov
Technopole 38TEC T3
37 quai Paul-Louis Merlin
FR - 38050 Grenoble Cedex 9
+33 (0)4 76 57 30 19 / 34 30 19
pierre.coll= e@schneider-electric.com
3D""
3D"InactiveJP Vasseur <jvasseur@cisco.com>




=
          JP Vasseur <jvasseur@cisco.com>
          Envoy=E9 par : roll-bounces@ietf.org

          15/05/2008 22:41

 =

A
3D""
<roll@ietf.org>

cc
3D""

Objet
3D""
[Roll] Adoption of draft-brandt-roll-home-routing-reqs= as a ROLL WG document ?
=3D""3D""<= /td>

Dear WG,

Do you support the adoption of http://www.ietf.org/internet-= drafts/draft-brandt-roll-home-routing-reqs-01.txt as a ROLL WG document ?

Thanks.

JP.
______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email
______________________________________________________________________<= /font>_______________________________________________
Roll mailing list
Roll@ietf.org
https:/= /www.ietf.org/mailman/listinfo/roll

= --1__=4EBBFED8DFD30A738f9e8a93df938690918c4EBBFED8DFD30A73-- --0__=4EBBFED8DFD30A738f9e8a93df938690918c4EBBFED8DFD30A73 Content-type: image/jpeg; name="C8074967.jpg" Content-Disposition: inline; filename="C8074967.jpg" Content-ID: <10__=4EBBFED8DFD30A738@schneider-electric.com> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAA1AdQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDvtO0f T59JsHNhalmtoyzGFck7RkniugsvDmimLL6ZZMfe3X/CszSn2eH9P/69o/8A0EVZS8lQYB/Ctndn JBRS1FvtE0eNvk0yyH0gX/CsiTS9OZuNPtAPaFf8K2VZ5FJfvUQgw2aa0HKN+hQj0XTsZawtf+/K /wCFObSNMA/5B1p/34X/AArRxiqty+FwOpoWo+VJGU+m6eXOLC1AHpCv+Fa2k6PpBP77TrNv96BT /Sq0SZb2FWAxQ8HFOXYmEVe7LOpaZoiJiLS7EH2t0/wrNa30sRY/sqxz6/Z0/wAKmkZm6mqdw2Fw OppRiVKy1sZ0ljZPIzCytgo7CJf8KfBplgXUPZ2/J7xLT2O3j0p6QSSfN+grVo542vexqnRtHW3z /Z9oTj/niv8AhXM3Gn2SzN/o0AXPQRit2BLm4zGMqBVa90823zHmpjZFyi59LF7RvC+m3UHmSWkB z6xrWT4h0SxtHZILaEH7wxGKvWesyWcPljpWTeXj3l3vc8DrTpp81xV1FU7GYbe2wki28OD1Gwda mje1R132NqVH/TFf8KYoxbt6M3y1E3StZpXMqD90uanPYXESpb6daxt6pCqn+VLp3h1dRYRpCmF6 naKoRjaGmPbhfrXR+GNajsgyOMs1KS5Y6Ci4zqXlsYeveHP7KAOxcH2rAS2MrYRM13via8F+m8qW RewriZ7t8FEGxfQVVJaak1272ghDbW0H+ufc391a6LT9J0iTSpZ5Nu7Hy561x0jE0w3k6RmMOQvp VTjzbBQhyXctRksbSX7QwscFsDBrSvvD15p1rHcys2w8kE1k205t7tJupU5rq9T15tb0b7Og/eRj p6ijld0kXKcIRbkRT6xoy6KkSWVv9o7v5Yz+dbei6x4cj0kfadPs5JgOrwKx/lXmU0EiHDBh9ahL SKuAxxQ6AoYuLeiOpv7201K/uIrWCKFWU7PLULg/hXIyzXCMVM0gx/tmrFjOYLuOTPRuauappbtI 9zCN8TfN8vat4wSjY82dRqs29hmjTGaVoJWLb1IBY5INW/D1zb2urMupfvY1ONsnzCsS0dre6R+m 1qteIItl0J4zhZVDjFOUE1YVKp7OrfodiNa0P/hIkItIPsw6oUGPyroNY1rw09mUttLswzD70cCg j8cV4pGXaVfmOc17R4N8IWt1pK3Ny24sM81y1KcYWbPWpzdZNJWPONXt3t9txbzymFycDceKcjNc 6LIysRLEc7geSK6bxVp8Ea3NpAQfL+dcVymhyAXLW7/dkUoa6ocso3seNWjKEnG+w/R5WnMlvI5Z nQ7WJ5BqzokM17dy2bbmZlIBPVTWVCWsdUxg5R67/wAL2Udt4hNxIuYpPmB+tKo1CNy8PRlVqW6H Har4f1bTojM8s4X/AHjXPfa7ocfaJv8Avs19GeM9PW88Ov5EQJ25GBXzndwNBcujDBBrGhNTWp6G JoeytYT7Zc/8/E3/AH2aX7Xdf8/E3/fZq7omlvqmoR26j7xr0fU/hwlnorXGRvVc1c5wi7Mzp4ec 48x5bHeXHmKWuJcZ/vmvYvDWp+G49DU3dlaSzBeTJErE/mK8Zmj8uZk9DUkc04XYjnFE6SqLQKVb 2TfMbvirU4rnVXNgPIizwsXyj9KzrJL24kVVmmYn/aNSafpct3Lk9P4mPQVo3V/b6ZCYLMgydGk/ wrSMElY469d1Je6TSzQ6VBiR/OuCOhOQtc5c6jPJISsrr7KcVDNO8zEkkk1e03Q7m++faVj9TTfK KnBrVlaB764cKk8xPs5rbt7d7ZMzSySyn+DcTTtn2ZxbWkXz9C5Fd94W0C0Nv507LJN3J7VlUnGK vY3o05VZWODW3uJJA9y5hj7IDjNbJ0S6urPfboVXH3u9HjCNLXVU2NlQegroLXxTZ2+jiPA3bcVl Kd0mkdtLCxi3znCaWTZ64sd67SRhuVc5Fery33hwacPJ0uwaUrx/o6Zz+VeQ3aS6lqbzx/Kmc5q7 DrMVhIkSNvYdTTnS5kmTHEQg3BI6B9BlaaS9dcIeViQYX8q5jVdbkikMKW0Me3uIxmvR7bxDY/2R 85BfbXlOuOLzUneMcE0UlzOzQ66jTjzXGQ63MrfvFVh9Ku6TrCxan5kkQliP8Eg3D8jWfbaTPOfk jY1tWmipaOsly6ALzt7mun2aeh5f1hQfMjT1WZJ7lJI4IoQ0YJRIwB1PoKKoeY88kkjZGW+Uegor mdNXNliJNXPWNNbOi6cvpbR/+gitKKIBcnrWZow36TYf9e8f/oIrVlfy46432PZhtcGdVoHzdKzL i7ggZPtFxHGXPy72xmt7TrYOvzVLktrmqjLe2hSYY61TlG9+DW7qMCJH8vWufBKv9DTi77Ez00ZM ibVqzDZPOMimRxtLjaK2IJltIMOMGk2VFGFdW7QNtasyY5l9hzWrqV4JpiQOKyJMOXHfFaQXcxqy VtCBBn5z07Vp2U6QRHeMk1TVMsB2xxW3Y6QbiPeelObFRj1KlvqEcTsSOtVNRvRc8L0qbUrL7LNt rPMZIyBUq25s29inJwDVZwRHgfekOPwq3KhZgnrUe0GRpP4UG1a6Idzhru75StIvIUdFGKryDirh TioZEpXuzRR5YFecbYo09txpIh9nUSH77dKsyxg3KFvuHFKunXmoXTx20Dyugzhewq20lc5oRcmk bL6lZLohj2gyEVws43SMfer7ow4Pai40y8gtkuZrWaOCT7kjIQGqI6Ha1cxnWq7rWk8VV3irRMzs ZzIadDM8DbkYg1YaKomiq07Gc6amrMtJqhYbZo0kHuKbd21tc2Lz28exkPzCqZiIrU0ld7PC3SRd tWpHHUw/JrE5oqVar+n3ssEqgOdmeVPSlurUxTMpHQ1DHHtcUKVi50FONx+sWggv2ZBhH+YVPcxf bNAR+rwNg/Sr99b/AGrSYZsZaP5TTNGQSLLbN0kXH41XMczpaJ9jmLa1eSdQoyc8V6Bba3f6dDFp 1s7M5T5gOxrM02wW28+dly8Q4FangzZJrxluRnJzzWdWzidOFlL2m9kRtpOpJdC8uw21+Gz71y6W TW+veT0xJxXr/i7XbJbE28O0v7V53fWb3Vxa3MI+d+D9ailUfLqaYihH2qfc0fEPh6C1hi1ElQWw SBV4eJ9Nh0+3ijQBxjJrRu/C19f6GGnkPypnFeWXdq9vcvESflOKzjapuztaVJe6j2248Y6cuh43 gtsxivCtWlF1qMsqjAZqlLTMm3c2PSmi1du1aUqahsY1qntFYk0DUDpOopcAfdNdrr3xBl1HTjbR jG4YNcZHpsjnhTWtaeH22+ZcHy0Hc1UoRk7sx+sOnHlRziWktzNwpJY9q27fRYbSMTXsgQf3O5q9 Ne21ghjs4wW/vmsWZ7i9lP3nY1qpJI4vZVKrJNQ1cGL7PaJ5cXt1NZcNhdXzfuo2b6CtWDQbqSRT MhRPU17J4R0LS7fSldQjPjljWVWvyo6cPhE3ZnjEOjpYlXvfvdkr13wdotpdaWs8yqFI4WuZ8V6b b/2wXiHmN2QVh3PiLWNJh8k7o4+wrOTdSKsbUYeym3JXRd+IVxaabeeTYBQe5Fc5pfiq5soygc81 i399NfzmSVizH1pLWwmupAEU49a2jT92zMZ11Co5RO/0XS5PE8pmmbNHiHw1DpC+ZLJhB2qbw5qy 6Hb+TGDJJ7VX16W51p91zKIo/Qmsowlz+RrVxVN0m09Tj7q/knHlQLsj9u9V7fTZ53G1GJ9q6SG0 soDhI2nf9Kt4n29Y7dPQda7EjxXX7GdBpc8cYFxcCNfTPNWIrezib9zA07+p6VKPs4bgPO/v0qU/ aCvzMlun60JWMpVZS3YhE2395IkCeg61GpgDfuonnf1bpSD7OG+VXnf9Km/0gr8zJbp+tMzK1z5n mL5gVDt4UDoKKbLsD/JIz8cn3orkluzuh8KPWNAjJ0axbHH2eP8A9BFWJ23SY9K0vDkEY8M6axxz axn/AMcFUL9o7dpp2/1cSl2/CvPc0rtn00INpRXU5aVItU8ZRWrwRyR2yfvWOe3Pr6kV0sep3TO4 solKqcF3rmvDKuLDUNVlz5ty+xT+p/U/pXZaTpxGmxseC/zn+lfPqdSvW9lF2vq318j28So0opWv y6L9Sk82rXBwY4z+X+NVHM8d2IbiIK7D+GugtwIrjDVjJKLrUru8YZVQQn8h+lTi1PByg4VG7vr2 RzU+WsnzRRbtLiWMeXDErSd2boKZeXFxINk/lj2U1VDunKk89aikHmHO7n3rowuFq4umq9Wo436L t0OWrWjSfJGNw8tT0z+dczq3iD7LqCWOnWpur4jLIPur9a6V3FvAXl5VFJauI8GmO+1LU9RmkQTy thELDIBOT/ICunJpVJOpzScop2V/I7qOGpOnKvOF+Vbeb2J/P8ZZyLKzXHbK8f8Aj1WG8b+K/Dxh bUrG0a1c7fl4z7BgxwfqK6JXTYCXXjg/MK47WnTX/Fen6ZA6y28HzSsh3D1b9ABXsuz3RvgKyryc alFKKV72Og1jxDOuswGVFWylVWyR82D1/Ku2ttKg+yhmwcjrXG69p/27Tn2LmWL50/qPyqLS/GX2 Xw+sM7F54f3aIOrj+H/CvNdV06jjN6PY+fdRRqO+zLWsPBp0zSO2EHGB1P0rJ06S5uxI7xrHb43R qR8x96fDp9zqVx9v1XljzHB2Ue/+H5112i2cTRzX00XmGFdqJjOTjPT8q3pznL3nouxg4SnO+xzg tpXXKRSMPUKTWjYabpr25OofbFl3cBImxj/vmr8viDUlkOPKQdgE6VMup6zJGDG0bE8ACOtm2dUY ozdY8P28Olpd2U0jx5wFkXn+Qra0qDTrLSXuo5JQtwAjSFcMT0+UY9c1dvXjZo7edgzKu5gO7dP8 ap6rE0cNtZwL8sS72x69v61HM5KzJVOMJOSRial4Z0xYIo7IXJuJZFRS54AJ5J49Kn8RaXfatf22 mQXDtDEgZzJjAb1OB6fzq5o00l7qJeYYjtV3HP8AePH+NW9NvGnsbzUFQkszbQOT/np+VO7RpZNH KtonhWxYw32pXEs68N5QIAP4A/zpqaZ4JlkEYvLtWY4BJYD/ANBqC9sDLMzrz7GptA0SS41e3d4m 8mN97kjjjkD88Veyu2ZKSbtYoax4La21y1sLCUyi6BK+Z1THXdjtWpb+DPDsVybO5vbm4ul++Ixt VT+A/rXSwNFLreoas7ZjtIvJU9hjlv8APvXFtrUyXTzqAGdizfU0RcpaXB2WyNHUPCfhHTlBvJLy IHvuJ/kKyPEHhe00H7He6fcySQTt8qyYyOMgg+lS+dceItVtbOQkrJIA3+71b9M1a8c3f2jW4rVP 9XaR7cdtzcn9NtOLaklcKkIyi9DkdZsh5wlUcON1ZBt8GuwmgFxpYOMtGf0rDa3APSujmMKcdLE+ mQ+fazWx/iXI+tZ9rGba+HbDVrab+5uFPvTtUtPJviwHyt8wp8xm6erRP9nCXx4+SZf51GLY6fay PF/rGbbn0q8i+bYxSj70ZxVx4EmjO77sgBz6GhyMlTsyfQvCS6haC5uW3FueaiudOh028ELcKrbl NX7bUbqws/Kj+ZR0xWPPqks85+0JuHvWMea7uddRxcVbc6DUdclGlmKFd3y44rzMaRPf35+Qlmau zijWUZhcr7GrUMkFnKJJCoaqjaOxn7SUtGZVv8PWNt5khC8Vmz6Xp+nyFZG3sOwrvLvxPbCxKR9c V55eCa9uWdVJyaVOcnuaVKMWtBH1GGEYt4FX3NZ8s1zqEoQEknsK0I9Fmfl/lHvW5oFjZWeoI8zB iK0c7IzjRjc5yTwfqBgEpjOK6zwT4askJe52vKOx7V1uq6hA9gYbcDcwwK5O3t7vTI3njDOx5rH2 kpLU35YxkrFjxvYWywp5brGo64rjP+Erl022NtaEntmn6td3+qzFZd2B/CKpR+H5X5cBB6mtqcPd sznq1EpXR1PgSa3v7iS51Bg0h/vVH8RUtLpVitIwXH90Vl2VtHp5/dyM7ei1PNLJJ8xAX601S9/m MKmNXs+VLU5Kz8ONgPcYRfQ1qr9ktl8uJS/stSTyQlvnkaU/3E6Uimcr+6iSBPU9a7Eu54kqjbAG 4K/KqW6ep61Efs4b5med/bpQwhDfvZXmf0XpUimYr+6iSBPU9adrGV2wH2gr8qpbp6nrUR+zhvmZ 539ulKwgDfvZXmf0HSpF88r+6iSBPVutAgH2gr8qpAnr3qI/Zw3zM87+3SlbyA372V539B0qRfPI xFEkCep60DAfaCvyqlunr3qP/Rw3zF7h/wBK1bDQzenczvMfbpU9/ol3ZR5jjSFPU1HtI3tc6Pq1 Tl57aHPXBbeN0Sx8cLRSXAUScy+YccmiueW7N4fCjr7T4gyWWnW1kNP3CCJY93n4zgYzjbUd342i v7Ga1m02QJMMMyXOG9f7lFFcE4pxdz26dacWmntYanjC0h023so9IkWGHp/pQyxPUn5K10+KeyII ujAADA/0n0/4BRRWFKjTjNyS1NKmJqy3l3IP+Fkq+7dpBy2RkXWMcf7lVI/HEMcHkx6W4DHJJuck /wDjlFFKvh6VSXvxuKGIqqOj6jG8cAn/AJBuOP8Anv8A/Y03/hN+x07P/bb/AOxoorenFKKitjGV WbldsH8bBwVOncEcjzv/ALGuZuo9IuJd6afPBk8rHc8fkVNFFPD04UoWgrLU6aGOxFOd4TauQLa6 UH5trsj0+0r/APEVvaZrlhpCFbPSAhcDc5nyx+p20UVrJs2xGYYma5ZTdjSTxwg5OmZ/7eP/ALGs qDWrKG/e7TTDudiyK04Ij+ny/wD6qKKwqQjKSujzpVJNq5fPjHP/AC4f+Rv/ALGrFj4+msXYxWWV bBKmXj/0GiitLaFe1nfcvt8U7jb8ulRg+82f/ZaR/ijdFONNjVvVZf8A7Giilyor20+5lL43mW7F ybTfIG3/ADy5yR+H+cVo/wDCy3bcW0pS7DO7z+mB/u0UU2kT7WfcpDx7NFFcQxWCKtxy58zJGRjA 4q1YfEUWFuY49KJGcn/SeCfpsoooaQRqz7k0nxRvd/yadAB6M5NU7v4jajdoY/JWFW4PlNg/njNF FCSG6s+5TTxncx6VJpyWsawyHLNu+Y57Z/Cs46zk/wDHv/4//wDWooqkL2su5Z0zxTLpV6t1Baxt IFKgO2QM/wD6qrXOvPd3MlxLDmSR97Hd3PPpRRTW9w9rO25NB4iEEbxm03hh/wA9Mf0qm+qBmJEG P+B//Woop3ZMZyuEeq7WBEP/AI//APWqzea+LmKMG1wyjG7zOv6UUUXYOcrjrfxF9ngeM2u8MP8A npjH6VJD4nliwv2cMvoX/wDrUUUXZDkyb/hLB1WxKn2m/wDsain8SpOoDWKg56iT/wCtRRRdgmx3 /CUlYgkNmE46+Zn+lZ8usvKxLRnP+9/9aiii7HGTHw6wkR/eWpk/7aY/pVj/AISTaMJZqv8AwP8A +tRRRcbnK+5GdfL8vbsR6ebj+lPHiFIjlLIA+pk/+tRRRcOZkieKpVnRnt96g/d8zH9K3f8AhZMX 2byhoYxjr9p/+wooqJFwqSs9TBl8SK8jNHYrHk/38/0qqda8zmSAt7eZ/wDWooraMnY5p6sR9Zwu I7YJ/wACz/Sqj3fmtmZXcZ6b8D+VFFVGpLuYTpxe6A3ewYhiSP36movN8w7pS7+27FFFV7WfcydG n2JPtOwYhiVPfqaj83zDmXe/tuxRRS9rPuJ0KfYk+1bBiGJE9+ppgl8w7pd7+27FFFHtZ9w9hT7E gu1RcRQqh9c5qNZQ7hpg0ntuxRRR7Wfcr2ML7HWaX43h0yARppCtjv5+P/Zabq3jaPVbcxNpezPf z8/+y0UVh9u56PM+Tl6HKSTI7ZSIIPTOf6UUUVq5O5yKEbbH/9k= --0__=4EBBFED8DFD30A738f9e8a93df938690918c4EBBFED8DFD30A73 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <20__=4EBBFED8DFD30A738@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFED8DFD30A738f9e8a93df938690918c4EBBFED8DFD30A73 Content-type: image/gif; name="pic25313.gif" Content-Disposition: inline; filename="pic25313.gif" Content-ID: <30__=4EBBFED8DFD30A738@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFED8DFD30A738f9e8a93df938690918c4EBBFED8DFD30A73 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <40__=4EBBFED8DFD30A738@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFED8DFD30A738f9e8a93df938690918c4EBBFED8DFD30A73-- --===============0454828816== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0454828816==-- From roll-bounces@ietf.org Fri May 16 07:32:12 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C4928C115; Fri, 16 May 2008 07:32:12 -0700 (PDT) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 65534) id 2462E28C157; Fri, 16 May 2008 01:00:00 -0700 (PDT) X-Original-To: roll@core3.amsl.com Old-Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA483A6925 for ; Fri, 16 May 2008 00:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmeVNvld273F for ; Fri, 16 May 2008 00:49:38 -0700 (PDT) Received: from smtpsal.upv.es (electra.cc.upv.es [158.42.249.4]) by core3.amsl.com (Postfix) with ESMTP id 981F93A67AA for ; Fri, 16 May 2008 00:49:38 -0700 (PDT) Received: from pop.upv.es (deneb.cc.upv.es [158.42.3.51]) by smtpsal.upv.es (8.13.6/8.13.6) with ESMTP id m4G7nQB8011101; Fri, 16 May 2008 09:49:26 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id m4G7nPB14222; Fri, 16 May 2008 09:49:25 +0200 (METDST) Received: from [158.42.53.165] (msanchez2.disca.upv.es [158.42.53.165]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id m4G7nMrX008553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 May 2008 09:49:23 +0200 Message-ID: <482D3C82.8060309@gmail.com> Date: Fri, 16 May 2008 09:49:22 +0200 From: Miguel User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: X-TMDA-Confirmed: Fri, 16 May 2008 01:00:01 -0700 X-Mailman-Approved-At: Fri, 16 May 2008 07:32:11 -0700 Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Yes, Miguel S=E1nchez JP Vasseur escribi=F3: > Dear WG, > > Do you support the adoption of = > http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-0= 1.txt = > as a ROLL WG document ? > > Thanks. > > JP. > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > = _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri May 16 08:19:56 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7300328C221; Fri, 16 May 2008 08:19:56 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D0428C20B for ; Fri, 16 May 2008 08:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EikS3eZ7Ie9i for ; Fri, 16 May 2008 08:19:53 -0700 (PDT) Received: from auswood.securesites.net (auswood.securesites.net [128.121.62.173]) by core3.amsl.com (Postfix) with ESMTP id D2B1328C230 for ; Fri, 16 May 2008 08:19:13 -0700 (PDT) Received: from [10.0.1.5] (c-98-210-6-113.hsd1.ca.comcast.net [98.210.6.113]) (authenticated bits=0) by auswood.securesites.net (8.13.6.20060614/8.13.6) with ESMTP id m4GFJ8Pp039190; Fri, 16 May 2008 15:19:08 GMT Message-Id: <105ABCCF-405D-4248-9791-7E743361908D@daintree.net> From: Zachary Smith To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 16 May 2008 08:19:07 -0700 References: X-Mailer: Apple Mail (2.919.2) Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0310215193==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0310215193== Content-Type: multipart/alternative; boundary=Apple-Mail-1-715713655 --Apple-Mail-1-715713655 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit RIght. Thanks for the clarification. z On May 15, 2008, at 3:46 PM, JP Vasseur wrote: > Thanks for your reply. > > ps: that gives me the opportunity to clarify one thing though: by > all means, adopting a document as a WG document does not mean that > the document is ready for publication ! It just means that the WG > agrees to take it as the base document to address a WG item. > > Thanks. > > JP. > > > On 5/15/08 6:22 PM, "Zachary Smith" wrote: > >> Yes, >> >> Although there is a point that probably bears discussion. In a >> multi-application network with sleeping end devices and resource- >> constrained routers, there is an end device management problem that >> is related to routing and might be considered as part of the >> routing solution. In short, it doesn't really make sense to rely on >> nearby routers to buffer arbitrary traffic for sleeping end >> devices. There are a number of possible solutions to this problem >> and not all of them involve the network layer but, if we are >> talking about "resource aware" routing then we might want to put in >> a requirement or two around this. >> >> My $0.02US, >> >> z >> >> On May 15, 2008, at 1:41 PM, JP Vasseur wrote: >> >>> Dear WG, >>> >>> Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-01.txt >>> as a ROLL WG document ? >>> >>> Thanks. >>> >>> JP. >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >>> Zachary Smith - CTO >>> http://www.daintree.net/ >>> zsmith@daintree.net >>> >>> >>> >>> >>> Zachary Smith - CTO http://www.daintree.net/ zsmith@daintree.net --Apple-Mail-1-715713655 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

= Thanks for your reply.

ps: that gives = me the opportunity to clarify one thing though: by all means, adopting a = document as a WG document does not mean that the document is ready for = publication ! It just means that the WG agrees to take it as the = base document to address a WG item.

Thanks.

JP.
=

On 5/15/08 6:22 PM, "Zachary Smith" <zsmith@daintree.net> wrote:
=
Yes,

Although there is a point that = probably bears discussion. In a multi-application network with sleeping = end devices and resource-constrained routers, there is an end device = management problem that is related to routing and might be considered as = part of the routing solution. In short, it doesn't really make sense to = rely on nearby routers to buffer arbitrary traffic for sleeping end = devices. There are a number of possible solutions to this problem and = not all of them involve the network layer but, if we are talking about = "resource aware" routing then we might want to put in a requirement or = two around this.

My $0.02US,

  z

On = May 15, 2008, at 1:41 PM, JP Vasseur wrote:

=
Dear WG,
 
 Do you support = the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-r= outing-reqs-01.txt as a ROLL WG document ?
 
=  Thanks.
 
 JP.
=   _______________________________________________
Roll = mailing list
Roll@ietf.org
= https://www.ietf.org/m= ailman/listinfo/roll

 
Zachary Smith - CTO
http://www.daintree.net/
zsmith@daintree.net

=
 


=
=

Zachary Smith - = CTO
<= a = href=3D"mailto:zsmith@daintree.net">zsmith@daintree.net


 =

= --Apple-Mail-1-715713655-- --===============0310215193== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0310215193==-- From roll-bounces@ietf.org Fri May 16 08:46:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938D828C188; Fri, 16 May 2008 08:46:33 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA7D28C155 for ; Fri, 16 May 2008 08:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srOuIvrhSdeA for ; Fri, 16 May 2008 08:46:30 -0700 (PDT) Received: from cypress.ugent.be (cypress.ugent.be [157.193.71.48]) by core3.amsl.com (Postfix) with ESMTP id 4E2A928C1CE for ; Fri, 16 May 2008 08:46:30 -0700 (PDT) Received: from gorilla.ugent.be (HELO localhost) ([157.193.49.20]) by cypress.ugent.be with ESMTP; 16 May 2008 17:46:24 +0200 Received: from cypress.ugent.be ([157.193.71.48]) by localhost (gorilla.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 24978-05-14 for ; Fri, 16 May 2008 17:46:24 +0200 (CEST) Received: from mail4.intec.ugent.be ([157.193.214.4]) by cypress.ugent.be with ESMTP; 16 May 2008 17:46:15 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIxJLUidwdYE/2dsb2JhbACuEg Received: from localhost (localhost [127.0.0.1]) by mail4.intec.ugent.be (Postfix) with ESMTP id DF90A40B2B9 for ; Fri, 16 May 2008 17:46:14 +0200 (CEST) Received: from mail4.intec.ugent.be ([127.0.0.1]) by localhost (mail4.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLMwAMRpIGk6 for ; Fri, 16 May 2008 17:46:14 +0200 (CEST) Received: from [157.193.214.151] (crane.intec.ugent.be [157.193.214.151]) by mail4.intec.ugent.be (Postfix) with ESMTP id BB11C40011C for ; Fri, 16 May 2008 17:46:14 +0200 (CEST) Message-ID: <482DAC42.9080800@intec.ugent.be> Date: Fri, 16 May 2008 17:46:10 +0200 From: Pieter De Mil User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: X-Virus-Scanned: by UGent DICT Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Yes Pieter JP Vasseur wrote: > Dear WG, > > Do you support the adoption of > http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-01.txt > as a ROLL WG document ? > > Thanks. > > JP. > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > -- Pieter De Mil Department of Information Technology (INTEC) Ghent University Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium tel.: +32-9331 4981; tel. secr.: +32-9331 4900 fax: +32-9331 4899 pieter.demil@intec.ugent.be http://www.ibcn.intec.ugent.be Confidentiality Statement: This e-mail and any attached files are confidential and may be legally privileged. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify INTEC immediately and then delete this e-mail. INTEC does not accept liability for the correct and complete transmission of the information, nor for any delay or interruption of the transmission, nor for damages arising from the use of or reliance on the information. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri May 16 09:37:09 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3FB83A6B4B; Fri, 16 May 2008 09:37:08 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7836E3A6B4B for ; Fri, 16 May 2008 09:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB0ENFkYMOFA for ; Fri, 16 May 2008 09:37:05 -0700 (PDT) Received: from smtp108.biz.mail.mud.yahoo.com (smtp108.biz.mail.mud.yahoo.com [68.142.201.177]) by core3.amsl.com (Postfix) with SMTP id A825A3A6B4A for ; Fri, 16 May 2008 09:37:05 -0700 (PDT) Received: (qmail 87966 invoked from network); 16 May 2008 16:36:38 -0000 Received: from unknown (HELO zeke.ekasystems.com) (tim.winter@ekasystems.com@68.166.148.162 with plain) by smtp108.biz.mail.mud.yahoo.com with SMTP; 16 May 2008 16:36:38 -0000 X-YMail-OSG: 8LIY078VM1lyek0A2orY7Z.SjHpdp_UL3e2WkBpe4I1Jb95OiviV8fSZoxvjLdYisBiFHkkyWI6q6GcRm6kfpK6BiV4xv6z9ppDQV1kS7p6IlMVCQPa0skzhj_VfUrMQebOkcQ1wHftQQ1l9BWq5aK.g X-Yahoo-Newman-Property: ymail-3 Message-ID: <482DB815.7040204@ekasystems.com> Date: Fri, 16 May 2008 12:36:37 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: roll@ietf.org Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Yes, -Tim Winter On May 15, 2008, at 1:41 PM, JP Vasseur wrote: > > Dear WG, > > > > Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-01.txt > > as a ROLL WG document ? > > > > Thanks. > > > > JP. > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri May 16 11:01:40 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5443A6B51; Fri, 16 May 2008 11:01:40 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13EFC3A6B51 for ; Fri, 16 May 2008 11:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaMEUKtZxLC4 for ; Fri, 16 May 2008 11:01:38 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 494BD3A6B4C for ; Fri, 16 May 2008 11:01:38 -0700 (PDT) Received: from c-76-102-175-32.hsd1.ca.comcast.net ([76.102.175.32] helo=[192.168.1.103]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Jx4Ez-0003GJ-2z; Fri, 16 May 2008 11:01:15 -0700 Message-Id: From: Philip Levis To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 16 May 2008 11:01:12 -0700 References: X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: c6b7461a7773f457175e025605fe13fe Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On May 15, 2008, at 1:41 PM, JP Vasseur wrote: > Dear WG, > > Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-01.txt > as a ROLL WG document ? > > Thanks. Yes. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri May 16 11:13:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2B13A6B7C; Fri, 16 May 2008 11:13:33 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7B43A6B6F for ; Fri, 16 May 2008 11:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQE-Dsk8EKDm for ; Fri, 16 May 2008 11:13:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3D91B28C172 for ; Fri, 16 May 2008 11:12:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,498,1204531200"; d="scan'208,217";a="34222955" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 May 2008 11:12:06 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m4GIC6A6022807 for ; Fri, 16 May 2008 11:12:06 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4GIC2MX012373 for ; Fri, 16 May 2008 18:12:06 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 May 2008 11:12:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 May 2008 11:14:33 -0700 Message-ID: <813F12598722004A9F0A3593D83F7A0405BB1290@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? Thread-Index: Aci2zBFOkmEiPwCzpUuia/ew5usrXQAtJOhA References: From: "Tarun Banka (tabanka)" To: "Jean Philippe Vasseur (jvasseur)" , X-OriginalArrivalTime: 16 May 2008 18:12:01.0883 (UTC) FILETIME=[56BAAAB0:01C8B780] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2428; t=1210961526; x=1211825526; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tabanka@cisco.com; z=From:=20=22Tarun=20Banka=20(tabanka)=22=20 |Subject:=20RE=3A=20[Roll]=20Adoption=20of=20draft-brandt-r oll-home-routing-reqs=20as=20a=20ROLL=20WG=20document=20? |Sender:=20; bh=eiIZuhemvaGKEJ3vv5Q++sZJ6GrdgRuVw8CRiF+nmhk=; b=r0XBymzcSGEosYRQ98Cx0kpzrn+XkpOfs8RQ1xmmosjSvYGXl/XS00QMFp Y2oUTst2ktbkQZjoFD9HJTCe0vqSQybrt5XQODQM4pLjC3JRbgqCekvM9gl2 vfVjHndsXI; Authentication-Results: sj-dkim-3; header.From=tabanka@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1810498172==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1810498172== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B780.412500AD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B780.412500AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes =20 Tarun ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur (jvasseur) Sent: Thursday, May 15, 2008 1:42 PM To: roll@ietf.org Subject: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? Dear WG, Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs- 01.txt as a ROLL WG document ? Thanks. JP.=20 ------_=_NextPart_001_01C8B780.412500AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adoption of draft-brandt-roll-home-routing-reqs as a = ROLL WG document ?
Yes
 
Tarun

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur = (jvasseur)
Sent: Thursday, May 15, 2008 1:42 PM
To:=20 roll@ietf.org
Subject: [Roll] Adoption of=20 draft-brandt-roll-home-routing-reqs as a ROLL WG document = ?

Dear WG,

Do you support the adoption of = http://www.ietf.org/internet-drafts/draft-brandt-roll-home= -routing-reqs-01.txt=20 as a ROLL WG document ?

Thanks.

JP.=20 ------_=_NextPart_001_01C8B780.412500AD-- --===============1810498172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1810498172==-- From roll-bounces@ietf.org Fri May 16 11:34:37 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCE628C221; Fri, 16 May 2008 11:34:37 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B14C3A687D for ; Fri, 16 May 2008 11:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, HOST_MISMATCH_COM=0.311, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qpwv11hHMfH for ; Fri, 16 May 2008 11:34:35 -0700 (PDT) Received: from zensys17.zensys.local (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 01F4728C21D for ; Fri, 16 May 2008 11:34:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8B68A.4B59828A" Date: Thu, 15 May 2008 14:50:46 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EB68B8B@zensys17.zensys.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Version 01 of draft-brandt-roll-home-routing-reqs posted Thread-Index: Aci1IVx4lni5eWyYeUCqlfuNDzBvewAaeWNAAD+8zMA= From: "Anders Brandt" To: Subject: [Roll] Version 01 of draft-brandt-roll-home-routing-reqs posted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B68A.4B59828A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Gentlemen, A new version of the home control draft has been published. Changes from version 00: * Removed MUST, SHOULD, etc. from use case sections * Removed requirements statements that were stronger than needed * Added section on health care * Added section on alarm systems; merged with previous section on networked smoke alarms * Tried to get rid of the term "constrained" after objections from routing gurus in Philadelphia More remains to be done on this task. * Various editorial clarifications * Added co-author Giorgio Porcu, Telecom Italia - welcome! br. Anders Brandt ------ Forwarded Message From: Reply-To: Date: Tue, 13 May 2008 10:45:01 -0700 (PDT) To: Subject: I-D ACTION:draft-brandt-roll-home-routing-reqs-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Home Automation Routing Requirement in Low Power and Lossy Networks Author(s) : A. Brandt Filename : draft-brandt-roll-home-routing-reqs-01.txt Pages : 14 Date : 2008-5-13 =20 This document presents home control and automation application specific requirements for ROuting in Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include lighting control, heating control, sensors, leak detectors, healthcare systems and advanced remote controls. Because such devices only cover a limited radio range, multi-hop routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home network environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs- 01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------_=_NextPart_001_01C8B68A.4B59828A Content-Type: application/octet-stream; name="draft-brandt-roll-home-routing-reqs-01.txt" Content-Transfer-Encoding: base64 Content-Description: draft-brandt-roll-home-routing-reqs-01.txt Content-Disposition: attachment; filename="draft-brandt-roll-home-routing-reqs-01.txt" Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA4LTUtMTMxMDM1MDguSS1E QGlldGYub3JnPg0N ------_=_NextPart_001_01C8B68A.4B59828A Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01C8B68A.4B59828A-- From roll-bounces@ietf.org Fri May 16 13:15:56 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB8428C29F; Fri, 16 May 2008 13:15:56 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E3B28C29D for ; Fri, 16 May 2008 13:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj5-eUzi498w for ; Fri, 16 May 2008 13:15:53 -0700 (PDT) Received: from mail.dustnetworks.com (cust-67-203-88-34.static.o1.com [67.203.88.34]) by core3.amsl.com (Postfix) with ESMTP id C6BAE28C29B for ; Fri, 16 May 2008 13:15:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 May 2008 13:16:34 -0700 Message-ID: <9E9E6A5B6B547F4D8AFA7601E29508A71109D6@dust-exch-01.dusthq.dust-inc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? Thread-Index: Aci2zBFOkmEiPwCzpUuia/ew5usrXQAxZhEQ From: "Chol Su Kang" To: "JP Vasseur" Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1287977808==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1287977808== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B791.BD2E4B03" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B791.BD2E4B03 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the adoption. =20 Chol Su Kang =20 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Thursday, May 15, 2008 1:42 PM To: roll@ietf.org Subject: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? =20 Dear WG, Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs- 01.txt as a ROLL WG document ? Thanks. JP.=20 ------_=_NextPart_001_01C8B791.BD2E4B03 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG = document ?

I support the = adoption.

 

Chol Su = Kang

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: Thursday, May 15, = 2008 1:42 PM
To: roll@ietf.org
Subject: [Roll] Adoption = of draft-brandt-roll-home-routing-reqs as a ROLL WG document = ?

 

Dear WG,

Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home= -routing-reqs-01.txt as a ROLL WG document ?

Thanks.

JP.

------_=_NextPart_001_01C8B791.BD2E4B03-- --===============1287977808== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1287977808==-- From roll-bounces@ietf.org Fri May 16 19:33:50 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F44228C30D; Fri, 16 May 2008 19:33:50 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE7928C30A for ; Fri, 16 May 2008 19:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tv8uAnqChoXe for ; Fri, 16 May 2008 19:33:48 -0700 (PDT) Received: from mail.sf.archrock.com (71.16.121.216.reverse.servepath.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 986EF28C0E8 for ; Fri, 16 May 2008 19:33:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 32B36A92BA; Fri, 16 May 2008 19:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZKmKpXmckQs; Fri, 16 May 2008 19:33:37 -0700 (PDT) Received: from [10.0.1.197] (adsl-71-142-65-177.dsl.pltn13.pacbell.net [71.142.65.177]) by mail.sf.archrock.com (Postfix) with ESMTP id 9D1BDA9220; Fri, 16 May 2008 19:33:37 -0700 (PDT) Message-Id: From: Jonathan Hui To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 16 May 2008 19:33:36 -0700 References: X-Mailer: Apple Mail (2.919.2) Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as a ROLL WG document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1519580609==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1519580609== Content-Type: multipart/alternative; boundary=Apple-Mail-16-756182696 --Apple-Mail-16-756182696 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Yes. -- Jonathan Hui On May 15, 2008, at 1:41 PM, JP Vasseur wrote: > Dear WG, > > Do you support the adoption of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-01.txt > as a ROLL WG document ? > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-16-756182696 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
--
Jonathan = Hui



On May 15, = 2008, at 1:41 PM, JP Vasseur wrote:

= Dear WG,

Do you support the adoption = of http://www.ietf.org/internet-drafts/draft-brandt-roll-home-r= outing-reqs-01.txt as a ROLL WG document ?

Thanks.

= JP.
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-16-756182696-- --===============1519580609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1519580609==-- From roll-bounces@ietf.org Sat May 17 01:58:22 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35ABA28C2F8; Sat, 17 May 2008 01:58:22 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40BCD28C2F8 for ; Sat, 17 May 2008 01:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4ZPAcW4DC5h for ; Sat, 17 May 2008 01:58:20 -0700 (PDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by core3.amsl.com (Postfix) with ESMTP id 5098828C1E0 for ; Sat, 17 May 2008 01:58:19 -0700 (PDT) Received: from smtp1-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp1-g19.free.fr (Postfix) with ESMTP id 4DB851AB315 for ; Sat, 17 May 2008 10:58:14 +0200 (CEST) Received: from [192.168.0.1] (mir01-2-82-245-104-81.fbx.proxad.net [82.245.104.81]) by smtp1-g19.free.fr (Postfix) with ESMTP id 2C0701AB2B4 for ; Sat, 17 May 2008 10:58:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <919DD8E2-F8A8-4106-ADEA-8C71BD54A5EE@ens-lyon.fr> To: roll@ietf.org From: Bernard Tourancheau Date: Sat, 17 May 2008 10:58:13 +0200 X-Mailer: Apple Mail (2.753) Subject: [Roll] =?iso-8859-1?q?R=E9p_=3A__Adoption_of_draft-brandt-roll-ho?= =?iso-8859-1?q?me-routing-reqs_as_a_ROLL_WG_document_=3F?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > Yes. We will had some comments on 3.2 next week. > Dear WG, > > Do you support the adoption of > http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing- > reqs-01.txt > as a ROLL WG document ? > > Thanks. > > JP. > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sat May 17 23:29:02 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB1E28C0D7; Sat, 17 May 2008 23:29:02 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DFD83A6D37 for ; Sat, 17 May 2008 23:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.423 X-Spam-Level: X-Spam-Status: No, score=-0.423 tagged_above=-999 required=5 tests=[HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwiuGbdU-sB0 for ; Sat, 17 May 2008 23:28:58 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 64DF03A696E for ; Sat, 17 May 2008 23:28:57 -0700 (PDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 May 2008 08:28:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 18 May 2008 08:28:52 +0200 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC207A953D1@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as Thread-Index: Aci4UMyZ4eYNsFVQQV68t3UeX4zx5gAX35Rg References: From: To: X-OriginalArrivalTime: 18 May 2008 06:28:53.0621 (UTC) FILETIME=[71644250:01C8B8B0] Subject: Re: [Roll] Adoption of draft-brandt-roll-home-routing-reqs as X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi JP, I support it as well. Dominique _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue May 20 21:00:18 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820283A7029; Tue, 20 May 2008 21:00:18 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622953A6D08 for ; Tue, 20 May 2008 21:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.975 X-Spam-Level: X-Spam-Status: No, score=-4.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0SExdPJJO45 for ; Tue, 20 May 2008 21:00:08 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D62263A7664 for ; Tue, 20 May 2008 19:38:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,518,1204520400"; d="scan'208,217";a="8822606" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 May 2008 22:38:29 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4L2cThw013310; Tue, 20 May 2008 22:38:29 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4L2cTjI009074; Wed, 21 May 2008 02:38:29 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 May 2008 22:38:29 -0400 Received: from 10.21.86.90 ([10.21.86.90]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 May 2008 02:38:28 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 20 May 2008 19:38:25 -0700 From: JP Vasseur To: Message-ID: Thread-Topic: New ROLL WG Document: draft-brandt-roll-home-routing-reqs-01 Thread-Index: Aci6674hwQzu4dstM02yUiOFW9ksFg== Mime-version: 1.0 X-OriginalArrivalTime: 21 May 2008 02:38:29.0166 (UTC) FILETIME=[C09D14E0:01C8BAEB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1295; t=1211337509; x=1212201509; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20New=20ROLL=20WG=20Document=3A=20draft-brandt-ro ll-home-routing-reqs-01=20 |Sender:=20 |To:=20; bh=1PzdHsXO9HeY6TdZ1SPaA2pyWPdAONCGeCGdu/JtEuc=; b=n8nMc+js39QKZL7CnikdjmC0fbxuReRUfvlOtrM+4t+M+8Y1jyX+kmQVnM SBJ9iP2zz3Pj0PpGLgTBxnSrZxzwnuJnGzEFM/SdSzcEuePXt3DbTTPXdUaD cOVNcom1Ay; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Porcu Giorgio Subject: [Roll] New ROLL WG Document: draft-brandt-roll-home-routing-reqs-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1017733726==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1017733726== Content-type: multipart/alternative; boundary="B_3294157107_6611120" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3294157107_6611120 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, Considering the good support to adopt draft-brandt-roll-home-routing-reqs as a ROLL WG document, authors please resubmit as draft-ietf-roll-home-routing-reqs-00.txt with no change other than the title, name and date. Note that there were a few comments that you may want to address for the next revision. Thanks. JP. --B_3294157107_6611120 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable New ROLL WG Document: draft-brandt-roll-home-routing-reqs-01 </TITLE= > </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:13pt= '>Dear WG,<BR> <BR> Considering the good support to adopt draft-brandt-roll-home-routing-reqs a= s a ROLL WG document, authors please resubmit as draft-ietf-roll-home-routin= g-reqs-00.txt with no change other than the title, name and date. Note that = there were a few comments that you may want to address for the next revision= .<BR> <BR> Thanks.<BR> <BR> JP. </SPAN></FONT> </BODY> </HTML> --B_3294157107_6611120-- --===============1017733726== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1017733726==-- From roll-bounces@ietf.org Tue May 20 21:18:57 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5445C3A6C75; Tue, 20 May 2008 21:18:57 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC053A6A14 for <roll@core3.amsl.com>; Tue, 20 May 2008 21:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.975 X-Spam-Level: X-Spam-Status: No, score=-4.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Cx5TRebX2RF for <roll@core3.amsl.com>; Tue, 20 May 2008 21:17:19 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5A9FA3A7130 for <roll@ietf.org>; Tue, 20 May 2008 21:06:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,518,1204520400"; d="scan'208,217";a="8836294" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 May 2008 00:06:11 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4L46B5U000617; Wed, 21 May 2008 00:06:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4L46Bq5005038; Wed, 21 May 2008 04:06:11 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 May 2008 00:06:10 -0400 Received: from 10.21.147.165 ([10.21.147.165]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 May 2008 04:06:10 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 20 May 2008 21:06:07 -0700 From: JP Vasseur <jvasseur@cisco.com> To: <roll@ietf.org> Message-ID: <C458EDBF.3D562%jvasseur@cisco.com> Thread-Topic: New ROLL WG Document: draft-brandt-roll-home-routing-reqs Thread-Index: Aci69/6GKlMf0lbT+0GQUmY1Fl0cUA== Mime-version: 1.0 X-OriginalArrivalTime: 21 May 2008 04:06:10.0971 (UTC) FILETIME=[00E4CEB0:01C8BAF8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1288; t=1211342771; x=1212206771; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20New=20ROLL=20WG=20Document=3A=20draft-brandt-ro ll-home-routing-reqs |Sender:=20 |To:=20<roll@ietf.org>; bh=+ywZZ6I/2x8mV+3CoQshuo2ijgZUd4gQNr2s84ZEu3o=; b=J1A4hRh0y1EcNOzNfyDvX3jNeFzvyIG413RiCgcrmbnLAwvF/EyjgrcvAZ B4hxK8nIz1Fgb2Wf/YrZJl17bonOOa6saR7ENj8cldpMyZVrljklaUpAxNDR iQ+5igf7Tn; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Porcu Giorgio <giorgio.porcu@guest.telecomitalia.it> Subject: [Roll] New ROLL WG Document: draft-brandt-roll-home-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/roll> List-Post: <mailto:roll@ietf.org> List-Help: <mailto:roll-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1072887198==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1072887198== Content-type: multipart/alternative; boundary="B_3294162370_6927515" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3294162370_6927515 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, Considering the good support to adopt draft-brandt-roll-home-routing-reqs as a ROLL WG document, authors please resubmit as draft-ietf-roll-home-routing-reqs-00.txt with no change other than the title, name and date. Note that there were a few comments that you may want to address for the next revision. Thanks. JP. --B_3294162370_6927515 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>New ROLL WG Document: draft-brandt-roll-home-routing-reqs Dear WG,

Considering the good support to adopt draft-brandt-roll-home-routing-reqs a= s a ROLL WG document, authors please resubmit as draft-ietf-roll-home-routin= g-reqs-00.txt with no change other than the title, name and date. Note that = there were a few comments that you may want to address for the next revision= .

Thanks.

JP. --B_3294162370_6927515-- --===============1072887198== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1072887198==-- From roll-bounces@ietf.org Wed May 21 07:15:05 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3063A69B0; Wed, 21 May 2008 07:15:05 -0700 (PDT) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BA03C3A698F; Wed, 21 May 2008 07:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080521141501.BA03C3A698F@core3.amsl.com> Date: Wed, 21 May 2008 07:15:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Home Automation Routing Requirement in Low Power and Lossy Networks Author(s) : A. Brandt, P. Affari Filename : draft-ietf-roll-home-routing-reqs-00.txt Pages : 14 Date : 2008-05-21 This document presents home control and automation application specific requirements for ROuting in Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include lighting control, heating control, sensors, leak detectors, healthcare systems and advanced remote controls. Because such devices only cover a limited radio range, multi-hop routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home network environment. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-home-routing-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-21071237.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --NextPart-- From roll-bounces@ietf.org Thu May 22 00:48:12 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986D928C232; Thu, 22 May 2008 00:48:12 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA8C3A69F4; Thu, 22 May 2008 00:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.979 X-Spam-Level: X-Spam-Status: No, score=-6.979 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFfhIoy2NG0q; Thu, 22 May 2008 00:48:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4DD6B3A6A5A; Thu, 22 May 2008 00:48:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,524,1204498800"; d="scan'208";a="9590612" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 May 2008 09:48:08 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4M7m800016083; Thu, 22 May 2008 09:48:08 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4M7m82n022852; Thu, 22 May 2008 07:48:08 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 09:48:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 May 2008 09:47:34 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> In-Reply-To: <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISA100.11a status and requirements (was RE: [6lowpan] New charter for 6lowpan) Thread-Index: Aci7kNbmHT5GGQ+2TY2at3c8aAYrNQASYm6A References: <482CA4DC.40508@cisco.com><7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com><482DD69F.7080304@cisco.com><208D4602-AE7F-457E-9377-962968881CDE@archrock.com><4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Mark Townsley (townsley)" X-OriginalArrivalTime: 22 May 2008 07:48:08.0356 (UTC) FILETIME=[2D163E40:01C8BBE0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8542; t=1211442488; x=1212306488; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20ISA100.11a=20=20status=20and=20requirements=20( was=20RE=3A=20[6lowpan]=20New=20charter=20for=206lowpan) |Sender:=20; bh=OytlN4Ai8tRteqoM335ysDVg5t0Sn/McD6Ga9h/1tLI=; b=ojIMJOqErIL5v6zm2LVDxc4fXusNCr1+vDkZjnIVVBCbfOrctMEkwoFiKz q/PF+8JdgYR2uwFWcOGWVd33WRtHvdnTHmy2Mu7RQeE60HQUaqvMPBuWq3qF GVWP4DueEA; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org, Jay Werb , Robert Assimiti , "Chernoguzov, Alexander \(PA35\)" , "Polyzois, Christos A" , 6lowpan@ietf.org Subject: [Roll] ISA100.11a status and requirements (was RE: [6lowpan] New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi: My understanding is that defining how mesh-under computes its routes is out of scope for the IETF overall. I'm not even sure we need to document requirements in that space. It's good that we push some requirements to ROLL on route-over, and that's certainly the right time to do so. To Jonathan: I do not completely agree that ISA100 is mesh under. The routing is not specified and left to the system manager implementation. My personal hope is to promote a ROLL solution in ISA100.11a next release. See http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . So the current release of ISA100.11a is at the same level as 6LoWPAN on the matter of routing. In a same fashion, ISA does not define the backbone operation, the fragment recovery mechanism or the Explicit Congestion Notification. For all those features, there's a hope at ISA that the IETF will come up with more generic solutions that they can apply. But time is running out. 6LoWPAN hasn't produced anything for the last 6 months. At this rate, ISA will have to define everything on its own and hopefully publish an informational to this group. At the moment, the first draft of ISA100.11a is in letter ballot. The current draft mostly applies 6loWPAN formats over ISA100.11a DLL, which is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN so ISA is using NaLP headers starting with b'00'. What ISA needs from 6LoWPAN in very short term is in that order: - promote Jonathan's draft as a convergence specification so ISA can at least use standard HC headers. This enables: non-Link-Local-Address compression Hops limit compression UDP checksum compression Better placement of HC2 Which are all mandatory for ISA100.11a - better define the NaLPs. There should be a way to indicate to a 6LoWPAN node whether a NaLP can be skipped and what its length is. - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes to report congestion. - specify a fragment flow control and recovery protocol at the 6LoWPAN Shim layer There is no rocket science in any of this and it all could/should be carried out swiftly. What ISA needs in longer term: - define backbone operation when the backbone federates multiple LoWPANs into a single link (or subnet, TBD). This is more theoretical work for us. Related to proxy ND, a new registration protocols, multilink subnet, etc... Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: jeudi 22 mai 2008 00:20 >To: Mark Townsley (townsley) >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] New charter for 6lowpan > > >Hi Mark: > >On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>> - To your point on ND, this is precisely why the architecture draft >>> is so important. We haven't given it as much attention lately, but >>> it will help resolve the question your raise and many other >>> questions in the future. For example, the architecture draft >>> identifies two modes of operation: mesh-under and route-over. Both >>> of which may require different ND mechanisms. This doesn't apply to >>> just ND, but may apply questions of fragmentation, header >>> compression, security, etc. >> I worry about the under/over debate. It seems that with all the >> effort and enthusiasm in ROLL, we might be well-served at the moment >> by focusing on helping them be successful with route-over than >> spending too much of our time on route-under. > >I worry too, especially since it will pull the WG in different >directions. I'm with you on the preference for route-over, but others >in this group feel strongly about mesh-under as well, especially since >ISA100.11a seems to have adopted a mesh-under approach. I've >personally been focused on developing route-over solutions while being >conscious of supporting mesh-under when possible (evident with 6lowpan- >hc). However, things will start to diverge when we start to talk about >bootstrapping, ND, etc. So we should make a conscious decision of >whether we're supporting one or both. > >-- >Jonathan Hui > >> >>> >>> - I hesitate a bit that we suggest possible solutions to ND in the >>> charter ("reusing the 802.15.4 network structure (use the >>> coordinators)") especially since the definition of such link >>> mechanisms are still in motion within the IEEE. It seems more >>> productive to me if we can develop mechanisms that are less >>> dependent on the specific structure of 802.15.4 mechanisms. >> I agree that we should develop mechanisms that could work >> generically whenever possible. >> >> - Mark >>> >>> Rest of the charter looks good to me. >>> >>> Thanks. >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>> >>>> Pascal Thubert (pthubert) wrote: >>>>> Hi Mark: >>>>> >>>>> I think we need a work item (usually implicit) around the concept >>>>> of >>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>> aspects: >>>>> >>>> >>>>> >>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>> to >>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>> given. >>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>> RFC >>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>> resolve >>>>> for the most part. >>>>> >>>> Are the resolutions backwards compatible with RFC 4944? I'm eager to >>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>> interoperability. >>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>> radio >>>>> mesh exposes the network to congestion collapse, as described in >>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>> provide >>>>> additional functions that would improve the LoWPAN operation WRT >>>>> flow >>>>> control and recovery of fragments. >>>>> >>>> Fragmentation, OK, but why is flow control a network layer issue >>>> rather >>>> than a transport layer issue? >>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>> It >>>>> would be appropriate that the IETF comes up with a proposal to >>>>> implement >>>>> the concept in the IPv6 world. This partially falls under the >>>>> first work >>>>> item on ND but might also include ND proxy over the backbone >>>>> which is a >>>>> stretch to the work item. More in >>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>> . >>>>> >>>> Well, don't we need to define what ND looks like on a lowpan >>>> before we >>>> decide whether it needs to be proxied or not? >>>> >>>> - Mark >>>>> What do you think? >>>>> >>>>> Pascal >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>>> On >>>>>> >>>>> Behalf Of Mark Townsley >>>>> >>>>>> (townsley) >>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>> To: 6lowpan@ietf.org >>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>> >>>>>> >>>>>> I'd like to ask the group one final time for comments on the >>>>>> proposed >>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>> >>>>>> As I said before, soon after the format document was published, >>>>>> there >>>>>> >>>>> is >>>>> >>>>>> nothing stopping the WG from discussing and working on new and >>>>>> existing >>>>>> items at this time. In fact, activity helps us to decide what >>>>>> should be >>>>>> in and out of the charter. Please do not construe not having a >>>>>> charter >>>>>> in place as a reason not to update drafts, or discuss topics >>>>>> that need >>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>> before >>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>> discussions when creating new WG charters. >>>>>> >>>>>> - Mark >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >> > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 22 09:14:42 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC91D28C194; Thu, 22 May 2008 09:14:42 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3833A68B2; Thu, 22 May 2008 09:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USUbAgg6XfI6; Thu, 22 May 2008 09:14:23 -0700 (PDT) Received: from mail.sf.archrock.com (unknown [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 6C37528C158; Thu, 22 May 2008 09:14:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id DC225A935E; Thu, 22 May 2008 09:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZRnP00t8rZA; Thu, 22 May 2008 09:14:09 -0700 (PDT) Received: from [192.168.7.66] (69-12-164-139.sfo.archedrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id AAFBBA921E; Thu, 22 May 2008 09:14:09 -0700 (PDT) Message-Id: <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 22 May 2008 09:14:06 -0700 References: <482CA4DC.40508@cisco.com><7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com><482DD69F.7080304@cisco.com><208D4602-AE7F-457E-9377-962968881CDE@archrock.com><4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: roll@ietf.org, Jay Werb , Robert Assimiti , "Chernoguzov, Alexander \(PA35\)" , "Mark Townsley \(townsley\)" , 6lowpan@ietf.org, "Polyzois, Christos A" Subject: Re: [Roll] ISA100.11a status and requirements (was RE: [6lowpan] New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Pascal, So let's drop the mesh-under/route-over terminology for a second, I think they are confusing since everyone seems to have a different definition for those terms. What I am mainly concerned about is the kind of IP Link abstraction 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g. 802.15.4 and possible others through a BbR), what I've been calling mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the radio range of 802.15.4), what I've been calling route-over. My point to Mark's concern was that solutions to some work items within 6LoWPAN will be different depending on our IP Link abstraction. From what I understand, ISA100.11a has chosen option (i). But to your point below, using IP routing to provide connectivity between nodes within the same IP Link doesn't seem right to me, so it'd be great if you could help me see a path to get there. A lot of this confusion can be cleaned up within the 6LoWPAN architecture document. But I think Mark's concern still stands: whether or not we're focused on one or both of these IP Link abstractions. -- Jonathan Hui On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: > Hi: > > My understanding is that defining how mesh-under computes its routes > is > out of scope for the IETF overall. I'm not even sure we need to > document > requirements in that space. It's good that we push some requirements > to > ROLL on route-over, and that's certainly the right time to do so. > > To Jonathan: I do not completely agree that ISA100 is mesh under. The > routing is not specified and left to the system manager > implementation. > My personal hope is to promote a ROLL solution in ISA100.11a next > release. See > http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . > > So the current release of ISA100.11a is at the same level as 6LoWPAN > on > the matter of routing. > > In a same fashion, ISA does not define the backbone operation, the > fragment recovery mechanism or the Explicit Congestion Notification. > For > all those features, there's a hope at ISA that the IETF will come up > with more generic solutions that they can apply. But time is running > out. > > 6LoWPAN hasn't produced anything for the last 6 months. At this rate, > ISA will have to define everything on its own and hopefully publish an > informational to this group. > > At the moment, the first draft of ISA100.11a is in letter ballot. The > current draft mostly applies 6loWPAN formats over ISA100.11a DLL, > which > is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN > so ISA is using NaLP headers starting with b'00'. > > What ISA needs from 6LoWPAN in very short term is in that order: > - promote Jonathan's draft as a convergence specification so ISA can > at > least use standard HC headers. > This enables: non-Link-Local-Address compression > Hops limit compression > UDP checksum compression > Better placement of HC2 > Which are all mandatory for ISA100.11a > - better define the NaLPs. > There should be a way to indicate to a 6LoWPAN node whether a NaLP > can > be skipped and what its length is. > - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes > to report congestion. > - specify a fragment flow control and recovery protocol at the 6LoWPAN > Shim layer > There is no rocket science in any of this and it all could/should be > carried out swiftly. > > What ISA needs in longer term: > - define backbone operation when the backbone federates multiple > LoWPANs > into a single link (or subnet, TBD). > This is more theoretical work for us. Related to proxy ND, a new > registration protocols, multilink subnet, etc... > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jonathan Hui >> Sent: jeudi 22 mai 2008 00:20 >> To: Mark Townsley (townsley) >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] New charter for 6lowpan >> >> >> Hi Mark: >> >> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>> - To your point on ND, this is precisely why the architecture draft >>>> is so important. We haven't given it as much attention lately, but >>>> it will help resolve the question your raise and many other >>>> questions in the future. For example, the architecture draft >>>> identifies two modes of operation: mesh-under and route-over. Both >>>> of which may require different ND mechanisms. This doesn't apply to >>>> just ND, but may apply questions of fragmentation, header >>>> compression, security, etc. >>> I worry about the under/over debate. It seems that with all the >>> effort and enthusiasm in ROLL, we might be well-served at the moment >>> by focusing on helping them be successful with route-over than >>> spending too much of our time on route-under. >> >> I worry too, especially since it will pull the WG in different >> directions. I'm with you on the preference for route-over, but others >> in this group feel strongly about mesh-under as well, especially >> since >> ISA100.11a seems to have adopted a mesh-under approach. I've >> personally been focused on developing route-over solutions while >> being >> conscious of supporting mesh-under when possible (evident with >> 6lowpan- >> hc). However, things will start to diverge when we start to talk >> about >> bootstrapping, ND, etc. So we should make a conscious decision of >> whether we're supporting one or both. >> >> -- >> Jonathan Hui >> >>> >>>> >>>> - I hesitate a bit that we suggest possible solutions to ND in the >>>> charter ("reusing the 802.15.4 network structure (use the >>>> coordinators)") especially since the definition of such link >>>> mechanisms are still in motion within the IEEE. It seems more >>>> productive to me if we can develop mechanisms that are less >>>> dependent on the specific structure of 802.15.4 mechanisms. >>> I agree that we should develop mechanisms that could work >>> generically whenever possible. >>> >>> - Mark >>>> >>>> Rest of the charter looks good to me. >>>> >>>> Thanks. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> >>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>>> Hi Mark: >>>>>> >>>>>> I think we need a work item (usually implicit) around the concept >>>>>> of >>>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>>> aspects: >>>>>> >>>>> >>>>>> >>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>>> to >>>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>>> given. >>>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>>> RFC >>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>>> resolve >>>>>> for the most part. >>>>>> >>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager > to >>>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>>> interoperability. >>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>>> radio >>>>>> mesh exposes the network to congestion collapse, as described in >>>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>>> provide >>>>>> additional functions that would improve the LoWPAN operation WRT >>>>>> flow >>>>>> control and recovery of fragments. >>>>>> >>>>> Fragmentation, OK, but why is flow control a network layer issue >>>>> rather >>>>> than a transport layer issue? >>>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>>> It >>>>>> would be appropriate that the IETF comes up with a proposal to >>>>>> implement >>>>>> the concept in the IPv6 world. This partially falls under the >>>>>> first work >>>>>> item on ND but might also include ND proxy over the backbone >>>>>> which is a >>>>>> stretch to the work item. More in >>>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>>> . >>>>>> >>>>> Well, don't we need to define what ND looks like on a lowpan >>>>> before we >>>>> decide whether it needs to be proxied or not? >>>>> >>>>> - Mark >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>>>> On >>>>>>> >>>>>> Behalf Of Mark Townsley >>>>>> >>>>>>> (townsley) >>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>> To: 6lowpan@ietf.org >>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>> >>>>>>> >>>>>>> I'd like to ask the group one final time for comments on the >>>>>>> proposed >>>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>>> >>>>>>> As I said before, soon after the format document was published, >>>>>>> there >>>>>>> >>>>>> is >>>>>> >>>>>>> nothing stopping the WG from discussing and working on new and >>>>>>> existing >>>>>>> items at this time. In fact, activity helps us to decide what >>>>>>> should be >>>>>>> in and out of the charter. Please do not construe not having a >>>>>>> charter >>>>>>> in place as a reason not to update drafts, or discuss topics >>>>>>> that need >>>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>>> before >>>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>>> discussions when creating new WG charters. >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>>> >>> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 22 16:29:11 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA38F3A6B63; Thu, 22 May 2008 16:29:11 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2853A6968; Thu, 22 May 2008 16:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAq81WTnZLvj; Thu, 22 May 2008 16:29:08 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 638A23A6807; Thu, 22 May 2008 16:29:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,526,1204520400"; d="scan'208";a="9070060" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 May 2008 19:29:07 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4MNT7BI025155; Thu, 22 May 2008 19:29:07 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4MNT744016366; Thu, 22 May 2008 23:29:07 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 19:29:07 -0400 Received: from 10.21.97.96 ([10.21.97.96]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 May 2008 23:29:07 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 22 May 2008 08:07:16 -0400 From: JP Vasseur To: "David E. Culler" , Mark Townsley Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci8HYWBI63i0eSCHUCAHP2V00SofA== In-Reply-To: <4833379D.7070904@eecs.berkeley.edu> Mime-version: 1.0 X-OriginalArrivalTime: 22 May 2008 23:29:07.0809 (UTC) FILETIME=[A18B1510:01C8BC63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17613; t=1211498947; x=1212362947; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20 |To:=20=22David=20E.=20Culler=22=20,=0A=20=20=20=20=20=20=20=20Mark=20Townsley=20; bh=F3Gi2cmaJO/h2aqF1aXOCNYxmLpwCTUjlu3e6CwOgow=; b=b1FblCaQMZmjLMbfdCWi74xS4LivNc+zGWfCOlrDDc27PrDquFgxk6/+rZ NZ9Eef3RcT4JpS7zLH40cs+p/yNVPZhblcc5Rk9FKDlqZ++yT3xxN18Gk2Tp BvcZwKmbQq; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org, 6lowpan@ietf.org, roll-chairs@tools.ietf.org Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, On 5/20/08 1:42 PM, "David E. Culler" wrote: > Here's my take from ROLL. JP may want to weigh in. For sure, mesh under is clearly out of the scope of ROLL. That said, if there are specifics issues that must be addressed (for example) to take into account 15.4 link specific characteristic they can be addressed as part of the "routing link and node metric" ROLL WG item. By the way I thought that the authors had mentioned to respin their document to focus on 15.4 specific specific aspects. With no ROLL co-chair hat ... my technical comment here is that I would HIGHY want to stress the issue of trying to combine routing decisions at multiple layers. We now have almost two decades of experience and almost (if not all attempt in that direction) have *failed*, leading to complex *and* poorly efficient routing decision: lack of end to end routing consistency, multi-layer recovery issue (timer-based bottom-up approach is usually quite ineffective), ... Further, I would say that there are IMO further higher priorities for 6lowpan. Thanks. JP. > > ROLL has a series of routing requirements documents. We'd like 6LoWPAN > to review, comment, and potentially contribute to those. I think that > it makes sense to continue to run them through ROLL. They are to be > used to guide the analysis of existing routing protocols. I6LoWPAN > might want to use them to guide 6LoWPAN efforts as well. > > ROLL is looking at routing (L3) over low-power and lossy links - > including but not limited to 802.15.4. It is not looking at mesh-under > (L2) forwarding, which the 6LoWPAN adaptation layer provides some > support for. The "requirements" documents in 6LoWPAN so far have been > of a very general observational nature. Perhaps those will become more > focused on the issues most germane to 6LoWPAN. If there is to be more > work on L2 meshing, 6LoWPAN would likely be the only home for it in > IETF. There has been lots of discussion about providing the equivalents > of ICMPv6 and IPv6 hop-by-hop options for mesh under, but it's not clear > if that is on the table. It certainly is not within ROLL. > > A key place of cooperation seems like the ND, Autoconf, ICMPv6 aspects. > For example, how will router advertisements be utilized? To date, much > of the 6LoWPAN ND and bootsrapping discussion has been from 802.15.4 MAC > concepts-up (eg. PAN coordinator) rather than IP down (e.g., DHCPv6). > Being in the internet area, 6LoWPAN is well positioned to lead efforts > that cut across areas. > > D > > > > Mark Townsley wrote: >> Eunsook "Eunah" Kim wrote: >>> Dear AD, and chairmen, >>> >>> It's good to finally see official rechater text. >>> >> It's only proposed text. >>> I think it's pretty well delivering our discussion of rechartering so >>> far, EXCEPT one part; 6lowpan routing requirement. >>> Last meeting (71th IETF), we discussed RR matter and agreed to see >>> IEEE 802.15.4 specific routing requirements for 6LoWPAN. If I remember >>> correctly, we would keep this work with alignment with ROLL, as long >>> as it's not duplicate work with ROLL. >>> >> You could be right. I've cc'd the ROLL chairs here. Roll-chairs, what >> are your expectations from 6lowpan with respect to the >> routing-requirements document? >> >> http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt >> >> I have some more questions for you specifically: >> >> Should that be pulled into roll, or left in 6lowpan? Is roll >> considering the L2"route-under" model at all? Is there anything that >> the L3 "route-over" model might not provide that is listed as a >> requirement for 6lowpan's "route-under" model? If 6lowpan were to work >> on an L2 "route-under" model, would there be constructs (e.g., the >> routing protocol itself and any low-power modifications) from ROLL >> that we would invariably want to try and reuse? >>> I would like to know if it is implied that the RR work is included in >>> Architecture work, OR, if you have *intentionally* excluded the work. >>> If the first case, I would suggest 6LoWPANers check the updated >>> version (-05) of draft. We updated our RR draft (-05) after the >>> meeting based on the meeting discussion, and circulated to the mailing >>> list. >>> >>> If the second case, I think we should get a chance to discuss the >>> updated version. If the meeting decide the fate of this work after >>> that, I would accept it. However, I have problem if AD or chairmen >>> simply exclude this item without such discussion and concensus >>> >> There has never been any intention to go against consensus or limit >> discussion on this topic. So, let's use this thread to get to the >> bottom of what we want to do as a group here. >> >> - Mark >>> Would you please clarify it to me? >>> >>> Thanks, >>> >>> -eunah >>> >>> On Thu, May 15, 2008 at 11:02 PM, Mark Townsley >>> wrote: >>> >>>> I'd like to ask the group one final time for comments on the >>>> proposed new >>>> charter. I've also asked the ROLL WG chairs to comment. >>>> >>>> As I said before, soon after the format document was published, >>>> there is >>>> nothing stopping the WG from discussing and working on new and existing >>>> items at this time. In fact, activity helps us to decide what should >>>> be in >>>> and out of the charter. Please do not construe not having a charter >>>> in place >>>> as a reason not to update drafts, or discuss topics that need to be >>>> discussed. Just as when we have BoF's and mailing lists before >>>> creating a >>>> new WG, it is good to have WG meetings and on-lists discussions when >>>> creating new WG charters. >>>> >>>> - Mark >>>> >>>> >>>> >>>> >>>> >>>> >>>> Background/Introduction: >>>> >>>> Note: Given that there is not much precedent for this type of activity >>>> at the IETF, the text that follows is of an introductory >>>> nature. Hence, its objective is to give a general idea of the >>>> application area and motivations for the work. In particular, this >>>> section is not to be construed as detailing work items for the working >>>> group. That is done in the following section entitled "Scope of the >>>> Working Group." >>>> >>>> Well-established fields such as control networks, and burgeoning ones >>>> such as "sensor" (or transducer) networks, are increasingly being >>>> based on wireless technologies. Most (but certainly not all) of these >>>> nodes are amongst the most constrained that have ever been networked >>>> wirelessly. Extreme low power (such that they will run potentially for >>>> years on batteries) and extreme low cost (total device cost in single >>>> digit dollars, and riding Moore's law to continuously reduce that >>>> price point) are seen as essential enablers towards their deployment >>>> in networks with the following characteristics: >>>> >>>> * Significantly more devices than current networks >>>> >>>> * Severely limited code and ram space (e.g., highly desirable to >>>> fit the required code--MAC, IP and anything else needed to >>>> execute the embedded application-- in, for example, 32K of flash >>>> memory, using 8-bit microprocessors) >>>> >>>> * Unobtrusive but very different user interface for configuration >>>> (e.g., using gestures or interactions involving the physical >>>> world) >>>> >>>> * Robustness and simplicity in routing or network fabric >>>> >>>> A chief component of these devices is wireless communication >>>> technology. In particular, the IEEE 802.15.4 standard is very >>>> promising for the lower (physical and link) layers. As for higher >>>> layer functions, there is considerable interest from non-IETF groups >>>> in using IP technology (the ZigBee alliance, for example, is currently >>>> studying what such a work item might entail). The working group is >>>> expected to coordinate and interact with such groups. >>>> >>>> The required work includes items in the following (incomplete) list: >>>> >>>> * IP adaptation/Packet Formats and interoperability >>>> * Addressing schemes and address management >>>> * Network management >>>> * Routing in dynamically adaptive topologies >>>> * Security, including set-up and maintenance >>>> * Application programming interface >>>> * Discovery (of devices, of services, etc) >>>> * Implementation considerations >>>> >>>> Whereas at least some of the above items are within the purview of the >>>> IETF, at this point it is not clear that all of them are. Accordingly, >>>> the 6LoWPAN working group will address a reduced, more focused set of >>>> objectives. >>>> >>>> Scope of 6lowpan: >>>> >>>> Produce "Problems Statement, Assumptions and Goals for IPv6 for >>>> LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the >>>> problem statement and goals of 6lowpan networks. >>>> >>>> Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN >>>> Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the >>>> basic packet formats and sub-IP adaptation layer for transmission of >>>> IPv6 packets over IEEE 802.15.4. This includes framing, adaptation, >>>> header compression and address generation. Furthermore, IEEE 802.15.4 >>>> devices are expected to be deployed in mesh topologies. >>>> >>>> As such, the working group may also work on an informational document >>>> to show how to apply an existing MANET protocol to LoWPANs (e.g., >>>> AODV, OLSR, DYMO, etc). >>>> >>>> The working group will reuse existing specifications whenever >>>> reasonable and possible. >>>> >>>> The working group will also serve as a venue for ongoing discussions >>>> on other topics related to the more complete list outlined above. >>>> Additional related milestones may be added in the future via a >>>> rechartering operation. >>>> >>>> Note: As may be obvious from its official name above, this particular >>>> working group will not work on IPv4 over IEEE 802.15.4 specifications. >>>> Given the limitations of the target devices, dual-stack deployments >>>> are not practical. Because of its higher potential for header >>>> compression, its support for the huge number of devices expected and >>>> of cleanly built-in features such as address autoconfiguration, IPv6 >>>> is the exclusive focus of the working group. >>>> Goals and Milestones: >>>> Done Working group last call on >>>> draft-ietf-lowpan-goals-assumptions-xx.txt >>>> Done Submit draft-ietf-lowpan-goals-assumptions-xx.txt to >>>> IESG >>>> for consideration of publication as Informational >>>> Done Working Group Last Call on >>>> draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt >>>> Done Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt >>>> to IESG >>>> for consideration of publication as Proposed Standard >>>> >>>> >>>> >>>> Background/Introduction: >>>> >>>> Note: Given that there is not much precedent for this type of activity >>>> at the IETF, the text that follows is of an introductory >>>> nature. Hence, its objective is to give a general idea of the >>>> application area and motivations for the work. In particular, this >>>> section is not to be construed as detailing work items for the working >>>> group. That is done in the following section entitled "Scope of the >>>> Working Group." >>>> >>>> Well-established fields such as control networks, and burgeoning ones >>>> such as "sensor" (or transducer) networks, are increasingly being >>>> based on wireless technologies. Most (but certainly not all) of these >>>> nodes are amongst the most constrained that have ever been networked >>>> wirelessly. Extreme low power (such that they will run potentially for >>>> years on batteries) and extreme low cost (total device cost in single >>>> digit dollars, and riding Moore's law to continuously reduce that >>>> price point) are seen as essential enablers towards their deployment >>>> in networks with the following characteristics: >>>> >>>> * Significantly more devices than current local area networks >>>> >>>> * Severely limited code and ram space (e.g., highly desirable to fit >>>> the required code--MAC, IP and anything else needed to execute the >>>> embedded application-- in, for example, 32K of flash memory, using >>>> 8-bit microprocessors) >>>> >>>> * Unobtrusive but very different user interface for configuration >>>> (e.g., using gestures or interactions involving the physical world) >>>> >>>> A chief component of these devices is wireless communication >>>> technology. In particular, the IEEE 802.15.4 standard is very >>>> promising for the lower (physical and link) layers. As for higher >>>> layer functions, there is considerable interest from non-IETF groups >>>> in using IP technology. The IEEE 1451.5 standard for wireless >>>> transducers has a chapter for 6LoWPAN and the ISA SP100 standard for >>>> wireless industrial networks has adopted 6LoWPAN for their network >>>> layer. This working group is expected to coordinate and interact with >>>> such groups. >>>> >>>> Description of Working Group: >>>> >>>> The working group has completed two RFCs: "IPv6 over Low-Power >>>> Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, >>>> Problem Statement, and Goals" (RFC4919) that documents and discusses >>>> the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 >>>> Networks" (RFC4944) which defines the format for the adaptation >>>> between IPv6 and 802.15.4. >>>> >>>> The Working Group will generate the necessary documents to enusre >>>> interoperable implementations of 6LoWPAN networks and will define the >>>> necessary security and management protocols and constructs for build >>>> 6LoWPAN networks, paying particular attention to protocols already >>>> available. >>>> >>>> Work Items: >>>> >>>> 1. Produce "6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations" >>>> to define the required optimizations to make IPv6 ND applicable in >>>> 6lowpans, given the fact that IPv6 ND is too expensive for the devices >>>> of 6lowpan and requires multicast. >>>> >>>> This document (or these documents - as the working group delves into >>>> this topic it may determine that this should be two separate >>>> documents) will define how to bootstrap a 6lowpan network and explore >>>> ND optimizations such as reusing the 802.15.4 network structure (use >>>> the coordinators), and obviate multicast by having devices talk to >>>> coordinators without creating a single point-of-failure, and changing >>>> the IPv6 ND multicast semantics. This document will be a proposed >>>> standard. >>>> >>>> 2. Produce "Problem Statement for Stateful Header Compression in >>>> 6lowpans" to document the problem of using stateful header compression >>>> (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of >>>> stateless header compression given the assumption that stateful header >>>> compression may be too complex. This document will determine if the >>>> assumption is correct and will be an informational document. The WG >>>> will determine if the assumption is correct at this time and record >>>> the findings in this informational document. >>>> >>>> 3. Produce "6LoWPAN Architecture" to describe the design and >>>> implementation of 6LoWPAN networks. This document will cover the >>>> concepts of "Mesh Under" and "Route Over", 802.15.4 design issues, >>>> network components, addressing, and IPv4/IPv6 network connections. >>>> >>>> 4. Produce "Recommendations for 6lowpan Applications" to define a set >>>> of recommendations of protocols to use for applications. The >>>> recommendations will cover protocols for transport, application layer, >>>> discovery, configuration and commissioning. This document will be an >>>> informational document. >>>> >>>> 5. Produce "6lowpan Security Analysis" to define the threat model of >>>> 6lowpans and to document suitability of existing key management >>>> schemes and to discuss bootstrapping/installation/commissioning/setup >>>> issues. This document will be an informational document. >>>> >>>> The working group will continue to reuse existing protocols and >>>> mechanisms whenever reasonable and possible. >>>> >>>> Goals and Milestones: >>>> >>>> Jan 2008 - First Draft of Bootstrapping and ND Optimization document >>>> Feb 2008 - First Draft of Stateful Header Compression document >>>> Dec 2007 - First Draft of 6LoWPAN Architecture docuement >>>> Feb 2008 - First Draft of Applications document >>>> Mar 2008 - First Draft of Security Analysis >>>> Jun 2008 - Submit Bootstrapping and ND Optimiation document to IESG to >>>> be considered as Proposed Standard >>>> Jul 2008 - Submit Stateful Header Compression document to IESG to be >>>> considered as Proposed Standard >>>> May 2008 - Submit Architecture docuement to IESG to be considered as >>>> Informational RFC >>>> Jul 2008 - Submit Applications docuement to IESG to be considered as >>>> Informational RFC >>>> Sep 2008 - Submit Security Analysis document to IESG to be considered >>>> as Informational RFC. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>>> >>>> >>> >>> >> > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 22 16:29:20 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3AE3A6B7E; Thu, 22 May 2008 16:29:20 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F353A6B7B; Thu, 22 May 2008 16:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.625 X-Spam-Level: X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24eaGDQoL9ch; Thu, 22 May 2008 16:29:17 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 57CA23A6968; Thu, 22 May 2008 16:29:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,526,1204520400"; d="scan'208";a="9079590" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 May 2008 19:29:14 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4MNTEuo015676; Thu, 22 May 2008 19:29:14 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4MNTEYt016402; Thu, 22 May 2008 23:29:14 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 19:29:14 -0400 Received: from 10.21.97.96 ([10.21.97.96]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 May 2008 23:29:14 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 22 May 2008 08:12:50 -0400 From: JP Vasseur To: "Pascal Thubert (pthubert)" , Jonathan Hui , "Mark Townsley (townsley)" Message-ID: Thread-Topic: [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) Thread-Index: Aci7kNbmHT5GGQ+2TY2at3c8aAYrNQASYm6AABD6/iM= In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 22 May 2008 23:29:14.0809 (UTC) FILETIME=[A5B73290:01C8BC63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9475; t=1211498954; x=1212362954; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20ISA100.11a=20status=20and=2 0requirements=20(was=20RE=3A=20New=20charter=0A=20for=206low pan) |Sender:=20 |To:=20=22Pascal=20Thubert=20(pthubert)=22=20,=0A=20=20=20=20=20=20=20=20Jonathan=20Hui=20,=0A=20=20=20=20=20=20=20=20=22Mark=20Townsley=20( townsley)=22=20; bh=iaJ17L31JrUKt9FLdnjmqz4r8blu8uL5bwewTnmlb0g=; b=XFXYtgRp2t+2eDG/Z1eDZOLzNy+fHdCeFzG02pIxhhe/zA4trKoRAShueV 2JwtO8ykc8MfqRQk/AnlgbRDhhTJCYRO6hJ0vc53Tklb09WZX7IfHz7rwLyR 3WAqfWUgk8; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "Chernoguzov, Alexander \(PA35\)" , roll@ietf.org, 6lowpan@ietf.org, Jay Werb , "Polyzois, Christos A" Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Pascal, On 5/22/08 12:47 AM, "Pascal Thubert (pthubert)" wrote: > Hi: > > My understanding is that defining how mesh-under computes its routes is > out of scope for the IETF overall. I'm not even sure we need to document > requirements in that space. Well you just saw my reply to the other email, we're in sync. It's good that we push some requirements to > ROLL on route-over, and that's certainly the right time to do so. > > To Jonathan: I do not completely agree that ISA100 is mesh under. The > routing is not specified and left to the system manager implementation. > My personal hope is to promote a ROLL solution in ISA100.11a next > release. See > http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . > Considering the quick progress we hope to have something soon. > So the current release of ISA100.11a is at the same level as 6LoWPAN on > the matter of routing. > > In a same fashion, ISA does not define the backbone operation, the > fragment recovery mechanism or the Explicit Congestion Notification. For > all those features, there's a hope at ISA that the IETF will come up > with more generic solutions that they can apply. But time is running > out. > > 6LoWPAN hasn't produced anything for the last 6 months. At this rate, > ISA will have to define everything on its own and hopefully publish an > informational to this group. Sharing your view. > > At the moment, the first draft of ISA100.11a is in letter ballot. The > current draft mostly applies 6loWPAN formats over ISA100.11a DLL, which > is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN > so ISA is using NaLP headers starting with b'00'. > > What ISA needs from 6LoWPAN in very short term is in that order: > - promote Jonathan's draft as a convergence specification so ISA can at > least use standard HC headers. > This enables: non-Link-Local-Address compression > Hops limit compression > UDP checksum compression > Better placement of HC2 > Which are all mandatory for ISA100.11a > - better define the NaLPs. > There should be a way to indicate to a 6LoWPAN node whether a NaLP can > be skipped and what its length is. > - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes > to report congestion. This would be worth having a discussion on this, probably a specific thread. > - specify a fragment flow control and recovery protocol at the 6LoWPAN > Shim layer Will reply to this in another email thread. > There is no rocket science in any of this and it all could/should be > carried out swiftly. > > What ISA needs in longer term: > - define backbone operation when the backbone federates multiple LoWPANs > into a single link (or subnet, TBD). Mmmm "Subnet" please. > This is more theoretical work for us. Related to proxy ND, a new > registration protocols, multilink subnet, etc... Thanks. JP. > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jonathan Hui >> Sent: jeudi 22 mai 2008 00:20 >> To: Mark Townsley (townsley) >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] New charter for 6lowpan >> >> >> Hi Mark: >> >> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>> - To your point on ND, this is precisely why the architecture draft >>>> is so important. We haven't given it as much attention lately, but >>>> it will help resolve the question your raise and many other >>>> questions in the future. For example, the architecture draft >>>> identifies two modes of operation: mesh-under and route-over. Both >>>> of which may require different ND mechanisms. This doesn't apply to >>>> just ND, but may apply questions of fragmentation, header >>>> compression, security, etc. >>> I worry about the under/over debate. It seems that with all the >>> effort and enthusiasm in ROLL, we might be well-served at the moment >>> by focusing on helping them be successful with route-over than >>> spending too much of our time on route-under. >> >> I worry too, especially since it will pull the WG in different >> directions. I'm with you on the preference for route-over, but others >> in this group feel strongly about mesh-under as well, especially since >> ISA100.11a seems to have adopted a mesh-under approach. I've >> personally been focused on developing route-over solutions while being >> conscious of supporting mesh-under when possible (evident with 6lowpan- >> hc). However, things will start to diverge when we start to talk about >> bootstrapping, ND, etc. So we should make a conscious decision of >> whether we're supporting one or both. >> >> -- >> Jonathan Hui >> >>> >>>> >>>> - I hesitate a bit that we suggest possible solutions to ND in the >>>> charter ("reusing the 802.15.4 network structure (use the >>>> coordinators)") especially since the definition of such link >>>> mechanisms are still in motion within the IEEE. It seems more >>>> productive to me if we can develop mechanisms that are less >>>> dependent on the specific structure of 802.15.4 mechanisms. >>> I agree that we should develop mechanisms that could work >>> generically whenever possible. >>> >>> - Mark >>>> >>>> Rest of the charter looks good to me. >>>> >>>> Thanks. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> >>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>>> Hi Mark: >>>>>> >>>>>> I think we need a work item (usually implicit) around the concept >>>>>> of >>>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>>> aspects: >>>>>> >>>>> >>>>>> >>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>>> to >>>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>>> given. >>>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>>> RFC >>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>>> resolve >>>>>> for the most part. >>>>>> >>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager > to >>>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>>> interoperability. >>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>>> radio >>>>>> mesh exposes the network to congestion collapse, as described in >>>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>>> provide >>>>>> additional functions that would improve the LoWPAN operation WRT >>>>>> flow >>>>>> control and recovery of fragments. >>>>>> >>>>> Fragmentation, OK, but why is flow control a network layer issue >>>>> rather >>>>> than a transport layer issue? >>>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>>> It >>>>>> would be appropriate that the IETF comes up with a proposal to >>>>>> implement >>>>>> the concept in the IPv6 world. This partially falls under the >>>>>> first work >>>>>> item on ND but might also include ND proxy over the backbone >>>>>> which is a >>>>>> stretch to the work item. More in >>>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>>> . >>>>>> >>>>> Well, don't we need to define what ND looks like on a lowpan >>>>> before we >>>>> decide whether it needs to be proxied or not? >>>>> >>>>> - Mark >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>>>> On >>>>>>> >>>>>> Behalf Of Mark Townsley >>>>>> >>>>>>> (townsley) >>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>> To: 6lowpan@ietf.org >>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>> >>>>>>> >>>>>>> I'd like to ask the group one final time for comments on the >>>>>>> proposed >>>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>>> >>>>>>> As I said before, soon after the format document was published, >>>>>>> there >>>>>>> >>>>>> is >>>>>> >>>>>>> nothing stopping the WG from discussing and working on new and >>>>>>> existing >>>>>>> items at this time. In fact, activity helps us to decide what >>>>>>> should be >>>>>>> in and out of the charter. Please do not construe not having a >>>>>>> charter >>>>>>> in place as a reason not to update drafts, or discuss topics >>>>>>> that need >>>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>>> before >>>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>>> discussions when creating new WG charters. >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>>> >>> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 22 19:32:22 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E50673A693A; Thu, 22 May 2008 19:32:22 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F7728C164; Thu, 22 May 2008 15:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEdbWB6zSoqJ; Thu, 22 May 2008 15:54:23 -0700 (PDT) Received: from grab.coslabs.com (unknown [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 3F69E28C13A; Thu, 22 May 2008 15:54:23 -0700 (PDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id m4MMsCWV009470; Thu, 22 May 2008 16:54:13 -0600 (MDT) From: Geoff Mulligan To: Jonathan Hui In-Reply-To: <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> Date: Thu, 22 May 2008 16:54:20 -0600 Message-Id: <1211496860.23290.41.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 X-Mailman-Approved-At: Thu, 22 May 2008 19:32:21 -0700 Cc: roll@ietf.org, Jay Werb , "Polyzois, Christos A" , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Aren't both abstractions equally valid? I think that the biggest issue with a mesh under is that there is no one standard for it. ISA100 is one; I have done another using AODVtiny; I think Jennic has one using their mesh protocol and there are others. If IEEE had defined a multi-hop L2 mesh then we could point at that and define a solution for ND and bootstrapping and security and ... for it. The WG decided a couple of meetings ago that we would focus on solutions for the Route Over abstraction. [If while we are doing this we can keep in mind some of the issues w.r.t. mesh under that's good.] Somewhat independent from this is the HC1G draft that is important to deal with since we do need a way to efficiently handle non-local addresses. So as to remove the mesh under vs. route over issues from the HC1G draft I would like to see the draft updated to remove the UDP checksum optimization. I would like to ask the WG if we should consider taking draft-hui-6lowpan-hc-00.txt on a a WG document, with the change of removing the UDP checksum compression. geoff On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote: > Hi Pascal, > > So let's drop the mesh-under/route-over terminology for a second, I > think they are confusing since everyone seems to have a different > definition for those terms. > > What I am mainly concerned about is the kind of IP Link abstraction > 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g. > 802.15.4 and possible others through a BbR), what I've been calling > mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the > radio range of 802.15.4), what I've been calling route-over. My point > to Mark's concern was that solutions to some work items within 6LoWPAN > will be different depending on our IP Link abstraction. From what I > understand, ISA100.11a has chosen option (i). But to your point below, > using IP routing to provide connectivity between nodes within the same > IP Link doesn't seem right to me, so it'd be great if you could help > me see a path to get there. > > A lot of this confusion can be cleaned up within the 6LoWPAN > architecture document. But I think Mark's concern still stands: > whether or not we're focused on one or both of these IP Link > abstractions. > > -- > Jonathan Hui > > On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: > > > Hi: > > > > My understanding is that defining how mesh-under computes its routes > > is > > out of scope for the IETF overall. I'm not even sure we need to > > document > > requirements in that space. It's good that we push some requirements > > to > > ROLL on route-over, and that's certainly the right time to do so. > > > > To Jonathan: I do not completely agree that ISA100 is mesh under. The > > routing is not specified and left to the system manager > > implementation. > > My personal hope is to promote a ROLL solution in ISA100.11a next > > release. See > > http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . > > > > So the current release of ISA100.11a is at the same level as 6LoWPAN > > on > > the matter of routing. > > > > In a same fashion, ISA does not define the backbone operation, the > > fragment recovery mechanism or the Explicit Congestion Notification. > > For > > all those features, there's a hope at ISA that the IETF will come up > > with more generic solutions that they can apply. But time is running > > out. > > > > 6LoWPAN hasn't produced anything for the last 6 months. At this rate, > > ISA will have to define everything on its own and hopefully publish an > > informational to this group. > > > > At the moment, the first draft of ISA100.11a is in letter ballot. The > > current draft mostly applies 6loWPAN formats over ISA100.11a DLL, > > which > > is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN > > so ISA is using NaLP headers starting with b'00'. > > > > What ISA needs from 6LoWPAN in very short term is in that order: > > - promote Jonathan's draft as a convergence specification so ISA can > > at > > least use standard HC headers. > > This enables: non-Link-Local-Address compression > > Hops limit compression > > UDP checksum compression > > Better placement of HC2 > > Which are all mandatory for ISA100.11a > > - better define the NaLPs. > > There should be a way to indicate to a 6LoWPAN node whether a NaLP > > can > > be skipped and what its length is. > > - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes > > to report congestion. > > - specify a fragment flow control and recovery protocol at the 6LoWPAN > > Shim layer > > There is no rocket science in any of this and it all could/should be > > carried out swiftly. > > > > What ISA needs in longer term: > > - define backbone operation when the backbone federates multiple > > LoWPANs > > into a single link (or subnet, TBD). > > This is more theoretical work for us. Related to proxy ND, a new > > registration protocols, multilink subnet, etc... > > > > Pascal > > > >> -----Original Message----- > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Jonathan Hui > >> Sent: jeudi 22 mai 2008 00:20 > >> To: Mark Townsley (townsley) > >> Cc: 6lowpan@ietf.org > >> Subject: Re: [6lowpan] New charter for 6lowpan > >> > >> > >> Hi Mark: > >> > >> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: > >>>> - To your point on ND, this is precisely why the architecture draft > >>>> is so important. We haven't given it as much attention lately, but > >>>> it will help resolve the question your raise and many other > >>>> questions in the future. For example, the architecture draft > >>>> identifies two modes of operation: mesh-under and route-over. Both > >>>> of which may require different ND mechanisms. This doesn't apply to > >>>> just ND, but may apply questions of fragmentation, header > >>>> compression, security, etc. > >>> I worry about the under/over debate. It seems that with all the > >>> effort and enthusiasm in ROLL, we might be well-served at the moment > >>> by focusing on helping them be successful with route-over than > >>> spending too much of our time on route-under. > >> > >> I worry too, especially since it will pull the WG in different > >> directions. I'm with you on the preference for route-over, but others > >> in this group feel strongly about mesh-under as well, especially > >> since > >> ISA100.11a seems to have adopted a mesh-under approach. I've > >> personally been focused on developing route-over solutions while > >> being > >> conscious of supporting mesh-under when possible (evident with > >> 6lowpan- > >> hc). However, things will start to diverge when we start to talk > >> about > >> bootstrapping, ND, etc. So we should make a conscious decision of > >> whether we're supporting one or both. > >> > >> -- > >> Jonathan Hui > >> > >>> > >>>> > >>>> - I hesitate a bit that we suggest possible solutions to ND in the > >>>> charter ("reusing the 802.15.4 network structure (use the > >>>> coordinators)") especially since the definition of such link > >>>> mechanisms are still in motion within the IEEE. It seems more > >>>> productive to me if we can develop mechanisms that are less > >>>> dependent on the specific structure of 802.15.4 mechanisms. > >>> I agree that we should develop mechanisms that could work > >>> generically whenever possible. > >>> > >>> - Mark > >>>> > >>>> Rest of the charter looks good to me. > >>>> > >>>> Thanks. > >>>> > >>>> -- > >>>> Jonathan Hui > >>>> > >>>> > >>>> > >>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: > >>>> > >>>>> Pascal Thubert (pthubert) wrote: > >>>>>> Hi Mark: > >>>>>> > >>>>>> I think we need a work item (usually implicit) around the concept > >>>>>> of > >>>>>> improving existing WG RFCs. RFC 4944 can be improved in several > >>>>>> aspects: > >>>>>> > >>>>> > >>>>>> > >>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a > >>>>>> to > >>>>>> conform to 6LoWPAN would be a major win, but is certainly not a > >>>>>> given. > >>>>>> At the moment, the ISA100.11a documents expose discrepencies with > >>>>>> RFC > >>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc > >>>>>> resolve > >>>>>> for the most part. > >>>>>> > >>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager > > to > >>>>> improve RFC 4944, but not eager to endorse changes that inhibit > >>>>> interoperability. > >>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop > >>>>>> radio > >>>>>> mesh exposes the network to congestion collapse, as described in > >>>>>> > > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec > >>>>>> overy . I think that the WG should dedicate some bandwitdth to > >>>>>> provide > >>>>>> additional functions that would improve the LoWPAN operation WRT > >>>>>> flow > >>>>>> control and recovery of fragments. > >>>>>> > >>>>> Fragmentation, OK, but why is flow control a network layer issue > >>>>> rather > >>>>> than a transport layer issue? > >>>>>> Another aspect of ISA100.11a is the concept of a backbone router. > >>>>>> It > >>>>>> would be appropriate that the IETF comes up with a proposal to > >>>>>> implement > >>>>>> the concept in the IPv6 world. This partially falls under the > >>>>>> first work > >>>>>> item on ND but might also include ND proxy over the backbone > >>>>>> which is a > >>>>>> stretch to the work item. More in > >>>>>> > > http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router > >>>>>> . > >>>>>> > >>>>> Well, don't we need to define what ND looks like on a lowpan > >>>>> before we > >>>>> decide whether it needs to be proxied or not? > >>>>> > >>>>> - Mark > >>>>>> What do you think? > >>>>>> > >>>>>> Pascal > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] > >>>>>>> On > >>>>>>> > >>>>>> Behalf Of Mark Townsley > >>>>>> > >>>>>>> (townsley) > >>>>>>> Sent: jeudi 15 mai 2008 23:02 > >>>>>>> To: 6lowpan@ietf.org > >>>>>>> Subject: [6lowpan] New charter for 6lowpan > >>>>>>> > >>>>>>> > >>>>>>> I'd like to ask the group one final time for comments on the > >>>>>>> proposed > >>>>>>> new charter. I've also asked the ROLL WG chairs to comment. > >>>>>>> > >>>>>>> As I said before, soon after the format document was published, > >>>>>>> there > >>>>>>> > >>>>>> is > >>>>>> > >>>>>>> nothing stopping the WG from discussing and working on new and > >>>>>>> existing > >>>>>>> items at this time. In fact, activity helps us to decide what > >>>>>>> should be > >>>>>>> in and out of the charter. Please do not construe not having a > >>>>>>> charter > >>>>>>> in place as a reason not to update drafts, or discuss topics > >>>>>>> that need > >>>>>>> to be discussed. Just as when we have BoF's and mailing lists > >>>>>>> before > >>>>>>> creating a new WG, it is good to have WG meetings and on-lists > >>>>>>> discussions when creating new WG charters. > >>>>>>> > >>>>>>> - Mark > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 6lowpan mailing list > >>>>> 6lowpan@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/6lowpan > >>>> > >>>> > >>> > >> > >> _______________________________________________ > >> 6lowpan mailing list > >> 6lowpan@ietf.org > >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 22 19:32:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB023A6BA9; Thu, 22 May 2008 19:32:33 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E157A3A6B30; Thu, 22 May 2008 17:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id av2qEGFMkaPw; Thu, 22 May 2008 17:19:02 -0700 (PDT) Received: from grab.coslabs.com (unknown [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id A54B33A6C0D; Thu, 22 May 2008 17:18:46 -0700 (PDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id m4N0ITb7009945; Thu, 22 May 2008 18:18:29 -0600 (MDT) From: Geoff Mulligan To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> Date: Thu, 22 May 2008 18:18:37 -0600 Message-Id: <1211501917.23290.59.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 X-Mailman-Approved-At: Thu, 22 May 2008 19:32:32 -0700 Cc: roll@ietf.org, Jay Werb , "Chernoguzov, Alexander \(PA35\)" , "Mark Townsley \(townsley\)" , "Polyzois, Christos A" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Pascal, On Thu, 2008-05-22 at 09:47 +0200, Pascal Thubert (pthubert) wrote: > Hi: > > My understanding is that defining how mesh-under computes its routes is > out of scope for the IETF overall. I'm not even sure we need to document > requirements in that space. It's good that we push some requirements to > ROLL on route-over, and that's certainly the right time to do so. > I'm not completely positive that this is true, but I do think that it is not in the scope of 6lowpan right now. > To Jonathan: I do not completely agree that ISA100 is mesh under. The > routing is not specified and left to the system manager implementation. > My personal hope is to promote a ROLL solution in ISA100.11a next > release. See > http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . > I have to disagree. While the system manager can choose some routing options, my understanding of the ISA100 DLL is that it does offer a mesh under layer 2. > So the current release of ISA100.11a is at the same level as 6LoWPAN on > the matter of routing. > > In a same fashion, ISA does not define the backbone operation, the > fragment recovery mechanism or the Explicit Congestion Notification. For > all those features, there's a hope at ISA that the IETF will come up > with more generic solutions that they can apply. But time is running > out. > > 6LoWPAN hasn't produced anything for the last 6 months. At this rate, > ISA will have to define everything on its own and hopefully publish an > informational to this group. > > At the moment, the first draft of ISA100.11a is in letter ballot. The > current draft mostly applies 6loWPAN formats over ISA100.11a DLL, which > is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN > so ISA is using NaLP headers starting with b'00'. And this still needs to be discussed in ISA100. I'm not sure that a NALP is the correct header and we have had this discussion in ISA100. I'm hoping that this will be corrected in a subsequent draft. > > What ISA needs from 6LoWPAN in very short term is in that order: > - promote Jonathan's draft as a convergence specification so ISA can at > least use standard HC headers. > This enables: non-Link-Local-Address compression > Hops limit compression > UDP checksum compression > Better placement of HC2 > Which are all mandatory for ISA100.11a I don't think that these are all mandatory. The problem with the current ISA100 draft is that there was a clear statement that ISA100 would be compliant with 6lowpan and the application layer has chosen not to be compliant and to try to push changes into 6lowpan to make 6lowpan compliant with ISA100. There is some concern that has been expressed that we are prematurely optimizing the headers. I'm not convinced that the benefits of saving 3 bytes outweighs un-thought-of issues that might come about because of these optimizations. > - better define the NaLPs. > There should be a way to indicate to a 6LoWPAN node whether a NaLP can > be skipped and what its length is. I'm not sure that 6lowpan should specify this. I think that is what a nalp is for. The bits following it are unknown. I think that ISA100 should apply for a dispatch value and should include a dll header length so that it can be skipped. > - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes > to report congestion. > - specify a fragment flow control and recovery protocol at the 6LoWPAN > Shim layer > There is no rocket science in any of this and it all could/should be > carried out swiftly. > > What ISA needs in longer term: > - define backbone operation when the backbone federates multiple LoWPANs > into a single link (or subnet, TBD). > This is more theoretical work for us. Related to proxy ND, a new > registration protocols, multilink subnet, etc... > > Pascal > > >-----Original Message----- > >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jonathan Hui > >Sent: jeudi 22 mai 2008 00:20 > >To: Mark Townsley (townsley) > >Cc: 6lowpan@ietf.org > >Subject: Re: [6lowpan] New charter for 6lowpan > > > > > >Hi Mark: > > > >On May 20, 2008, at 8:24 AM, Mark Townsley wrote: > >>> - To your point on ND, this is precisely why the architecture draft > >>> is so important. We haven't given it as much attention lately, but > >>> it will help resolve the question your raise and many other > >>> questions in the future. For example, the architecture draft > >>> identifies two modes of operation: mesh-under and route-over. Both > >>> of which may require different ND mechanisms. This doesn't apply to > >>> just ND, but may apply questions of fragmentation, header > >>> compression, security, etc. > >> I worry about the under/over debate. It seems that with all the > >> effort and enthusiasm in ROLL, we might be well-served at the moment > >> by focusing on helping them be successful with route-over than > >> spending too much of our time on route-under. > > > >I worry too, especially since it will pull the WG in different > >directions. I'm with you on the preference for route-over, but others > >in this group feel strongly about mesh-under as well, especially since > >ISA100.11a seems to have adopted a mesh-under approach. I've > >personally been focused on developing route-over solutions while being > >conscious of supporting mesh-under when possible (evident with 6lowpan- > >hc). However, things will start to diverge when we start to talk about > >bootstrapping, ND, etc. So we should make a conscious decision of > >whether we're supporting one or both. > > > >-- > >Jonathan Hui > > > >> > >>> > >>> - I hesitate a bit that we suggest possible solutions to ND in the > >>> charter ("reusing the 802.15.4 network structure (use the > >>> coordinators)") especially since the definition of such link > >>> mechanisms are still in motion within the IEEE. It seems more > >>> productive to me if we can develop mechanisms that are less > >>> dependent on the specific structure of 802.15.4 mechanisms. > >> I agree that we should develop mechanisms that could work > >> generically whenever possible. > >> > >> - Mark > >>> > >>> Rest of the charter looks good to me. > >>> > >>> Thanks. > >>> > >>> -- > >>> Jonathan Hui > >>> > >>> > >>> > >>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: > >>> > >>>> Pascal Thubert (pthubert) wrote: > >>>>> Hi Mark: > >>>>> > >>>>> I think we need a work item (usually implicit) around the concept > >>>>> of > >>>>> improving existing WG RFCs. RFC 4944 can be improved in several > >>>>> aspects: > >>>>> > >>>> > >>>>> > >>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a > >>>>> to > >>>>> conform to 6LoWPAN would be a major win, but is certainly not a > >>>>> given. > >>>>> At the moment, the ISA100.11a documents expose discrepencies with > >>>>> RFC > >>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc > >>>>> resolve > >>>>> for the most part. > >>>>> > >>>> Are the resolutions backwards compatible with RFC 4944? I'm eager > to > >>>> improve RFC 4944, but not eager to endorse changes that inhibit > >>>> interoperability. > >>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop > >>>>> radio > >>>>> mesh exposes the network to congestion collapse, as described in > >>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec > >>>>> overy . I think that the WG should dedicate some bandwitdth to > >>>>> provide > >>>>> additional functions that would improve the LoWPAN operation WRT > >>>>> flow > >>>>> control and recovery of fragments. > >>>>> > >>>> Fragmentation, OK, but why is flow control a network layer issue > >>>> rather > >>>> than a transport layer issue? > >>>>> Another aspect of ISA100.11a is the concept of a backbone router. > >>>>> It > >>>>> would be appropriate that the IETF comes up with a proposal to > >>>>> implement > >>>>> the concept in the IPv6 world. This partially falls under the > >>>>> first work > >>>>> item on ND but might also include ND proxy over the backbone > >>>>> which is a > >>>>> stretch to the work item. More in > >>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router > >>>>> . > >>>>> > >>>> Well, don't we need to define what ND looks like on a lowpan > >>>> before we > >>>> decide whether it needs to be proxied or not? > >>>> > >>>> - Mark > >>>>> What do you think? > >>>>> > >>>>> Pascal > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] > >>>>>> On > >>>>>> > >>>>> Behalf Of Mark Townsley > >>>>> > >>>>>> (townsley) > >>>>>> Sent: jeudi 15 mai 2008 23:02 > >>>>>> To: 6lowpan@ietf.org > >>>>>> Subject: [6lowpan] New charter for 6lowpan > >>>>>> > >>>>>> > >>>>>> I'd like to ask the group one final time for comments on the > >>>>>> proposed > >>>>>> new charter. I've also asked the ROLL WG chairs to comment. > >>>>>> > >>>>>> As I said before, soon after the format document was published, > >>>>>> there > >>>>>> > >>>>> is > >>>>> > >>>>>> nothing stopping the WG from discussing and working on new and > >>>>>> existing > >>>>>> items at this time. In fact, activity helps us to decide what > >>>>>> should be > >>>>>> in and out of the charter. Please do not construe not having a > >>>>>> charter > >>>>>> in place as a reason not to update drafts, or discuss topics > >>>>>> that need > >>>>>> to be discussed. Just as when we have BoF's and mailing lists > >>>>>> before > >>>>>> creating a new WG, it is good to have WG meetings and on-lists > >>>>>> discussions when creating new WG charters. > >>>>>> > >>>>>> - Mark > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> 6lowpan mailing list > >>>> 6lowpan@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/6lowpan > >>> > >>> > >> > > > >_______________________________________________ > >6lowpan mailing list > >6lowpan@ietf.org > >https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri May 23 00:49:53 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED7B3A6C4E; Fri, 23 May 2008 00:49:53 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5113D3A6C01; Fri, 23 May 2008 00:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.042 X-Spam-Level: X-Spam-Status: No, score=-7.042 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hU+4KPN6hWi; Fri, 23 May 2008 00:49:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 58B473A6C73; Fri, 23 May 2008 00:48:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,528,1204498800"; d="scan'208";a="9701664" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 May 2008 09:48:41 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4N7me2u025569; Fri, 23 May 2008 09:48:40 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4N7mei9018997; Fri, 23 May 2008 07:48:41 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 May 2008 09:48:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 May 2008 09:48:08 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05B6148E@xmb-ams-337.emea.cisco.com> In-Reply-To: <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISA100.11a status and requirements (was RE: [6lowpan] New charter for 6lowpan) Thread-Index: Aci8JwhP5EG8Whb3Sk+ZsgRvA4gH/gAga9Sg References: <482CA4DC.40508@cisco.com><7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com><482DD69F.7080304@cisco.com><208D4602-AE7F-457E-9377-962968881CDE@archrock.com><4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 23 May 2008 07:48:40.0838 (UTC) FILETIME=[6ADC5A60:01C8BCA9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11329; t=1211528920; x=1212392920; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20ISA100.11a=20=20status=20and=20requirem ents=20(was=20RE=3A=20[6lowpan]=20New=20charter=20for=206low pan) |Sender:=20; bh=BwVStKpvilR8NbcWaf/BU+WrLibosktc5qOIQv4dgSw=; b=v8AUIUha351RAGGGYhgel7Nwem7h9oXG50KNYyn7f1u7rc/K9Fp+IQCiNE wjqL08AEBghQa7nms7+/esCd9GP/RfKvciCJUdrfu4lgqbiyWcMU+LR/40kc yPNKoht147; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org, Jay Werb , Robert Assimiti , "Chernoguzov, Alexander \(PA35\)" , "Mark Townsley \(townsley\)" , 6lowpan@ietf.org, "Polyzois, Christos A" Subject: Re: [Roll] ISA100.11a status and requirements (was RE: [6lowpan] New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Jonathan: I agree we need a definition of mesh under; and that we have not found one yet that satisties us all. For me, mesh under is when L2 takes care of the connectivity between nodes and L3 sees everyone on the media. E.g. NBMA. And route over is when IP has to take care of routing between nodes. E.g. P2MP. What is important is that the route over has an end to end scope across the radio hops and the rest of the way. Whereas mesh under optimizes within the mesh but could create an overall poor end to end path, like a zig zag. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: jeudi 22 mai 2008 18:14 >To: Pascal Thubert (pthubert) >Cc: Mark Townsley (townsley); 6lowpan@ietf.org; Jay Werb; Polyzois, Christos A; Chernoguzov, >Alexander (PA35); Robert Assimiti; roll@ietf.org >Subject: Re: ISA100.11a status and requirements (was RE: [6lowpan] New charter for 6lowpan) > > >Hi Pascal, > >So let's drop the mesh-under/route-over terminology for a second, I >think they are confusing since everyone seems to have a different >definition for those terms. > >What I am mainly concerned about is the kind of IP Link abstraction >6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g. >802.15.4 and possible others through a BbR), what I've been calling >mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the >radio range of 802.15.4), what I've been calling route-over. My point >to Mark's concern was that solutions to some work items within 6LoWPAN >will be different depending on our IP Link abstraction. From what I >understand, ISA100.11a has chosen option (i). But to your point below, >using IP routing to provide connectivity between nodes within the same >IP Link doesn't seem right to me, so it'd be great if you could help >me see a path to get there. > >A lot of this confusion can be cleaned up within the 6LoWPAN >architecture document. But I think Mark's concern still stands: >whether or not we're focused on one or both of these IP Link >abstractions. > >-- >Jonathan Hui > >On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: > >> Hi: >> >> My understanding is that defining how mesh-under computes its routes >> is >> out of scope for the IETF overall. I'm not even sure we need to >> document >> requirements in that space. It's good that we push some requirements >> to >> ROLL on route-over, and that's certainly the right time to do so. >> >> To Jonathan: I do not completely agree that ISA100 is mesh under. The >> routing is not specified and left to the system manager >> implementation. >> My personal hope is to promote a ROLL solution in ISA100.11a next >> release. See >> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . >> >> So the current release of ISA100.11a is at the same level as 6LoWPAN >> on >> the matter of routing. >> >> In a same fashion, ISA does not define the backbone operation, the >> fragment recovery mechanism or the Explicit Congestion Notification. >> For >> all those features, there's a hope at ISA that the IETF will come up >> with more generic solutions that they can apply. But time is running >> out. >> >> 6LoWPAN hasn't produced anything for the last 6 months. At this rate, >> ISA will have to define everything on its own and hopefully publish an >> informational to this group. >> >> At the moment, the first draft of ISA100.11a is in letter ballot. The >> current draft mostly applies 6loWPAN formats over ISA100.11a DLL, >> which >> is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN >> so ISA is using NaLP headers starting with b'00'. >> >> What ISA needs from 6LoWPAN in very short term is in that order: >> - promote Jonathan's draft as a convergence specification so ISA can >> at >> least use standard HC headers. >> This enables: non-Link-Local-Address compression >> Hops limit compression >> UDP checksum compression >> Better placement of HC2 >> Which are all mandatory for ISA100.11a >> - better define the NaLPs. >> There should be a way to indicate to a 6LoWPAN node whether a NaLP >> can >> be skipped and what its length is. >> - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes >> to report congestion. >> - specify a fragment flow control and recovery protocol at the 6LoWPAN >> Shim layer >> There is no rocket science in any of this and it all could/should be >> carried out swiftly. >> >> What ISA needs in longer term: >> - define backbone operation when the backbone federates multiple >> LoWPANs >> into a single link (or subnet, TBD). >> This is more theoretical work for us. Related to proxy ND, a new >> registration protocols, multilink subnet, etc... >> >> Pascal >> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Jonathan Hui >>> Sent: jeudi 22 mai 2008 00:20 >>> To: Mark Townsley (townsley) >>> Cc: 6lowpan@ietf.org >>> Subject: Re: [6lowpan] New charter for 6lowpan >>> >>> >>> Hi Mark: >>> >>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>>> - To your point on ND, this is precisely why the architecture draft >>>>> is so important. We haven't given it as much attention lately, but >>>>> it will help resolve the question your raise and many other >>>>> questions in the future. For example, the architecture draft >>>>> identifies two modes of operation: mesh-under and route-over. Both >>>>> of which may require different ND mechanisms. This doesn't apply to >>>>> just ND, but may apply questions of fragmentation, header >>>>> compression, security, etc. >>>> I worry about the under/over debate. It seems that with all the >>>> effort and enthusiasm in ROLL, we might be well-served at the moment >>>> by focusing on helping them be successful with route-over than >>>> spending too much of our time on route-under. >>> >>> I worry too, especially since it will pull the WG in different >>> directions. I'm with you on the preference for route-over, but others >>> in this group feel strongly about mesh-under as well, especially >>> since >>> ISA100.11a seems to have adopted a mesh-under approach. I've >>> personally been focused on developing route-over solutions while >>> being >>> conscious of supporting mesh-under when possible (evident with >>> 6lowpan- >>> hc). However, things will start to diverge when we start to talk >>> about >>> bootstrapping, ND, etc. So we should make a conscious decision of >>> whether we're supporting one or both. >>> >>> -- >>> Jonathan Hui >>> >>>> >>>>> >>>>> - I hesitate a bit that we suggest possible solutions to ND in the >>>>> charter ("reusing the 802.15.4 network structure (use the >>>>> coordinators)") especially since the definition of such link >>>>> mechanisms are still in motion within the IEEE. It seems more >>>>> productive to me if we can develop mechanisms that are less >>>>> dependent on the specific structure of 802.15.4 mechanisms. >>>> I agree that we should develop mechanisms that could work >>>> generically whenever possible. >>>> >>>> - Mark >>>>> >>>>> Rest of the charter looks good to me. >>>>> >>>>> Thanks. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> >>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>>> >>>>>> Pascal Thubert (pthubert) wrote: >>>>>>> Hi Mark: >>>>>>> >>>>>>> I think we need a work item (usually implicit) around the concept >>>>>>> of >>>>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>>>> aspects: >>>>>>> >>>>>> >>>>>>> >>>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>>>> to >>>>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>>>> given. >>>>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>>>> RFC >>>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>>>> resolve >>>>>>> for the most part. >>>>>>> >>>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager >> to >>>>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>>>> interoperability. >>>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>>>> radio >>>>>>> mesh exposes the network to congestion collapse, as described in >>>>>>> >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>>>> provide >>>>>>> additional functions that would improve the LoWPAN operation WRT >>>>>>> flow >>>>>>> control and recovery of fragments. >>>>>>> >>>>>> Fragmentation, OK, but why is flow control a network layer issue >>>>>> rather >>>>>> than a transport layer issue? >>>>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>>>> It >>>>>>> would be appropriate that the IETF comes up with a proposal to >>>>>>> implement >>>>>>> the concept in the IPv6 world. This partially falls under the >>>>>>> first work >>>>>>> item on ND but might also include ND proxy over the backbone >>>>>>> which is a >>>>>>> stretch to the work item. More in >>>>>>> >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>>>> . >>>>>>> >>>>>> Well, don't we need to define what ND looks like on a lowpan >>>>>> before we >>>>>> decide whether it needs to be proxied or not? >>>>>> >>>>>> - Mark >>>>>>> What do you think? >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>>>>> On >>>>>>>> >>>>>>> Behalf Of Mark Townsley >>>>>>> >>>>>>>> (townsley) >>>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>>> To: 6lowpan@ietf.org >>>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>>> >>>>>>>> >>>>>>>> I'd like to ask the group one final time for comments on the >>>>>>>> proposed >>>>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>>>> >>>>>>>> As I said before, soon after the format document was published, >>>>>>>> there >>>>>>>> >>>>>>> is >>>>>>> >>>>>>>> nothing stopping the WG from discussing and working on new and >>>>>>>> existing >>>>>>>> items at this time. In fact, activity helps us to decide what >>>>>>>> should be >>>>>>>> in and out of the charter. Please do not construe not having a >>>>>>>> charter >>>>>>>> in place as a reason not to update drafts, or discuss topics >>>>>>>> that need >>>>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>>>> before >>>>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>>>> discussions when creating new WG charters. >>>>>>>> >>>>>>>> - Mark >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue May 27 22:38:20 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F5B28C0F5; Tue, 27 May 2008 22:38:20 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC61E3A6C5B; Tue, 27 May 2008 22:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIEyVs1UR1UN; Tue, 27 May 2008 22:38:18 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 375463A6C46; Tue, 27 May 2008 22:38:15 -0700 (PDT) Received: from [76.14.71.180] (helo=[192.168.2.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1K1EMf-0005Tu-Md; Tue, 27 May 2008 22:38:22 -0700 From: Philip Levis To: Carles Gomez Montenegro In-Reply-To: <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> X-Priority: 3 (Normal) References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> Message-Id: <19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 27 May 2008 22:38:21 -0700 X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae Cc: Mark Townsley , roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On May 27, 2008, at 2:29 AM, Carles Gomez Montenegro wrote: > > At least, there are the following items listed in the routing > requirements > draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt) > that route-over approach cannot provide or would provide only in a > limited > way: I disagree wholeheartedly. I think there is a big confusion here between a protocol specification and a protocol implementation. These are all arguments for cross-layer design, that tightly integrating routing and the link layer will lead to a better solution. Practice has shown us otherwise; only by clearly separating concerns do you give a protocol the flexibility needed to evolve over time. What happens when a new low power link layer emerges? Having N different solutions, each with their own details, which somehow need to be made to work well together, seems like a path of brittle and difficult to manage networks. Switches are good, to a point; there's a reason you have routers. The purpose of a protocol specification, IMO, is to specify what is needed for interoperability; there should, in theory, be multiple possible implementations (and by that, I mean power saving approaches) that can all interoperate. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed May 28 01:05:09 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593163A6CA8; Wed, 28 May 2008 01:05:09 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1543A6C93 for ; Wed, 28 May 2008 01:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zxjsQ76X3Ql for ; Wed, 28 May 2008 01:04:40 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by core3.amsl.com (Postfix) with ESMTP id 05E513A6CAA for ; Wed, 28 May 2008 01:04:12 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so2539237tib.25 for ; Wed, 28 May 2008 01:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=3OEqorSDCS1j01HMP+obuvQB52m6rXqknCrWFLvkZ7I=; b=YMz5JBDPB5E6g0l4GSY4Ezce7q2i77Pkf8RdaGVFQ83dvcfSSj+2RJp2tZ5wQQGqzp0qGALCrJeppfBKKGRUsZVxk3LdCeOMI2Zur5Jcpy0ddQPWHoe8XqIEZSEXYBVc5OxEbwHNuulpAH7skqdPiPNf69ybEK87zUo45LJJ+QQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qtQNUJLS2wt9g6YRHEvd9b21K2/pBvwkANKKqFctaq/0SBus3g0SbKLwX1SgOKkZN7wgy2rvppRvgicro/BgETc4PVsuCDRTVHqDqu+zfD6JcDdLQ74Gix850Sn4ZNgyrLbSdUNSw9+hNHUuiSRNBJWNRaUkJpvYx6t/L9CF/s8= Received: by 10.110.69.5 with SMTP id r5mr332396tia.17.1211961854733; Wed, 28 May 2008 01:04:14 -0700 (PDT) Received: by 10.110.21.5 with HTTP; Wed, 28 May 2008 01:04:14 -0700 (PDT) Message-ID: <77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com> Date: Wed, 28 May 2008 17:04:14 +0900 From: "Eunsook \"Eunah\" Kim" To: "Philip Levis" In-Reply-To: <19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu> MIME-Version: 1.0 Content-Disposition: inline References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> <19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu> Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear Philip, > What happens when a new low power link layer emerges? Having N > different solutions, each with their own details, which somehow need > to be made to work well together, seems like a path of brittle and > difficult to manage networks. Switches are good, to a point; there's a > reason you have routers. > We don't talk about solutions. We want to see if 6LoWPAN has special routing requirements due to 802.15.4 specific or not. If route-over solutions can be provided to fit the requirements of 6LoWPAN, I'm happy. -eunah _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed May 28 09:18:45 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802A028C0DD; Wed, 28 May 2008 09:18:45 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9473A6AA5; Wed, 28 May 2008 09:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rko6rM51khVz; Wed, 28 May 2008 09:18:43 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 304DA3A6AB1; Wed, 28 May 2008 09:18:43 -0700 (PDT) Received: from dnab42327d.stanford.edu ([171.66.50.125]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1K1OMV-000542-LI; Wed, 28 May 2008 09:18:51 -0700 Message-Id: <46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> From: Philip Levis To: Eunsook Eunah Kim In-Reply-To: <77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 08:36:24 -0700 References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> <19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu> <77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: 2c238adc2661b13b123d68c6db09dced Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On May 28, 2008, at 1:04 AM, Eunsook Eunah Kim wrote: > Dear Philip, > >> What happens when a new low power link layer emerges? Having N >> different solutions, each with their own details, which somehow need >> to be made to work well together, seems like a path of brittle and >> difficult to manage networks. Switches are good, to a point; >> there's a >> reason you have routers. >> > > We don't talk about solutions. We want to see if 6LoWPAN has special > routing requirements due to 802.15.4 specific or not. If route-over > solutions can be provided to fit the requirements of 6LoWPAN, I'm > happy. Exactly: as soon as you start talking about things like LQI, you are coupling yourself not only to a specific link layer, but also a specific implementation of that link layer. In practice, many networks use the 802.15.4 link layer but not its MAC layer, as it has terrible energy properties. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed May 28 20:01:37 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49DC73A6978; Wed, 28 May 2008 20:01:37 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774603A6CFB for ; Wed, 28 May 2008 20:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQB5+-Bqg5W7 for ; Wed, 28 May 2008 20:01:15 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id 358613A6939 for ; Wed, 28 May 2008 20:00:12 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so2774067tib.25 for ; Wed, 28 May 2008 20:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/5qYXHJj15d9gSOSdUABGTDrrRepIEZslfLlPPIsIK8=; b=tIofAClJ9BYCz3IhcnlPTNneV/9WRudyqKMi3LAk22gaujOZlmIUapFEW+O2ygOsk2Do+oUcBjM4jnYB6777i/mr8G8sGNC3uIA7jW6/gBArwF5lKNC9ikeLmkJ8nUzRBzoP8mmLOo4xXJktunOoEMdws4nnfnR1Z9qiAhds4Wo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Kp0Pfhr6uktEa6hQPzHbHa8r235dbiYM51eQWYEvMvNcYAbouR+BhyYfTnw5HNTEc+e9i7iL01lJtF2Vw7SnDsy+rMeOdTPrJAyftivFf6GLGilKvj/vXFfXf/iXKSzQPEVgN6gEx93YdElLqVRw6MAcMvYpXRrGL1Zg6w90sJ4= Received: by 10.110.15.9 with SMTP id 9mr463691tio.50.1212029654396; Wed, 28 May 2008 19:54:14 -0700 (PDT) Received: by 10.110.21.5 with HTTP; Wed, 28 May 2008 19:54:14 -0700 (PDT) Message-ID: <77f1dba80805281954u7f97f472q86c4261e51f6e498@mail.gmail.com> Date: Thu, 29 May 2008 11:54:14 +0900 From: "Eunsook \"Eunah\" Kim" To: "Philip Levis" In-Reply-To: <46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> MIME-Version: 1.0 Content-Disposition: inline References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> <19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu> <77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com> <46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Philip, Thanks for the comment. LQI in the draft was mentioned for one requirement, and it is given as just one of the examples for routing matrics to utilize possible information to build up better routing metrics for low power networks. If you think we shouldn't bond 6LoWPAN to use MAC metrics, I'm okay with that. We can rule out it, but keep doing the study about routing matrics. Thank you. -eunah On 5/29/08, Philip Levis wrote: > > On May 28, 2008, at 1:04 AM, Eunsook Eunah Kim wrote: > > > Dear Philip, > > > > > > > What happens when a new low power link layer emerges? Having N > > > different solutions, each with their own details, which somehow need > > > to be made to work well together, seems like a path of brittle and > > > difficult to manage networks. Switches are good, to a point; there's a > > > reason you have routers. > > > > > > > > > > We don't talk about solutions. We want to see if 6LoWPAN has special > > routing requirements due to 802.15.4 specific or not. If route-over > > solutions can be provided to fit the requirements of 6LoWPAN, I'm > > happy. > > > > Exactly: as soon as you start talking about things like LQI, you are > coupling yourself not only to a specific link layer, but also a specific > implementation of that link layer. In practice, many networks use the > 802.15.4 link layer but not its MAC layer, as it has terrible energy > properties. > > Phil > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed May 28 21:54:50 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C623A681B; Wed, 28 May 2008 21:54:50 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79D63A681B for ; Wed, 28 May 2008 21:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmScDdxh+qrp for ; Wed, 28 May 2008 21:54:43 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by core3.amsl.com (Postfix) with ESMTP id C51113A685A for ; Wed, 28 May 2008 21:54:42 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so2794600tib.25 for ; Wed, 28 May 2008 21:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9qw3OrUVCcfBZFk22KWCwkTdwAY6FtBqzu4nHKEaoMA=; b=pzyErBjVftc2U180L+Kjb6X1JRVXLzIyC2bbJd1q8Ze568q0TWKZW8AdiTsS7mBzlA4NzijiO/OcVQtD4MmwEvPggD9KAeSrNAFTe0dEVIuCgKJdJsws1Xty+W5T1c9bXwnaSkti5JfU+rJseSXT6CDBTN7atKFV7XLPFIqhlg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p8aIsnWJzA4P9iEi06ER0nfb4emWYPdKx7DYEgzXcnpMESBOs/EldzldqSOeVTBoldVhoQr8J8rXvhltnJKDFTGMYWR/32lSjdsovzGAHdQ/o39lcAPGoVDMCWqsUpOxC1yHJJWAmwGCBL4+UecIUjWJU4cbZvjssY03b+9ceuY= Received: by 10.110.28.15 with SMTP id b15mr481906tib.26.1212036888686; Wed, 28 May 2008 21:54:48 -0700 (PDT) Received: by 10.110.21.5 with HTTP; Wed, 28 May 2008 21:54:48 -0700 (PDT) Message-ID: <77f1dba80805282154g66f1db7dw2c501ec37337c864@mail.gmail.com> Date: Thu, 29 May 2008 13:54:48 +0900 From: "Eunsook \"Eunah\" Kim" To: "Benjamin A. Rolfe" In-Reply-To: <024101c8c140$c4b9fc90$0efaa8c0@RunningDog2> MIME-Version: 1.0 Content-Disposition: inline References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> <19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu> <77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com> <46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> <77f1dba80805281954u7f97f472q86c4261e51f6e498@mail.gmail.com> <024101c8c140$c4b9fc90$0efaa8c0@RunningDog2> Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Benjamin, On 5/29/08, Benjamin A. Rolfe wrote: > Sorry, first post to the list, so forgive if I'm sounding like a newbie... > How would one get link quality information to the upper layers other than > via a MAC service? We are in the same track. That's why I think we need to utilize information from MAC for 6lowpan routing matrics. > I can see inserting a shim-layer service to isolate upper layers form the > different MACs which may be under it, so as to provide a consistent service > interface. Of course you can only get what the MAC provides, but the shim > layer and upper layer's can be designed to handle gracefully different MAC > capabilities (at least consistently). > :) > I'm asking with a bit of a bias here: I'm currently working on MAC > enhancements for 802.15.4 (in task group "e" in 802.15), including a > proposal for enhanced link assessment information from the MAC. So of course > I'd suggest not ruling out some better link metrics in the 802.15.4 MAC at > some point, although upper layers still need to deal with existing 802.15.4 > devices. So the general thinking from upper layer uses is very interesting. > Thanks > -Ben > The current 6LoWPAN RR draft has been started with the reason you concern, and we've kept working on it, as I believe that there are necessity of this work nevertheless some folks have different opinion(I'm trying to listen other side too). Thank you for sharing your thought. :) - eunah > > ----- Original Message ----- > From: "Eunsook "Eunah" Kim" > To: "Philip Levis" > Cc: ; <6lowpan@ietf.org> > Sent: Wednesday, May 28, 2008 7:54 PM > Subject: Re: [6lowpan] New charter for 6lowpan > > > > Philip, > > Thanks for the comment. LQI in the draft was mentioned for one > > requirement, and it is given as just one of the examples for routing > > matrics to utilize possible information to build up better routing > > metrics for low power networks. If you think we shouldn't bond 6LoWPAN > > to use MAC metrics, I'm okay with that. We can rule out it, but keep > > doing the study about routing matrics. Thank you. > > > > -eunah > > > > On 5/29/08, Philip Levis wrote: > >> > >> On May 28, 2008, at 1:04 AM, Eunsook Eunah Kim wrote: > >> > >> > Dear Philip, > >> > > >> > > >> > > What happens when a new low power link layer emerges? Having N > >> > > different solutions, each with their own details, which somehow need > >> > > to be made to work well together, seems like a path of brittle and > >> > > difficult to manage networks. Switches are good, to a point; there's > >> > > a > >> > > reason you have routers. > >> > > > >> > > > >> > > >> > We don't talk about solutions. We want to see if 6LoWPAN has special > >> > routing requirements due to 802.15.4 specific or not. If route-over > >> > solutions can be provided to fit the requirements of 6LoWPAN, I'm > >> > happy. > >> > > >> > >> Exactly: as soon as you start talking about things like LQI, you are > >> coupling yourself not only to a specific link layer, but also a specific > >> implementation of that link layer. In practice, many networks use the > >> 802.15.4 link layer but not its MAC layer, as it has terrible energy > >> properties. > >> > >> Phil > >> > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed May 28 22:50:01 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549BC28C1D3; Wed, 28 May 2008 22:50:01 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF9A3A68AE; Wed, 28 May 2008 22:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8663Uzkg4yT; Wed, 28 May 2008 22:49:58 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 431AE3A67AB; Wed, 28 May 2008 22:49:52 -0700 (PDT) Received: from [76.14.71.180] (helo=[192.168.2.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1K1b1K-0000KG-0G; Wed, 28 May 2008 22:49:50 -0700 In-Reply-To: <024101c8c140$c4b9fc90$0efaa8c0@RunningDog2> References: <482CA4DC.40508@cisco.com><77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com><4832F276.70406@cisco.com><2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu><19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu><77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com><46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> <77f1dba80805281954u7f97f472q86c4261e51f6e498@mail.gmail.com> <024101c8c140$c4b9fc90$0efaa8c0@RunningDog2> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 3 Message-Id: From: Philip Levis Date: Wed, 28 May 2008 22:49:40 -0700 To: Benjamin A. Rolfe X-Mailer: Apple Mail (2.753) X-Scan-Signature: fb418a055a615a79fddacbea7bf2a8e8 Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On May 28, 2008, at 9:02 PM, Benjamin A. Rolfe wrote: > Sorry, first post to the list, so forgive if I'm sounding like a > newbie... > How would one get link quality information to the upper layers > other than > via a MAC service? > I can see inserting a shim-layer service to isolate upper layers > form the > different MACs which may be under it, so as to provide a consistent > service > interface. Of course you can only get what the MAC provides, but > the shim > layer and upper layer's can be designed to handle gracefully > different MAC > capabilities (at least consistently). > > I'm asking with a bit of a bias here: I'm currently working on MAC > enhancements for 802.15.4 (in task group "e" in 802.15), including a > proposal for enhanced link assessment information from the MAC. So > of course > I'd suggest not ruling out some better link metrics in the 802.15.4 > MAC at > some point, although upper layers still need to deal with existing > 802.15.4 > devices. So the general thinking from upper layer uses is very > interesting. > Thanks > This is a very good question. It turns out to be very difficult, for two major reasons: separation of concerns and time scale. For the sake of simplicity, let's just consider the simplest link quality metric, the packet reception ratio. By separation of concerns, I mean that the MAC layer has to maintain state to generate link estimates. However, the MAC layer does not know which links are useful to a network layer. That is, it could learn and estimate the best links, but those links could be not very good for routing. For example, they could lead to a disconnected network, or high stretch routes. By time scale, I mean that if the average PRR over ten seconds is 50%, that could be due to bursts of high and bursts of low reception. Let's say that an application sends a packet every one second, the link layer transmits 5 times, and the 50% PRR is due to 5 seconds of 0% and 5 seconds of 100%. During the 5 seconds of 0%, the node will transmit 25 packets, with no successful deliveries. Meanwhile, during the 5 seconds of 100%, it will transmit five packets with 5 deliveries. While the PRR over the 10 second window was 50%, the link layer observed a PRR of 16% (5/30). Most radio chips (e.g., CC2420 and RF230) provide LQI as chip correlation values over some number of packet octets. These physical layer measurements effectively add significant bits to the SNR in the sharp part of the BER curve, and are amazingly useful. However, because they are only taken on successful packets, they suffer from measurement bias; in the example above of 50% PRR, a network layer would see all packets having an excellent LQI value, even though packets are lost. This happens in practice, when you have channel variations. Within the TinyOS community, our conclusion is that the MAC layer needs to provide 2 bits of information to the network layer. The first, the "white bit," is a simplification of things like LQI or SNR and essentially indicates whether a received packet had a very low BER, indicating it is probably -- but not certainly -- a good link. The second, the "ack bit" is signaled on each link layer transmission and indicates whether the transmitter received a layer 2 ack. A paper in HotNets last year quantified the benefits each of the bits provides.[1] Phil [1] http://enl.usc.edu/papers/abstract/Fonseca07.html _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 29 01:22:35 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E533A6A2E; Thu, 29 May 2008 01:22:35 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934883A6942 for ; Thu, 29 May 2008 01:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTNJgCx4YaJW for ; Thu, 29 May 2008 01:22:33 -0700 (PDT) Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by core3.amsl.com (Postfix) with ESMTP id 2B0493A6A99 for ; Thu, 29 May 2008 01:19:09 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id m4T8J77B018293 for ; Thu, 29 May 2008 11:19:07 +0300 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 01177-296-31 for ; Thu, 29 May 2008 11:19:07 +0300 (EEST) Received: from [130.233.152.99] (e3n-3.netlab.hut.fi [130.233.152.99]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id m4T8H61R016729 for ; Thu, 29 May 2008 11:17:06 +0300 Message-ID: <483E6682.30103@tkk.fi> Date: Thu, 29 May 2008 11:17:06 +0300 From: Jukka MJ Manner User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: ROLL WG X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: [Roll] Some thoughts on the requirements documents [2nd try] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org [2nd try, 1st one bounced for some reason] Hi I went through the various requirements documents and I'm a bit puzzled. In general the drafts are easy to read and we have many interesting scenarios described that open up nicely the environment. Yet, the drafts list similar requirements, there is very little difference in what they expect the routing service to do. If we are to work on a solution later on, it is somewhat challenging to find out the what our goals truly are. IMHO, the requirements documents should focus on the scenarios and use cases of sensor networks, and list in general what the routing subsystem aught to do. These drafts should not use RFC 2119 language. We need a separate document that lists the concrete goals of such a routing subsystem/protocol/architecture/service/whateveryouwanttocallit. Here there is also a clear need to separate functional and performance requirements. Typically performance values and goals are mutually exclusive, e.g., we can't have low power and high performance at the same time (with some definition of what is low and what is high). This latter document is used in both analysing the existing schemes and drafting a potential solution. I would expect that we end up with one general solution, where the parameters can be tuned to certain direction to make it fit different use cases. Actually, we also need to document the threats we see in the environment, and focus on the routing subsystem. The current drafts have some thoughts about that, but its only a beginning. Regards, Jukka _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 29 02:48:38 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF24C3A69AD; Thu, 29 May 2008 02:48:38 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31F53A67A7 for ; Thu, 29 May 2008 02:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mMZ1zT3-8Vd for ; Thu, 29 May 2008 02:48:36 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id AAF313A68BE for ; Thu, 29 May 2008 02:48:36 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so281045yxg.49 for ; Thu, 29 May 2008 02:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:content-type:subject:mime-version:date:references:x-mailer; bh=j/vtg2b9MAZtU/860pIR84w/cDAUss5IJMhA6UiiZuo=; b=TstQ+a+RjdBWC9Gw4vBUvOzKpznCUzIHiGPFUqHKqa+csPoB6Z91hQdHY+sMj7f8+mNkkdHleyA1Lce+fUkFn7lnqCT+YbfdQmkv1JVCgLLHJHAJPd2DhbFB9zbT/pGfOqcHXXu7cWeRIjc+G+l++FtOwCQTbS+YvdNUv/sO5p4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:content-type:subject:mime-version:date:references:x-mailer; b=Qf3sLI1alICWsyv7On1iX4TsZ8G+DGUXvPyQ+jaVCCfhP/yCr2Zy3KF+MWv62YU0S5XLDWdiYFyiFHZp3VGzWJjiamXnIBKf4pnzSWgtqzttLeIrtBndhM2ChKz4wK5RpFjw0u2OW4QK28oK15OZVYKi1QOirHrEaFCsk6F4t6g= Received: by 10.142.207.8 with SMTP id e8mr1058548wfg.110.1212054513432; Thu, 29 May 2008 02:48:33 -0700 (PDT) Received: from EM60-254-232-83.pool.e-mobile.ne.jp ( [60.254.232.83]) by mx.google.com with ESMTPS id 28sm1164203wfd.4.2008.05.29.02.48.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 May 2008 02:48:32 -0700 (PDT) Message-Id: <7A71A0CD-7B0E-4CEA-918B-BB3158FFBFA1@gmail.com> From: Ryuji Wakikawa To: roll@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-23--328415745 Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 29 May 2008 18:48:21 +0900 References: <20080529093001.D1E7E3A6B6F@core3.amsl.com> X-Mailer: Apple Mail (2.919.2) Cc: h-kuwabara@jp.toyota-itc.com Subject: [Roll] Fwd: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --Apple-Mail-23--328415745 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello all, We published a new requirement document for ROLL routing protocols. Although an in-vehicle network is not currently chartered in WG, we are very interested in ROLL activity for the future automobile. As Jukka mentioned, some requirements are very similar to other requirements documents. We tried to highlight the differences in the document. Any feedback will be appreciated. thanks, ryuji Begin forwarded message: > From: Internet-Drafts@ietf.org > date: 2008/5/2918:30:01:JST > To: i-d-announce@ietf.org > Subject: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt > Reply-to: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : In-Vehicle Routing Requirements in Low Power and > Lossy Networks > Author(s) : R. Wakikawa, H. Kuwabara > Filename : draft-wakikawa-roll-invehicle-reqs-00.txt > Pages : 20 > Date : 2008-05-29 > > This document presents the routing requirements for in-vehicle low > power and lossy networks. Automobiles are already equipped with > several sensors and devices named Electronic Control Unit (ECU) for > controlling, monitoring and entertainment, etc. For the future in- > vehicle networks, the shift to wireless is desirable due to heavy > weight and volume of cables in vehicles and to be able to efficiently > install devices. However, with the limitation of low power, in- > vehicle network still requires reliability and scalability in nature > of the rolls of ECU. The routing protocol should support the > features of low-power, high-reliability, Subnetting, QoS, Mobility, > etc. This document briefly explains the in-vehicle networks and > ECUs, then discusses the requirements for the future wireless in- > vehicle networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wakikawa-roll-invehicle-reqs-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --Apple-Mail-23--328415745 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2008-05-29021724.I-D@ietf.org>

--Apple-Mail-23--328415745 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-23--328415745 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-23--328415745-- From roll-bounces@ietf.org Thu May 29 08:25:19 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B32E3A6AB0; Thu, 29 May 2008 08:25:19 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761CC3A6CE0; Wed, 28 May 2008 21:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLs0nxKTA6X0; Wed, 28 May 2008 21:02:17 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [65.254.51.10]) by core3.amsl.com (Postfix) with ESMTP id 7DF953A6781; Wed, 28 May 2008 21:02:05 -0700 (PDT) Received: from [64.74.213.174] (helo=RunningDog2) by wilson.nswebhost.com with smtp (Exim 4.68) (envelope-from ) id 1K1ZL6-0003ni-QI; Wed, 28 May 2008 23:02:09 -0500 Message-ID: <024101c8c140$c4b9fc90$0efaa8c0@RunningDog2> From: "Benjamin A. Rolfe" To: , <6lowpan@ietf.org> References: <482CA4DC.40508@cisco.com><77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com><4832F276.70406@cisco.com><2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu><19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu><77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com><46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> <77f1dba80805281954u7f97f472q86c4261e51f6e498@mail.gmail.com> Date: Wed, 28 May 2008 21:02:07 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ClamAntiVirus-Scanner: This mail is clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Mailman-Approved-At: Thu, 29 May 2008 08:25:17 -0700 Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Sorry, first post to the list, so forgive if I'm sounding like a newbie... How would one get link quality information to the upper layers other than via a MAC service? I can see inserting a shim-layer service to isolate upper layers form the different MACs which may be under it, so as to provide a consistent service interface. Of course you can only get what the MAC provides, but the shim layer and upper layer's can be designed to handle gracefully different MAC capabilities (at least consistently). I'm asking with a bit of a bias here: I'm currently working on MAC enhancements for 802.15.4 (in task group "e" in 802.15), including a proposal for enhanced link assessment information from the MAC. So of course I'd suggest not ruling out some better link metrics in the 802.15.4 MAC at some point, although upper layers still need to deal with existing 802.15.4 devices. So the general thinking from upper layer uses is very interesting. Thanks -Ben ----- Original Message ----- From: "Eunsook "Eunah" Kim" To: "Philip Levis" Cc: ; <6lowpan@ietf.org> Sent: Wednesday, May 28, 2008 7:54 PM Subject: Re: [6lowpan] New charter for 6lowpan > Philip, > Thanks for the comment. LQI in the draft was mentioned for one > requirement, and it is given as just one of the examples for routing > matrics to utilize possible information to build up better routing > metrics for low power networks. If you think we shouldn't bond 6LoWPAN > to use MAC metrics, I'm okay with that. We can rule out it, but keep > doing the study about routing matrics. Thank you. > > -eunah > > On 5/29/08, Philip Levis wrote: >> >> On May 28, 2008, at 1:04 AM, Eunsook Eunah Kim wrote: >> >> > Dear Philip, >> > >> > >> > > What happens when a new low power link layer emerges? Having N >> > > different solutions, each with their own details, which somehow need >> > > to be made to work well together, seems like a path of brittle and >> > > difficult to manage networks. Switches are good, to a point; there's >> > > a >> > > reason you have routers. >> > > >> > > >> > >> > We don't talk about solutions. We want to see if 6LoWPAN has special >> > routing requirements due to 802.15.4 specific or not. If route-over >> > solutions can be provided to fit the requirements of 6LoWPAN, I'm >> > happy. >> > >> >> Exactly: as soon as you start talking about things like LQI, you are >> coupling yourself not only to a specific link layer, but also a specific >> implementation of that link layer. In practice, many networks use the >> 802.15.4 link layer but not its MAC layer, as it has terrible energy >> properties. >> >> Phil >> > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 29 08:25:19 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E70A3A6BB5; Thu, 29 May 2008 08:25:19 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23F93A6B58 for ; Thu, 29 May 2008 00:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoXvKR5b-oTh for ; Thu, 29 May 2008 00:12:38 -0700 (PDT) Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by core3.amsl.com (Postfix) with ESMTP id D0F1B28C1E9 for ; Thu, 29 May 2008 00:09:22 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id m4T79KEp006922 for ; Thu, 29 May 2008 10:09:20 +0300 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 21948-63-4 for ; Thu, 29 May 2008 10:09:20 +0300 (EEST) Received: from [130.233.152.99] (e3n-3.netlab.hut.fi [130.233.152.99]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id m4T75DSf004097 for ; Thu, 29 May 2008 10:05:13 +0300 Message-ID: <483E55A9.6070006@tkk.fi> Date: Thu, 29 May 2008 10:05:13 +0300 From: Jukka MJ Manner User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: ROLL WG X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-Mailman-Approved-At: Thu, 29 May 2008 08:25:17 -0700 Subject: [Roll] Some thoughts on the requirements documents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi I went through the various requirements documents and I'm a bit puzzled. In general the drafts are easy to read and we have many interesting scenarios described that open up nicely the environment. Yet, the drafts list similar requirements, there is very little difference in what they expect the routing service to do. If we are to work on a solution later on, it is somewhat challenging to find out the what our goals truly are. IMHO, the requirements documents should focus on the scenarios and use cases of sensor networks, and list in general what the routing subsystem aught to do. These drafts should not use RFC 2119 language. We need a separate document that lists the concrete goals of such a routing subsystem/protocol/architecture/service/whateveryouwanttocallit. Here there is also a clear need to separate functional and performance requirements. Typically performance values and goals are mutually exclusive, e.g., we can't have low power and high performance at the same time (with some definition of what is low and what is high). This latter document is used in both analysing the existing schemes and drafting a potential solution. I would expect that we end up with one general solution, where the parameters can be tuned to certain direction to make it fit different use cases. Actually, we also need to document the threats we see in the environment, and focus on the routing subsystem. The current drafts have some thoughts about that, but its only a beginning. Regards, Jukka _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 29 08:32:47 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF9F28C27D; Thu, 29 May 2008 08:32:47 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C626C28C283 for ; Thu, 29 May 2008 08:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfDqGdVejToQ for ; Thu, 29 May 2008 08:32:43 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7E7FF3A6B6C for ; Thu, 29 May 2008 08:28:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,562,1204531200"; d="scan'208";a="51383992" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 29 May 2008 08:28:52 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4TFSoNB032651; Thu, 29 May 2008 08:28:50 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4TFSg9O012863; Thu, 29 May 2008 15:28:50 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 11:28:49 -0400 Received: from 10.21.118.139 ([10.21.118.139]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 May 2008 15:28:49 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 29 May 2008 11:24:30 -0400 From: JP Vasseur To: Jukka MJ Manner Message-ID: Thread-Topic: [Roll] Some thoughts on the requirements documents [2nd try] Thread-Index: AcjBoBa1Ey7hUxXonEyk4fInHkYf7w== In-Reply-To: <483E6682.30103@tkk.fi> Mime-version: 1.0 X-OriginalArrivalTime: 29 May 2008 15:28:49.0531 (UTC) FILETIME=[B16714B0:01C8C1A0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3067; t=1212074930; x=1212938930; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Some=20thoughts=20on=20the=20r equirements=20documents=20[2nd=20try] |Sender:=20; bh=oSAeppHtufPz/BkNgesJohP6lkOlV0zkaqytNvt3/Yk=; b=BAaSXRipFLZQZ53fdSmRw4EZUo8STW6UnhTBzGAHLkbO5ejAhyOKS5h5zY vU5tJ+8re8pEIMvOePBYNts6MP1z+lLd/JfI7lqSdVbrXO2cM0Om2XlYAbFD 8Hwn34YuT8D2Ty0qSKnuC++X22wwVes6ay3Ere+GiwVbulTwYsh5E=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ROLL WG Subject: Re: [Roll] Some thoughts on the requirements documents [2nd try] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Jukka, On 5/29/08 4:17 AM, "Jukka MJ Manner" wrote: > > [2nd try, 1st one bounced for some reason] You need to subscribe to the list. > > Hi > > I went through the various requirements documents and I'm a bit puzzled. > In general the drafts are easy to read and we have many interesting > scenarios described that open up nicely the environment. Yet, the drafts > list similar requirements, there is very little difference in what they > expect the routing service to do. Two comments here: (1) I think that there are significant differences between the requirement set forth in the IDs, in term of functionality (e.g. constrained based routing, scale, ....) (2) There is no issue in having some similar routing requirements spelled out in the IDs. This is a good news. > > If we are to work on a solution later on, it is somewhat challenging to > find out the what our goals truly are. Sounds fairly obvious to me. How can you select/define a solution w/o knowing what the requirements are ? > > IMHO, the requirements documents should focus on the scenarios and use > cases of sensor networks, and list in general what the routing subsystem > aught to do. These drafts should not use RFC 2119 language. > No. "Requirements" and "Use cases" (what we usually call "Applicability statement" at the IETF) have very different purposes and what we need to do according to our charter is first to spell out the requirement documents. Note that RFC 2119 is very much appropriate in requirement documents. > We need a separate document that lists the concrete goals of such a > routing subsystem/protocol/architecture/service/whateveryouwanttocallit. Not sure what you mean here. > Here there is also a clear need to separate functional and performance > requirements. Typically performance values and goals are mutually > exclusive, e.g., we can't have low power and high performance at the > same time (with some definition of what is low and what is high). One of the key reasons why the Internet has been so successful is that we avoid to specify performances, so I disagree with your vision here. Of course, we will use performance related metric during our protocol survey evaluation. > > This latter document is used in both analysing the existing schemes and > drafting a potential solution. See http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.txt I would expect that we end up with one > general solution, where the parameters can be tuned to certain direction > to make it fit different use cases. Absolutely. > > Actually, we also need to document the threats we see in the > environment, and focus on the routing subsystem. The current drafts have > some thoughts about that, but its only a beginning. Please elaborate. Thanks. JP. > > Regards, > Jukka > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 29 08:48:05 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA7E28C186; Thu, 29 May 2008 08:48:05 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CAFC28C176 for ; Thu, 29 May 2008 08:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgDjTn13kg1F for ; Thu, 29 May 2008 08:48:00 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3741628C186 for ; Thu, 29 May 2008 08:48:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,562,1204531200"; d="scan'208";a="73641054" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 29 May 2008 08:48:00 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m4TFlxiZ013467; Thu, 29 May 2008 08:47:59 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m4TFlxwk007474; Thu, 29 May 2008 15:47:59 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 11:47:59 -0400 Received: from 10.21.118.139 ([10.21.118.139]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 May 2008 15:47:58 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 29 May 2008 11:47:54 -0400 From: JP Vasseur To: Ryuji Wakikawa , Message-ID: Thread-Topic: [Roll] Fwd: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt Thread-Index: AcjBo1uPSAcdOzsGeUqpVbwyZba2Ig== In-Reply-To: <7A71A0CD-7B0E-4CEA-918B-BB3158FFBFA1@gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 29 May 2008 15:47:59.0288 (UTC) FILETIME=[5EB61380:01C8C1A3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3263; t=1212076079; x=1212940079; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Fwd=3A=20I-D=20Action=3Adraft- wakikawa-roll-invehicle-reqs-00.txt |Sender:=20; bh=W770JZTcYy/5BiyJ2OD8mn+G1bGtb3/spzGliPb0U+o=; b=brc1vF5g0gmXBO1e6ktMMrHeJ5Nl5RLbvrRpz1/c+btYGiQ2IxxAizxsTA usLiWLrY6StTGRY6UilHsYsrZL9Dd4QpGuQQUuQf2f34/wn39WfaCBX0xl3w 6Kv69mHlMA; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: h-kuwabara@jp.toyota-itc.com Subject: Re: [Roll] Fwd: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear Ryuji, First of all sorry for the delay in replying to your message. As you pointed out, in-vehicle is not part of the WG charter. Thus this document could not be a WG document for the time being. That being said, there is no issue in using the ROLL mailing list to discuss it. I would encourage people to look at it and comment. If we have some time in Dublin, I have no problem giving you a slot to present your document. Thanks. JP. On 5/29/08 5:48 AM, "Ryuji Wakikawa" wrote: > Hello all, > > We published a new requirement document for ROLL routing protocols. > Although an in-vehicle network is not currently chartered in WG, > we are very interested in ROLL activity for the future automobile. > > As Jukka mentioned, some requirements are very similar to other > requirements documents. > We tried to highlight the differences in the document. > > Any feedback will be appreciated. > > thanks, > ryuji > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> date: 2008/5/2918:30:01:JST >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt >> Reply-to: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : In-Vehicle Routing Requirements in Low Power and >> Lossy Networks >> Author(s) : R. Wakikawa, H. Kuwabara >> Filename : draft-wakikawa-roll-invehicle-reqs-00.txt >> Pages : 20 >> Date : 2008-05-29 >> >> This document presents the routing requirements for in-vehicle low >> power and lossy networks. Automobiles are already equipped with >> several sensors and devices named Electronic Control Unit (ECU) for >> controlling, monitoring and entertainment, etc. For the future in- >> vehicle networks, the shift to wireless is desirable due to heavy >> weight and volume of cables in vehicles and to be able to efficiently >> install devices. However, with the limitation of low power, in- >> vehicle network still requires reliability and scalability in nature >> of the rolls of ECU. The routing protocol should support the >> features of low-power, high-reliability, Subnetting, QoS, Mobility, >> etc. This document briefly explains the in-vehicle networks and >> ECUs, then discusses the requirements for the future wireless in- >> vehicle networks. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-wakikawa-roll-invehicle-reqs-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 29 08:48:11 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8D928C181; Thu, 29 May 2008 08:48:11 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F6728C23E; Thu, 29 May 2008 08:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63rPoBlmdlA6; Thu, 29 May 2008 08:48:08 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4A09128C17A; Thu, 29 May 2008 08:48:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,562,1204531200"; d="scan'208";a="73641106" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 29 May 2008 08:48:07 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4TFm75m031930; Thu, 29 May 2008 08:48:07 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4TFm7mk016598; Thu, 29 May 2008 15:48:07 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 11:48:06 -0400 Received: from 10.21.118.139 ([10.21.118.139]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 May 2008 15:48:06 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 29 May 2008 11:48:02 -0400 From: JP Vasseur To: Philip Levis , "Benjamin A. Rolfe" Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: AcjBo2BTFQVY2oG0o0mY9pN0fWLrrw== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 29 May 2008 15:48:06.0945 (UTC) FILETIME=[63467110:01C8C1A3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4455; t=1212076087; x=1212940087; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20; bh=5fjOFCjLIr1a8A8RMmMDwLFxfK9Syu+4FWrDwqKKdO0=; b=hnn9oby4dzZl/YSKbbq+NaD2Q/f8rk49rssy7LG+dlLIFZJEqCNy0HBDs9 QJpwTi3dR+xT1byMFIfAQMF3tsO9z7Sg1xrUQkFLUGlRrzSJXDO+DfPNnc34 MDvfJ5MJkn; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Phil, I share your analysis, it is a difficult thing to do, especially with very unstable links. But this is also true with many other technologies. Look at QoS with RED when you need to decide when dropping packet based on queue length with bursty traffic: you use low pass filters. They are not perfect but good enough. As you pointed out below, you could end up collapsing the metric to 1 bit or provide a more granular indicator/metric but in all cases you need to make sure that the mechanism is robust enough to avoid routing oscillation: an interesting topic of discussion to come ... Cheers. JP. On 5/29/08 1:49 AM, "Philip Levis" wrote: > > On May 28, 2008, at 9:02 PM, Benjamin A. Rolfe wrote: >> Sorry, first post to the list, so forgive if I'm sounding like a >> newbie... >> How would one get link quality information to the upper layers >> other than >> via a MAC service? >> I can see inserting a shim-layer service to isolate upper layers >> form the >> different MACs which may be under it, so as to provide a consistent >> service >> interface. Of course you can only get what the MAC provides, but >> the shim >> layer and upper layer's can be designed to handle gracefully >> different MAC >> capabilities (at least consistently). >> >> I'm asking with a bit of a bias here: I'm currently working on MAC >> enhancements for 802.15.4 (in task group "e" in 802.15), including a >> proposal for enhanced link assessment information from the MAC. So >> of course >> I'd suggest not ruling out some better link metrics in the 802.15.4 >> MAC at >> some point, although upper layers still need to deal with existing >> 802.15.4 >> devices. So the general thinking from upper layer uses is very >> interesting. >> Thanks >> > > This is a very good question. It turns out to be very difficult, for > two major reasons: separation of concerns and time scale. For the > sake of simplicity, let's just consider the simplest link quality > metric, the packet reception ratio. > > By separation of concerns, I mean that the MAC layer has to maintain > state to generate link estimates. However, the MAC layer does not > know which links are useful to a network layer. That is, it could > learn and estimate the best links, but those links could be not very > good for routing. For example, they could lead to a disconnected > network, or high stretch routes. > > By time scale, I mean that if the average PRR over ten seconds is > 50%, that could be due to bursts of high and bursts of low reception. > Let's say that an application sends a packet every one second, the > link layer transmits 5 times, and the 50% PRR is due to 5 seconds of > 0% and 5 seconds of 100%. During the 5 seconds of 0%, the node will > transmit 25 packets, with no successful deliveries. Meanwhile, during > the 5 seconds of 100%, it will transmit five packets with 5 > deliveries. While the PRR over the 10 second window was 50%, the link > layer observed a PRR of 16% (5/30). > > Most radio chips (e.g., CC2420 and RF230) provide LQI as chip > correlation values over some number of packet octets. These physical > layer measurements effectively add significant bits to the SNR in the > sharp part of the BER curve, and are amazingly useful. However, > because they are only taken on successful packets, they suffer from > measurement bias; in the example above of 50% PRR, a network layer > would see all packets having an excellent LQI value, even though > packets are lost. This happens in practice, when you have channel > variations. > > Within the TinyOS community, our conclusion is that the MAC layer > needs to provide 2 bits of information to the network layer. The > first, the "white bit," is a simplification of things like LQI or SNR > and essentially indicates whether a received packet had a very low > BER, indicating it is probably -- but not certainly -- a good link. > The second, the "ack bit" is signaled on each link layer transmission > and indicates whether the transmitter received a layer 2 ack. A paper > in HotNets last year quantified the benefits each of the bits > provides.[1] > > Phil > > [1] http://enl.usc.edu/papers/abstract/Fonseca07.html > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 29 08:48:20 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA79F28C266; Thu, 29 May 2008 08:48:20 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D85328C176; Thu, 29 May 2008 08:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soHR1NRGuvwe; Thu, 29 May 2008 08:48:18 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 21E113A6A79; Thu, 29 May 2008 08:48:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,562,1204520400"; d="scan'208";a="9555330" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 May 2008 11:48:14 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4TFmEdW020700; Thu, 29 May 2008 11:48:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4TFmEJK022367; Thu, 29 May 2008 15:48:14 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 11:48:14 -0400 Received: from 10.21.118.139 ([10.21.118.139]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 May 2008 15:48:13 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 29 May 2008 11:48:09 -0400 From: JP Vasseur To: Philip Levis , Eunsook Eunah Kim Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: AcjBo2SA9K8k2G+YIUCdbfN4e4lQ+Q== In-Reply-To: <46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> Mime-version: 1.0 X-OriginalArrivalTime: 29 May 2008 15:48:14.0012 (UTC) FILETIME=[677CC7C0:01C8C1A3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1469; t=1212076094; x=1212940094; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20 |To:=20Philip=20Levis=20,=0A=20=20=20= 20=20=20=20=20Eunsook=20Eunah=20Kim=20; bh=DK0lFVvTPp3a3fdHWeZKzN7AsEldEZtLKJrk208g65A=; b=iPcrzAxnWmX+fCSqraLXBE6vOnGBS8ZYgVkbD1HsfSnvXFYklid5mL+y5l 2T7GNyg42A4tMt2mSDVkfp9kK3Q95BabJ9YyBwJta7/3RniXkbTlC+zKOS1o wqwg4FwCSF; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org In that particular example (LQI), translate it into a routing link metric and we'll achieve what you're trying to do. The use of a dynamic metric has to be studied with great care of course to prevent oscillations. Look at the ARPANET experiment using dynamic metrics. JP. On 5/28/08 11:36 AM, "Philip Levis" wrote: > > On May 28, 2008, at 1:04 AM, Eunsook Eunah Kim wrote: > >> Dear Philip, >> >>> What happens when a new low power link layer emerges? Having N >>> different solutions, each with their own details, which somehow need >>> to be made to work well together, seems like a path of brittle and >>> difficult to manage networks. Switches are good, to a point; >>> there's a >>> reason you have routers. >>> >> >> We don't talk about solutions. We want to see if 6LoWPAN has special >> routing requirements due to 802.15.4 specific or not. If route-over >> solutions can be provided to fit the requirements of 6LoWPAN, I'm >> happy. > > Exactly: as soon as you start talking about things like LQI, you are > coupling yourself not only to a specific link layer, but also a > specific implementation of that link layer. In practice, many networks > use the 802.15.4 link layer but not its MAC layer, as it has terrible > energy properties. > > Phil > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 29 08:48:28 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0B628C278; Thu, 29 May 2008 08:48:28 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6545A3A6A79; Thu, 29 May 2008 08:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjH9syez0OHE; Thu, 29 May 2008 08:48:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 630F828C176; Thu, 29 May 2008 08:48:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,562,1204520400"; d="scan'208";a="9555364" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 May 2008 11:48:19 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4TFmJPW020823; Thu, 29 May 2008 11:48:19 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4TFmJ4R023542; Thu, 29 May 2008 15:48:19 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 11:48:18 -0400 Received: from 10.21.118.139 ([10.21.118.139]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 May 2008 15:48:18 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 29 May 2008 11:48:15 -0400 From: JP Vasseur To: Philip Levis , Carles Gomez Montenegro Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: AcjBo2gT8B0FO8W5I0yiQWBZn+AUFw== Mime-version: 1.0 X-OriginalArrivalTime: 29 May 2008 15:48:18.0934 (UTC) FILETIME=[6A6BD160:01C8C1A3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2079; t=1212076099; x=1212940099; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20 |To:=20Philip=20Levis=20,=0A=20=20=20= 20=20=20=20=20Carles=20Gomez=20Montenegro=20; bh=+wx+pWx8GLIqQdJv0bWvCvqX+lTwaEft4NtCC0qcalQ=; b=PtzbTWVh5Zt4foxFktCz3nhyxa2/45PuZWqJ/IYt1aKGjQdqVBi66F+rUD g2H1R39et66ke1K6yDqDSwwBpdZaEMcjrOTe0CN126rs6HEmRYhMElxkdshB gyrbjVV0O9; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Phil and Carles, On 5/28/08 1:38 AM, "Philip Levis" wrote: > On May 27, 2008, at 2:29 AM, Carles Gomez Montenegro wrote: >> >> At least, there are the following items listed in the routing >> requirements >> draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt) >> that route-over approach cannot provide or would provide only in a >> limited >> way: > > I disagree wholeheartedly. So do I. I think there is a big confusion here > between a protocol specification and a protocol implementation. > > These are all arguments for cross-layer design, that tightly > integrating routing and the link layer will lead to a better solution. > Practice has shown us otherwise; Indeed, "practice" being "The Internet". only by clearly separating concerns > do you give a protocol the flexibility needed to evolve over time. > What happens when a new low power link layer emerges? Having N > different solutions, each with their own details, which somehow need > to be made to work well together, seems like a path of brittle and > difficult to manage networks. Switches are good, to a point; there's a > reason you have routers. > > The purpose of a protocol specification, IMO, is to specify what is > needed for interoperability; there should, in theory, be multiple > possible implementations (and by that, I mean power saving approaches) > that can all interoperate. Indeed. Carles, we're not saying that L3 should not take into account the specific characteristics of L2. This is why we have the following WG item: "- Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs." There are a few cases where cross-layer "collaboration" may be quite powerful but we need to be very careful at what we're doing here. Thanks. JP. > > Phil > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 29 15:59:59 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1183A6B51; Thu, 29 May 2008 15:59:59 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297943A6B51 for ; Thu, 29 May 2008 15:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVQfsOUQXS3t for ; Thu, 29 May 2008 15:59:57 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id 4512E3A6A7D for ; Thu, 29 May 2008 15:59:56 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so3162797tib.25 for ; Thu, 29 May 2008 15:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=aoW3WKzCnS1bmZWTNQtSwNvkKACga3M85FGs00abR+0=; b=X+Nq9zogQnR6VEcV5tY0Prd43g5rjBkXB2cY/JbwcWPTw64R12OdficXpnWvwgjitUXnb6bkPWuIpiD2u9pL+VPFFh4DBi3O3piSurYUKBaaQIcovYgEJVwkt8yoz23tmA2LBsU03s//OeW2dpmXZps8ybQVl5nqgXUEwCRW6OE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EoTV9kGQfMhNwM9Is2uuRGFDu0rInAAJR+wBEJMFByM3lmMwuRjjYbYNT8LcCvuK0pHNYx7BK689HN341nfw8f2sDXkvhMGZSKTGAcQlX3YDbmY8zpP5s2L8yHOs8/XjHkKKGRbbnnBnsPBwXB3DTZdKqi24aqq00TXld8Hicr8= Received: by 10.110.49.6 with SMTP id w6mr619792tiw.6.1212101990712; Thu, 29 May 2008 15:59:50 -0700 (PDT) Received: by 10.110.86.14 with HTTP; Thu, 29 May 2008 15:59:50 -0700 (PDT) Message-ID: <4b0d6e0d0805291559p146bb60bo16b8df895a0553c8@mail.gmail.com> Date: Fri, 30 May 2008 04:29:50 +0530 From: "joy merwin monteiro" To: roll@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [Roll] Query X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: joy.merwin@gmail.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, went through the protocol survey document, and had one question: are the protocols being considered only from among those which exist as RFCs ? If yes, why ? If not, why are protocols like directed diffusion and rumor routing not considered ? Apologies if it sounds retarded to some. TIA, Joy -- "...For there is no freedom if it is not secured by the state; and conversely, only a state which is controlled by free citizens can offer them any reasonable security at all" -- Karl Popper in "Open Society and its Enemies, discussing balance of freedom and state control. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 29 17:57:40 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA883A68F2; Thu, 29 May 2008 17:57:40 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC6893A68F2 for ; Thu, 29 May 2008 17:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8FyWh0l3bBW for ; Thu, 29 May 2008 17:57:39 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 28EAC3A63C9 for ; Thu, 29 May 2008 17:57:39 -0700 (PDT) Received: from [76.14.71.180] (helo=[192.168.2.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1K1sw5-0002Nj-4b; Thu, 29 May 2008 17:57:37 -0700 Message-Id: <00E9FD92-90D8-49F0-AF69-7E5486BC8368@cs.stanford.edu> From: Philip Levis To: joy.merwin@gmail.com In-Reply-To: <4b0d6e0d0805291559p146bb60bo16b8df895a0553c8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 29 May 2008 17:57:36 -0700 References: <4b0d6e0d0805291559p146bb60bo16b8df895a0553c8@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: ff384b2b9a2989b26e23b1d864f6aba2 Cc: roll@ietf.org Subject: Re: [Roll] Query X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On May 29, 2008, at 3:59 PM, joy merwin monteiro wrote: > Hi, > > went through the protocol survey document, and had one question: > are the protocols being considered only from among those which > exist as RFCs ? If yes, why ? If not, why are protocols like > directed diffusion and rumor routing not considered ? Well, you'll note that no research protocols -- UCLA/USC/ISI or otherwise -- are mentioned. From the perspective of this document, the question is whether an existing IETF protocol will meet the needs of ROLL. That is, whether there needs to be one or more RFCs that describe protocols for ROLL, or whether existing ones suffice. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 29 22:00:22 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663573A6A0E; Thu, 29 May 2008 22:00:22 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525DA3A685C for ; Thu, 29 May 2008 22:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGX50bgpFSnB for ; Thu, 29 May 2008 22:00:20 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 2BC073A6963 for ; Thu, 29 May 2008 22:00:20 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3434862wfd.31 for ; Thu, 29 May 2008 22:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=HHoyW8wzTIQKdMOM61MSEzxIoZgHzbhKcT8bUoZes2g=; b=iRuQTLdB9DiKn/aus21hp7XP+2IGmy+I2cKg0rFhK3JwpvdEyqAmd3WR/JrI/UgsP46TpGsjeuvzGU6l2uFeX4q/9Igmq8LkHIdGKo2/i2orEeklgpCtmxJg6pmq6xA6/tQ8n0GbShzl4akZVjKvW7zvkzAXH+Rtl7TNsVKi70c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=vmHMtp5RHfEE0RhoMtJzR7nqIGELgmLZXx/YnWA8d2OdWbS0wBJywBwbsk8KsVFK9QFJU9H640sw0HPoRRgYikYwoCDTvMUcRAmo4HcQlsog2DVEKV8mTr3wxgfJMo437g2Nh15kpaZ5zjtb9NoU8vU1FjjHfGvaYCa9e6QKcI8= Received: by 10.142.178.13 with SMTP id a13mr604691wff.143.1212123619653; Thu, 29 May 2008 22:00:19 -0700 (PDT) Received: from 178-1.tmplife.jp.interop.net ( [45.99.1.178]) by mx.google.com with ESMTPS id 30sm3650556wfd.1.2008.05.29.22.00.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 May 2008 22:00:18 -0700 (PDT) From: Ryuji Wakikawa To: JP Vasseur In-Reply-To: References: Message-Id: <209F64E1-DA4C-4F0E-A82C-095027B0A7AF@gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 30 May 2008 13:59:56 +0900 X-Mailer: Apple Mail (2.919.2) Cc: roll@ietf.org, h-kuwabara@jp.toyota-itc.com Subject: Re: [Roll] Fwd: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear JP, On 2008/05/30, at 0:47, JP Vasseur wrote: > Dear Ryuji, > > First of all sorry for the delay in replying to your message. As you > pointed > out, in-vehicle is not part of the WG charter. Thus this document > could not > be a WG document for the time being. No problem at all. The intention of this document is new input to ROLL WG from vehicle industry. > That being said, there is no issue in using the ROLL mailing list to > discuss > it. I would encourage people to look at it and comment. If we have > some time > in Dublin, I have no problem giving you a slot to present your > document. Thanks. IETF community might not be familiar with in-vehicle networks. (So am I..). but the network characteristics is similar to the ROLL network. Vehicle industry is extending functionalities of in-vehicle networks and might need routing functionality soon. Inputs from ROLL group is highly appreciated. It will be great if we can present our requirements at the Dublin meeting. regards, ryuji > Thanks. > > JP. > > > On 5/29/08 5:48 AM, "Ryuji Wakikawa" wrote: > >> Hello all, >> >> We published a new requirement document for ROLL routing protocols. >> Although an in-vehicle network is not currently chartered in WG, >> we are very interested in ROLL activity for the future automobile. >> >> As Jukka mentioned, some requirements are very similar to other >> requirements documents. >> We tried to highlight the differences in the document. >> >> Any feedback will be appreciated. >> >> thanks, >> ryuji >> >> Begin forwarded message: >> >>> From: Internet-Drafts@ietf.org >>> date: 2008/5/2918:30:01:JST >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt >>> Reply-to: internet-drafts@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : In-Vehicle Routing Requirements in Low Power and >>> Lossy Networks >>> Author(s) : R. Wakikawa, H. Kuwabara >>> Filename : draft-wakikawa-roll-invehicle-reqs-00.txt >>> Pages : 20 >>> Date : 2008-05-29 >>> >>> This document presents the routing requirements for in-vehicle low >>> power and lossy networks. Automobiles are already equipped with >>> several sensors and devices named Electronic Control Unit (ECU) for >>> controlling, monitoring and entertainment, etc. For the future in- >>> vehicle networks, the shift to wireless is desirable due to heavy >>> weight and volume of cables in vehicles and to be able to >>> efficiently >>> install devices. However, with the limitation of low power, in- >>> vehicle network still requires reliability and scalability in nature >>> of the rolls of ECU. The routing protocol should support the >>> features of low-power, high-reliability, Subnetting, QoS, Mobility, >>> etc. This document briefly explains the in-vehicle networks and >>> ECUs, then discusses the requirements for the future wireless in- >>> vehicle networks. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-wakikawa-roll-invehicle-reqs-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu May 29 22:30:30 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EE553A6827; Thu, 29 May 2008 22:30:30 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30A83A6ABF for ; Thu, 29 May 2008 22:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIqXAMEMO4eP for ; Thu, 29 May 2008 22:30:15 -0700 (PDT) Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by core3.amsl.com (Postfix) with ESMTP id D08C828C11A for ; Thu, 29 May 2008 22:27:19 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id m4U5REEZ020737; Fri, 30 May 2008 08:27:14 +0300 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 20708-343-2; Fri, 30 May 2008 08:27:13 +0300 (EEST) Received: from [130.233.152.99] (e3n-3.netlab.hut.fi [130.233.152.99]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id m4U5QiFo020491; Fri, 30 May 2008 08:26:44 +0300 Message-ID: <483F9014.7010908@tkk.fi> Date: Fri, 30 May 2008 08:26:44 +0300 From: Jukka MJ Manner User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: ROLL WG Subject: Re: [Roll] Some thoughts on the requirements documents [2nd try] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi JP, Some answers below. Jukka JP Vasseur wrote: > Hi Jukka, > > > On 5/29/08 4:17 AM, "Jukka MJ Manner" wrote: > >> [2nd try, 1st one bounced for some reason] > > You need to subscribe to the list. I quite well know, thanks - I've been hanging around in the IETF for quite some time. And I was subscribed on the list, too. > >> Hi >> >> I went through the various requirements documents and I'm a bit puzzled. >> In general the drafts are easy to read and we have many interesting >> scenarios described that open up nicely the environment. Yet, the drafts >> list similar requirements, there is very little difference in what they >> expect the routing service to do. > > Two comments here: > (1) I think that there are significant differences between the requirement > set forth in the IDs, in term of functionality (e.g. constrained based > routing, scale, ....) To me the documents looked, in terms of _requirements_ very, very similar. Sure, there are small differences, but most of the things are the same. > (2) There is no issue in having some similar routing requirements spelled > out in the IDs. This is a good news. The point is: what is the value of saying similar things many times? > >> If we are to work on a solution later on, it is somewhat challenging to >> find out the what our goals truly are. > > Sounds fairly obvious to me. How can you select/define a solution w/o > knowing what the requirements are ? The point was that the current drafts talk about usecases and list requirements in a mixed way, and repeat the same things. For the work to proceed, we eventually need to gather a single set of requirements, in particular to make the work more focused. The WG charter lists three usecase/reqs drafts, so does that mean we need to interpret all three concurrently while drafting solutions? Reading a single list of requirements would be easier, IMHO. E.g., one draft says we need to support couple hundred nodes, another one says we need to support couple thousand, one drafts says we could support multicast, another says that multicast is a must. Then there are those performance requirements (see below). > >> IMHO, the requirements documents should focus on the scenarios and use >> cases of sensor networks, and list in general what the routing subsystem >> aught to do. These drafts should not use RFC 2119 language. >> > > No. "Requirements" and "Use cases" (what we usually call "Applicability > statement" at the IETF) have very different purposes and what we need to do > according to our charter is first to spell out the requirement documents. The point is that if you look at the WGs in the IETF (NSIS, DCCP, PCN, 6lowpan, DNA, Netlmm, PANA, to name a few), they typically have one requirements/goals document describing in a single place what the work is tackling. Roll has 3 documents, it doesn't make it any simpler for an outsider, or probably even the WG, to figure out the requirements of the work. > > Note that RFC 2119 is very much appropriate in requirement documents. RFC2119 only talks about language issues, it doesn't tell how one should present requirements. > >> We need a separate document that lists the concrete goals of such a >> routing subsystem/protocol/architecture/service/whateveryouwanttocallit. > > Not sure what you mean here. Use the current drafts as the use cases for Roll (without RFC2119 language). Then take out the requirements, use RFC2119 language and formulate a single document that can then be used to steer the design of a solution. > >> Here there is also a clear need to separate functional and performance >> requirements. Typically performance values and goals are mutually >> exclusive, e.g., we can't have low power and high performance at the >> same time (with some definition of what is low and what is high). > > One of the key reasons why the Internet has been so successful is that we > avoid to specify performances, so I disagree with your vision here. I kinda know that... Again, the point is that the drafts already do that, i.e., they specify absolute performance values to be achieved. I don't want to have strict performance values, but the WG documents already do that. Should these then be taken out from the existing drafts? > > Of course, we will use performance related metric during our protocol survey > evaluation. If the various WG requirement documents list performance values, then the WG must achieve those. (I would expect an eventual AD and/or IESG review to ask you to remove those performance requirements, though.) > >> This latter document is used in both analysing the existing schemes and >> drafting a potential solution. > > See > http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.txt Yes, I know the draft. > > I would expect that we end up with one >> general solution, where the parameters can be tuned to certain direction >> to make it fit different use cases. > > Absolutely. > >> Actually, we also need to document the threats we see in the >> environment, and focus on the routing subsystem. The current drafts have >> some thoughts about that, but its only a beginning. > > Please elaborate. Well, the industrial use cases draft already talks about trust issues and compartmentalizing things. The urban reqs also hints at some threats that would be present in that environment. The home reqs doesn't list any, yet. Several WGs have a separate document that highlights the threats, c.f. RFC4081 or RFC4832. Maybe I'm just the only one having difficulty in seeing where the work of the WG as a whole is going and what the goals are. In that case you can just neglect my questions and suggestions. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri May 30 00:47:48 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C0F3A6870; Fri, 30 May 2008 00:47:48 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863763A67DA for ; Fri, 30 May 2008 00:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.277 X-Spam-Level: X-Spam-Status: No, score=-4.277 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ii6jr6TGj1Js for ; Fri, 30 May 2008 00:47:46 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C98FA3A6870 for ; Fri, 30 May 2008 00:47:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,565,1204520400"; d="scan'208";a="9629145" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 May 2008 03:47:42 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4U7lfrL029793; Fri, 30 May 2008 03:47:41 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4U7lfUS024235; Fri, 30 May 2008 07:47:41 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 03:47:41 -0400 Received: from 144.254.93.8 ([144.254.93.8]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 May 2008 07:47:41 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 30 May 2008 09:47:38 +0200 From: JP Vasseur To: Jukka MJ Manner Message-ID: Thread-Topic: [Roll] Some thoughts on the requirements documents [2nd try] Thread-Index: AcjCKW5MJOzQDXc1x0u2o6JSh3npoA== In-Reply-To: <483F9014.7010908@tkk.fi> Mime-version: 1.0 X-OriginalArrivalTime: 30 May 2008 07:47:41.0756 (UTC) FILETIME=[708967C0:01C8C229] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7598; t=1212133661; x=1212997661; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Some=20thoughts=20on=20the=20r equirements=20documents=20[2nd=20try] |Sender:=20 |To:=20Jukka=20MJ=20Manner=20; bh=YoeZ+jAf9ynikz+EYw16K3MzJw90Xh0Jwu77pUxMxHs=; b=PMhLVY+2TzZnhcniI4l1H/zxo+W2VMe2SqSdO3lmtra6wbCo0UrX3Nh5us G3uRU/vKVVmHTT4fZKvISB/lwFIO67s2cjHfFHKjVXVt3SHQvcttJiEmjj0j 1s1ZrKGr5C; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: ROLL WG Subject: Re: [Roll] Some thoughts on the requirements documents [2nd try] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, On 5/30/08 7:26 AM, "Jukka MJ Manner" wrote: > Hi JP, > > Some answers below. > > Jukka > > JP Vasseur wrote: >> Hi Jukka, >> >> >> On 5/29/08 4:17 AM, "Jukka MJ Manner" wrote: >> >>> [2nd try, 1st one bounced for some reason] >> >> You need to subscribe to the list. > > I quite well know, thanks - I've been hanging around in the IETF for > quite some time. And I was subscribed on the list, too. > >> >>> Hi >>> >>> I went through the various requirements documents and I'm a bit puzzled. >>> In general the drafts are easy to read and we have many interesting >>> scenarios described that open up nicely the environment. Yet, the drafts >>> list similar requirements, there is very little difference in what they >>> expect the routing service to do. >> >> Two comments here: >> (1) I think that there are significant differences between the requirement >> set forth in the IDs, in term of functionality (e.g. constrained based >> routing, scale, ....) > > To me the documents looked, in terms of _requirements_ very, very > similar. Sure, there are small differences, but most of the things are > the same. Just to take one example, the specification of a routing protocol for a few dozen of nodes (Home Automation) and several hundreds of thousands (urban networks) is not exactly the same and has strong implications on the design. > >> (2) There is no issue in having some similar routing requirements spelled >> out in the IDs. This is a good news. > > The point is: what is the value of saying similar things many times? Please look at the history of the WG. We decided to be application driven. Thus the task consists of analyzing the routing requirements of (in our case) 4 applications. If it turns out that several applications have similar requirements, this is a perfectly good outcome, that will simply the task of the WG to select or specify a new WG. > >> >>> If we are to work on a solution later on, it is somewhat challenging to >>> find out the what our goals truly are. >> >> Sounds fairly obvious to me. How can you select/define a solution w/o >> knowing what the requirements are ? > > The point was that the current drafts talk about usecases and list > requirements in a mixed way, and repeat the same things. For the work to > proceed, we eventually need to gather a single set of requirements, in > particular to make the work more focused. The WG charter lists three > usecase/reqs drafts, 4 so does that mean we need to interpret all three > concurrently while drafting solutions? Reading a single list of > requirements would be easier, IMHO. The super-set of requirements will be taken into account in the protocol survey and then protocol selection/design. > > E.g., one draft says we need to support couple hundred nodes, another > one says we need to support couple thousand, one drafts says we could > support multicast, another says that multicast is a must. Ah so you saw some differences .... Then there are > those performance requirements (see below). > >> >>> IMHO, the requirements documents should focus on the scenarios and use >>> cases of sensor networks, and list in general what the routing subsystem >>> aught to do. These drafts should not use RFC 2119 language. >>> >> >> No. "Requirements" and "Use cases" (what we usually call "Applicability >> statement" at the IETF) have very different purposes and what we need to do >> according to our charter is first to spell out the requirement documents. > > The point is that if you look at the WGs in the IETF (NSIS, DCCP, PCN, > 6lowpan, DNA, Netlmm, PANA, to name a few), they typically have one > requirements/goals document describing in a single place what the work > is tackling. Roll has 3 documents, it doesn't make it any simpler for an > outsider, or probably even the WG, to figure out the requirements of the > work. This is the approach that we took. Note that other WGs took the same approach (e.g. PCE, ...) and have been very successful. > >> >> Note that RFC 2119 is very much appropriate in requirement documents. > > RFC2119 only talks about language issues, it doesn't tell how one should > present requirements. Please look around and you will see many requirements documents with RFC 2119 language. > >> >>> We need a separate document that lists the concrete goals of such a >>> routing subsystem/protocol/architecture/service/whateveryouwanttocallit. >> >> Not sure what you mean here. > > Use the current drafts as the use cases for Roll (without RFC2119 > language). Then take out the requirements, use RFC2119 language and > formulate a single document that can then be used to steer the design of > a solution. No, the requirements will make use of the RFC 2119 language. > >> >>> Here there is also a clear need to separate functional and performance >>> requirements. Typically performance values and goals are mutually >>> exclusive, e.g., we can't have low power and high performance at the >>> same time (with some definition of what is low and what is high). >> >> One of the key reasons why the Internet has been so successful is that we >> avoid to specify performances, so I disagree with your vision here. > > I kinda know that... Again, the point is that the drafts already do > that, i.e., they specify absolute performance values to be achieved. I > don't want to have strict performance values, but the WG documents > already do that. Should these then be taken out from the existing drafts? They are indicative. > >> >> Of course, we will use performance related metric during our protocol survey >> evaluation. > > If the various WG requirement documents list performance values, then > the WG must achieve those. (I would expect an eventual AD and/or IESG > review to ask you to remove those performance requirements, though.) > >> >>> This latter document is used in both analysing the existing schemes and >>> drafting a potential solution. >> >> See >> http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.txt > > Yes, I know the draft. > >> >> I would expect that we end up with one >>> general solution, where the parameters can be tuned to certain direction >>> to make it fit different use cases. >> >> Absolutely. >> >>> Actually, we also need to document the threats we see in the >>> environment, and focus on the routing subsystem. The current drafts have >>> some thoughts about that, but its only a beginning. >> >> Please elaborate. > > Well, the industrial use cases draft already talks about trust issues > and compartmentalizing things. The urban reqs also hints at some threats > that would be present in that environment. The home reqs doesn't list > any, yet. Several WGs have a separate document that highlights the > threats, c.f. RFC4081 or RFC4832. > > Maybe I'm just the only one having difficulty in seeing where the work > of the WG as a whole is going and what the goals are. In that case you > can just neglect my questions and suggestions. All comments are most welcome. But indeed, I haven't received any other similar complaints. This is indeed quite the opposite with many comments from regular contributors finding that the WG formed a few months ago was moving fairly quickly. There is still quite some work on the requirements IDs but we're getting close to our Milestone. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri May 30 00:49:39 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E753A6870; Fri, 30 May 2008 00:49:39 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7CB3A6870 for ; Fri, 30 May 2008 00:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.227 X-Spam-Level: X-Spam-Status: No, score=-4.227 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of0xdGr2nvJz for ; Fri, 30 May 2008 00:49:37 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2B5233A67A4 for ; Fri, 30 May 2008 00:49:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,565,1204520400"; d="scan'208";a="9629190" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 May 2008 03:49:36 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4U7naD2029472; Fri, 30 May 2008 03:49:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4U7naeG024655; Fri, 30 May 2008 07:49:36 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 03:49:35 -0400 Received: from 144.254.93.8 ([144.254.93.8]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 May 2008 07:49:35 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 30 May 2008 09:49:29 +0200 From: JP Vasseur To: Ryuji Wakikawa Message-ID: Thread-Topic: [Roll] Fwd: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt Thread-Index: AcjCKbB1Lxjd6x1PLEqfX92PFyhl7Q== In-Reply-To: <209F64E1-DA4C-4F0E-A82C-095027B0A7AF@gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 30 May 2008 07:49:35.0978 (UTC) FILETIME=[B49E4CA0:01C8C229] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4362; t=1212133776; x=1212997776; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Fwd=3A=20I-D=20Action=3Adraft- wakikawa-roll-invehicle-reqs-00.txt |Sender:=20 |To:=20Ryuji=20Wakikawa=20; bh=pQla+TKbXrKWGos1Bbn9hidD7usGoGfAyKszkZmxMR8=; b=mE1Y2WPXn2W9fneewujQveFB9PIVU7t4QiYt7qTMS/kwgpPX8QeLk+vG6x AqG6hSlYjyv5o9bFBXZ1FrUMbZqcE9DuSkaNJTUvpVf26rCR8PhbzcCjvSvk racDWM75Fg; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org, h-kuwabara@jp.toyota-itc.com Subject: Re: [Roll] Fwd: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, On 5/30/08 6:59 AM, "Ryuji Wakikawa" wrote: > Dear JP, > > On 2008/05/30, at 0:47, JP Vasseur wrote: > >> Dear Ryuji, >> >> First of all sorry for the delay in replying to your message. As you >> pointed >> out, in-vehicle is not part of the WG charter. Thus this document >> could not >> be a WG document for the time being. > > No problem at all. > The intention of this document is new input to ROLL WG from vehicle > industry. Great. > >> That being said, there is no issue in using the ROLL mailing list to >> discuss >> it. I would encourage people to look at it and comment. If we have >> some time >> in Dublin, I have no problem giving you a slot to present your >> document. > > Thanks. > > IETF community might not be familiar with in-vehicle networks. (So am > I..). > but the network characteristics is similar to the ROLL network. > > Vehicle industry is extending functionalities of in-vehicle networks > and might need routing functionality soon. > Inputs from ROLL group is highly appreciated. > > It will be great if we can present our requirements at the Dublin > meeting. As we get closer to the WG meeting schedule I will let you know if you can have a slot but there should be no problem. Thanks. JP. > > regards, > ryuji > > > > >> Thanks. >> >> JP. >> >> >> On 5/29/08 5:48 AM, "Ryuji Wakikawa" wrote: >> >>> Hello all, >>> >>> We published a new requirement document for ROLL routing protocols. >>> Although an in-vehicle network is not currently chartered in WG, >>> we are very interested in ROLL activity for the future automobile. >>> >>> As Jukka mentioned, some requirements are very similar to other >>> requirements documents. >>> We tried to highlight the differences in the document. >>> >>> Any feedback will be appreciated. >>> >>> thanks, >>> ryuji >>> >>> Begin forwarded message: >>> >>>> From: Internet-Drafts@ietf.org >>>> date: 2008/5/2918:30:01:JST >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt >>>> Reply-to: internet-drafts@ietf.org >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> Title : In-Vehicle Routing Requirements in Low Power and >>>> Lossy Networks >>>> Author(s) : R. Wakikawa, H. Kuwabara >>>> Filename : draft-wakikawa-roll-invehicle-reqs-00.txt >>>> Pages : 20 >>>> Date : 2008-05-29 >>>> >>>> This document presents the routing requirements for in-vehicle low >>>> power and lossy networks. Automobiles are already equipped with >>>> several sensors and devices named Electronic Control Unit (ECU) for >>>> controlling, monitoring and entertainment, etc. For the future in- >>>> vehicle networks, the shift to wireless is desirable due to heavy >>>> weight and volume of cables in vehicles and to be able to >>>> efficiently >>>> install devices. However, with the limitation of low power, in- >>>> vehicle network still requires reliability and scalability in nature >>>> of the rolls of ECU. The routing protocol should support the >>>> features of low-power, high-reliability, Subnetting, QoS, Mobility, >>>> etc. This document briefly explains the in-vehicle networks and >>>> ECUs, then discusses the requirements for the future wireless in- >>>> vehicle networks. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-wakikawa-roll-invehicle-reqs-00.t >>>> xt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri May 30 01:16:22 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4073D3A683C; Fri, 30 May 2008 01:16:22 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377AA28C136 for ; Fri, 30 May 2008 01:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.733 X-Spam-Level: X-Spam-Status: No, score=-5.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8pK3EWGoOtt for ; Fri, 30 May 2008 01:16:19 -0700 (PDT) Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by core3.amsl.com (Postfix) with ESMTP id 074AC3A6813 for ; Fri, 30 May 2008 01:16:18 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id m4U8G69k001346; Fri, 30 May 2008 11:16:06 +0300 Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 02498-353-3; Fri, 30 May 2008 11:16:06 +0300 (EEST) Received: from [130.233.152.99] (e3n-3.netlab.hut.fi [130.233.152.99]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id m4U8G2Si001267; Fri, 30 May 2008 11:16:02 +0300 Message-ID: <483FB7C2.1020405@tkk.fi> Date: Fri, 30 May 2008 11:16:02 +0300 From: Jukka MJ Manner User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: ROLL WG Subject: Re: [Roll] Some thoughts on the requirements documents [2nd try] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi JP, Don't get me wrong, I'm not complaining as you seem to think. Application driven approach is fine. I'm trying to understand how four sets of requirements (in the broad sense incl. security), partly mutually excluding, are used in the future. Is the WG in fact going towards 4 distinct parallel tracks in the survey, and specification of the architecture? So it is a non-goal to have a unified vision of how routing in sensor networks in the broad sense should perform. Regards, Jukka JP Vasseur wrote: > Hi, > > > On 5/30/08 7:26 AM, "Jukka MJ Manner" wrote: > >> Hi JP, >> >> Some answers below. >> >> Jukka >> >> JP Vasseur wrote: >>> Hi Jukka, >>> >>> >>> On 5/29/08 4:17 AM, "Jukka MJ Manner" wrote: >>> >>>> [2nd try, 1st one bounced for some reason] >>> You need to subscribe to the list. >> I quite well know, thanks - I've been hanging around in the IETF for >> quite some time. And I was subscribed on the list, too. >> >>>> Hi >>>> >>>> I went through the various requirements documents and I'm a bit puzzled. >>>> In general the drafts are easy to read and we have many interesting >>>> scenarios described that open up nicely the environment. Yet, the drafts >>>> list similar requirements, there is very little difference in what they >>>> expect the routing service to do. >>> Two comments here: >>> (1) I think that there are significant differences between the requirement >>> set forth in the IDs, in term of functionality (e.g. constrained based >>> routing, scale, ....) >> To me the documents looked, in terms of _requirements_ very, very >> similar. Sure, there are small differences, but most of the things are >> the same. > > Just to take one example, the specification of a routing protocol for a few > dozen of nodes (Home Automation) and several hundreds of thousands (urban > networks) is not exactly the same and has strong implications on the design. > >>> (2) There is no issue in having some similar routing requirements spelled >>> out in the IDs. This is a good news. >> The point is: what is the value of saying similar things many times? > > Please look at the history of the WG. We decided to be application driven. > Thus the task consists of analyzing the routing requirements of (in our > case) 4 applications. If it turns out that several applications have similar > requirements, this is a perfectly good outcome, that will simply the task of > the WG to select or specify a new WG. > >>>> If we are to work on a solution later on, it is somewhat challenging to >>>> find out the what our goals truly are. >>> Sounds fairly obvious to me. How can you select/define a solution w/o >>> knowing what the requirements are ? >> The point was that the current drafts talk about usecases and list >> requirements in a mixed way, and repeat the same things. For the work to >> proceed, we eventually need to gather a single set of requirements, in >> particular to make the work more focused. The WG charter lists three >> usecase/reqs drafts, > > 4 > > so does that mean we need to interpret all three >> concurrently while drafting solutions? Reading a single list of >> requirements would be easier, IMHO. > > The super-set of requirements will be taken into account in the protocol > survey and then protocol selection/design. > >> E.g., one draft says we need to support couple hundred nodes, another >> one says we need to support couple thousand, one drafts says we could >> support multicast, another says that multicast is a must. > > Ah so you saw some differences .... > > > Then there are >> those performance requirements (see below). >> >>>> IMHO, the requirements documents should focus on the scenarios and use >>>> cases of sensor networks, and list in general what the routing subsystem >>>> aught to do. These drafts should not use RFC 2119 language. >>>> >>> No. "Requirements" and "Use cases" (what we usually call "Applicability >>> statement" at the IETF) have very different purposes and what we need to do >>> according to our charter is first to spell out the requirement documents. >> The point is that if you look at the WGs in the IETF (NSIS, DCCP, PCN, >> 6lowpan, DNA, Netlmm, PANA, to name a few), they typically have one >> requirements/goals document describing in a single place what the work >> is tackling. Roll has 3 documents, it doesn't make it any simpler for an >> outsider, or probably even the WG, to figure out the requirements of the >> work. > > This is the approach that we took. Note that other WGs took the same > approach (e.g. PCE, ...) and have been very successful. > >>> Note that RFC 2119 is very much appropriate in requirement documents. >> RFC2119 only talks about language issues, it doesn't tell how one should >> present requirements. > > Please look around and you will see many requirements documents with RFC > 2119 language. > >>>> We need a separate document that lists the concrete goals of such a >>>> routing subsystem/protocol/architecture/service/whateveryouwanttocallit. >>> Not sure what you mean here. >> Use the current drafts as the use cases for Roll (without RFC2119 >> language). Then take out the requirements, use RFC2119 language and >> formulate a single document that can then be used to steer the design of >> a solution. > > No, the requirements will make use of the RFC 2119 language. > >>>> Here there is also a clear need to separate functional and performance >>>> requirements. Typically performance values and goals are mutually >>>> exclusive, e.g., we can't have low power and high performance at the >>>> same time (with some definition of what is low and what is high). >>> One of the key reasons why the Internet has been so successful is that we >>> avoid to specify performances, so I disagree with your vision here. >> I kinda know that... Again, the point is that the drafts already do >> that, i.e., they specify absolute performance values to be achieved. I >> don't want to have strict performance values, but the WG documents >> already do that. Should these then be taken out from the existing drafts? > > They are indicative. > >>> Of course, we will use performance related metric during our protocol survey >>> evaluation. >> If the various WG requirement documents list performance values, then >> the WG must achieve those. (I would expect an eventual AD and/or IESG >> review to ask you to remove those performance requirements, though.) >> >>>> This latter document is used in both analysing the existing schemes and >>>> drafting a potential solution. >>> See >>> http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.txt >> Yes, I know the draft. >> >>> I would expect that we end up with one >>>> general solution, where the parameters can be tuned to certain direction >>>> to make it fit different use cases. >>> Absolutely. >>> >>>> Actually, we also need to document the threats we see in the >>>> environment, and focus on the routing subsystem. The current drafts have >>>> some thoughts about that, but its only a beginning. >>> Please elaborate. >> Well, the industrial use cases draft already talks about trust issues >> and compartmentalizing things. The urban reqs also hints at some threats >> that would be present in that environment. The home reqs doesn't list >> any, yet. Several WGs have a separate document that highlights the >> threats, c.f. RFC4081 or RFC4832. >> >> Maybe I'm just the only one having difficulty in seeing where the work >> of the WG as a whole is going and what the goals are. In that case you >> can just neglect my questions and suggestions. > > All comments are most welcome. But indeed, I haven't received any other > similar complaints. This is indeed quite the opposite with many comments > from regular contributors finding that the WG formed a few months ago was > moving fairly quickly. There is still quite some work on the requirements > IDs but we're getting close to our Milestone. > -- Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+451 2481 Helsinki University of Technology Fax: +358+(0)9+451 2474 Department of Communications Office: E309 (Otakaari 5) and Networking E-mail: jukka.manner@tkk.fi P.O. Box 3000, FIN-02015 TKK WWW: www.netlab.tkk.fi Finland Private:+358+(0)50+320 3018 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri May 30 11:18:18 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596283A6A54; Fri, 30 May 2008 11:18:18 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923D53A6A54 for ; Fri, 30 May 2008 11:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaX3GVuNN0Nc for ; Fri, 30 May 2008 11:18:16 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by core3.amsl.com (Postfix) with ESMTP id 55CCF3A6A0F for ; Fri, 30 May 2008 11:18:16 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so34788pyg.24 for ; Fri, 30 May 2008 11:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=6NpiW2mxFBlxLzLq6oOtQz2Ts67KpDy27NVpNYqYcPE=; b=V7ML8fega/YCDtDrZQf8YQeP6SZiLikC56SGKXAplc0mMPnmR6AsmtTKBLAIox5sPJYKbeoClsnZfnMrcq3RigxIeKnfxYGBPqtYBGftPMJ6TSgRjQ1csZxaH2kWhbKVP6k3sfADhCR7h56PcRjAiPlGlK99K986hl1NX8ODU+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=QomZWe9GE3PrRGKRC+Ls51qoS9mxE49Vq/qu3/A6ZNRr4bkRT7dlG1sXqRY6x+BZlk80UuJoXFmDZUvBXH0AhSHp7Ie52hVA3Y3oevmmIRZ5pOJ/MbKiG+Oisd+kSyZ4FX02+DV2K7dlHWpYwdVt43Cd+AHbHyqxEauaU06vBiE= Received: by 10.114.13.1 with SMTP id 1mr6609212wam.96.1212171493235; Fri, 30 May 2008 11:18:13 -0700 (PDT) Received: by 10.115.91.7 with HTTP; Fri, 30 May 2008 11:18:13 -0700 (PDT) Message-ID: <86c3ed7b0805301118j18ddc19dy9a111d9073f4ca3b@mail.gmail.com> Date: Fri, 30 May 2008 20:18:13 +0200 From: "Miguel Sanchez" To: "JP Vasseur" In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: f99ece1b01a23488 Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1453146904==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1453146904== Content-Type: multipart/alternative; boundary="----=_Part_11171_8377706.1212171493192" ------=_Part_11171_8377706.1212171493192 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi JP, On 5/29/08, JP Vasseur wrote: > > Hi Phil and Carles, > > > > On 5/28/08 1:38 AM, "Philip Levis" wrote: > > > On May 27, 2008, at 2:29 AM, Carles Gomez Montenegro wrote: > >> > >> At least, there are the following items listed in the routing > >> requirements > >> draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt) > >> that route-over approach cannot provide or would provide only in a > >> limited > >> way: > > > > I disagree wholeheartedly. > > > So do I. > > > I think there is a big confusion here > > between a protocol specification and a protocol implementation. > > > > These are all arguments for cross-layer design, that tightly > > integrating routing and the link layer will lead to a better solution. > > Practice has shown us otherwise; > > > Indeed, "practice" being "The Internet". > > > There are a couple of topics that seem to be cross-layer by nature. One of them seems to be power awareness. The other seems to be routing involving wireless links. That is why I am not so sure that "practice" (done mostly with wired links and without power constraints) is very relevant here. That is why IETF MANE= T group was created; not because current routing on the Internet was wrong bu= t because a new type of problem was being addressed (mobile ad-hoc networking). I do not see how MAC feedback can be bad, as not being a mandatory feature network layer can always just ignore it. However I can see how such a feedback can avoid repeating operations already performed at the link layer (i.e. link quality estimation). Just my two cents, Miguel S=E1nchez ------=_Part_11171_8377706.1212171493192 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi JP,


On 5/29/08, JP Vasseur <= jvasseur@cisco.com> wrote:
Hi Phil and Carles,



On 5/28/08 1:38 AM, "Philip Levi= s" <pal@cs.stanford.edu&= gt; wrote:

> On May 27, 2008, at 2:29 AM, Carles Gomez Monteneg= ro wrote:
>>
>> At least, there are the following items listed in th= e routing
>> requirements
>> draft (http://tools.ietf.o= rg/id/draft-dokaspar-6lowpan-routreq-05.txt)
>> that route-over approach cannot provide or would provide only in = a
>> limited
>> way:
>
> I disagree whole= heartedly.


So do I.


I think there is a big confus= ion here
> between a protocol specification and a protocol implementation.
&= gt;
> These are all arguments for cross-layer design, that tightly > integrating routing and the link layer will lead to a better soluti= on.
> Practice has shown us otherwise;


Indeed, "practice&= quot; being "The Internet".



Th= ere are a couple of topics that seem to be cross-layer by nature. One of th= em seems to be power awareness. The other seems to be routing involving wir= eless links.

That is why I am not so sure that "practice" (done mostly wit= h wired links and without power constraints) is very relevant here. That is= why IETF MANET group was created; not because current routing on the Inter= net was wrong but because a new type of problem was being addressed (mobile= ad-hoc networking).

I do not see how MAC feedback can be bad, as not being a mandatory feat= ure network layer can always just ignore it. However I can see how such a f= eedback can avoid repeating operations already performed at the link layer = (i.e. link quality estimation).

Just my two cents,

Miguel S=E1nchez

------=_Part_11171_8377706.1212171493192-- --===============1453146904== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1453146904==-- From roll-bounces@ietf.org Fri May 30 11:51:06 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F0C3A6A57; Fri, 30 May 2008 11:51:06 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82DC33A6A2D for ; Fri, 30 May 2008 11:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYdVlzNZcHJ9 for ; Fri, 30 May 2008 11:50:59 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by core3.amsl.com (Postfix) with ESMTP id 9F1293A6A19 for ; Fri, 30 May 2008 11:50:59 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id m64so21071rnd.18 for ; Fri, 30 May 2008 11:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=fdNe8s90B6hK4Wi8oKo/xurBQaSEVvM4DOA2z2FxbBQ=; b=RgfPrbMeg9b1cfoCBBdRYH6odSN7t97ig8N0xZrf8pNvV/86iHvBAcYj1BdLVgbIKtXWVJGIFNyuk7aiM2FcTTgDku8K9SFWOdhw7lpI+JPjZYgu6ts2JrsoGIwBNCcMj3CLG+eX9LUzKaGOK3PLT71UPT//XsPLdtShpSbPkc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=s0NxABqqMWglhegOLA0PYlroPJ9jLcZZadI+KlvAT08vt3o9OXuFPGHmKX4dWsRA6TLvS2e9cc8v0Zw+LZAyGsGP+huLqtg8PjqBgoANAQjCVb/YTVpE8YO4PSRhWOAi/7/Rjj8lRdFgLGUMNUX16s3aklUimgALGB2Bhx8xIC0= Received: by 10.114.126.1 with SMTP id y1mr2724472wac.37.1212173456189; Fri, 30 May 2008 11:50:56 -0700 (PDT) Received: by 10.115.91.7 with HTTP; Fri, 30 May 2008 11:50:56 -0700 (PDT) Message-ID: <86c3ed7b0805301150u3eb6f137gc9fe8fb9295543c2@mail.gmail.com> Date: Fri, 30 May 2008 20:50:56 +0200 From: "Miguel Sanchez" To: "Ryuji Wakikawa" In-Reply-To: <7A71A0CD-7B0E-4CEA-918B-BB3158FFBFA1@gmail.com> MIME-Version: 1.0 References: <20080529093001.D1E7E3A6B6F@core3.amsl.com> <7A71A0CD-7B0E-4CEA-918B-BB3158FFBFA1@gmail.com> X-Google-Sender-Auth: 0a352adecf28cbde Cc: roll@ietf.org Subject: Re: [Roll] Fwd: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0094799086==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0094799086== Content-Type: multipart/alternative; boundary="----=_Part_11315_27961540.1212173456172" ------=_Part_11315_27961540.1212173456172 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Ryuji, Here you have my comments. On page 8, Body Network: you mention air-bag control and 100msec latency. However, you later refer to the power train latency for the air-bag contro= l (from 2 to 6 msec). Next, on Infotainment Network: you mention a latency of 100msec (including phone communication) but as you put Electronic Toll Collection on the same network you later admit that latency for that has to be much lower. I find these two cases above confusing: having a certain latency for some services but one. (Not sure 100msec for the hands-free is going to be comfortable either). Page 10, Path reliability: What is that? I know what you mean but you may want to elaborate on this concept. Page 13, Security: For encryption, key management needs to be addressed. Regards, Miguel S=E1nchez ------=_Part_11315_27961540.1212173456172 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Ryuji,


Here you have my comments.

On page 8, Body Netw= ork: you mention air-bag control and 100msec latency. However,  you la= ter refer to the power train latency for the air-bag control (from 2 to 6 m= sec).

Next, on Infotainment Network: you mention a latency of 100msec (includ= ing phone communication) but as you put Electronic Toll Collection on the s= ame network you later admit that latency for that has to be much lower.
I find these two cases above confusing: having a certain latency for so= me services but one. (Not sure 100msec for the hands-free is going to be co= mfortable either).

Page 10, Path reliability: What is that? I know w= hat you mean but you may want to elaborate on this concept.

Page 13, Security:  For encryption, key management needs to be add= ressed.

Regards,

Miguel S=E1nchez


------=_Part_11315_27961540.1212173456172-- --===============0094799086== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0094799086==-- From roll-bounces@ietf.org Fri May 30 12:08:37 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61043A6A5C; Fri, 30 May 2008 12:08:36 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0748B3A6B50 for ; Fri, 30 May 2008 12:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgubCtJaiZWj for ; Fri, 30 May 2008 12:08:18 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191]) by core3.amsl.com (Postfix) with ESMTP id 2D1D83A6D1A for ; Fri, 30 May 2008 12:07:26 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id m64so26323rnd.18 for ; Fri, 30 May 2008 12:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=gP+LYQBOaAaRdaLRG+Ch/uoj1c66OyRttqEfg7z0ZnQ=; b=bHiisM1sRAWCJ6DLhaLkQ9MoEINcvhbj4JnH7UsRD5DKYCCbZ9X+TZdGRGokw4WhkP2qXIH2ySknOXKnWCioY0T5l1aMnQthBo+Y4apF6FCl2cXESrw032ccE+4WM2m4L5YhO9qCQoLP3oWk0VIJVthG6Ho8qTeLuD/22baj7qk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Gk+oN53hiPjuPbGK4+uOQ+WV+6xpsm4p2WB1RinrWBV4X7Ex7hZWyeJxNuCfaAcstkBUsusxol4yueKnYmuLh39fn4ixbgpOuiypOo9ZhwMTVFCqmpUO2X5Szm7J9KdXe5g52aEkOz95BRg1IwlREE7Mc2x2eMLl3b94Kb/sCS8= Received: by 10.114.14.1 with SMTP id 1mr6722740wan.9.1212174442991; Fri, 30 May 2008 12:07:22 -0700 (PDT) Received: by 10.115.91.7 with HTTP; Fri, 30 May 2008 12:07:22 -0700 (PDT) Message-ID: <86c3ed7b0805301207g66557b36u14af1ed8d8d9ce8c@mail.gmail.com> Date: Fri, 30 May 2008 21:07:22 +0200 From: "Miguel Sanchez" To: "Jukka MJ Manner" In-Reply-To: <483FB7C2.1020405@tkk.fi> MIME-Version: 1.0 References: <483FB7C2.1020405@tkk.fi> X-Google-Sender-Auth: bf45367f10d9bf6a Cc: ROLL WG Subject: Re: [Roll] Some thoughts on the requirements documents [2nd try] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0113817524==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0113817524== Content-Type: multipart/alternative; boundary="----=_Part_11396_8219963.1212174442972" ------=_Part_11396_8219963.1212174442972 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Jukka, I can see how different set of requirements may make a single workable solution impossible. Having four application scenarios does not mean that 4 different protocols will be needed but we may end up with more than one though. If we look at the Internet routing we can see that several protocols are being used. Kind regards, Miguel S=E1nchez, PhD Associate Professor +349638779709 Computer Egineering Department (DISCA) Polytechnic University of Valencia, Spain On 5/30/08, Jukka MJ Manner wrote: > > Hi JP, > > Don't get me wrong, I'm not complaining as you seem to think. > Application driven approach is fine. I'm trying to understand how four > sets of requirements (in the broad sense incl. security), partly > mutually excluding, are used in the future. Is the WG in fact going > towards 4 distinct parallel tracks in the survey, and specification of > the architecture? So it is a non-goal to have a unified vision of how > routing in sensor networks in the broad sense should perform. > > Regards, > > Jukka > > JP Vasseur wrote: > > Hi, > > > > > > On 5/30/08 7:26 AM, "Jukka MJ Manner" wrote: > > > >> Hi JP, > >> > >> Some answers below. > >> > >> Jukka > >> > >> JP Vasseur wrote: > >>> Hi Jukka, > >>> > >>> > >>> On 5/29/08 4:17 AM, "Jukka MJ Manner" wrote: > >>> > >>>> [2nd try, 1st one bounced for some reason] > >>> You need to subscribe to the list. > >> I quite well know, thanks - I've been hanging around in the IETF for > >> quite some time. And I was subscribed on the list, too. > >> > >>>> Hi > >>>> > >>>> I went through the various requirements documents and I'm a bit > puzzled. > >>>> In general the drafts are easy to read and we have many interesting > >>>> scenarios described that open up nicely the environment. Yet, the > drafts > >>>> list similar requirements, there is very little difference in what > they > >>>> expect the routing service to do. > >>> Two comments here: > >>> (1) I think that there are significant differences between the > requirement > >>> set forth in the IDs, in term of functionality (e.g. constrained base= d > >>> routing, scale, ....) > >> To me the documents looked, in terms of _requirements_ very, very > >> similar. Sure, there are small differences, but most of the things are > >> the same. > > > > Just to take one example, the specification of a routing protocol for a > few > > dozen of nodes (Home Automation) and several hundreds of thousands (urb= an > > networks) is not exactly the same and has strong implications on the > design. > > > >>> (2) There is no issue in having some similar routing requirements > spelled > >>> out in the IDs. This is a good news. > >> The point is: what is the value of saying similar things many times? > > > > Please look at the history of the WG. We decided to be application > driven. > > Thus the task consists of analyzing the routing requirements of (in our > > case) 4 applications. If it turns out that several applications have > similar > > requirements, this is a perfectly good outcome, that will simply the ta= sk > of > > the WG to select or specify a new WG. > > > >>>> If we are to work on a solution later on, it is somewhat challenging > to > >>>> find out the what our goals truly are. > >>> Sounds fairly obvious to me. How can you select/define a solution w/o > >>> knowing what the requirements are ? > >> The point was that the current drafts talk about usecases and list > >> requirements in a mixed way, and repeat the same things. For the work = to > >> proceed, we eventually need to gather a single set of requirements, in > >> particular to make the work more focused. The WG charter lists three > >> usecase/reqs drafts, > > > > 4 > > > > so does that mean we need to interpret all three > >> concurrently while drafting solutions? Reading a single list of > >> requirements would be easier, IMHO. > > > > The super-set of requirements will be taken into account in the protoco= l > > survey and then protocol selection/design. > > > >> E.g., one draft says we need to support couple hundred nodes, another > >> one says we need to support couple thousand, one drafts says we could > >> support multicast, another says that multicast is a must. > > > > Ah so you saw some differences .... > > > > > > Then there are > >> those performance requirements (see below). > >> > >>>> IMHO, the requirements documents should focus on the scenarios and u= se > >>>> cases of sensor networks, and list in general what the routing > subsystem > >>>> aught to do. These drafts should not use RFC 2119 language. > >>>> > >>> No. "Requirements" and "Use cases" (what we usually call "Applicabili= ty > >>> statement" at the IETF) have very different purposes and what we need > to do > >>> according to our charter is first to spell out the requirement > documents. > >> The point is that if you look at the WGs in the IETF (NSIS, DCCP, PCN, > >> 6lowpan, DNA, Netlmm, PANA, to name a few), they typically have one > >> requirements/goals document describing in a single place what the work > >> is tackling. Roll has 3 documents, it doesn't make it any simpler for = an > >> outsider, or probably even the WG, to figure out the requirements of t= he > >> work. > > > > This is the approach that we took. Note that other WGs took the same > > approach (e.g. PCE, ...) and have been very successful. > > > >>> Note that RFC 2119 is very much appropriate in requirement documents. > >> RFC2119 only talks about language issues, it doesn't tell how one shou= ld > >> present requirements. > > > > Please look around and you will see many requirements documents with RF= C > > 2119 language. > > > >>>> We need a separate document that lists the concrete goals of such a > >>>> routing > subsystem/protocol/architecture/service/whateveryouwanttocallit. > >>> Not sure what you mean here. > >> Use the current drafts as the use cases for Roll (without RFC2119 > >> language). Then take out the requirements, use RFC2119 language and > >> formulate a single document that can then be used to steer the design = of > >> a solution. > > > > No, the requirements will make use of the RFC 2119 language. > > > >>>> Here there is also a clear need to separate functional and performan= ce > >>>> requirements. Typically performance values and goals are mutually > >>>> exclusive, e.g., we can't have low power and high performance at the > >>>> same time (with some definition of what is low and what is high). > >>> One of the key reasons why the Internet has been so successful is tha= t > we > >>> avoid to specify performances, so I disagree with your vision here. > >> I kinda know that... Again, the point is that the drafts already do > >> that, i.e., they specify absolute performance values to be achieved. I > >> don't want to have strict performance values, but the WG documents > >> already do that. Should these then be taken out from the existing > drafts? > > > > They are indicative. > > > >>> Of course, we will use performance related metric during our protocol > survey > >>> evaluation. > >> If the various WG requirement documents list performance values, then > >> the WG must achieve those. (I would expect an eventual AD and/or IESG > >> review to ask you to remove those performance requirements, though.) > >> > >>>> This latter document is used in both analysing the existing schemes > and > >>>> drafting a potential solution. > >>> See > >>> > http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.= txt > >> Yes, I know the draft. > >> > >>> I would expect that we end up with one > >>>> general solution, where the parameters can be tuned to certain > direction > >>>> to make it fit different use cases. > >>> Absolutely. > >>> > >>>> Actually, we also need to document the threats we see in the > >>>> environment, and focus on the routing subsystem. The current drafts > have > >>>> some thoughts about that, but its only a beginning. > >>> Please elaborate. > >> Well, the industrial use cases draft already talks about trust issues > >> and compartmentalizing things. The urban reqs also hints at some threa= ts > >> that would be present in that environment. The home reqs doesn't list > >> any, yet. Several WGs have a separate document that highlights the > >> threats, c.f. RFC4081 or RFC4832. > >> > >> Maybe I'm just the only one having difficulty in seeing where the work > >> of the WG as a whole is going and what the goals are. In that case you > >> can just neglect my questions and suggestions. > > > > All comments are most welcome. But indeed, I haven't received any other > > similar complaints. This is indeed quite the opposite with many comment= s > > from regular contributors finding that the WG formed a few months ago w= as > > moving fairly quickly. There is still quite some work on the requiremen= ts > > IDs but we're getting close to our Milestone. > > > > > -- > > Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+451 2481 > Helsinki University of Technology Fax: +358+(0)9+451 2474 > Department of Communications Office: E309 (Otakaari 5) > and Networking E-mail: jukka.manner@tkk.fi > P.O. Box 3000, FIN-02015 TKK WWW: www.netlab.tkk.fi > Finland Private:+358+(0)50+320 3018 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > ------=_Part_11396_8219963.1212174442972 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Jukka,

I can see how different set of requirements may make a sin= gle workable solution impossible. Having four application scenarios does no= t mean that 4 different protocols will be needed but we may end up with mor= e than one though.

If we look at the Internet routing we can see that several protocols ar= e being used.

Kind regards,

Miguel S=E1nchez, PhD Associate P= rofessor +349638779709
Computer Egineering Department (DISCA)
Polytec= hnic University of Valencia, Spain

On 5/30/08, Jukka MJ Manner <jukka.ma= nner@tkk.fi> wrote:
Hi JP,

Don't get me wrong, I'm not complaining as you seem= to think.
Application driven approach is fine. I'm trying to under= stand how four
sets of requirements (in the broad sense incl. security)= , partly
mutually excluding, are used in the future. Is the WG in fact going
to= wards 4 distinct parallel tracks in the survey, and specification of
th= e architecture? So it is a non-goal to have a unified vision of how
routing in sensor networks in the broad sense should perform.

Reg= ards,

Jukka

JP Vasseur wrote:
> Hi,
>
&g= t;
> On 5/30/08 7:26 AM, "Jukka MJ Manner" <jukka.manner@tkk.fi> wrote:
>
>> Hi JP,
>>
>> Some answers below.
= >>
>> Jukka
>>
>> JP Vasseur wrote: >>> Hi Jukka,
>>>
>>>
>>>= On 5/29/08 4:17 AM, "Jukka MJ Manner" <jukka.manner@tkk.fi> wrote:
>>>
>>>> [2nd try, 1st one bounced for some reaso= n]
>>> You need to subscribe to the list.
>> I quite= well know, thanks - I've been hanging around in the IETF for
>&= gt; quite some time. And I was subscribed on the list, too.
>>
>>>> Hi
>>>>
>>>>= I went through the various requirements documents and I'm a bit puzzle= d.
>>>> In general the drafts are easy to read and we have = many interesting
>>>> scenarios described that open up nicely the environment. = Yet, the drafts
>>>> list similar requirements, there is ve= ry little difference in what they
>>>> expect the routing s= ervice to do.
>>> Two comments here:
>>> (1) I think that there ar= e significant differences between the requirement
>>> set fort= h in the IDs, in term of functionality (e.g. constrained based
>>= > routing, scale, ....)
>> To me the documents looked, in terms of _requirements_ very, very=
>> similar. Sure, there are small differences, but most of the t= hings are
>> the same.
>
> Just to take one example= , the specification of a routing protocol for a few
> dozen of nodes (Home Automation) and several hundreds of thousands (u= rban
> networks) is not exactly the same and has strong implications= on the design.
>
>>> (2) There is no issue in having s= ome similar routing requirements spelled
>>> out in the IDs. This is a good news.
>> The point i= s: what is the value of saying similar things many times?
>
>= Please look at the history of the WG. We decided to be application driven.=
> Thus the task consists of analyzing the routing requirements of (in o= ur
> case) 4 applications. If it turns out that several applications= have similar
> requirements, this is a perfectly good outcome, that= will simply the task of
> the WG to select or specify a new WG.
>
>>>> I= f we are to work on a solution later on, it is somewhat challenging to
= >>>> find out the what our goals truly are.
>>> So= unds fairly obvious to me. How can you select/define a solution w/o
>>> knowing what the requirements are ?
>> The point wa= s that the current drafts talk about usecases and list
>> require= ments in a mixed way, and repeat the same things. For the work to
>&= gt; proceed, we eventually need to gather a single set of requirements, in<= br> >> particular to make the work more focused. The WG charter lists th= ree
>> usecase/reqs drafts,
>
> 4
>
>= so does that mean we need to interpret all three
>> concurrently= while drafting solutions? Reading a single list of
>> requirements would be easier, IMHO.
>
> The super-s= et of requirements will be taken into account in the protocol
> surv= ey and then protocol selection/design.
>
>> E.g., one draf= t says we need to support couple hundred nodes, another
>> one says we need to support couple thousand, one drafts says we c= ould
>> support multicast, another says that multicast is a must.=
>
> Ah so you saw some differences ....
>
> > Then there are
>> those performance requirements (see below= ).
>>
>>>> IMHO, the requirements documents shoul= d focus on the scenarios and use
>>>> cases of sensor netwo= rks, and list in general what the routing subsystem
>>>> aught to do. These drafts should not use RFC 2119 languag= e.
>>>>
>>> No. "Requirements" and &= quot;Use cases" (what we usually call "Applicability
>>= > statement" at the IETF) have very different purposes and what we = need to do
>>> according to our charter is first to spell out the requiremen= t documents.
>> The point is that if you look at the WGs in the I= ETF (NSIS, DCCP, PCN,
>> 6lowpan, DNA, Netlmm, PANA, to name a fe= w), they typically have one
>> requirements/goals document describing in a single place what the= work
>> is tackling. Roll has 3 documents, it doesn't make i= t any simpler for an
>> outsider, or probably even the WG, to fig= ure out the requirements of the
>> work.
>
> This is the approach that we took. Note t= hat other WGs took the same
> approach (e.g. PCE, ...) and have been= very successful.
>
>>> Note that RFC 2119 is very much= appropriate in requirement documents.
>> RFC2119 only talks about language issues, it doesn't tell how= one should
>> present requirements.
>
> Please loo= k around and you will see many requirements documents with RFC
> 211= 9 language.
>
>>>> We need a separate document that lists the concr= ete goals of such a
>>>> routing subsystem/protocol/archite= cture/service/whateveryouwanttocallit.
>>> Not sure what you m= ean here.
>> Use the current drafts as the use cases for Roll (without RFC2119=
>> language). Then take out the requirements, use RFC2119 langua= ge and
>> formulate a single document that can then be used to st= eer the design of
>> a solution.
>
> No, the requirements will make use = of the RFC 2119 language.
>
>>>> Here there is also = a clear need to separate functional and performance
>>>> re= quirements. Typically performance values and goals are mutually
>>>> exclusive, e.g., we can't have low power and high per= formance at the
>>>> same time (with some definition of wha= t is low and what is high).
>>> One of the key reasons why the= Internet has been so successful is that we
>>> avoid to specify performances, so I disagree with your vision= here.
>> I kinda know that... Again, the point is that the draft= s already do
>> that, i.e., they specify absolute performance val= ues to be achieved. I
>> don't want to have strict performance values, but the WG docu= ments
>> already do that. Should these then be taken out from the= existing drafts?
>
> They are indicative.
>
>&= gt;> Of course, we will use performance related metric during our protoc= ol survey
>>> evaluation.
>> If the various WG requirement docume= nts list performance values, then
>> the WG must achieve those. (= I would expect an eventual AD and/or IESG
>> review to ask you to= remove those performance requirements, though.)
>>
>>>> This latter document is used in both analysi= ng the existing schemes and
>>>> drafting a potential solut= ion.
>>> See
>>> http://www.ietf.or= g/internet-drafts/draft-levis-roll-protocols-survey-00.txt
>> Yes, I know the draft.
>>
>>> I would expe= ct that we end up with one
>>>> general solution, where the= parameters can be tuned to certain direction
>>>> to make = it fit different use cases.
>>> Absolutely.
>>>
>>>> Actually, w= e also need to document the threats we see in the
>>>> envi= ronment, and focus on the routing subsystem. The current drafts have
>>>> some thoughts about that, but its only a beginning.
&= gt;>> Please elaborate.
>> Well, the industrial use cases d= raft already talks about trust issues
>> and compartmentalizing t= hings. The urban reqs also hints at some threats
>> that would be present in that environment. The home reqs doesn= 9;t list
>> any, yet. Several WGs have a separate document that h= ighlights the
>> threats, c.f. RFC4081 or RFC4832.
>> >> Maybe I'm just the only one having difficulty in seeing where= the work
>> of the WG as a whole is going and what the goals are= . In that case you
>> can just neglect my questions and suggestio= ns.
>
> All comments are most welcome. But indeed, I haven't rec= eived any other
> similar complaints. This is indeed quite the oppos= ite with many comments
> from regular contributors finding that the = WG formed a few months ago was
> moving fairly quickly. There is still quite some work on the requirem= ents
> IDs but we're getting close to our Milestone.
>

--

Jukka MJ Manner, Professor, PhD.  Phone:&n= bsp; +358+(0)9+451 2481
Helsinki University of Technology Fax:    +358+(0)9+45= 1 2474
Department of Communications      = Office: E309 (Otakaari 5)
and Networking     &= nbsp;           &nbs= p;  E-mail: jukka.manner@t= kk.fi
P.O. Box 3000, FIN-02015 TKK      WWW: =    www.netlab.tkk.fi
Finland          &n= bsp;            = ;    Private:+358+(0)50+320 3018

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

------=_Part_11396_8219963.1212174442972-- --===============0113817524== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0113817524==-- From roll-bounces@ietf.org Sat May 31 05:30:58 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A40E3A6A7F; Sat, 31 May 2008 05:30:58 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 650643A68B7 for ; Sat, 31 May 2008 05:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gKMtJraE00z for ; Sat, 31 May 2008 05:30:55 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E966D3A699C for ; Sat, 31 May 2008 05:29:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,570,1204520400"; d="scan'208";a="9736764" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 May 2008 08:29:45 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4VCTjQT005487; Sat, 31 May 2008 08:29:45 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4VCTjnD004253; Sat, 31 May 2008 12:29:45 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 May 2008 08:29:45 -0400 Received: from 10.21.115.225 ([10.21.115.225]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 31 May 2008 12:29:45 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sat, 31 May 2008 14:24:30 +0200 From: JP Vasseur To: Jukka MJ Manner Message-ID: Thread-Topic: [Roll] Some thoughts on the requirements documents [2nd try] Thread-Index: AcjDGUY8WeRrTOQEOUC9npRSVcIgew== In-Reply-To: <483FB7C2.1020405@tkk.fi> Mime-version: 1.0 X-OriginalArrivalTime: 31 May 2008 12:29:45.0516 (UTC) FILETIME=[024BFEC0:01C8C31A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8815; t=1212236985; x=1213100985; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Some=20thoughts=20on=20the=20r equirements=20documents=20[2nd=20try] |Sender:=20 |To:=20Jukka=20MJ=20Manner=20; bh=9kklpi+rtdv0IX6/VqMPAA6CZfXYt2esDS0wcb31MKQ=; b=Fo15vtovwrvMliNjZjVsuVrXhLrssHWSF4WcNRkTlI/ot2HTt4VjSFYjfq 6M9jitUSY1Irg1K+Z/dV8cr4CyWvPAC7n6c5mxvOokQrxpNVDsmEFiFuXoHk SHgdE1DsJ4; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] Some thoughts on the requirements documents [2nd try] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, On 5/30/08 10:16 AM, "Jukka MJ Manner" wrote: > Hi JP, > > Don't get me wrong, I'm not complaining as you seem to think. > Application driven approach is fine. I'm trying to understand how four > sets of requirements (in the broad sense incl. security), partly > mutually excluding, are used in the future. Is the WG in fact going > towards 4 distinct parallel tracks in the survey, and specification of > the architecture? No, the survey will look take into account all the requirements spelled out in the 4 requirement documents. And of course, the architecture ID and potential protocol work will not have parallel tracks. So it is a non-goal to have a unified vision of how > routing in sensor networks in the broad sense should perform. This only place whether we'll have parallel "tracks" is for the routing requirements, which makes sense by essence. Thanks. JP. > > Regards, > Jukka > > JP Vasseur wrote: >> Hi, >> >> >> On 5/30/08 7:26 AM, "Jukka MJ Manner" wrote: >> >>> Hi JP, >>> >>> Some answers below. >>> >>> Jukka >>> >>> JP Vasseur wrote: >>>> Hi Jukka, >>>> >>>> >>>> On 5/29/08 4:17 AM, "Jukka MJ Manner" wrote: >>>> >>>>> [2nd try, 1st one bounced for some reason] >>>> You need to subscribe to the list. >>> I quite well know, thanks - I've been hanging around in the IETF for >>> quite some time. And I was subscribed on the list, too. >>> >>>>> Hi >>>>> >>>>> I went through the various requirements documents and I'm a bit puzzled. >>>>> In general the drafts are easy to read and we have many interesting >>>>> scenarios described that open up nicely the environment. Yet, the drafts >>>>> list similar requirements, there is very little difference in what they >>>>> expect the routing service to do. >>>> Two comments here: >>>> (1) I think that there are significant differences between the requirement >>>> set forth in the IDs, in term of functionality (e.g. constrained based >>>> routing, scale, ....) >>> To me the documents looked, in terms of _requirements_ very, very >>> similar. Sure, there are small differences, but most of the things are >>> the same. >> >> Just to take one example, the specification of a routing protocol for a few >> dozen of nodes (Home Automation) and several hundreds of thousands (urban >> networks) is not exactly the same and has strong implications on the design. >> >>>> (2) There is no issue in having some similar routing requirements spelled >>>> out in the IDs. This is a good news. >>> The point is: what is the value of saying similar things many times? >> >> Please look at the history of the WG. We decided to be application driven. >> Thus the task consists of analyzing the routing requirements of (in our >> case) 4 applications. If it turns out that several applications have similar >> requirements, this is a perfectly good outcome, that will simply the task of >> the WG to select or specify a new WG. >> >>>>> If we are to work on a solution later on, it is somewhat challenging to >>>>> find out the what our goals truly are. >>>> Sounds fairly obvious to me. How can you select/define a solution w/o >>>> knowing what the requirements are ? >>> The point was that the current drafts talk about usecases and list >>> requirements in a mixed way, and repeat the same things. For the work to >>> proceed, we eventually need to gather a single set of requirements, in >>> particular to make the work more focused. The WG charter lists three >>> usecase/reqs drafts, >> >> 4 >> >> so does that mean we need to interpret all three >>> concurrently while drafting solutions? Reading a single list of >>> requirements would be easier, IMHO. >> >> The super-set of requirements will be taken into account in the protocol >> survey and then protocol selection/design. >> >>> E.g., one draft says we need to support couple hundred nodes, another >>> one says we need to support couple thousand, one drafts says we could >>> support multicast, another says that multicast is a must. >> >> Ah so you saw some differences .... >> >> >> Then there are >>> those performance requirements (see below). >>> >>>>> IMHO, the requirements documents should focus on the scenarios and use >>>>> cases of sensor networks, and list in general what the routing subsystem >>>>> aught to do. These drafts should not use RFC 2119 language. >>>>> >>>> No. "Requirements" and "Use cases" (what we usually call "Applicability >>>> statement" at the IETF) have very different purposes and what we need to do >>>> according to our charter is first to spell out the requirement documents. >>> The point is that if you look at the WGs in the IETF (NSIS, DCCP, PCN, >>> 6lowpan, DNA, Netlmm, PANA, to name a few), they typically have one >>> requirements/goals document describing in a single place what the work >>> is tackling. Roll has 3 documents, it doesn't make it any simpler for an >>> outsider, or probably even the WG, to figure out the requirements of the >>> work. >> >> This is the approach that we took. Note that other WGs took the same >> approach (e.g. PCE, ...) and have been very successful. >> >>>> Note that RFC 2119 is very much appropriate in requirement documents. >>> RFC2119 only talks about language issues, it doesn't tell how one should >>> present requirements. >> >> Please look around and you will see many requirements documents with RFC >> 2119 language. >> >>>>> We need a separate document that lists the concrete goals of such a >>>>> routing subsystem/protocol/architecture/service/whateveryouwanttocallit. >>>> Not sure what you mean here. >>> Use the current drafts as the use cases for Roll (without RFC2119 >>> language). Then take out the requirements, use RFC2119 language and >>> formulate a single document that can then be used to steer the design of >>> a solution. >> >> No, the requirements will make use of the RFC 2119 language. >> >>>>> Here there is also a clear need to separate functional and performance >>>>> requirements. Typically performance values and goals are mutually >>>>> exclusive, e.g., we can't have low power and high performance at the >>>>> same time (with some definition of what is low and what is high). >>>> One of the key reasons why the Internet has been so successful is that we >>>> avoid to specify performances, so I disagree with your vision here. >>> I kinda know that... Again, the point is that the drafts already do >>> that, i.e., they specify absolute performance values to be achieved. I >>> don't want to have strict performance values, but the WG documents >>> already do that. Should these then be taken out from the existing drafts? >> >> They are indicative. >> >>>> Of course, we will use performance related metric during our protocol >>>> survey >>>> evaluation. >>> If the various WG requirement documents list performance values, then >>> the WG must achieve those. (I would expect an eventual AD and/or IESG >>> review to ask you to remove those performance requirements, though.) >>> >>>>> This latter document is used in both analysing the existing schemes and >>>>> drafting a potential solution. >>>> See >>>> http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.tx>>>> t >>> Yes, I know the draft. >>> >>>> I would expect that we end up with one >>>>> general solution, where the parameters can be tuned to certain direction >>>>> to make it fit different use cases. >>>> Absolutely. >>>> >>>>> Actually, we also need to document the threats we see in the >>>>> environment, and focus on the routing subsystem. The current drafts have >>>>> some thoughts about that, but its only a beginning. >>>> Please elaborate. >>> Well, the industrial use cases draft already talks about trust issues >>> and compartmentalizing things. The urban reqs also hints at some threats >>> that would be present in that environment. The home reqs doesn't list >>> any, yet. Several WGs have a separate document that highlights the >>> threats, c.f. RFC4081 or RFC4832. >>> >>> Maybe I'm just the only one having difficulty in seeing where the work >>> of the WG as a whole is going and what the goals are. In that case you >>> can just neglect my questions and suggestions. >> >> All comments are most welcome. But indeed, I haven't received any other >> similar complaints. This is indeed quite the opposite with many comments >> from regular contributors finding that the WG formed a few months ago was >> moving fairly quickly. There is still quite some work on the requirements >> IDs but we're getting close to our Milestone. >> _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sat May 31 05:50:59 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 057F13A6889; Sat, 31 May 2008 05:50:59 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515123A6805; Sat, 31 May 2008 05:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TADg+fyaFZPn; Sat, 31 May 2008 05:50:54 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2AE7A3A6932; Sat, 31 May 2008 05:50:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,570,1204520400"; d="scan'208,217";a="9737304" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 May 2008 08:50:53 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4VCorMp012945; Sat, 31 May 2008 08:50:53 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4VCorQF002055; Sat, 31 May 2008 12:50:53 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 May 2008 08:50:53 -0400 Received: from 10.21.115.225 ([10.21.115.225]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 31 May 2008 12:50:53 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sat, 31 May 2008 14:50:51 +0200 From: JP Vasseur To: Miguel Sanchez Message-ID: Thread-Topic: [Roll] [6lowpan] New charter for 6lowpan Thread-Index: AcjDHPSVkcfQpsAQHkujyE93ZsuSyA== In-Reply-To: <86c3ed7b0805301118j18ddc19dy9a111d9073f4ca3b@mail.gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 31 May 2008 12:50:53.0506 (UTC) FILETIME=[F613EA20:01C8C31C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6420; t=1212238253; x=1213102253; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20[6lowpan]=20New=20charter=20fo r=206lowpan |Sender:=20 |To:=20Miguel=20Sanchez=20; bh=QHUaNAnLnMdQ8GRr7w1yZjRbO6z7+98KY7Rx3SIkgUg=; b=jKsCxD8y7hI7S5M8m2jwbKb1/9L/duwl/xHeZecE724Sw+5r64Mp+TL1bh wqjSn0z0LjK4ve4IabLlnBEQQLJ/QgUd8jvC242xWGPCu5pLfIfG1FohjSgA uuk8lj6VFl; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New charter for 6lowpan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0535736418==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0535736418== Content-type: multipart/alternative; boundary="B_3295090251_6258788" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3295090251_6258788 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Miguel, On 5/30/08 8:18 PM, "Miguel Sanchez" wrote: > Hi JP, >=20 >=20 > On 5/29/08, JP Vasseur wrote: >> Hi Phil and Carles, >> =20 >>=20 >> =20 >> On 5/28/08 1:38 AM, "Philip Levis" wrote: >> =20 >>> > On May 27, 2008, at 2:29 AM, Carles Gomez Montenegro wrote: >>>> >> >>>> >> At least, there are the following items listed in the routing >>>> >> requirements >>>> >> draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.= txt) >>>> >> that route-over approach cannot provide or would provide only in a >>>> >> limited >>>> >> way: >>> > >>> > I disagree wholeheartedly. >> =20 >> =20 >> So do I. >> =20 >>=20 >> I think there is a big confusion here >>> > between a protocol specification and a protocol implementation. >>> > >>> > These are all arguments for cross-layer design, that tightly >>> > integrating routing and the link layer will lead to a better solutio= n. >>> > Practice has shown us otherwise; >> =20 >> =20 >> Indeed, "practice" being "The Internet". >> =20 >>=20 >=20 > There are a couple of topics that seem to be cross-layer by nature. One o= f > them seems to be power awareness. The other seems to be routing involving > wireless links.=20 >=20 > JP> I=B9m not against cross-layer if we know what we=B9re doing. You=B9re quite > right that some issues benefit from cross-layer (e.g. Deep packet inspect= ion, > even sometime dataware routing, ...). >=20 > That is why I am not so sure that "practice" (done mostly with wired link= s and > without power constraints) is very relevant here. That is why IETF MANET = group > was created; not because current routing on the Internet was wrong but be= cause > a new type of problem was being addressed (mobile ad-hoc networking). >=20 > JP> And this is also why ROLL was created, because we had to work on a > different set of issues, constraints, ... See the BOF slides. >=20 > I do not see how MAC feedback can be bad, as not being a mandatory featur= e > network layer can always just ignore it. However I can see how such a fee= dback > can avoid repeating operations already performed at the link layer (i.e. = link > quality estimation). >=20 > JP> Surely but the original email was going much further in term of layer > violation ... >=20 > Thanks. >=20 > JP. >=20 > Just my two cents, >=20 > Miguel S=E1nchez >=20 >=20 --B_3295090251_6258788 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Roll] [6lowpan] New charter for 6lowpan Hi Miguel,


On 5/30/08 8:18 PM, "Miguel Sanchez" <misan@disca.upv.es> wrote:

<= SPAN STYLE=3D'font-size:13pt'>Hi JP,


On 5/29/08, JP Vasseur <jvasseur@cis= co.com> wrote:
<= SPAN STYLE=3D'font-size:13pt'>Hi Phil and Carles,
 

 
 On 5/28/08 1:38 AM, "Philip Levis" <pal@cs.stanford.edu> wrote:
 
 > On May 27, 2008, at 2:29 AM, Carles Gomez Montenegro wrote:
 >>
 >> At least, there are the following items listed in the routin= g
 >> requirements
 >> draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-= 05.txt)
 >> that route-over approach cannot provide or would provide onl= y in a
 >> limited
 >> way:
 >
 > I disagree wholeheartedly.
 
 
So do I.
 

 I think there is a big confusion here
 > between a protocol specification and a protocol implementation.<= BR>  >
 > These are all arguments for cross-layer design, that tightly
 > integrating routing and the link layer will lead to a better sol= ution.
 > Practice has shown us otherwise;
 
 
Indeed, "practice" being "The Internet".
 

=
There are a couple of topics that seem to be cross-layer by nature. One of = them seems to be power awareness. The other seems to be routing involving wi= reless links.

JP> I’m not against cross-layer if we know what we’= ;re doing. You’re quite right that some issues benefit from cross-= layer (e.g. Deep packet inspection, even sometime dataware routing, ...).
That is why I am not so sure that "practice" (done mostly with wi= red links and without power constraints) is very relevant here. That is why = IETF MANET group was created; not because current routing on the Internet wa= s wrong but because a new type of problem was being addressed (mobile ad-hoc= networking).

JP> And this is also why ROLL was created, because we had to work on a d= ifferent set of issues, constraints, ... See the BOF slides.

I do not see how MAC feedback can be bad, as not being a mandatory feature = network layer can always just ignore it. However I can see how such a feedba= ck can avoid repeating operations already performed at the link layer (i.e. = link quality estimation).

JP> Surely but the original email was going much further in term of laye= r violation ...

Thanks.

JP.

Just my two cents,

Miguel Sánchez


--B_3295090251_6258788-- --===============0535736418== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0535736418==-- From roll-bounces@ietf.org Sat May 31 05:56:35 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08FB23A697F; Sat, 31 May 2008 05:56:35 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75EE23A697F for ; Sat, 31 May 2008 05:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I+gfKCYP5rT for ; Sat, 31 May 2008 05:56:30 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4D83E3A6805 for ; Sat, 31 May 2008 05:56:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,570,1204520400"; d="scan'208,217";a="9746395" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 May 2008 08:56:29 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4VCuTw1013931; Sat, 31 May 2008 08:56:29 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4VCuT4Q003388; Sat, 31 May 2008 12:56:29 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 May 2008 08:56:29 -0400 Received: from 10.21.115.225 ([10.21.115.225]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 31 May 2008 12:56:29 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sat, 31 May 2008 14:56:26 +0200 From: JP Vasseur To: Miguel Sanchez , Jukka MJ Manner Message-ID: Thread-Topic: [Roll] Some thoughts on the requirements documents [2nd try] Thread-Index: AcjDHbxC90rcRH5zQk69StWJgBadnw== In-Reply-To: <86c3ed7b0805301207g66557b36u14af1ed8d8d9ce8c@mail.gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 31 May 2008 12:56:29.0788 (UTC) FILETIME=[BE8479C0:01C8C31D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=26674; t=1212238589; x=1213102589; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Some=20thoughts=20on=20the=20r equirements=20documents=20[2nd=20try] |Sender:=20 |To:=20Miguel=20Sanchez=20,=20Jukka=20M J=20Manner=20; bh=pYBigvR39FBfUAGR+pHQJM9Ok2H9mrqEOMzZveb25Yc=; b=OqweIZxwW+eMJbi3xyFuj8ifCGSQ4G9Hmgq8qix10UlbD0cxOf1d9U2FXw gZdecLRbrmmuSeDGzrqZZYzXUf1PP1UT8r4C+qiGYbK9xQWCKhfrd2zRdCiO xdZpCWD7SJ; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: ROLL WG Subject: Re: [Roll] Some thoughts on the requirements documents [2nd try] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1213792554==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1213792554== Content-type: multipart/alternative; boundary="B_3295090586_6289087" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3295090586_6289087 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, On 5/30/08 9:07 PM, "Miguel Sanchez" wrote: > Hi Jukka, >=20 > I can see how different set of requirements may make a single workable > solution impossible. Having four application scenarios does not mean that= 4 > different protocols will be needed but we may end up with more than one > though. >=20 > JP> Absolutely as long as we carefully document the applicability but thi= s is > premature to discuss this until we have converged on the protocol survey.= Note > that we, as a WG, may also agree to not meet all requirements if some of = them > require to add unreasonable weight/overhead to the protocol. >=20 > If we look at the Internet routing we can see that several protocols are = being > used. >=20 > JP> But this is slightly different though. You do not use more than one I= GP at > the same time in the same region (unless in very specific conditions such= as > network migration). Further, you always try to avoid using routing at mul= tiple > layers with cross layer violation, which we must avoid. >=20 > Thanks. >=20 > JP. >=20 > Kind regards, >=20 > Miguel S=E1nchez, PhD Associate Professor +349638779709 > Computer Egineering Department (DISCA) > Polytechnic University of Valencia, Spain >=20 > On 5/30/08, Jukka MJ Manner wrote: >> Hi JP, >> =20 >> Don't get me wrong, I'm not complaining as you seem to think. >> Application driven approach is fine. I'm trying to understand how four >> sets of requirements (in the broad sense incl. security), partly >> mutually excluding, are used in the future. Is the WG in fact going >> towards 4 distinct parallel tracks in the survey, and specification of >> the architecture? So it is a non-goal to have a unified vision of how >> routing in sensor networks in the broad sense should perform. >> =20 >> Regards, >> =20 >> Jukka >> =20 >> JP Vasseur wrote: >>> > Hi, >>> > >>> > >>> > On 5/30/08 7:26 AM, "Jukka MJ Manner" wrote: >>> > >>>> >> Hi JP, >>>> >> >>>> >> Some answers below. >>>> >> >>>> >> Jukka >>>> >> >>>> >> JP Vasseur wrote: >>>>> >>> Hi Jukka, >>>>> >>> >>>>> >>> >>>>> >>> On 5/29/08 4:17 AM, "Jukka MJ Manner" wrot= e: >>>>> >>> >>>>>> >>>> [2nd try, 1st one bounced for some reason] >>>>> >>> You need to subscribe to the list. >>>> >> I quite well know, thanks - I've been hanging around in the IETF f= or >>>> >> quite some time. And I was subscribed on the list, too. >>>> >> >>>>>> >>>> Hi >>>>>> >>>> >>>>>> >>>> I went through the various requirements documents and I'm a bi= t >>>>>> puzzled. >>>>>> >>>> In general the drafts are easy to read and we have many intere= sting >>>>>> >>>> scenarios described that open up nicely the environment. Yet, = the >>>>>> drafts >>>>>> >>>> list similar requirements, there is very little difference in = what they >>>>>> >>>> expect the routing service to do. >>>>> >>> Two comments here: >>>>> >>> (1) I think that there are significant differences between the >>>>> requirement >>>>> >>> set forth in the IDs, in term of functionality (e.g. constrained >>>>> based >>>>> >>> routing, scale, ....) >>>> >> To me the documents looked, in terms of _requirements_ very, very >>>> >> similar. Sure, there are small differences, but most of the things= are >>>> >> the same. >>> > >>> > Just to take one example, the specification of a routing protocol fo= r a >>> few >>> > dozen of nodes (Home Automation) and several hundreds of thousands (= urban >>> > networks) is not exactly the same and has strong implications on the >>> design. >>> > >>>>> >>> (2) There is no issue in having some similar routing requirement= s >>>>> spelled >>>>> >>> out in the IDs. This is a good news. >>>> >> The point is: what is the value of saying similar things many time= s? >>> > >>> > Please look at the history of the WG. We decided to be application >>> driven. >>> > Thus the task consists of analyzing the routing requirements of (in = our >>> > case) 4 applications. If it turns out that several applications have >>> similar >>> > requirements, this is a perfectly good outcome, that will simply the= task of >>> > the WG to select or specify a new WG. >>> > >>>>>> >>>> If we are to work on a solution later on, it is somewhat >>>>>> challenging to >>>>>> >>>> find out the what our goals truly are. >>>>> >>> Sounds fairly obvious to me. How can you select/define a solutio= n w/o >>>>> >>> knowing what the requirements are ? >>>> >> The point was that the current drafts talk about usecases and list >>>> >> requirements in a mixed way, and repeat the same things. For the w= ork to >>>> >> proceed, we eventually need to gather a single set of requirements= , in >>>> >> particular to make the work more focused. The WG charter lists thr= ee >>>> >> usecase/reqs drafts, >>> > >>> > 4 >>> > >>> > so does that mean we need to interpret all three >>>> >> concurrently while drafting solutions? Reading a single list of >>>> >> requirements would be easier, IMHO. >>> > >>> > The super-set of requirements will be taken into account in the prot= ocol >>> > survey and then protocol selection/design. >>> > >>>> >> E.g., one draft says we need to support couple hundred nodes, anot= her >>>> >> one says we need to support couple thousand, one drafts says we co= uld >>>> >> support multicast, another says that multicast is a must. >>> > >>> > Ah so you saw some differences .... >>> > >>> > >>> > Then there are >>>> >> those performance requirements (see below). >>>> >> >>>>>> >>>> IMHO, the requirements documents should focus on the scenarios= and use >>>>>> >>>> cases of sensor networks, and list in general what the routing >>>>>> subsystem >>>>>> >>>> aught to do. These drafts should not use RFC 2119 language. >>>>>> >>>> >>>>> >>> No. "Requirements" and "Use cases" (what we usually call >>>>> "Applicability >>>>> >>> statement" at the IETF) have very different purposes and what we= need >>>>> to do >>>>> >>> according to our charter is first to spell out the requirement >>>>> documents. >>>> >> The point is that if you look at the WGs in the IETF (NSIS, DCCP, = PCN, >>>> >> 6lowpan, DNA, Netlmm, PANA, to name a few), they typically have on= e >>>> >> requirements/goals document describing in a single place what the = work >>>> >> is tackling. Roll has 3 documents, it doesn't make it any simpler = for an >>>> >> outsider, or probably even the WG, to figure out the requirements = of the >>>> >> work. >>> > >>> > This is the approach that we took. Note that other WGs took the same >>> > approach (e.g. PCE, ...) and have been very successful. >>> > >>>>> >>> Note that RFC 2119 is very much appropriate in requirement docum= ents. >>>> >> RFC2119 only talks about language issues, it doesn't tell how one >>>> should >>>> >> present requirements. >>> > >>> > Please look around and you will see many requirements documents with= RFC >>> > 2119 language. >>> > >>>>>> >>>> We need a separate document that lists the concrete goals of s= uch a >>>>>> >>>> routing >>>>>> subsystem/protocol/architecture/service/whateveryouwanttocallit. >>>>> >>> Not sure what you mean here. >>>> >> Use the current drafts as the use cases for Roll (without RFC2119 >>>> >> language). Then take out the requirements, use RFC2119 language an= d >>>> >> formulate a single document that can then be used to steer the des= ign of >>>> >> a solution. >>> > >>> > No, the requirements will make use of the RFC 2119 language. >>> > >>>>>> >>>> Here there is also a clear need to separate functional and >>>>>> performance >>>>>> >>>> requirements. Typically performance values and goals are mutua= lly >>>>>> >>>> exclusive, e.g., we can't have low power and high performance = at the >>>>>> >>>> same time (with some definition of what is low and what is hig= h). >>>>> >>> One of the key reasons why the Internet has been so successful i= s >>>>> that we >>>>> >>> avoid to specify performances, so I disagree with your vision he= re. >>>> >> I kinda know that... Again, the point is that the drafts already d= o >>>> >> that, i.e., they specify absolute performance values to be achieve= d. I >>>> >> don't want to have strict performance values, but the WG documents >>>> >> already do that. Should these then be taken out from the existing >>>> drafts? >>> > >>> > They are indicative. >>> > >>>>> >>> Of course, we will use performance related metric during our pro= tocol >>>>> survey >>>>> >>> evaluation. >>>> >> If the various WG requirement documents list performance values, t= hen >>>> >> the WG must achieve those. (I would expect an eventual AD and/or I= ESG >>>> >> review to ask you to remove those performance requirements, though= .) >>>> >> >>>>>> >>>> This latter document is used in both analysing the existing sc= hemes and >>>>>> >>>> drafting a potential solution. >>>>> >>> See >>>>> >>>=20 >>>>>=20 http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.tx= t >>>> >> Yes, I know the draft. >>>> >> >>>>> >>> I would expect that we end up with one >>>>>> >>>> general solution, where the parameters can be tuned to certain >>>>>> direction >>>>>> >>>> to make it fit different use cases. >>>>> >>> Absolutely. >>>>> >>> >>>>>> >>>> Actually, we also need to document the threats we see in the >>>>>> >>>> environment, and focus on the routing subsystem. The current d= rafts have >>>>>> >>>> some thoughts about that, but its only a beginning. >>>>> >>> Please elaborate. >>>> >> Well, the industrial use cases draft already talks about trust iss= ues >>>> >> and compartmentalizing things. The urban reqs also hints at some >>>> threats >>>> >> that would be present in that environment. The home reqs doesn't l= ist >>>> >> any, yet. Several WGs have a separate document that highlights the >>>> >> threats, c.f. RFC4081 or RFC4832. >>>> >> >>>> >> Maybe I'm just the only one having difficulty in seeing where the = work >>>> >> of the WG as a whole is going and what the goals are. In that case= you >>>> >> can just neglect my questions and suggestions. >>> > >>> > All comments are most welcome. But indeed, I haven't received any ot= her >>> > similar complaints. This is indeed quite the opposite with many comm= ents >>> > from regular contributors finding that the WG formed a few months ag= o was >>> > moving fairly quickly. There is still quite some work on the require= ments >>> > IDs but we're getting close to our Milestone. >>> > >> =20 >> =20 >> -- >> =20 >> Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+451 2481 >> Helsinki University of Technology Fax: +358+(0)9+451 2474 >> Department of Communications Office: E309 (Otakaari 5) >> and Networking E-mail: jukka.manner@tkk.fi >> P.O. Box 3000, FIN-02015 TKK WWW: www.netlab.tkk.fi >> >> Finland Private:+358+(0)50+320 3018 >> =20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> =20 >=20 >=20 --B_3295090586_6289087 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Roll] Some thoughts on the requirements documents [2nd try]</TI= TLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:13pt= '>Hi,<BR> <BR> <BR> On 5/30/08 9:07 PM, "Miguel Sanchez" <<a href=3D"misan@disca.upv= .es">misan@disca.upv.es</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:13pt'>Hi Jukka,<BR> <BR> I can see how different set of requirements may make a single workable solu= tion impossible. Having four application scenarios does not mean that 4 diff= erent protocols will be needed but we may end up with more than one though.<= BR> <BR> JP> Absolutely as long as we carefully document the applicability but th= is is premature to discuss this until we have converged on the protocol surv= ey. Note that we, as a WG, may also agree to not meet all requirements if so= me of them require to add unreasonable weight/overhead to the protocol.<BR> <BR> If we look at the Internet routing we can see that several protocols are be= ing used.<BR> <BR> JP> But this is slightly different though. You do not use more than one = IGP at the same time in the same region (unless in very specific conditions = such as network migration). Further, you always try to avoid using routing a= t multiple layers with cross layer violation, which we must avoid.<BR> <BR> Thanks.<BR> <BR> JP.<BR> <BR> Kind regards,<BR> <BR> Miguel Sánchez, PhD Associate Professor +349638779709<BR> Computer Egineering Department (DISCA)<BR> Polytechnic University of Valencia, Spain<BR> <BR> On 5/30/08, <B>Jukka MJ Manner</B> <<a href=3D"jukka.manner@tkk.fi">jukka.= manner@tkk.fi</a>> wrote:<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:13pt'>Hi JP,<BR>  <BR>  Don't get me wrong, I'm not complaining as you seem to think.<BR>  Application driven approach is fine. I'm trying to understand how fou= r<BR>  sets of requirements (in the broad sense incl. security), partly<BR>  mutually excluding, are used in the future. Is the WG in fact going<B= R>  towards 4 distinct parallel tracks in the survey, and specification o= f<BR>  the architecture? So it is a non-goal to have a unified vision of how= <BR>  routing in sensor networks in the broad sense should perform.<BR>  <BR>  Regards,<BR>  <BR> Jukka<BR>  <BR>  JP Vasseur wrote:<BR>  > Hi,<BR>  ><BR>  ><BR>  > On 5/30/08 7:26 AM, "Jukka MJ Manner" <<a href=3D"juk= ka.manner@tkk.fi">jukka.manner@tkk.fi</a>> wrote:<BR>  ><BR>  >> Hi JP,<BR>  >><BR>  >> Some answers below.<BR>  >><BR>  >> Jukka<BR>  >><BR>  >> JP Vasseur wrote:<BR>  >>> Hi Jukka,<BR>  >>><BR>  >>><BR>  >>> On 5/29/08 4:17 AM, "Jukka MJ Manner" <<a h= ref=3D"jukka.manner@tkk.fi">jukka.manner@tkk.fi</a>> wrote:<BR>  >>><BR>  >>>> [2nd try, 1st one bounced for some reason]<BR>  >>> You need to subscribe to the list.<BR>  >> I quite well know, thanks - I've been hanging around in the = IETF for<BR>  >> quite some time. And I was subscribed on the list, too.<BR>  >><BR>  >>>> Hi<BR>  >>>><BR>  >>>> I went through the various requirements documents an= d I'm a bit puzzled.<BR>  >>>> In general the drafts are easy to read and we have m= any interesting<BR>  >>>> scenarios described that open up nicely the environm= ent. Yet, the drafts<BR>  >>>> list similar requirements, there is very little diff= erence in what they<BR>  >>>> expect the routing service to do.<BR>  >>> Two comments here:<BR>  >>> (1) I think that there are significant differences betwe= en the requirement<BR>  >>> set forth in the IDs, in term of functionality (e.g. con= strained based<BR>  >>> routing, scale, ....)<BR>  >> To me the documents looked, in terms of _requirements_ very,= very<BR>  >> similar. Sure, there are small differences, but most of the = things are<BR>  >> the same.<BR>  ><BR>  > Just to take one example, the specification of a routing protoco= l for a few<BR>  > dozen of nodes (Home Automation) and several hundreds of thousan= ds (urban<BR>  > networks) is not exactly the same and has strong implications on= the design.<BR>  ><BR>  >>> (2) There is no issue in having some similar routing req= uirements spelled<BR>  >>> out in the IDs. This is a good news.<BR>  >> The point is: what is the value of saying similar things man= y times?<BR>  ><BR>  > Please look at the history of the WG. We decided to be applicati= on driven.<BR>  > Thus the task consists of analyzing the routing requirements of = (in our<BR>  > case) 4 applications. If it turns out that several applications = have similar<BR>  > requirements, this is a perfectly good outcome, that will simply= the task of<BR>  > the WG to select or specify a new WG.<BR>  ><BR>  >>>> If we are to work on a solution later on, it is some= what challenging to<BR>  >>>> find out the what our goals truly are.<BR>  >>> Sounds fairly obvious to me. How can you select/define a= solution w/o<BR>  >>> knowing what the requirements are ?<BR>  >> The point was that the current drafts talk about usecases an= d list<BR>  >> requirements in a mixed way, and repeat the same things. For= the work to<BR>  >> proceed, we eventually need to gather a single set of requir= ements, in<BR>  >> particular to make the work more focused. The WG charter lis= ts three<BR>  >> usecase/reqs drafts,<BR>  ><BR>  > 4<BR>  ><BR>  > so does that mean we need to interpret all three<BR>  >> concurrently while drafting solutions? Reading a single list= of<BR>  >> requirements would be easier, IMHO.<BR>  ><BR>  > The super-set of requirements will be taken into account in the = protocol<BR>  > survey and then protocol selection/design.<BR>  ><BR>  >> E.g., one draft says we need to support couple hundred nodes= , another<BR>  >> one says we need to support couple thousand, one drafts says= we could<BR>  >> support multicast, another says that multicast is a must.<BR= >  ><BR>  > Ah so you saw some differences ....<BR>  ><BR>  ><BR>  > Then there are<BR>  >> those performance requirements (see below).<BR>  >><BR>  >>>> IMHO, the requirements documents should focus on the= scenarios and use<BR>  >>>> cases of sensor networks, and list in general what t= he routing subsystem<BR>  >>>> aught to do. These drafts should not use RFC 2119 la= nguage.<BR>  >>>><BR>  >>> No. "Requirements" and "Use cases" (= what we usually call "Applicability<BR>  >>> statement" at the IETF) have very different purpose= s and what we need to do<BR>  >>> according to our charter is first to spell out the requi= rement documents.<BR>  >> The point is that if you look at the WGs in the IETF (NSIS, = DCCP, PCN,<BR>  >> 6lowpan, DNA, Netlmm, PANA, to name a few), they typically h= ave one<BR>  >> requirements/goals document describing in a single place wha= t the work<BR>  >> is tackling. Roll has 3 documents, it doesn't make it any si= mpler for an<BR>  >> outsider, or probably even the WG, to figure out the require= ments of the<BR>  >> work.<BR>  ><BR>  > This is the approach that we took. Note that other WGs took the = same<BR>  > approach (e.g. PCE, ...) and have been very successful.<BR>  ><BR>  >>> Note that RFC 2119 is very much appropriate in requireme= nt documents.<BR>  >> RFC2119 only talks about language issues, it doesn't tell ho= w one should<BR>  >> present requirements.<BR>  ><BR>  > Please look around and you will see many requirements documents = with RFC<BR>  > 2119 language.<BR>  ><BR>  >>>> We need a separate document that lists the concrete = goals of such a<BR>  >>>> routing subsystem/protocol/architecture/service/what= everyouwanttocallit.<BR>  >>> Not sure what you mean here.<BR>  >> Use the current drafts as the use cases for Roll (without RF= C2119<BR>  >> language). Then take out the requirements, use RFC2119 langu= age and<BR>  >> formulate a single document that can then be used to steer t= he design of<BR>  >> a solution.<BR>  ><BR>  > No, the requirements will make use of the RFC 2119 language.<BR>  ><BR>  >>>> Here there is also a clear need to separate function= al and performance<BR>  >>>> requirements. Typically performance values and goals= are mutually<BR>  >>>> exclusive, e.g., we can't have low power and high pe= rformance at the<BR>  >>>> same time (with some definition of what is low and w= hat is high).<BR>  >>> One of the key reasons why the Internet has been so succ= essful is that we<BR>  >>> avoid to specify performances, so I disagree with your v= ision here.<BR>  >> I kinda know that... Again, the point is that the drafts alr= eady do<BR>  >> that, i.e., they specify absolute performance values to be a= chieved. I<BR>  >> don't want to have strict performance values, but the WG doc= uments<BR>  >> already do that. Should these then be taken out from the exi= sting drafts?<BR>  ><BR>  > They are indicative.<BR>  ><BR>  >>> Of course, we will use performance related metric during= our protocol survey<BR>  >>> evaluation.<BR>  >> If the various WG requirement documents list performance val= ues, then<BR>  >> the WG must achieve those. (I would expect an eventual AD an= d/or IESG<BR>  >> review to ask you to remove those performance requirements, = though.)<BR>  >><BR>  >>>> This latter document is used in both analysing the e= xisting schemes and<BR>  >>>> drafting a potential solution.<BR>  >>> See<BR>  >>> <a href=3D"http://www.ietf.org/internet-drafts/draft-levis= -roll-protocols-survey-00.txt">http://www.ietf.org/internet-drafts/draft-lev= is-roll-protocols-survey-00.txt</a><BR>  >> Yes, I know the draft.<BR>  >><BR>  >>> I would expect that we end up with one<BR>  >>>> general solution, where the parameters can be tuned = to certain direction<BR>  >>>> to make it fit different use cases.<BR>  >>> Absolutely.<BR>  >>><BR>  >>>> Actually, we also need to document the threats we se= e in the<BR>  >>>> environment, and focus on the routing subsystem. The= current drafts have<BR>  >>>> some thoughts about that, but its only a beginning.<= BR>  >>> Please elaborate.<BR>  >> Well, the industrial use cases draft already talks about tru= st issues<BR>  >> and compartmentalizing things. The urban reqs also hints at = some threats<BR>  >> that would be present in that environment. The home reqs doe= sn't list<BR>  >> any, yet. Several WGs have a separate document that highligh= ts the<BR>  >> threats, c.f. RFC4081 or RFC4832.<BR>  >><BR>  >> Maybe I'm just the only one having difficulty in seeing wher= e the work<BR>  >> of the WG as a whole is going and what the goals are. In tha= t case you<BR>  >> can just neglect my questions and suggestions.<BR>  ><BR>  > All comments are most welcome. But indeed, I haven't received an= y other<BR>  > similar complaints. This is indeed quite the opposite with many = comments<BR>  > from regular contributors finding that the WG formed a few month= s ago was<BR>  > moving fairly quickly. There is still quite some work on the req= uirements<BR>  > IDs but we're getting close to our Milestone.<BR>  ><BR>  <BR>  <BR> --<BR>  <BR>  Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 248= 1<BR>  Helsinki University of Technology Fax:    +358+(0)9+45= 1 2474<BR>  Department of Communications      Office: E3= 09 (Otakaari 5)<BR>  and Networking          =           E-mail: <a href=3D= "jukka.manner@tkk.fi">jukka.manner@tkk.fi</a><BR>  P.O. Box 3000, FIN-02015 TKK      WWW:  = ;  www.netlab.tkk.fi <<a href=3D"http://www.netlab.tkk.fi">http:/= /www.netlab.tkk.fi</a>> <BR>  Finland           &= nbsp;            = ;   Private:+358+(0)50+320 3018<BR>  <BR> _______________________________________________<BR>  Roll mailing list<BR>  <a href=3D"Roll@ietf.org">Roll@ietf.org</a><BR>  <a href=3D"https://www.ietf.org/mailman/listinfo/roll">https://www.ietf= .org/mailman/listinfo/roll</a><BR>  <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN STYLE=3D'font-size:13pt'><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3295090586_6289087-- --===============1213792554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1213792554==--