From roll-bounces@ietf.org Sat Aug 9 13:50: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 2FCED3A68A4; Sat, 9 Aug 2008 13:50: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 4DDB23A68A4 for ; Sat, 9 Aug 2008 13:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.528 X-Spam-Level: X-Spam-Status: No, score=-5.528 tagged_above=-999 required=5 tests=[AWL=-0.326, 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 XKfi+ZqE2feY for ; Sat, 9 Aug 2008 13:50:27 -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 1D5E33A6835 for ; Sat, 9 Aug 2008 13:50:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,334,1215388800"; d="scan'208,217";a="17004089" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2008 20:50:25 +0000 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 m79KoPrw003663 for ; Sat, 9 Aug 2008 16:50:25 -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 m79KoPma001644 for ; Sat, 9 Aug 2008 20:50:25 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, 9 Aug 2008 16:50:25 -0400 Received: from 10.61.81.172 ([10.61.81.172]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 9 Aug 2008 20:50:25 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sat, 09 Aug 2008 22:50:24 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: Adoption of draft-levis-roll-protocols-survey as a ROLL WG document Thread-Index: Acj6YYuLuMHTFm5cuUyrafLczWZV4A== Mime-version: 1.0 X-OriginalArrivalTime: 09 Aug 2008 20:50:25.0523 (UTC) FILETIME=[8C73CC30:01C8FA61] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1722; t=1218315025; x=1219179025; 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:=20Adoption=20of=20draft-levis-roll-protocols-surv ey=20as=20a=20ROLL=20WG=20document |Sender:=20 |To:=20; bh=TibEj2e9suk08VNtIOtj7lPPw83uk+87/m3IZRNCZFs=; b=Nkh3eX4UIAXu0e+HHxEt6oNB0LOzRWi7AkEQx96g0u5ilddd1ArG6OwL9S T7NAJo8R7JU39FkWryMuHq242ZCx1p/mlJjCaKi92/gXyTOujLwlcto6IL8x 1MsZH159IJ; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Roll] Adoption of draft-levis-roll-protocols-survey 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="===============1900746766==" 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. --===============1900746766== Content-type: multipart/alternative; boundary="B_3301167024_11872651" > 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_3301167024_11872651 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, There was a good consensus to adopt draft-levis-roll-protocols-survey as a ROLL WG document during the ROLL WG meeting in Dublin but as usual we need to confirm on the mailing list. Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.tx t) as a ROLL WG document ? Note that the draft has been slightly updated to align it with the presentation that was made during the meeting. Thanks. JP. --B_3301167024_11872651 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Adoption of draft-levis-roll-protocols-survey as a ROLL WG document<= /TITLE> </HEAD> <BODY> <FONT FACE=3D"Arial"><SPAN STYLE=3D'font-size:14pt'>Dear WG,<BR> <BR> There was a good consensus to adopt draft-levis-roll-protocols-survey as a = ROLL WG document during the ROLL WG meeting in Dublin but as usual we need t= o confirm on the mailing list.<BR> <BR> Are you in favor/opposed adopting draft-levis-roll-protocols-survey (<a hre= f=3D"http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.= txt">http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-0= 2.txt</a>) as a ROLL WG document ?<BR> <BR> Note that the draft has been slightly updated to align it with the presenta= tion that was made during the meeting.<BR> <BR> Thanks.<BR> <BR> JP.</SPAN></FONT> </BODY> </HTML> --B_3301167024_11872651-- --===============1900746766== 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 --===============1900746766==-- From roll-bounces@ietf.org Sun Aug 10 12:32:21 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 E1C063A6C10; Sun, 10 Aug 2008 12:32:21 -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 4DD5B3A6B10 for <roll@core3.amsl.com>; Sun, 10 Aug 2008 12:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_LOW=-1] 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 D4wktiAiHdzz for <roll@core3.amsl.com>; Sun, 10 Aug 2008 12:32:19 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4DE7B3A6B16 for <roll@ietf.org>; Sun, 10 Aug 2008 12:32:18 -0700 (PDT) Received: from koa-lohtaja.bogus (line-6770.dyn.kponet.fi [85.29.72.203]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m7AJVOA2017302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Aug 2008 22:31:25 +0300 Message-ID: <489D8E22.9050108@sensinode.com> Date: Sat, 09 Aug 2008 15:31:30 +0300 From: Zach Shelby <zach@sensinode.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: JP Vasseur <jvasseur@cisco.com> References: <C4C3CFB0.4DAEB%jvasseur@cisco.com> In-Reply-To: <C4C3CFB0.4DAEB%jvasseur@cisco.com> Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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 <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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org In favor! JP Vasseur wrote: > Dear WG, > > There was a good consensus to adopt draft-levis-roll-protocols-survey as > a ROLL WG document during the ROLL WG meeting in Dublin but as usual we > need to confirm on the mailing list. > > Are you in favor/opposed adopting draft-levis-roll-protocols-survey > (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt) > as a ROLL WG document ? > > Note that the draft has been slightly updated to align it with the > presentation that was made during the meeting. > > Thanks. > > JP. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Aug 11 00:05:23 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 2542C3A6B59; Mon, 11 Aug 2008 00:05:23 -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 216423A67ED for <roll@core3.amsl.com>; Mon, 11 Aug 2008 00:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 ONGnFPAir8PH for <roll@core3.amsl.com>; Mon, 11 Aug 2008 00:05:20 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id ECC7A3A691E for <roll@ietf.org>; Mon, 11 Aug 2008 00:05:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Aug 2008 09:05:11 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EB68CF4@zensys17.zensys.local> In-Reply-To: <C4C3CFB0.4DAEB%jvasseur@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WGdocument Thread-Index: Acj6YYuLuMHTFm5cuUyrafLczWZV4ABHv6KQ References: <C4C3CFB0.4DAEB%jvasseur@cisco.com> From: "Anders Brandt" <abr@zen-sys.com> To: <roll@ietf.org> Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WGdocument 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="===============0216598003==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0216598003== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FB80.9892250E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FB80.9892250E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support it. =20 - Anders ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: 9. august 2008 22:50 To: roll@ietf.org Subject: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WGdocument Dear WG, There was a good consensus to adopt draft-levis-roll-protocols-survey as a ROLL WG document during the ROLL WG meeting in Dublin but as usual we need to confirm on the mailing list. Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-0 2.txt) as a ROLL WG document ? Note that the draft has been slightly updated to align it with the presentation that was made during the meeting. Thanks. JP.=20 ------_=_NextPart_001_01C8FB80.9892250E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Adoption of draft-levis-roll-protocols-survey as a = ROLL WG document
I support it.
 
- Anders

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent: 9.=20 august 2008 22:50
To: roll@ietf.org
Subject: [Roll] = Adoption=20 of draft-levis-roll-protocols-survey as a ROLL = WGdocument

Dear = WG,

There=20 was a good consensus to adopt draft-levis-roll-protocols-survey as a = ROLL WG=20 document during the ROLL WG meeting in Dublin but as usual we need to = confirm on=20 the mailing list.

Are you in favor/opposed adopting=20 draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protoco= ls-survey-02.txt)=20 as a ROLL WG document ?

Note that the draft has been slightly = updated to=20 align it with the presentation that was made during the=20 meeting.

Thanks.

JP. ------_=_NextPart_001_01C8FB80.9892250E-- --===============0216598003== 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 --===============0216598003==-- From roll-bounces@ietf.org Mon Aug 11 00:38: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 E2D673A6C60; Mon, 11 Aug 2008 00:38: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 B31483A6C58 for ; Mon, 11 Aug 2008 00:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 hTP0MBHkK-Gh for ; Mon, 11 Aug 2008 00:38:43 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by core3.amsl.com (Postfix) with ESMTP id 8F6B23A67D7 for ; Mon, 11 Aug 2008 00:38:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,341,1215381600"; d="scan'208";a="7818718" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1a.tno.nl with ESMTP; 11 Aug 2008 09:38:38 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 x-mimeole: Produced By Microsoft Exchange V6.5 Date: Mon, 11 Aug 2008 09:38:37 +0200 Message-ID: <42F3BE57026C6E49B09E267EEF639D56034D6806@ms-dt01thalia.tsn.tno.nl> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Roll Digest, Vol 7, Issue 1 Thread-Index: Acj7G2As3vrxxONFRJuvBApyh1+19wAachcw References: From: "Zhang, S. (Shuang)" To: Subject: Re: [Roll] Roll Digest, Vol 7, Issue 1 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 WG, I am in favor of the adoption of draft-levis-roll-protocols-survey as a ROLL WG document. Kind regards, Shuang Zhang -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of roll-request@ietf.org Sent: zondag 10 augustus 2008 21:00 To: roll@ietf.org Subject: Roll Digest, Vol 7, Issue 1 Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/roll or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. Adoption of draft-levis-roll-protocols-survey as a ROLL WG document (JP Vasseur) ---------------------------------------------------------------------- Message: 1 Date: Sat, 09 Aug 2008 22:50:24 +0200 From: JP Vasseur Subject: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WG document To: Message-ID: Content-Type: text/plain; charset="us-ascii" Dear WG, There was a good consensus to adopt draft-levis-roll-protocols-survey as a ROLL WG document during the ROLL WG meeting in Dublin but as usual we need to confirm on the mailing list. Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-0 2.tx t) as a ROLL WG document ? Note that the draft has been slightly updated to align it with the presentation that was made during the meeting. Thanks. JP. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 7, Issue 1 ********************************** This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Aug 11 09:34:51 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 3EC3D3A6ABC; Mon, 11 Aug 2008 09:34:51 -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 413C23A6A4D for ; Mon, 11 Aug 2008 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 HEICZio7ocvO for ; Mon, 11 Aug 2008 09:34:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 2DB003A6801 for ; Mon, 11 Aug 2008 09:34:48 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D0D1A48085; Mon, 11 Aug 2008 18:34:47 +0200 (CEST) Received: from PMEXCC21.intranet-paris.francetelecom.fr (unknown [10.196.130.6]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 98DB36800B; Mon, 11 Aug 2008 18:34:47 +0200 (CEST) Received: from PMEXCB30.intranet-paris.francetelecom.fr ([10.196.130.38]) by PMEXCC21.intranet-paris.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.2499); Mon, 11 Aug 2008 18:34:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Aug 2008 18:34:42 +0200 Message-ID: <53DE7AEBE1DD5741A44C363427681922033F3800@PMEXCB30.intranet-paris.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WGdocument thread-index: Acj6YYuLuMHTFm5cuUyrafLczWZV4ABbpNRg From: To: "JP Vasseur" , X-OriginalArrivalTime: 11 Aug 2008 16:34:47.0423 (UTC) FILETIME=[2B0EF8F0:01C8FBD0] Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WGdocument 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="===============0807582776==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0807582776== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FBD0.2AE1C0B0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FBD0.2AE1C0B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, =20 In favor=2E =20 Cheers, =20 Christian=2E ________________________________ De : roll-bounces@ietf=2Eorg [mailto:roll-bounces@ietf=2Eorg] De la part= de JP Vasseur Envoy=E9 : samedi 9 ao=FBt 2008 22:50 =C0 : roll@ietf=2Eorg Objet : [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL= WGdocument =09 =09 Dear WG, =09 There was a good consensus to adopt draft-levis-roll-protocols-survey as a= ROLL WG document during the ROLL WG meeting in Dublin but as usual we need= to confirm on the mailing list=2E =09 Are you in favor/opposed adopting draft-levis-roll-protocols-survey= (http://www=2Eietf= =2Eorg/internet-drafts/draft-levis-roll-protocols-survey-02=2Etxt) as a= ROLL WG document ? =09 Note that the draft has been slightly updated to align it with the= presentation that was made during the meeting=2E =09 Thanks=2E =09 JP=2E=20 ********************************* This message and any attachments (the "message") are confidential and= intended solely for the addressees=2E=20 Any unauthorised use or dissemination is prohibited=2E Messages are susceptible to alteration=2E=20 France Telecom Group shall not be liable for the message if altered,= changed or falsified=2E If you are not the intended addressee of this message, please cancel it= immediately and inform the sender=2E ******************************** ------_=_NextPart_001_01C8FBD0.2AE1C0B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adoption of draft-levis-roll-protocols-survey as a ROLL= WG document
Dear all,
 
In favor=2E
 
Cheers,
 
Christian=2E

De : roll-bounces@ietf=2Eorg=20 [mailto:roll-bounces@ietf=2Eorg] De la part de JP=20 Vasseur
Envoy=E9 : samedi 9 ao=FBt 2008 22:50
= =C0 :=20 roll@ietf=2Eorg
Objet : [Roll] Adoption of=20 draft-levis-roll-protocols-survey as a ROLL= WGdocument

Dear=20 WG,

There was a good consensus to adopt=20 draft-levis-roll-protocols-survey as a ROLL WG document during the ROLL= WG=20 meeting in Dublin but as usual we need to confirm on the mailing=20 list=2E

Are you in favor/opposed adopting=20 draft-levis-roll-protocols-survey (http://www=2Eietf= =2Eorg/internet-drafts/draft-levis-roll-protocols-survey-02=2Etxt)=20 as a ROLL WG document ?

Note that the draft has been slightly= updated=20 to align it with the presentation that was made during the=20 meeting=2E

Thanks=2E

JP=2E=
*********************************
This message and any attachments (the "message") are confidential and= intended solely for the addressees=2E
Any unauthorised use or dissemination is prohibited=2E
Messages are susceptible to alteration=2E
France Telecom Group shall not be liable for the message if altered,= changed or falsified=2E
If you are not the intended addressee of this message, please cancel it= immediately and inform the sender=2E
********************************
------_=_NextPart_001_01C8FBD0.2AE1C0B0-- --===============0807582776== 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 --===============0807582776==-- From roll-bounces@ietf.org Mon Aug 11 09:37:27 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 9BA093A69D5; Mon, 11 Aug 2008 09:37:27 -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 CB1F43A69F2 for ; Mon, 11 Aug 2008 09:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 1DN7mPJCb9rq for ; Mon, 11 Aug 2008 09:37:26 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 1C9DB3A6359 for ; Mon, 11 Aug 2008 09:37:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 9F53CAF8D6; Mon, 11 Aug 2008 09:37:28 -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 kInCtrGsagXE; Mon, 11 Aug 2008 09:37:28 -0700 (PDT) Received: from [192.168.7.78] (unknown [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id D50A0AF85E; Mon, 11 Aug 2008 09:37:27 -0700 (PDT) Message-Id: From: Jonathan Hui To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 11 Aug 2008 09:37:17 -0700 References: X-Mailer: Apple Mail (2.926) Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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="===============1837407378==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1837407378== Content-Type: multipart/alternative; boundary=Apple-Mail-19--352731426 --Apple-Mail-19--352731426 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit +1 It provides a good foundation for the discussion moving forward. -- Jonathan Hui On Aug 9, 2008, at 1:50 PM, JP Vasseur wrote: > Dear WG, > > There was a good consensus to adopt draft-levis-roll-protocols- > survey as a ROLL WG document during the ROLL WG meeting in Dublin > but as usual we need to confirm on the mailing list. > > Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt > ) as a ROLL WG document ? > > Note that the draft has been slightly updated to align it with the > presentation that was made during the meeting. > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-19--352731426 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
--
Jonathan = Hui



On Aug 9, 2008, = at 1:50 PM, JP Vasseur wrote:

= Dear WG,

= There was a good consensus to adopt draft-levis-roll-protocols-survey as = a ROLL WG document during the ROLL WG meeting in Dublin but as usual we = need to confirm on the mailing list.

Are you in favor/opposed = adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols= -survey-02.txt) as a ROLL WG document ?

Note that the draft = has been slightly updated to align it with the presentation that was = made during the meeting.

Thanks.

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

= --Apple-Mail-19--352731426-- --===============1837407378== 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 --===============1837407378==-- From roll-bounces@ietf.org Mon Aug 11 09:50:44 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 EADAC3A6C26; Mon, 11 Aug 2008 09:50:44 -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 A0C203A6C26 for ; Mon, 11 Aug 2008 09:50:44 -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 x9HkSpPucmge for ; Mon, 11 Aug 2008 09:50:44 -0700 (PDT) Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by core3.amsl.com (Postfix) with SMTP id A90C73A6C1C for ; Mon, 11 Aug 2008 09:50:43 -0700 (PDT) Received: (qmail 38869 invoked from network); 11 Aug 2008 16:50:45 -0000 Received: from unknown (HELO ?192.168.0.207?) (anand@ekasystems.com@209.48.242.66 with plain) by smtp108.biz.mail.re2.yahoo.com with SMTP; 11 Aug 2008 16:50:44 -0000 X-YMail-OSG: d5zbZfwVM1kGY1TZGaJYVCSWRdpmMQaX_pq3GP6RLUhcGbvb7m9143mOya15u2rPhz5SDgDM37PuXKoq1eoFrTfLK_80KWAB7XIPnXEGwmcPWE_xbs6IU8O_jqg6kcU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A06F3E.6090908@ekasystems.com> Date: Mon, 11 Aug 2008 12:56:30 -0400 From: "M. B. Anand" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org In favor. Regards, Anand. > Dear WG, > > There was a good consensus to adopt draft-levis-roll-protocols-survey > as a ROLL WG document during the ROLL WG meeting in Dublin but as > usual we need to confirm on the mailing list. > > Are you in favor/opposed adopting draft-levis-roll-protocols-survey > (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt) > as a ROLL WG document ? > > Note that the draft has been slightly updated to align it with the > presentation that was made during the meeting. > > 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 Mon Aug 11 10:44: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 395173A6B1F; Mon, 11 Aug 2008 10:44: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 E70463A6B03 for ; Mon, 11 Aug 2008 10:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Sm2H-epdxXzv for ; Mon, 11 Aug 2008 10:43:59 -0700 (PDT) Received: from mail.cs.wayne.edu (srv03fac.cs.wayne.edu [141.217.48.33]) by core3.amsl.com (Postfix) with ESMTP id 207233A6AFD for ; Mon, 11 Aug 2008 10:43:58 -0700 (PDT) Received: from [127.0.0.1] ([141.217.48.171]) by mail.cs.wayne.edu (8.14.2/8.13.4) with ESMTP id m7BHhwVJ001762; Mon, 11 Aug 2008 13:43:58 -0400 (EDT) Message-ID: <48A079C8.4040006@cs.wayne.edu> Date: Mon, 11 Aug 2008 13:41:28 -0400 From: Hongwei Zhang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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="===============1099909160==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1099909160== Content-Type: multipart/alternative; boundary="------------020407070106060707040204" This is a multi-part message in MIME format. --------------020407070106060707040204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In favor. Best, Hongwei JP Vasseur wrote: > Dear WG, > > There was a good consensus to adopt draft-levis-roll-protocols-survey > as a ROLL WG document during the ROLL WG meeting in Dublin but as > usual we need to confirm on the mailing list. > > Are you in favor/opposed adopting draft-levis-roll-protocols-survey > (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt) > as a ROLL WG document ? > > Note that the draft has been slightly updated to align it with the > presentation that was made during the meeting. > > Thanks. > > JP. > >------------------------------------------------------------------------ > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll > > --------------020407070106060707040204 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit In favor.

Best,

Hongwei


JP Vasseur wrote:
Adoption of draft-levis-roll-protocols-survey as a ROLL WG document Dear WG,

There was a good consensus to adopt draft-levis-roll-protocols-survey as a ROLL WG document during the ROLL WG meeting in Dublin but as usual we need to confirm on the mailing list.

Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt) as a ROLL WG document ?

Note that the draft has been slightly updated to align it with the presentation that was made during the meeting.

Thanks.

JP. 

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------020407070106060707040204-- --===============1099909160== 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 --===============1099909160==-- From roll-bounces@ietf.org Mon Aug 11 10:50: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 4FD433A6A43; Mon, 11 Aug 2008 10:50: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 9577E3A67EF for ; Mon, 11 Aug 2008 10:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2i-BwoBlAmQh for ; Mon, 11 Aug 2008 10:50:25 -0700 (PDT) Received: from auswood.securesites.net (auswood.securesites.net [128.121.62.173]) by core3.amsl.com (Postfix) with ESMTP id C9DB03A6A43 for ; Mon, 11 Aug 2008 10:50:25 -0700 (PDT) Received: from [192.168.2.98] (adsl-99-163-7-131.dsl.pltn13.sbcglobal.net [99.163.7.131]) (authenticated bits=0) by auswood.securesites.net (8.13.6.20060614/8.13.6) with ESMTP id m7BHm8gh024417; Mon, 11 Aug 2008 17:48:08 GMT Message-Id: From: Zachary Smith To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 11 Aug 2008 10:48:04 -0700 References: X-Mailer: Apple Mail (2.928.1) Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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="===============2133959163==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============2133959163== Content-Type: multipart/alternative; boundary=Apple-Mail-16--348483486 --Apple-Mail-16--348483486 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit in favor. z On Aug 9, 2008, at 1:50 PM, JP Vasseur wrote: > Dear WG, > > There was a good consensus to adopt draft-levis-roll-protocols- > survey as a ROLL WG document during the ROLL WG meeting in Dublin > but as usual we need to confirm on the mailing list. > > Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt > ) as a ROLL WG document ? > > Note that the draft has been slightly updated to align it with the > presentation that was made during the meeting. > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll Zachary Smith - CTO http://www.daintree.net/ --Apple-Mail-16--348483486 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable in = favor.

  z

On Aug = 9, 2008, at 1:50 PM, JP Vasseur wrote:

= Dear WG,

= There was a good consensus to adopt draft-levis-roll-protocols-survey as = a ROLL WG document during the ROLL WG meeting in Dublin but as usual we = need to confirm on the mailing list.

Are you in favor/opposed = adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols= -survey-02.txt) as a ROLL WG document ?

Note that the draft = has been slightly updated to align it with the presentation that was = made during the meeting.

Thanks.

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


Zachary Smith = - CTO
<= br class=3D"khtml-block-placeholder">



= --Apple-Mail-16--348483486-- --===============2133959163== 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 --===============2133959163==-- From roll-bounces@ietf.org Mon Aug 11 11:08: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 8C52A3A6C52; Mon, 11 Aug 2008 11:08: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 F2C743A69A5 for ; Mon, 11 Aug 2008 11:08:55 -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 B1c-XAQFOzk7 for ; Mon, 11 Aug 2008 11:08:55 -0700 (PDT) Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by core3.amsl.com (Postfix) with SMTP id 0C5AD3A6919 for ; Mon, 11 Aug 2008 11:08:54 -0700 (PDT) Received: (qmail 80305 invoked from network); 11 Aug 2008 18:08:57 -0000 Received: from unknown (HELO zeke.ekasystems.com) (tim.winter@ekasystems.com@209.48.242.66 with plain) by smtp105.biz.mail.re2.yahoo.com with SMTP; 11 Aug 2008 18:08:57 -0000 X-YMail-OSG: HH3VEZIVM1m8TV0bWtT8oG0F_834C7wTDFgZuyQW5f4G8qpJFv0o1nByZhjBYdhcSLHZqudtST3x1D2UWXZ7ORUwdxCKPbhvr4Ktb0bqk_.NzU8i25WIViK5nUP9uuA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A08036.6050005@ekasystems.com> Date: Mon, 11 Aug 2008 14:08:54 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org In favor. -Tim JP Vasseur wrote: > Dear WG, > > There was a good consensus to adopt draft-levis-roll-protocols-survey > as a ROLL WG document during the ROLL WG meeting in Dublin but as > usual we need to confirm on the mailing list. > > Are you in favor/opposed adopting draft-levis-roll-protocols-survey > (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt) > as a ROLL WG document ? > > Note that the draft has been slightly updated to align it with the > presentation that was made during the meeting. > > 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 Mon Aug 11 11:14:36 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 61E4F3A6CFC; Mon, 11 Aug 2008 11:14: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 386543A6CFC for ; Mon, 11 Aug 2008 11:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 2vK7d+-KDD91 for ; Mon, 11 Aug 2008 11:14:35 -0700 (PDT) Received: from smtp101.biz.mail.mud.yahoo.com (smtp101.biz.mail.mud.yahoo.com [68.142.200.236]) by core3.amsl.com (Postfix) with SMTP id 3B3433A6C52 for ; Mon, 11 Aug 2008 11:14:35 -0700 (PDT) Received: (qmail 99514 invoked from network); 11 Aug 2008 18:14:36 -0000 Received: from unknown (HELO zeke.ekasystems.com) (tim.winter@ekasystems.com@209.48.242.66 with plain) by smtp101.biz.mail.mud.yahoo.com with SMTP; 11 Aug 2008 18:14:36 -0000 X-YMail-OSG: Bbk1vnwVM1k4qxw5F8Y6zBUC4mKEnmSoo_Th_1K2vkofpsDKVAAflrXHSb4mwUlIMoZX3gceJxf12cSLC9r6LgKqVnnavQBt9cz1OUabKw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A0818B.90605@ekasystems.com> Date: Mon, 11 Aug 2008 14:14:35 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: roll@ietf.org Subject: [Roll] Comments on draft-levis-roll-protocols-survey-02 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org WG, In reviewing the document I have come up with the following comments: Overall I find that the approach taken is useful and constructive. It certainly provides a solid starting point from which to debate the merits and drawbacks of various prtocols and their suitability to ROLL. DSDV does not appear to be covered by any RFC or active draft. I suggest that it should be removed from ths survey. With regard to the Table Scalability criterion I think it should be more stringent. The use case of LLNs behaving as data collection networks, with the bulk of traffic flow through routers to data collection points, is certainly a dominant one. But there are other use cases, e.g. access points -> sensor/actuator, which may let the number of possible destinations D begin to approach N. Should it be necessary to maintain such state at individual nodes, for large networks, it would be better for a protocol to provide routing table scaling with O(log(D)). Such may be found, for example, in protocols which employ clustering or hierarchical strategies. The Control Cost criterion makes a lot of sense when considering the energy constraints of nodes who are only battery powered and must conserve energy at all times. However I think we should also consider that a (proactive) routing protocol may be able to take advantage of powered (i.e. not energy constrained) nodes that may be available in the network. For example, a set of powered nodes who are able to communicate without regard to limited energy may be able to maintain a proactive routing state in order to service transient battery powered nodes, who may come and go and would not be expected to maintain any unused state. None of the protocols under consideration appear to have such capabilities. Some small items: 111 Energy is a fundamental challenge in these devices. Convenience and >>>>> ^^^^^ in many of these devices 112 ease of use requires they be wireless and therefore battery powered. >>>>> ^^^^^^^^^ and in many cases 266 properties abd attributes such as power, memory, and battery life >>>>> ^^^ and 274 4. Routing Protocol Taxonomy >>>>> Suggest to add heading `4.1. Protocol Classes' 275 Routing protocols broadly fall into two classes: link-state and 276 distance-vector. 330 Protocols Today >>>>> ^^^ Suggest to add heading `4.2. ...' 362 protocols. Later sections consider the properties of these protocol >>>>> ^s 586 messages, but TC messages spread topology information throughout the 587 network (using MPRs). As such, control traffic is proportional to 588 O(N^2). As L is bounded by N, this means control traffic is >>>>> ^XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 589 proportional to O(N). MPRs reduce this load to O(N^2 / L). As the >>>>> ^XXXXXXXXXXXXXXXXXXXX >>>>> This sentence seems like it should be removed, the explanation is more >>>>> clearly laid out below 590 number of MPRs is inversely proportional to the density of the 591 network and L is bounded by N, this means control traffic is at best 592 proportional to O(N), and fails the control cost metric. Regards, -Tim _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Aug 11 11:15:25 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 9C73E3A6D70; Mon, 11 Aug 2008 11:15:25 -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 1A63B3A6D74 for ; Mon, 11 Aug 2008 11:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 f02hYAlCMJEo for ; Mon, 11 Aug 2008 11:15:24 -0700 (PDT) Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by core3.amsl.com (Postfix) with ESMTP id 4FDE53A6D23 for ; Mon, 11 Aug 2008 11:15:24 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0K5G0093Q58VZH10@mail-mta.sfvic.sunlabs.com> for roll@ietf.org; Mon, 11 Aug 2008 10:14:55 -0700 (PDT) Received: from dhcp-069-082.sfbay.sunlabs.com ([152.70.69.82]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0K5G0077458UQ010@mail.sunlabs.com> for roll@ietf.org; Mon, 11 Aug 2008 10:14:55 -0700 (PDT) Date: Mon, 11 Aug 2008 10:14:54 -0700 From: "Pete St. Pierre" In-reply-to: To: JP Vasseur Message-id: <0D71A114-70E3-4E9B-AD50-07E71A7644FD@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.926) References: Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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="===============0331079599==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0331079599== Content-type: multipart/alternative; boundary="Boundary_(ID_cku/cHRI3TWhoPZ4xHFiYg)" --Boundary_(ID_cku/cHRI3TWhoPZ4xHFiYg) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT Sounds good! ...Pete On Aug 9, 2008, at 1:50 PM, JP Vasseur wrote: > Dear WG, > > There was a good consensus to adopt draft-levis-roll-protocols- > survey as a ROLL WG document during the ROLL WG meeting in Dublin > but as usual we need to confirm on the mailing list. > > Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt > ) as a ROLL WG document ? > > Note that the draft has been slightly updated to align it with the > presentation that was made during the meeting. > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Boundary_(ID_cku/cHRI3TWhoPZ4xHFiYg) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT Sounds good!
...Pete

On Aug 9, 2008, at 1:50 PM, JP Vasseur wrote:

Dear WG,

There was a good consensus to adopt draft-levis-roll-protocols-survey as a ROLL WG document during the ROLL WG meeting in Dublin but as usual we need to confirm on the mailing list.

Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt) as a ROLL WG document ?

Note that the draft has been slightly updated to align it with the presentation that was made during the meeting.

Thanks.

JP.
___________________ ________ oll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--Boundary_(ID_cku/cHRI3TWhoPZ4xHFiYg)-- --===============0331079599== 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 --===============0331079599==-- From roll-bounces@ietf.org Mon Aug 11 12:37: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 78C103A6C03; Mon, 11 Aug 2008 12:37: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 892C63A68E7; Mon, 11 Aug 2008 12:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 E6Axz8sKq7oY; Mon, 11 Aug 2008 12:37:03 -0700 (PDT) Received: from exprod8og108.obsmtp.com (exprod8og108.obsmtp.com [64.18.3.96]) by core3.amsl.com (Postfix) with ESMTP id B525C3A6C03; Mon, 11 Aug 2008 12:36:52 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob108.postini.com ([64.18.7.12]) with SMTP; Mon, 11 Aug 2008 12:33:53 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2008081114381859-2171253 ; Mon, 11 Aug 2008 14:38:18 -0500 In-Reply-To: MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Mon, 11 Aug 2008 14:36:46 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 08/11/2008 02:36:53 PM, Serialize complete at 08/11/2008 02:36:53 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/11/2008 02:38:18 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/11/2008 02:38:20 PM, Serialize complete at 08/11/2008 02:38:20 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/11/2008 02:38:21 PM Cc: roll@ietf.org, roll-bounces@ietf.org, Ted.Humpal@jci.com Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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="===============0200194578==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multipart message in MIME format. --===============0200194578== Content-Type: multipart/alternative; boundary="=_alternative 006BBD94862574A2_=" This is a multipart message in MIME format. --=_alternative 006BBD94862574A2_= Content-Type: text/plain; charset="US-ASCII" The survey as given in Dublin only included the Home, Industrial and Urban routing requirements. I presume this was because the Commercial Building requirements were not available until early July. I would like the analysis to include the commercial building requirements. I also think that 'latency' should be a column on the decision matrix on page 9 of the document. Embedded real-time systems are mission critical (e.g. Fire Alarming) where latency is a prime discriminator of the protocol used. The routing algorithms are subject to this latency for example when a new path must be discovered while the packet is in transit. I would like to postpone the adoption of the document as a ROLL WG document until these two items have been addressed. Regards, Jerry Martocci JP Vasseur Sent by: roll-bounces@ietf.org 08/09/2008 03:50 PM To cc Subject [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WG document Dear WG, There was a good consensus to adopt draft-levis-roll-protocols-survey as a ROLL WG document during the ROLL WG meeting in Dublin but as usual we need to confirm on the mailing list. Are you in favor/opposed adopting draft-levis-roll-protocols-survey ( http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt ) as a ROLL WG document ? Note that the draft has been slightly updated to align it with the presentation that was made during the meeting. Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 006BBD94862574A2_= Content-Type: text/html; charset="US-ASCII"
The survey as given in Dublin only included the Home,  Industrial and Urban routing requirements.  I presume this was because the Commercial Building requirements were not available until early July.  I would like the analysis to include the commercial building requirements.  

I also think that 'latency' should be a column on the decision matrix on page 9 of the document.  Embedded real-time systems are mission critical (e.g. Fire Alarming) where latency is a prime discriminator of the protocol used.  The routing algorithms are subject to this latency for example when a new path must be discovered while the packet is in transit.

I would like to postpone the adoption of the document as a ROLL WG document until these two items have been addressed.


Regards,

Jerry Martocci





JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

08/09/2008 03:50 PM

To
<roll@ietf.org>
cc
Subject
[Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WG        document





Dear WG,

There was a good consensus to adopt draft-levis-roll-protocols-survey as a ROLL WG document during the ROLL WG meeting in Dublin but as usual we need to confirm on the mailing list.

Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt) as a ROLL WG document ?

Note that the draft has been slightly updated to align it with the presentation that was made during the meeting.

Thanks.

JP. _______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 006BBD94862574A2_=-- --===============0200194578== 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 --===============0200194578==-- From roll-bounces@ietf.org Mon Aug 11 13:13: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 A03CE3A68C6; Mon, 11 Aug 2008 13:13: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 3AC743A68C6; Mon, 11 Aug 2008 13:13:20 -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 cj9fK159oh6Z; Mon, 11 Aug 2008 13:13:19 -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 7AEF83A68B1; Mon, 11 Aug 2008 13:13:19 -0700 (PDT) Received: from dnab42228f.stanford.edu ([171.66.34.143]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KSdlZ-0002HN-TS; Mon, 11 Aug 2008 13:13:22 -0700 Message-Id: <81AA0163-15F3-4E3D-8DAB-65103F6E2515@cs.stanford.edu> From: Philip Levis To: Jerald.P.Martocci@jci.com In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 11 Aug 2008 13:13:22 -0700 References: X-Mailer: Apple Mail (2.926) X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae Cc: roll@ietf.org, Ted.Humpal@jci.com, roll-bounces@ietf.org Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Aug 11, 2008, at 12:36 PM, Jerald.P.Martocci@jci.com wrote: > > The survey as given in Dublin only included the Home, Industrial > and Urban routing requirements. I presume this was because the > Commercial Building requirements were not available until early > July. I would like the analysis to include the commercial building > requirements. Will the commercial routing requirements change the set? That is, is one of the existing columns not a criterion of commercial applications? If so, then I agree. If not, an update would merely require adding the correct references. > I also think that 'latency' should be a column on the decision > matrix on page 9 of the document. Embedded real-time systems are > mission critical (e.g. Fire Alarming) where latency is a prime > discriminator of the protocol used. The routing algorithms are > subject to this latency for example when a new path must be > discovered while the packet is in transit. Home monitoring applications are often not mission-critical real-time systems, and so do not share this requirement. The closest they come is the need for low latency alarms, but these events are very rare. Following the methodology of the draft, this means it shouldn't include latency. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Aug 11 14:43:25 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 45CFB3A6AC0; Mon, 11 Aug 2008 14:43:25 -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 3FA483A6A12; Mon, 11 Aug 2008 14:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ED8g0gce7j+Z; Mon, 11 Aug 2008 14:43:23 -0700 (PDT) Received: from exprod8og104.obsmtp.com (exprod8og104.obsmtp.com [64.18.3.88]) by core3.amsl.com (Postfix) with ESMTP id DD6EC3A6D0B; Mon, 11 Aug 2008 14:43:22 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob104.postini.com ([64.18.7.12]) with SMTP; Mon, 11 Aug 2008 14:40:13 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2008081116434935-41572 ; Mon, 11 Aug 2008 16:43:49 -0500 In-Reply-To: <81AA0163-15F3-4E3D-8DAB-65103F6E2515@cs.stanford.edu> MIME-Version: 1.0 To: Philip Levis X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Mon, 11 Aug 2008 16:43:05 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 08/11/2008 04:43:15 PM, Serialize complete at 08/11/2008 04:43:15 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/11/2008 04:43:49 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/11/2008 04:43:59 PM, Serialize complete at 08/11/2008 04:43:59 PM Cc: roll@ietf.org, Ted.Humpal@jci.com, roll-bounces@ietf.org Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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="===============0010824890==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multipart message in MIME format. --===============0010824890== Content-Type: multipart/alternative; boundary="=_alternative 00774D86862574A2_=" This is a multipart message in MIME format. --=_alternative 00774D86862574A2_= Content-Type: text/plain; charset="US-ASCII" Phil, I see 'latency' as an added requirement in addition to the ones defined not a replacement for an existing column, So in that regard, we could add it later. I guess I am not sure if making this document a ROLL WG document locks it out for future additions. I also agree the 'home' market probably has a limited use case for latency, however, I would think the 'industrial' market would require no more latency than the 'commercial' market. Don't get me wrong, I think your document is a great start! I just want to make sure we concern ourselves with the time-critical and deterministic nature of some of the applications. Jerry Philip Levis 08/11/2008 03:13 PM To Jerald.P.Martocci@jci.com cc JP Vasseur , roll@ietf.org, roll-bounces@ietf.org, Ted.Humpal@jci.com Subject Re: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WG document On Aug 11, 2008, at 12:36 PM, Jerald.P.Martocci@jci.com wrote: > > The survey as given in Dublin only included the Home, Industrial > and Urban routing requirements. I presume this was because the > Commercial Building requirements were not available until early > July. I would like the analysis to include the commercial building > requirements. Will the commercial routing requirements change the set? That is, is one of the existing columns not a criterion of commercial applications? If so, then I agree. If not, an update would merely require adding the correct references. > I also think that 'latency' should be a column on the decision > matrix on page 9 of the document. Embedded real-time systems are > mission critical (e.g. Fire Alarming) where latency is a prime > discriminator of the protocol used. The routing algorithms are > subject to this latency for example when a new path must be > discovered while the packet is in transit. Home monitoring applications are often not mission-critical real-time systems, and so do not share this requirement. The closest they come is the need for low latency alarms, but these events are very rare. Following the methodology of the draft, this means it shouldn't include latency. Phil --=_alternative 00774D86862574A2_= Content-Type: text/html; charset="US-ASCII"
Phil,

I see 'latency' as an added requirement in addition to the ones defined not a replacement for an existing column,  So in that regard, we could add it later.   I guess I am not sure if making this document a ROLL WG document locks it out for future additions.  I also agree the 'home' market probably has a limited use case for latency, however, I would think the 'industrial' market would require no more latency than the 'commercial' market.

Don't get me wrong, I think your document is a great start!  I just want to make sure we concern ourselves with the time-critical and deterministic nature of some of the applications.


Jerry







Philip Levis <pal@cs.stanford.edu>

08/11/2008 03:13 PM

To
Jerald.P.Martocci@jci.com
cc
JP Vasseur <jvasseur@cisco.com>, roll@ietf.org, roll-bounces@ietf.org, Ted.Humpal@jci.com
Subject
Re: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WG        document






On Aug 11, 2008, at 12:36 PM, Jerald.P.Martocci@jci.com wrote:

>
> The survey as given in Dublin only included the Home,  Industrial  
> and Urban routing requirements.  I presume this was because the  
> Commercial Building requirements were not available until early  
> July.  I would like the analysis to include the commercial building  
> requirements.

Will the commercial routing requirements change the set? That is, is  
one of the existing columns not a criterion of commercial  
applications? If so, then I agree. If not, an update would merely  
require adding the correct references.

> I also think that 'latency' should be a column on the decision  
> matrix on page 9 of the document.  Embedded real-time systems are  
> mission critical (e.g. Fire Alarming) where latency is a prime  
> discriminator of the protocol used.  The routing algorithms are  
> subject to this latency for example when a new path must be  
> discovered while the packet is in transit.

Home monitoring applications are often not mission-critical real-time  
systems, and so do not share this requirement. The closest they come  
is the need for low latency alarms, but these events are very rare.  
Following the methodology of the draft, this means it shouldn't  
include latency.

Phil
--=_alternative 00774D86862574A2_=-- --===============0010824890== 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 --===============0010824890==-- From roll-bounces@ietf.org Mon Aug 11 14:50:54 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 8CA2F3A6AC9; Mon, 11 Aug 2008 14:50:54 -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 D03A93A6A94; Mon, 11 Aug 2008 14:50:53 -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 AjX3Jk1Fc2KG; Mon, 11 Aug 2008 14:50:53 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 0620F3A681A; Mon, 11 Aug 2008 14:50:53 -0700 (PDT) Received: from [76.14.71.180] (helo=[192.168.2.101]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KSfHz-00086c-H0; Mon, 11 Aug 2008 14:50:55 -0700 Message-Id: <33599D2D-2D5F-4A1E-B705-9D8FCADBA286@cs.stanford.edu> From: Philip Levis To: Jerald.P.Martocci@jci.com In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 11 Aug 2008 13:54:23 -0700 References: X-Mailer: Apple Mail (2.926) X-Scan-Signature: 078eb853d78558c6c655f7b6c94b391a Cc: roll@ietf.org, Ted.Humpal@jci.com, roll-bounces@ietf.org Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Aug 11, 2008, at 12:36 PM, Jerald.P.Martocci@jci.com wrote: > > The survey as given in Dublin only included the Home, Industrial > and Urban routing requirements. I presume this was because the > Commercial Building requirements were not available until early > July. I would like the analysis to include the commercial building > requirements. Jerald, The commercial draft is a fantastic start. It points out several ways in which this application space differs from the others and will be invaluable moving forward. Using hard numbers (10 hops, 255 nodes, etc.) is very helpful. A couple of comments: 1) The goal of the requirements drafts is to state the requirements of a routing protocol, not a system as a whoe. For example, 18.Requirement says "RFDs SHOULD target for operation using viable energy harvesting techniques such as ambient light, mechanical action, solar load, air pressure and differential temperature." This is outside of ROLL's control and domain. 2) The draft seems to be very 6lowpan-specific. While ROLL is very concerned with 6lowpan, ROLL protocols can't be tied to it. Even within 6lowpan they're seeking to avoid 802.15.4-specific terminology such as FFD and RFD, as many systems today use the link layer but not MAC layer. E.g., ArchRock's 6lowpan stack operates on a completely ad- hoc network with low-power, battery-based devices. 3) Requirement 45 seems rather difficult: it suggests that ROLL cannot have any headers. Is this what you mean? Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Aug 11 14:56: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 28DFE3A6BB9; Mon, 11 Aug 2008 14:56: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 1E4113A6BB9; Mon, 11 Aug 2008 14:55:59 -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 d0vO6cIFw5zv; Mon, 11 Aug 2008 14:55:58 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 478443A6AC9; Mon, 11 Aug 2008 14:55:58 -0700 (PDT) Received: from [76.14.71.180] (helo=[192.168.2.101]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KSfMu-0002LW-RS; Mon, 11 Aug 2008 14:56:01 -0700 Message-Id: From: Philip Levis To: Jerald.P.Martocci@jci.com In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 11 Aug 2008 14:55:59 -0700 References: X-Mailer: Apple Mail (2.926) X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30 Cc: roll@ietf.org, Ted.Humpal@jci.com, roll-bounces@ietf.org Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Aug 11, 2008, at 2:43 PM, Jerald.P.Martocci@jci.com wrote: > > Phil, > > I see 'latency' as an added requirement in addition to the ones > defined not a replacement for an existing column, So in that > regard, we could add it later. I guess I am not sure if making > this document a ROLL WG document locks it out for future additions. > I also agree the 'home' market probably has a limited use case for > latency, however, I would think the 'industrial' market would > require no more latency than the 'commercial' market. Jerald, Ah, OK. The purpose of the document isn't to state all of the requirements of ROLL application domains. Instead, a subset, with the understanding that this subset may in fact be unable to satisfy any individual domain. "Necessary but not sufficient" is the key phrase. So in that way, the lack of latency there should not indicate that there aren't latency requirements, or that protocols ROLL considers won't be examined in terms of latency. > Don't get me wrong, I think your document is a great start! I just > want to make sure we concern ourselves with the time-critical and > deterministic nature of some of the applications. I agree. But this concern is for when we examine concrete protocol mechanisms. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Aug 11 15:11: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 249A43A6C7A; Mon, 11 Aug 2008 15:11: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 8D09F3A6C87 for ; Mon, 11 Aug 2008 15:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.327 X-Spam-Level: X-Spam-Status: No, score=-0.327 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] 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 MOjuuClC24i8 for ; Mon, 11 Aug 2008 15:11:32 -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 AA0F23A676A for ; Mon, 11 Aug 2008 15:11:32 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Aug 2008 15:11:32 -0700 Message-ID: <16745BFFDEC5F64BBB094C931862B495196B16@dust-exch-01.dusthq.dust-inc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WGdocument thread-index: Acj6YYuLuMHTFm5cuUyrafLczWZV4ABnXm8g From: "Chol Su Kang" To: "JP Vasseur" Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WGdocument 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="===============0465269325==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0465269325== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FBFF.368ECA0B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FBFF.368ECA0B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I vote in favor. =20 =20 Chol Su Kang =20 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Saturday, August 09, 2008 1:50 PM To: roll@ietf.org Subject: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WGdocument =20 Dear WG, There was a good consensus to adopt draft-levis-roll-protocols-survey as a ROLL WG document during the ROLL WG meeting in Dublin but as usual we need to confirm on the mailing list. Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-0 2.txt) as a ROLL WG document ? Note that the draft has been slightly updated to align it with the presentation that was made during the meeting. Thanks. JP.=20 ------_=_NextPart_001_01C8FBFF.368ECA0B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Adoption of draft-levis-roll-protocols-survey as a ROLL WG = document

I vote in = favor.

 

 

Chol Su = Kang

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: Saturday, August = 09, 2008 1:50 PM
To: roll@ietf.org
Subject: [Roll] Adoption = of draft-levis-roll-protocols-survey as a ROLL = WGdocument

 

Dear WG,

There was a good consensus to adopt draft-levis-roll-protocols-survey as = a ROLL WG document during the ROLL WG meeting in Dublin but as usual we need to confirm on the mailing list.

Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protoco= ls-survey-02.txt) as a ROLL WG document ?

Note that the draft has been slightly updated to align it with the = presentation that was made during the meeting.

Thanks.

JP.

------_=_NextPart_001_01C8FBFF.368ECA0B-- --===============0465269325== 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 --===============0465269325==-- From roll-bounces@ietf.org Mon Aug 11 22:22: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 0EA763A6843; Mon, 11 Aug 2008 22:22: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 EA9863A6BCF for ; Mon, 11 Aug 2008 22:22:03 -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 ARQILTSLMKVF for ; Mon, 11 Aug 2008 22:22:03 -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 6A0A53A67AA for ; Mon, 11 Aug 2008 22:21:55 -0700 (PDT) Received: from [76.14.71.180] (helo=[192.168.2.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KSmJU-0001qv-Im; Mon, 11 Aug 2008 22:20:56 -0700 Message-Id: <36B98059-6E33-47B1-87FE-2F5AA1D34700@cs.stanford.edu> From: Philip Levis To: Tim Winter In-Reply-To: <48A0818B.90605@ekasystems.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 11 Aug 2008 22:20:40 -0700 References: <48A0818B.90605@ekasystems.com> X-Mailer: Apple Mail (2.926) X-Scan-Signature: 3fe17504c5843e76b9e439a63759b02e Cc: roll@ietf.org Subject: Re: [Roll] Comments on draft-levis-roll-protocols-survey-02 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Aug 11, 2008, at 11:14 AM, Tim Winter wrote: > WG, > > In reviewing the document I have come up with the following comments: > > Overall I find that the approach taken is useful and constructive. > It certainly provides a solid starting point from which to debate > the merits and drawbacks of various prtocols and their suitability > to ROLL. > > DSDV does not appear to be covered by any RFC or active draft. I > suggest that it should be removed from ths survey. It is unique in this regard. We mostly put it in there because it is very much a key part of the MANET canon. If we didn't have it in, I'm sure someone would have said that we should. That being said, I'm not against holding hard and fast to the draft/RFC requirement. Does anyone else feel strongly about this? > > > With regard to the Table Scalability criterion I think it should be > more stringent. The use case of LLNs behaving as data collection > networks, with the bulk of traffic flow through routers to data > collection points, is certainly a dominant one. But there are other > use cases, e.g. access points -> sensor/actuator, which may let the > number of possible destinations D begin to approach N. Should it be > necessary to maintain such state at individual nodes, for large > networks, it would be better for a protocol to provide routing table > scaling with O(log(D)). Such may be found, for example, in > protocols which employ clustering or hierarchical strategies. Well, as soon as we go to sub-linear factors on D, then we're talking about routing stretch. Remember, the purpose here isn't to state the requirements of ROLL protocols -- the application drafts do that -- but rather to lay out a set of minimal (perhaps even insufficient) requirements by which we can judge existing protocols. I'm a bit wary saying that any protocol which does not use hierarchical routing cannot satisfy ROLL needs. > The Control Cost criterion makes a lot of sense when considering the > energy constraints of nodes who are only battery powered and must > conserve energy at all times. However I think we should also > consider that a (proactive) routing protocol may be able to take > advantage of powered (i.e. not energy constrained) nodes that may be > available in the network. For example, a set of powered nodes who > are able to communicate without regard to limited energy may be able > to maintain a proactive routing state in order to service transient > battery powered nodes, who may come and go and would not be expected > to maintain any unused state. None of the protocols under > consideration appear to have such capabilities. Agreed. The point here, though, isn't that some nodes could maintain more than O(D) state, or have a higher control cost, rather that some node's can't. If a protocol requires them to have > O(D) RT state, or a higher control cost, than it cannot be used on these weaker nodes. To some degree, I think node cost encompasses much of what you're talking about, though. Again, to reiterate, the criteria in this draft are *not* intended to be the principal ways in which we will evaluate ROLL protocols: those are the application requirements documents. This is just asking the question of whether existing protocols can meet our needs. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Aug 12 01:11:17 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 0F7413A6A0D; Tue, 12 Aug 2008 01:11:17 -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 A61DC3A6A0D for ; Tue, 12 Aug 2008 01:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 lHIN6c7qtp9h for ; Tue, 12 Aug 2008 01:11:15 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 53F563A67AA for ; Tue, 12 Aug 2008 01:11:14 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id m7C88U9j007890 for ; Tue, 12 Aug 2008 10:08:30 +0200 Received: from CTTCPCMDOHLER (pcmdohler.cttc.es [84.88.61.89]) by castor (Postfix) with ESMTP id 607AE2FC282 for ; Tue, 12 Aug 2008 10:08:30 +0200 (CEST) From: "Mischa Dohler" To: Date: Tue, 12 Aug 2008 10:05:54 +0200 Organization: CTTC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: Thread-Index: Acj6YYuLuMHTFm5cuUyrafLczWZV4AB8KeHw Message-Id: <20080812080830.607AE2FC282@castor> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Tue, 12 Aug 2008 10:08:30 +0200 (CEST) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WGdocument 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="===============0943422045==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0943422045== Content-Type: multipart/alternative; boundary="----=_NextPart_000_014B_01C8FC63.02678640" This is a multi-part message in MIME format. ------=_NextPart_000_014B_01C8FC63.02678640 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In favor. Mischa. _____ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Saturday, August 09, 2008 10:50 PM To: roll@ietf.org Subject: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WGdocument Dear WG, There was a good consensus to adopt draft-levis-roll-protocols-survey as a ROLL WG document during the ROLL WG meeting in Dublin but as usual we need to confirm on the mailing list. Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.tx t) as a ROLL WG document ? Note that the draft has been slightly updated to align it with the presentation that was made during the meeting. Thanks. JP. ------=_NextPart_000_014B_01C8FC63.02678640 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Adoption of draft-levis-roll-protocols-survey as a ROLL WG = document

In favor. = Mischa.

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: Saturday, August = 09, 2008 10:50 PM
To: roll@ietf.org
Subject: [Roll] Adoption = of draft-levis-roll-protocols-survey as a ROLL = WGdocument

 

Dear WG,

There was a good consensus to adopt draft-levis-roll-protocols-survey as = a ROLL WG document during the ROLL WG meeting in Dublin but as usual we need to confirm on the mailing list.

Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levis-roll-protoco= ls-survey-02.txt) as a ROLL WG document ?

Note that the draft has been slightly updated to align it with the = presentation that was made during the meeting.

Thanks.

JP.

------=_NextPart_000_014B_01C8FC63.02678640-- --===============0943422045== 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 --===============0943422045==-- From roll-bounces@ietf.org Tue Aug 12 01:17: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 208453A6A85; Tue, 12 Aug 2008 01:17: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 61CD63A6A85; Tue, 12 Aug 2008 01:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.419 X-Spam-Level: X-Spam-Status: No, score=-5.419 tagged_above=-999 required=5 tests=[AWL=-0.217, 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 ufpwVRvgOW0P; Tue, 12 Aug 2008 01:17:48 -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 595543A684A; Tue, 12 Aug 2008 01:17:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,194,1217808000"; d="scan'208,217";a="17213890" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Aug 2008 08:17:10 +0000 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 m7C8HAKr032218; Tue, 12 Aug 2008 04:17:10 -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 m7C8HA6J007432; Tue, 12 Aug 2008 08:17:10 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, 12 Aug 2008 04:17:10 -0400 Received: from 10.61.98.100 ([10.61.98.100]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 12 Aug 2008 08:17:10 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 12 Aug 2008 10:17:07 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WG document Thread-Index: Acj8U89F2OFdgzasI0aDRmQLkiLuGQ== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 12 Aug 2008 08:17:10.0424 (UTC) FILETIME=[D1503980:01C8FC53] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7698; t=1218529030; x=1219393030; 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]=20Adoption=20of=20draft-levis-ro ll-protocols-survey=20as=20a=20ROLL=20WG=0A=20document |Sender:=20 |To:=20; bh=qlQoEKVSuT9LdACpVzxjFtesGSM+TbigIR/aIw+t4WE=; b=narjUhujJhGvJF+O8/Es9fykfo2Ih74waRdUs+FGwgfEb96Kb8ud6SUJxd xamZYASDv/49e52x87q8KE19SrOQ+5bnZyUCdEczWBOyyqtV4jDZYOX/Z3Rj 9jcIYU8gnw; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: roll@ietf.org, roll-bounces@ietf.org, Ted.Humpal@jci.com Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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="===============1219550906==" 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. --===============1219550906== Content-type: multipart/alternative; boundary="B_3301381029_24659676" > 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_3301381029_24659676 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Jerry, You=B9re absolutely right that the requirements spelled out in the Building Automation documents MUST and will be taken into account, and I=B9m sure that Phil is planning to look at it once it will become a WG document. For the time being, there is no need to postpone the WG adoption. Cheers, JP. On 8/11/08 9:36 PM, "Jerald.P.Martocci@jci.com" wrote: >=20 > The survey as given in Dublin only included the Home, Industrial and Urb= an > routing requirements. I presume this was because the Commercial Building > requirements were not available until early July. I would like the analy= sis > to include the commercial building requirements. >=20 > I also think that 'latency' should be a column on the decision matrix on = page > 9 of the document. Embedded real-time systems are mission critical (e.g.= Fire > Alarming) where latency is a prime discriminator of the protocol used. T= he > routing algorithms are subject to this latency for example when a new pat= h > must be discovered while the packet is in transit. >=20 > I would like to postpone the adoption of the document as a ROLL WG docume= nt > until these two items have been addressed. >=20 >=20 > Regards,=20 >=20 > Jerry Martocci=20 >=20 >=20 >=20 >=20 >=20 > JP Vasseur > Sent by: roll-bounces@ietf.org 08/09/2008 03:50 PM > To=20 > =20 > cc > Subject=20 > [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WG > document=20 >=20 >=20 >=20 >=20 > Dear WG, >=20 > There was a good consensus to adopt draft-levis-roll-protocols-survey as = a > ROLL WG document during the ROLL WG meeting in Dublin but as usual we nee= d to > confirm on the mailing list. >=20 > Are you in favor/opposed adopting draft-levis-roll-protocols-survey > (http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02= .txt > > ) as a ROLL WG document ? >=20 > Note that the draft has been slightly updated to align it with the > presentation that was made during the meeting. >=20 > Thanks. >=20 > JP. _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 --B_3301381029_24659676 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL W= G document Hi Jerry,

You’re absolutely right that the requirements spelled out in the Buil= ding Automation documents MUST and will be taken into account, and I’m= sure that Phil is planning to look at it once it will become a WG document.= For the time being, there is no need to postpone the WG adoption.

Cheers,

JP.

On 8/11/08 9:36 PM, "Jerald.P.Mart= occi@jci.com" <Jerald.P.Mart= occi@jci.com> wrote:

<= SPAN STYLE=3D'font-size:13pt'>
The survey as given in Dublin only included the Home,  Industrial and = Urban routing requirements.  I presume this was because the Commercial = Building requirements were not available until early July.  I would lik= e the analysis to include the commercial building requirements.  

I also think that 'latency' should be a column on the decision matrix on pa= ge 9 of the document.  Embedded real-time systems are mission critical = (e.g. Fire Alarming) where latency is a prime discriminator of the protocol = used.  The routing algorithms are subject to this latency for example w= hen a new path must be discovered while the packet is in transit.

I would like to postpone the adoption of the document as a ROLL WG document= until these two items have been addressed.


Regards,

Jerry Martocci





JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org 08/09/2008 03:5= 0 PM=20

To

<roll@ietf.org>=20

cc
Subject

[Roll] Adoption of draft-levis-roll-protocols-survey as a R= OLL WG        document




Dear WG,

There was a good consensus to adopt draft-levis-roll-protocols-survey as a = ROLL WG document during the ROLL WG meeting in Dublin but as usual we need t= o confirm on the mailing list.

Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.ietf.org/internet-drafts/draft-levi= s-roll-protocols-survey-02.txt <http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey= -02.txt> ) as a ROLL WG document ?

Note that the draft has been slightly updated to align it with the presenta= tion that was made during the meeting.

Thanks.

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


--B_3301381029_24659676-- --===============1219550906== 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 --===============1219550906==-- From roll-bounces@ietf.org Tue Aug 12 06:09: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 170883A6A28; Tue, 12 Aug 2008 06:09: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 5BFBB3A6A28; Tue, 12 Aug 2008 06:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, 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 slBKMiplTu6Y; Tue, 12 Aug 2008 06:09:13 -0700 (PDT) Received: from psmtp.com (exprod8ob119.obsmtp.com [64.18.3.37]) by core3.amsl.com (Postfix) with ESMTP id 327223A6886; Tue, 12 Aug 2008 06:09:12 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob119.postini.com ([64.18.7.12]) with SMTP; Tue, 12 Aug 2008 06:08:27 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2008081208091051-97264 ; Tue, 12 Aug 2008 08:09:10 -0500 In-Reply-To: MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 12 Aug 2008 08:08:43 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 08/12/2008 08:08:34 AM, Serialize complete at 08/12/2008 08:08:34 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/12/2008 08:09:10 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/12/2008 08:09:51 AM, Serialize complete at 08/12/2008 08:09:51 AM Cc: roll@ietf.org, roll-bounces@ietf.org, Ted.Humpal@jci.com Subject: Re: [Roll] Adoption of draft-levis-roll-protocols-survey 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="===============1581332095==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multipart message in MIME format. --===============1581332095== Content-Type: multipart/alternative; boundary="=_alternative 00483669862574A3_=" This is a multipart message in MIME format. --=_alternative 00483669862574A3_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Agreed. I don't want to hold anything up. Just want to make sure we're=20 considering all application domains. JP Vasseur =20 08/12/2008 03:17 AM To cc , , Subject Re: [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WG=20 document Hi Jerry, You?re absolutely right that the requirements spelled out in the Building=20 Automation documents MUST and will be taken into account, and I?m sure=20 that Phil is planning to look at it once it will become a WG document. For = the time being, there is no need to postpone the WG adoption. Cheers, JP. On 8/11/08 9:36 PM, "Jerald.P.Martocci@jci.com" wrote: The survey as given in Dublin only included the Home, Industrial and=20 Urban routing requirements. I presume this was because the Commercial=20 Building requirements were not available until early July. I would like=20 the analysis to include the commercial building requirements.=20 I also think that 'latency' should be a column on the decision matrix on=20 page 9 of the document. Embedded real-time systems are mission critical=20 (e.g. Fire Alarming) where latency is a prime discriminator of the=20 protocol used. The routing algorithms are subject to this latency for=20 example when a new path must be discovered while the packet is in transit. = I would like to postpone the adoption of the document as a ROLL WG=20 document until these two items have been addressed.=20 Regards,=20 Jerry Martocci=20 JP Vasseur =20 Sent by: roll-bounces@ietf.org 08/09/2008 03:50 PM=20 To=20 =20 cc Subject=20 [Roll] Adoption of draft-levis-roll-protocols-survey as a ROLL WG document = Dear WG, There was a good consensus to adopt draft-levis-roll-protocols-survey as a = ROLL WG document during the ROLL WG meeting in Dublin but as usual we need = to confirm on the mailing list. Are you in favor/opposed adopting draft-levis-roll-protocols-survey ( http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.tx= t=20 < http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt > ) as a ROLL WG document ? Note that the draft has been slightly updated to align it with the=20 presentation that was made during the meeting. Thanks. JP. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 00483669862574A3_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Agreed.  I don't want to hold a= nything up.   Just want to make sure we're considering all application domains= .




JP Vasseur <jvasse= ur@cisco.com>

08/12/2008 03:17 AM

To
<Jerald.P.Martocci@jci.com>
cc
<roll@ietf.org>, <roll-boun= ces@ietf.org>, <Ted.Humpal@jci.com>
Subject
Re: [Roll] Adoption of draft-levis-r= oll-protocols-survey as a ROLL WG document





Hi Jerry,

You’re absolutely right that the requirements spelled out in the Buil= ding Automation documents MUST and will be taken into account, and I’m sure that Phil is planning to look at it once it will become a WG document. For the time being, there is no need to postpone the WG adoption.

Cheers,

JP.

On 8/11/08 9:36 PM, "Jerald.P.Martocci@jci.com" <Jerald.P.Martocci@jci.com> wrote:

The survey as given in Dublin only included the Home,  Industrial and Urban routing requirements.  I presume this was because the Commer= cial Building requirements were not available until early July.  I would like the analysis to include the commercial building requirements.  
I also think that 'latency' should be a column on the decision matrix on page 9 of the document.  Embedded real-time systems are mission critic= al (e.g. Fire Alarming) where latency is a prime discriminator of the protocol used.  The routing algorithms are subject to this latency for example when a new path must be discovered while the packet is in transit.

I would like to postpone the adoption of the document as a ROLL WG document until these two items have been addressed.


Regards,

Jerry Martocci





JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org 08/09/2008 03:50 PM

To

<roll@ietf.org>

cc
Subject

[Roll] Adoption of draft-levis-roll-prot= ocols-survey as a ROLL WG        document




Dear WG,

There was a good consensus to adopt draft-levis-roll-protocols-survey as a ROLL WG document during the ROLL WG meeting in Dublin but as usual we need to confirm on the mailing list.

Are you in favor/opposed adopting draft-levis-roll-protocols-survey (http://www.iet= f.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt <ht= tp://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-02.txt<= /u>> ) as a ROLL WG document ?

Note that the draft has been slightly updated to align it with the presenta= tion that was made during the meeting.

Thanks.

JP. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
Roll mailing list Roll@ietf.org
https://www.ietf.org/mailman/listinf= o/roll

--=_alternative 00483669862574A3_=-- --===============1581332095== 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 --===============1581332095==-- From roll-bounces@ietf.org Thu Aug 14 08:33:44 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 9B8483A6DA2; Thu, 14 Aug 2008 08:33:44 -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 580003A681B for ; Thu, 14 Aug 2008 08:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.365 X-Spam-Level: X-Spam-Status: No, score=-5.365 tagged_above=-999 required=5 tests=[AWL=-0.163, 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 gnUT7B-ESmVb for ; Thu, 14 Aug 2008 08:33:42 -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 1B4363A6D96 for ; Thu, 14 Aug 2008 08:33:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,210,1217808000"; d="scan'208,217";a="17501427" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Aug 2008 15:33:14 +0000 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 m7EFXEQG029738; Thu, 14 Aug 2008 11:33:14 -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 m7EFXDG4027830; Thu, 14 Aug 2008 15:33: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, 14 Aug 2008 11:33:14 -0400 Received: from 10.61.97.72 ([10.61.97.72]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 14 Aug 2008 15:33:13 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 14 Aug 2008 17:33:13 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: New ROLL WG Thread-Index: Acj+IxBAfLZg/irSY0moiiKILRqf3Q== Mime-version: 1.0 X-OriginalArrivalTime: 14 Aug 2008 15:33:14.0067 (UTC) FILETIME=[10E2D230:01C8FE23] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1037; t=1218727994; x=1219591994; 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:=20New=20ROLL=20WG |Sender:=20 |To:=20; bh=NCNL+WfZfA7uptXg6yU1Go7jSoA44D/zKXHfdnmJcRA=; b=F+C/VrmhQwRx+ABKqnmqZLGaG663CZngnE196CFJWavqw5K3jOQBAX4bmq L1MeU/3PfXEdCrcsMLi9XkzhfpD6afjlBli031RwkoSqtoCSMRxsZHmVDtvR 0N7HuM3sF2; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Roll] New ROLL WG 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="===============0555803419==" 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. --===============0555803419== Content-type: multipart/alternative; boundary="B_3301579993_5978558" > 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_3301579993_5978558 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, Considering the good support, draft-levis-roll-protocols-survey is adopted as a ROLL WG document. Authors, please resubmit as draft-ietf-roll-protocols-survey-00.txt with no change other than the name and date. Thanks. JP. --B_3301579993_5978558 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable New ROLL WG Dear WG,

Considering the good support, draft-levis-roll-protocols-survey is adopted = as a ROLL WG document. Authors, please resubmit as draft-ietf-roll-protocols= -survey-00.txt with no change other than the name and date.

Thanks.

JP. --B_3301579993_5978558-- --===============0555803419== 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 --===============0555803419==-- From roll-bounces@ietf.org Thu Aug 14 10:56:25 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 F09AC3A6A2C; Thu, 14 Aug 2008 10:56:24 -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 9B69B3A6921 for ; Thu, 14 Aug 2008 10:56:23 -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 MBt2yJAXLM3w for ; Thu, 14 Aug 2008 10:56:22 -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 5461B3A6A88 for ; Thu, 14 Aug 2008 10:56:22 -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 1KTh3S-0001NX-QE; Thu, 14 Aug 2008 10:56:10 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <8DF8F8A9-3E8D-42DF-9A68-30DFC1DA44CA@cs.stanford.edu> From: Philip Levis Date: Thu, 14 Aug 2008 10:55:09 -0700 To: JP Vasseur X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: c6b7461a7773f457175e025605fe13fe Cc: roll@ietf.org Subject: Re: [Roll] New ROLL WG 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Aug 14, 2008, at 8:33 AM, JP Vasseur wrote: > Dear WG, > > Considering the good support, draft-levis-roll-protocols-survey is > adopted as a ROLL WG document. Authors, please resubmit as draft- > ietf-roll-protocols-survey-00.txt with no change other than the > name and date. OK, will do tomorrow. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Aug 21 12:27:27 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 42A5C3A6996; Thu, 21 Aug 2008 12:27:27 -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 2EE063A67C0 for ; Thu, 21 Aug 2008 12:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.371 X-Spam-Level: X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[AWL=-0.169, 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 vDmzihELQrXZ for ; Thu, 21 Aug 2008 12:27:03 -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 A247928C11E for ; Thu, 21 Aug 2008 12:26:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,247,1217808000"; d="scan'208,217";a="77250671" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 21 Aug 2008 19:26:50 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7LJQoXZ031276 for ; Thu, 21 Aug 2008 12:26:50 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m7LJQZ0C011584 for ; Thu, 21 Aug 2008 19:26:49 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, 21 Aug 2008 15:26:49 -0400 Received: from 10.61.97.215 ([10.61.97.215]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Aug 2008 19:26:49 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 21 Aug 2008 21:26:48 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: Aligning Terminology across ROLL Routing Requirements Documents Thread-Index: AckDw9q7L5M0IvVf8EGd9qOQInzFGg== Mime-version: 1.0 X-OriginalArrivalTime: 21 Aug 2008 19:26:49.0469 (UTC) FILETIME=[DB9BB2D0:01C903C3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1166; t=1219346810; x=1220210810; 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:=20Aligning=20Terminology=20across=20ROLL=20Routin g=20Requirements=20Documents |Sender:=20; bh=fVw6DoQgt16zEIUllqyungxut2xNJiNH5eJTAiEIO6k=; b=MSa1rNBrkLLG4yr2f3//opih/ocuQkl+5TGVS0I7pUhk0ddym96QqRV6Cm NO7GGUOttKgOx8GzdTqvxe2B+Z5y7WKpkQzDLtrcqfMaTyiHpfVuyrQ1GPiU NMKrfJl7LP; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Roll] Aligning Terminology across ROLL Routing 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: multipart/mixed; boundary="===============1682140885==" 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. --===============1682140885== Content-type: multipart/alternative; boundary="B_3302198808_43104876" > 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_3302198808_43104876 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, Since there are quite a few inconsistencies between the terms used across the various ROLL WG ID, I will try to quickly prepare a short ID on Terminology that could be referenced in all ROLL documents. Let me know if you have comments. Thanks. JP. --B_3302198808_43104876 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Aligning Terminology across ROLL Routing Requirements Documents</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:13pt= '>Dear WG,<BR> <BR> Since there are quite a few inconsistencies between the terms used across t= he various ROLL WG ID, I will try to quickly prepare a short ID on Terminolo= gy that could be referenced in all ROLL documents. <BR> <BR> Let me know if you have comments.<BR> <BR> Thanks.<BR> <BR> JP.</SPAN></FONT> </BODY> </HTML> --B_3302198808_43104876-- --===============1682140885== 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 --===============1682140885==-- From roll-bounces@ietf.org Thu Aug 21 12:29:15 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 BC77A3A6831; Thu, 21 Aug 2008 12:29:15 -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 A773E3A6831 for <roll@core3.amsl.com>; Thu, 21 Aug 2008 12:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.945 X-Spam-Level: X-Spam-Status: No, score=-4.945 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_50=0.001, GB_I_LETTER=-2, 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 XHo+BKPZweRp for <roll@core3.amsl.com>; Thu, 21 Aug 2008 12:28:53 -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 25FD03A677E for <roll@ietf.org>; Thu, 21 Aug 2008 12:28:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,247,1217808000"; d="scan'208,217";a="18331253" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Aug 2008 19:28:57 +0000 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 m7LJSv4J012521; Thu, 21 Aug 2008 15:28:57 -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 m7LJSvbI001666; Thu, 21 Aug 2008 19:28:57 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, 21 Aug 2008 15:28:57 -0400 Received: from 10.61.97.215 ([10.61.97.215]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Aug 2008 19:28:56 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 21 Aug 2008 21:28:54 +0200 From: JP Vasseur <jvasseur@cisco.com> To: Mischa Dohler <mischa.dohler@cttc.es>, Tim Winter <tim.winter@ekasystems.com>, <thomas.watteyne@orange-ftgroup.com>, <christian.jacquenet@orange-ftgroup.com>, <giyyarpuram.madhusudan@orange-ftgroup.com>, <gabriel.chegaray@orange-ftgroup.com>, <Dominique.Barthel@orange-ftgroup.com>, <roll@ietf.org> Message-ID: <C4D38E96.4FB46%jvasseur@cisco.com> Thread-Topic: Review of draft-ietf-roll-urban-routing-reqs-01 Thread-Index: AckDxCXVl9keGlV0jkulakQaFFRIHQ== Mime-version: 1.0 X-OriginalArrivalTime: 21 Aug 2008 19:28:57.0135 (UTC) FILETIME=[27B3FBF0:01C903C4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=42268; t=1219346937; x=1220210937; 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<jvasseur@cisco.com> |Subject:=20Review=20of=20draft-ietf-roll-urban-routing-req s-01 |Sender:=20 |To:=20Mischa=20Dohler=20<mischa.dohler@cttc.es>,=0A=20=20= 20=20=20=20=20=20Tim=20Winter=20<tim.winter@ekasystems.com>, =0A=20=20=20=20=20=20=20=20<thomas.watteyne@orange-ftgroup.c om>,=0A=20=20=20=20=20=20=20=20<christian.jacquenet@orange-f tgroup.com>,=0A=20=20=20=20=20=20=20=20<giyyarpuram.madhusud an@orange-ftgroup.com>,=0A=20=20=20=20=20=20=20=20<gabriel.c hegaray@orange-ftgroup.com>,=0A=20=20=20=20=20=20=20=20<Domi nique.Barthel@orange-ftgroup.com>,=20<roll@ietf.org>; bh=gd8z5KJaZnBvDCPTbA0jaB/l/CEHdKw6QuuBGrPNgps=; b=XiZDdtxjPn1Jm0vI3+pcftGYGnB4z4Gqv79FaeVIcGAWFKfEfp7YLO/rzM CVuAvXKACMfBYrhasNgjHqvlmA/eRNSRSTNgsSLo6eNpB2DJFj57bteisZIW lBtOqZ4jbC; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "David E. Culler" <culler@cs.berkeley.edu> Subject: [Roll] Review of draft-ietf-roll-urban-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 <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="===============0990667676==" 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. --===============0990667676== Content-type: multipart/alternative; boundary="B_3302198935_43092083" > 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_3302198935_43092083 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Dear WG, As discussed in Dublin, the plan is to try to Last Call all the application-specific routing requirements document before end of September. Thus, please provide your detailed comments as soon as possible. Let me start my co-chair review with the Urban WSNs Routing Requirements, since (with the exception of the Mobility issue) the document is fairly stable. Comments are not by order of importance by in chronological order. Abstract ####### s/ for a wireless ROLL solution to be useful the protocol(s) ought to be energy-efficient, scalable, and autonomous/ the routing solution ought to b= e energy-efficient, scalable and autonomous. JP> You may want to use a different word than =B3Autonomous=B2. Do you refer to the =B3self configuration=B2 property ? Section 1 ####### * =B3Section 6 discusses the routing requirements for networks comprising such constrained devices in a U-LLN environment. These requirements may be overlapping requirements derived from other application- specific requirements documents or as listed in [I-D.culler-rl2n-routing-reqs].=B2 JP> Please remove this reference (ID abandoned) and insert reference to http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-02.tx= t ,=20 http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-01.t= x t and=20 http://www.ietf.org/internet-drafts/draft-martocci-roll-commercial-routing-= r eqs-00.txt. * s/ Section 7 provides an overview of security considerations/ Section 7 provides an overview of routing security considerations Section 2 ######## * S/ ROLL: Routing over Low power and Lossy networks/ ROLL: Routing Over Lo= w power and Lossy networks * Schedule: An agreed execution, wake-up, transmission, reception, etc., time-table between two or more field devices. The definition is a little bit too vague. If used in the generic sense, no need to add it to the terminology section. Otherwise, it ought to be more specific. Section 3.1.1 ########### * S/ pre- planned location/ pre-planned location * What you refer to as a repeater is in fact a router. What I would suggest here is to reword this paragraph to indicate that some nodes are simple routers whereas other nodes are routers and also perform sensing/actuating task. Insert this paragraph after the Actuators and Sensors paragraphs. * =B3Actuators may generally be mobile but are likely to be static in the majority of near-future roll-outs=B2: seems a bit contradictory. Don=B9t you want to simply say that in a near-future the majority will be static? * =B3Similar to the access points, actuator nodes do not suffer from any long-term resource constraints.=B2 what about battery-operated actuators ? Section 3.1.4 ########### * =B3pollution data, such as polluting gases (SO2, NOx, CO, Ozone), heavy metals (e.g. Mercury), pH, radioactivity, etc;=B2 =3D> please expand acronym when first used. * =B3These meters will be capable of advanced sensing functionalities such as measuring quality of service, providing granular interval data, or automating the detection of alarm conditions.=B2 You may want to more accurately define the term =B3quality of service=B2 since as you know, we used that term of other purposes in IETF documents. * In addition they may be capable of advanced interactive functionalities such as remote service disconnect or remote demand reset.=B2 =3D> in this case, they are also actin= g as actuators. Section 3.2=20 ######### * s/ between one other/between each other * =B3The network MUST be capable of supporting the organization of a large number of sensing nodes into regions containing on the order of 10^2 to 10^4 sensing nodes each.=B2 JP> Thanks to make this =B3MUST=B2 routing-specific and move it to the requirements section. Section 3.3 ######### * RFID: expand acronym (Radio Frequency IDentification) and add to the terminology section * s/battery-powered nodes/battery powered nodes =B3Sensor nodes are capable of forwarding data.=B2 In other words, they can act as routers. No need to repeat this here. Section 3.4 ######### * =B32. packet errors due to medium access control;=B2 JP> It is not really =B3packet error=B2 here. * Some available protocols may cause packets of neighbouring nodes to collide and hence cause a link outage.=B2 JP> You may want to be more specifi= c =B3Some=B2 ? * =B3if ISM bands are to be used. For instance, if the 2.4GHz ISM band is used to facilitate communication between U-LLN nodes, then heavily loaded WLAN hot-spots become a detrimental performance factor jeopardizing the functioning of the U-LLN.=B2 JP> Please expand acronym when first used and add to the terminology sectio= n (ISM, WLAN, ...) * Don=B9t you want to say a few words about the varying BER leading to potentially even higher packet error loss ratio? Section 4.1 ######### * =B3Pre-programmed MAC=B2: expand acronym * =B3the autonomous organization=B2 =3D> self-organizing? * =B3For example, nodes in urban sensor nodes SHOULD be able to:=B2 =3D> Several of the requirements that follow are nor routing specific. You may either want to change the SHOULD for a =B3should=B2 or just focus on the routing aspects and move them to the routing requirements section. * =B3o Dynamically compute, select and possibly optimize the (multiple) path(s) that will be used by the participating devices to forward the traffic towards the actuators and/or the access point according to the service-specific and traffic-specific QoS, traffic engineering and security policies that will have to be enforced at the scale of a routing domain (that is, a set of networking devices administered by a globally unique entity), or a region of such domain (e.g. a metropolitan area composed of clusters of sensors).=B2 JP> You list important and stringent requirements here. Do you really need = a routing algorithms capable of computing a path on a per QoS/service specific/... Basis ? Section 4.2 ######### * =B3After the initialization phase and possibly some operational time, new nodes may be injected into the network as well as existing nodes removed from the network. The former might be because a removed node is replaced or denser readings/actuations are needed or routing protocols report connectivity problems. =B3 JP> Just to avoid any mis-interpretation when referring to routing problem, you mean that it may be desirable to inject to node because connectivity is not sufficient (lack of enough redundant path, ...) and not because of a routing issue per say. * =B3Differentiation SHOULD be made between node disappearance, where the node disappears without prior notification, and user or node-initiated disassociation ("phased-out"), where the node has enough time to inform the network about its removal.=B2 JP> Again this is not a routing requirement. Unless you refer to the abilit= y for the routing protocol to advertise to the rest of the network that it will be removed in order for the other node to re-compute their path and avoid traffic disruption (e.g. Similarly to what we do with the ISIS overload bit for example.) Is it what you mean ? If so, please clarify and move the routing requirement (SHOULD in capital letter to the routing requirement section). * =B3The protocol(s) hence SHOULD support the pinpointing of problematic routing areas=B2 JP> Could you clarify what you mean by =B3pinpointing=B2 since it could be interpreted in many ways? * The following section also requires some clarification =AD you wrote: =B3Furthermore, to inform the access point(s) of the node's arrival and association with the network as well as freshly associated nodes about packet forwarding schedules, roles, etc, appropriate (link state) updating mechanisms SHOULD be supported.=B2 JP> Are you explicitly requiring a Link State routing protocol or a routing protocol that provides information about link states or ... ? Note that a requirement document should stay solution agnostic and stay focus on the requirement. Is you requirement that any node needs to have visibility on other node characteristics with no attempt of aggregation? Section 4.3 ######### * =B3The protocol(s) hence MUST support a large number of highly directional unicast flows from the sensing nodes or sensing clusters towards the access point or highly directed multicast or anycast flows from the nodes towards multiple access points.=B2 JP> I think that what you mean is that the routing protocol MUST be optimized for Multipoint-to-Point traffic patterns (from sensors/actuators to Sink). As written, it is not clear whether you refer to it as a routing requirement ? This in fact what you wrote in section 6.5: =B3To this end, the routing protocol(s) SHOULD support and utilize the fact of highly directed traffic flow to facilitate scalability and parameter constrained routing.=B2 * s/ More generally, entire routing areas may be avoided at e.g. night but heavily used during the day when nodes are scavenging from sunlight/ More generally, entire routing areas may be avoided (e.g. at night) but heavily used during the day when nodes are scavenging from sunlight. JP> Doesn=B9t this translate to the requirement for time-based routing (some form of policy routing) ? Section 4.4 ######### =B3However, they are not very stringent where latencies SHOULD simply be sufficiently smaller than typical reporting intervals=B2 JP> This is certainly true but not a routing requirement but a data plane requirement unless you refer to the ability to support QoS aware routing where each node may want to be able to compute different paths depending on the traffic requirements? * Move =B3U-LLN network devices SHOULD support unicast and multicast routing capabilities=B2 to the routing requirement section. You may want to leave the sentence here (without a SHOULD). * You use the term =B3anycast=B2 that has been discussed in the past, in particular in the context of the Home routing requirement document. I would suggest to define this term in the document, refer to RFC4291 or RFC1546, ... Section 4.5 ######### * =B3An alarm is likely being registered by a plurality of sensing nodes where the delivery of a single alert message with its location of origin suffices in most cases.=B2 Then you provide the example of toxic gas level. This is one example where it might be desirable not to perform data aggregation/fusion and get multiple copies of the same message from different source to perform =B3triangulation=B2 and better localize the incident. * =B3Routing within urban sensor networks SHOULD require the U-LLN nodes to dynamically compute, select and install different paths towards a same destination, depending on the nature of the traffic. From this perspective, such nodes SHOULD inspect the contents of traffic payload for making routing and forwarding decisions: JP> This clarifies my previous question; you do refer to ability to compute different paths (with different characteristic). Note that the path selection process performed by the sender and potentially routers along the path is not strictly speaking a routing requirement. Move this requirement to the requirement section. * =B3for example, the analysis of the traffic payload SHOULD be derived into aggregation capabilities for the sake of forwarding efficiency.=B2 JP> Can you clarify what you mean here? * =B3Delays and latencies are important; however, again, deliveries within seconds SHOULD suffice in most of the cases.=B2 JP> Clearly not a routing requirement! Section 5 ######## * =B3The network SHOULD take into consideration that different application traffic may require different priorities when traversing the network, and that some traffic may be more sensitive to latency.=B2 JP> If by priorities you mean different routes with different characteristics then this is fine and already covered. If you refer to packet marking to provide different QoS in the data plane, this is not a routing requirement. * =B3An U-LLN SHOULD support occasional large scale traffic flows from sensing nodes to access points, such as system-wide alerts. =B3 and =B3A nod= e MUST be able to send its own alerts toward an access point while continuing to forward traffic on behalf of other devices who are also experiencing an alert condition. The network MUST be able to manage this sudden large traffic flow.=B2 JP> Not routing requirements. Unless ... You require the ability to compute multiple paths and use all of them (symmetrical or asymmetrical routing ???= ) to spread out the traffic and limit network delays ? * You make an interesting reference to Smart Grid and DR/DSM. That said, yo= u wrote =B3The network SHOULD support internetworking, while giving attention t= o security implications of interfacing, for example, a home network with a utility U-LLN.=B2 JP> Don=B9t you mean that the routing protocol must be able to potentially interact via potential route redistribution with other routing protocol use= d in the Internet, should these two protocols not be identical ? =20 Section 6 ######### * S/Current urban roll-outs are composed of sometimes more than a hundred nodes/ Current urban roll-outs are composed of sometimes more than one hundred nodes * =B3 The routing protocols(s) SHOULD support the organization of a large number of nodes into regions of to-be-specified size.=B2 JP> It will be difficult (or too easy ;-)) to be compliant with that SHOULD with a to-be-specified size. Or did you mean =B3configurable=B2 ? * =B3To this end, the routing protocol(s) MUST support parameter constrained routing, where examples of such parameters (CPU, memory size, battery level, etc.) have been given in the previous paragraph.=B2 JP> Please use the term =B3node constrained based routing=B2 * =B3For the latter, the protocol(s) MUST support multi- and any-cast addressing. The protocol(s) SHOULD also support the formation and identification of groups of field devices in the network.=B2 JP> You may want to more accurately define the term =B3anycast=B2 * =B3 To mandate fully interoperable implementations, the routing protocol(s) proposed in U-LLN MUST support different devices and underlying technologies without compromising the operability and energy efficiency of the network.=B2 JP> This requires clarification here. Do you mean that the routing protocol MUST support node constrained based routing? If so, it is already stated above. The support of different L1/L2 is a given (route over). * Section 6.8, as written, is not related to routing but data plane. Let me be more specific: * =B3To this end, the routing protocol(s) SHOULD support minimum latency for alert reporting and time-critical data queries.=B2 JP> The support of minimum latency path (data plane !) or the support for different metric path (control plane) ? * =B3For regular data reporting, it SHOULD support latencies not exceeding a fraction of the smallest reporting interval. =B3 JP> Not a routing requirement. Even if you are referring to a bound on the total path metric (the metric reflecting the delay in this case), this is a= n implementation issue. * =B3Due to the different latency requirements, the routing protocol(s) SHOUL= D support the ability of dealing with different latency requirements. The routing protocol(s) SHOULD also support the ability to route according to different metrics (one of which could e.g. be latency).=B2 JP> yes these are routing requirements although I would suggest to remove the first sentence, the requirement being captured in the second sentence. Section 7 ######### * =B3As every network, U-LLNs are exposed to security threats that MUST be addressed.=B2 JP> You cannot put a MUST here unless you list the routing security threats= . * s/ potential security threats/ potential routing security threats =3D> JP> Please use the term =B3routing security=B2 in place of =B3security=B2 throughout th= e section.=20 * =B3U-LLN networks SHOULD support mechanisms to preserve the confidentiality of the traffic that they forward. The U-LLN network SHOULD NOT prevent an application from employing additional confidentiality mechanisms.=B2 JP> I do agree with the requirement but this is not a routing requirement. Could you focus on the routing security issues ? Or are you referring to th= e routing traffic confidentiality ? This is what you do right after: =B3 The U-LLN MUST be protected against attempts to inject false or modified packets. For example, an attacker SHOULD be prevented from manipulating or disabling the routing function by compromising routing update messages. Moreover, it SHOULD NOT be possible to coerce the network into routing packets which have been modified in transit. To this end the routing protocol(s) MUST support message integrity.=B2 JP> I do not see any reference to the type of routing attacks that could be performed on such networks because of the typical P2MP traffic pattern, extensive use of wireless links, ... JP> What I would suggest is to re-focus on the routing security issues with the Security expert that will get appointed. Reference section ############### The current reference section reads: 11.2. Informative References [I-D.brandt-roll-home-routing-reqs] Brandt, A., "Home Automation Routing Requirement in Low Power and Lossy Networks", draft-brandt-roll-home-routing-reqs-01 (work in progress), May 2008. JP> Please update to draft-ietf-roll-home-routing-reqs and add the referenc= e to draft-ietf-roll-indus-routing-reqs [I-D.culler-rl2n-routing-reqs] Vasseur, J. and D. Cullerot, "Routing Requirements for Low Power And Lossy Networks", draft-culler-rl2n-routing-reqs-01 (work in progress), July 2007. JP> This one can be removed. Last comment: please check that you expand acronyms when first used. Thanks. JP. --B_3302198935_43092083 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Review of draft-ietf-roll-urban-routing-reqs-01 Dear WG,

As discussed in Dublin, the plan is to try to Last Call all the application= -specific routing requirements document before end of September.
Thus, please provide your detailed comments as soon as possible.

Let me start my co-chair review with the Urban WSNs Routing Requirements, s= ince (with the exception of the Mobility issue) the document is fairly stabl= e. Comments are not by order of importance by in chronological order.

Abstract
#######
s/ for a wireless ROLL solution to be useful the protocol(s) ought to be en= ergy-efficient, scalable, and autonomous/ the routing solution ought to be e= nergy-efficient, scalable and autonomous.

JP> You may want to use a different word than “Autonomous”. = Do you refer to the “self configuration” property ?

Section 1
#######
* “Section 6 discusses the routing requirements for networks comprisi= ng
   such constrained devices in a U-LLN environment.  Th= ese requirements
   may be overlapping requirements derived from other applic= ation-
   specific requirements documents or as listed in
   [I-D.culler-rl2n-routing-reqs].”

JP> Please remove this reference (ID abandoned) and insert reference to = http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-= reqs-02.txt, http://www.ietf.org/internet-drafts/draft-ietf-= roll-indus-routing-reqs-01.txt and http://www.ietf.= org/internet-drafts/draft-martocci-roll-commercial-routing-reqs-00.txt.<= BR>
* s/ Section 7 provides an overview of security considerations/ Section 7 p= rovides an overview of routing security considerations

Section 2
########

* S/ ROLL: Routing over Low power and Lossy networks/ ROLL: Routing Over Lo= w power and Lossy networks

* Schedule:  An agreed execution, wake-up, transmission, reception,          etc., time-table betw= een two or more field devices.
The definition is a little bit too vague. If used in the generic sense, no = need to add it to the terminology section. Otherwise, it ought to be more sp= ecific.

Section 3.1.1
###########
* S/ pre- planned location/ pre-planned location

* What you refer to as a repeater is in fact a router. What I would suggest= here is to reword this paragraph to indicate that some nodes are simple rou= ters whereas other nodes are routers and also perform sensing/actuating task= . Insert this paragraph after the Actuators and Sensors paragraphs.

* “Actuators may generally be mobile but are likely to be static in t= he majority of near-future roll-outs”: seems a bit contradictory. Don&= #8217;t you want to simply say that in a near-future the majority will be st= atic?

* “Similar to the access points, actuator nodes do not suffer from an= y long-term resource constraints.” what about battery-operated actuato= rs ?

Section 3.1.4
###########
* “pollution data, such as polluting gases (SO2, NOx, CO, Ozone),
 heavy metals (e.g.  Mercury), pH, radioactivity, etc;” =3D&g= t; please expand acronym when first used.

* “These meters will be capable of
   advanced sensing functionalities such as measuring qualit= y of
   service, providing granular interval data, or automating = the
   detection of alarm conditions.”
You may want to more accurately define the term “quality of service&#= 8221; since as you know, we used that term of other purposes in IETF documen= ts.

* In addition they may be capable of
   advanced interactive functionalities such as remote servi= ce
   disconnect or remote demand reset.” =3D> in this c= ase, they are also acting as actuators.

Section 3.2
#########

* s/ between one other/between each other

* “The network MUST be capable of supporting the organization of
   a large number of sensing nodes into regions containing o= n the order
   of 10^2 to 10^4 sensing nodes each.”
JP> Thanks to make this “MUST” routing-specific and move it = to the requirements section.

Section 3.3
#########

* RFID: expand acronym (Radio Frequency IDentification) and add to the term= inology section

* s/battery-powered nodes/battery powered nodes
“Sensor nodes are capable of forwarding data.” In other words, = they can act as routers. No need to repeat this here.

Section 3.4
#########

* “2.  packet errors due to medium access control;” JP>= It is not really “packet error” here.

* Some available protocols may cause packets of neighbouring nodes to colli= de and hence cause a link outage.” JP> You may want to be more spec= ific “Some” ?

* “if ISM bands are to be used.  For instance, if the 2.4GHz ISM= band is
   used to facilitate communication between U-LLN nodes, the= n heavily
   loaded WLAN hot-spots become a detrimental performance fa= ctor
   jeopardizing the functioning of the U-LLN.”
JP> Please expand acronym when first used and add to the terminology sec= tion (ISM, WLAN, ...)

* Don’t you want to say a few words about the varying BER leading to = potentially even higher packet error loss ratio?

Section 4.1
#########

* “Pre-programmed MAC”: expand acronym

* “the autonomous organization” =3D> self-organizing?

* “For example, nodes in urban sensor nodes SHOULD be able to:”= =3D> Several of the requirements that follow are nor routing specific. You= may either want to change the SHOULD for a “should” or just foc= us on the routing aspects and move them to the routing requirements section.=

* “o  Dynamically compute, select and possibly optimize the (mul= tiple)
      path(s) that will be used by the partic= ipating devices to forward
      the traffic towards the actuators and/o= r the access point
      according to the service-specific and t= raffic-specific QoS,
      traffic engineering and security polici= es that will have to be
      enforced at the scale of a routing doma= in (that is, a set of
      networking devices administered by a gl= obally unique entity), or a
      region of such domain (e.g. a metropoli= tan area composed of
      clusters of sensors).”
JP> You list important and stringent requirements here. Do you really ne= ed a routing algorithms capable of computing a path on a per QoS/service spe= cific/... Basis ?

Section 4.2
#########

* “After the initialization phase and possibly some operational time,=
   new nodes may be injected into the network as well as exi= sting nodes
   removed from the network.  The former might be becau= se a removed node
   is replaced or denser readings/actuations are needed or r= outing
   protocols report connectivity problems. “
JP> Just to avoid any mis-interpretation when referring to routing probl= em, you mean that it may be desirable to inject to node because connectivity= is not sufficient (lack of enough redundant path, ...) and not because of a= routing issue per say.

* “Differentiation
   SHOULD be made between node disappearance, where the node= disappears
   without prior notification, and user or node-initiated di= sassociation
   ("phased-out"), where the node has enough time = to inform the network
   about its removal.”
JP> Again this is not a routing requirement. Unless you refer to the abi= lity for the routing protocol to advertise to the rest of the network that i= t will be removed in order for the other node to re-compute their path and a= void traffic disruption (e.g. Similarly to what we do with the ISIS overload= bit for example.) Is it what you mean ? If so, please clarify and move the = routing requirement (SHOULD in capital letter to the routing requirement sec= tion).

* “The protocol(s) hence SHOULD support the pinpointing of problemati= c routing areas”
JP> Could you clarify what you mean by “pinpointing” since i= t could be interpreted in many ways?  

* The following section also requires some clarification – you wrote:=
“Furthermore, to inform the
   access point(s) of the node's arrival and association wit= h the
   network as well as freshly associated nodes about packet = forwarding
   schedules, roles, etc, appropriate (link state) updating = mechanisms
   SHOULD be supported.”
JP> Are you explicitly requiring a Link State routing protocol or a rout= ing protocol that provides information about link states or ... ?
Note that a requirement document should stay solution agnostic and stay foc= us on the requirement. Is you requirement that any node needs to have visibi= lity on other node characteristics with no attempt of aggregation?

Section 4.3
#########

* “The protocol(s) hence MUST support a large number of highly
   directional unicast flows from the sensing nodes or sensi= ng clusters
   towards the access point or highly directed multicast or = anycast
   flows from the nodes towards multiple access points.̶= 1;
JP> I think that what you mean is that the routing protocol MUST be opti= mized for Multipoint-to-Point traffic patterns (from sensors/actuators to Si= nk). As written, it is not clear whether you refer to it as a routing requir= ement ?
This in fact what you wrote in section 6.5: “To this end, the routing= protocol(s) SHOULD support and utilize the fact of highly directed traffic = flow to facilitate scalability and parameter constrained routing.”

* s/ More generally, entire routing areas may be avoided at e.g. night but = heavily used during the day when nodes are scavenging from sunlight/ More ge= nerally, entire routing areas may be avoided (e.g. at night) but heavily use= d during the day when nodes are scavenging from sunlight.
JP> Doesn’t this translate to the requirement for time-based routi= ng (some form of policy routing) ?

Section 4.4
#########

“However, they are not very stringent where
   latencies SHOULD simply be sufficiently smaller than typi= cal
   reporting intervals”
JP> This is certainly true but not a routing requirement but a data plan= e requirement unless you refer to the ability to support QoS aware routing w= here each node may want to be able to compute different paths depending on t= he traffic requirements?

* Move “U-LLN network devices SHOULD support unicast and multicast ro= uting capabilities” to the routing requirement section. You may want t= o leave the sentence here (without a SHOULD).

* You use the term “anycast” that has been discussed in the pas= t, in particular in the context of the Home routing requirement document. I = would suggest to define this term in the document, refer to RFC4291 or RFC15= 46, ...

Section 4.5
#########

* “An alarm is likely being
   registered by a plurality of sensing nodes where the deli= very of a
   single alert message with its location of origin suffices= in most
   cases.”
Then you provide the example of toxic gas level. This is one example where = it might be desirable not to perform data aggregation/fusion and get multipl= e copies of the same message from different source to perform “triangu= lation” and better localize the incident.

* “Routing within urban sensor networks SHOULD require the U-LLN node= s
   to dynamically compute, select and install different path= s towards a
   same destination, depending on the nature of the traffic.=  From this
   perspective, such nodes SHOULD inspect the contents of tr= affic
   payload for making routing and forwarding decisions:

JP> This clarifies my previous question; you do refer to ability to comp= ute different paths (with different characteristic). Note that the path sele= ction process performed by the sender and potentially routers along the path= is not strictly speaking a routing requirement.
Move this requirement to the requirement section.

* “for example, the analysis of the traffic payload SHOULD be derived= into aggregation
   capabilities for the sake of forwarding efficiency.”= ;
JP> Can you clarify what you mean here?

* “Delays and latencies are
   important; however, again, deliveries within seconds SHOU= LD suffice
   in most of the cases.”
JP> Clearly not a routing requirement!

Section 5
########

* “The network SHOULD take into consideration that different applicat= ion
   traffic may require different priorities when traversing = the network,
   and that some traffic may be more sensitive to latency.&#= 8221;
JP> If by priorities you mean different routes with different characteri= stics then this is fine and already covered. If you refer to packet marking = to provide different QoS in the data plane, this is not a routing requiremen= t.

* “An U-LLN SHOULD support occasional large scale traffic flows from<= BR>    sensing nodes to access points, such as system-wide alert= s. “ and “A node MUST be able to send its own alerts toward an a= ccess
   point while continuing to forward traffic on behalf of ot= her devices
   who are also experiencing an alert condition.  The n= etwork MUST be
   able to manage this sudden large traffic flow.”
JP> Not routing requirements. Unless ... You require the ability to comp= ute multiple paths and use all of them (symmetrical or asymmetrical routing = ???) to spread out the traffic and limit network delays ?

* You make an interesting reference to Smart Grid and DR/DSM. That said, yo= u wrote “The network SHOULD support internetworking, while giving atte= ntion to security implications of interfacing, for example, a home network w= ith a utility U-LLN.”
JP> Don’t you mean that the routing protocol must be able to poten= tially interact via potential route redistribution with other routing protoc= ol used in the Internet, should these two protocols not be identical ?
 

Section 6
#########

* S/Current urban roll-outs are composed of sometimes more than a hundred n= odes/ Current urban roll-outs are composed of sometimes more than one hundre= d nodes

* “ The routing protocols(s) SHOULD support the organization of a lar= ge number of nodes into regions of to-be-specified size.”
JP> It will be difficult (or too easy ;-)) to be compliant with that SHO= ULD with a to-be-specified size. Or did you mean “configurable” = ?

* “To this end, the routing protocol(s) MUST support parameter
   constrained routing, where examples of such parameters (C= PU, memory
   size, battery level, etc.) have been given in the previou= s paragraph.”
JP> Please use the term “node constrained based routing”

* “For the latter, the protocol(s) MUST support multi- and
   any-cast addressing.  The protocol(s) SHOULD also su= pport the
   formation and identification of groups of field devices i= n the
   network.”
JP> You may want to more accurately define the term “anycast”= ;

* “ To mandate fully interoperable implementations, the routing
   protocol(s) proposed in U-LLN MUST support different devi= ces and
   underlying technologies without compromising the operabil= ity and
   energy efficiency of the network.”
JP> This requires clarification here. Do you mean that the routing proto= col MUST support node constrained based routing? If so, it is already stated= above. The support of different L1/L2 is a given (route over).

* Section 6.8, as written, is not related to routing but data plane. Let me= be more specific:

* “To this end, the routing protocol(s) SHOULD support minimum latenc= y
   for alert reporting and time-critical data queries.”= ;
JP> The support of minimum latency path (data plane !) or the support fo= r different metric path (control plane) ?

* “For regular data
   reporting, it SHOULD support latencies not exceeding a fr= action of
   the smallest reporting interval.  “
JP> Not a routing requirement. Even if you are referring to a bound on t= he total path metric (the metric reflecting the delay in this case), this is= an implementation issue.

* “Due to the different latency requirements, the routing protocol(s)= SHOULD support the ability of dealing with different latency requirements. =  The routing protocol(s) SHOULD also support the ability to route accor= ding to different metrics (one of which could e.g. be latency).”
JP> yes these are routing requirements although I would suggest to remov= e the first sentence, the requirement being captured in the second sentence.=

Section 7
#########

* “As every network, U-LLNs are exposed to security threats that MUST= be addressed.”
JP> You cannot put a MUST here unless you list the routing security thre= ats.

* s/ potential security threats/ potential routing security threats =3D> J= P> Please use the term “routing security” in place of “= security” throughout the section.

* “U-LLN networks SHOULD support mechanisms to preserve the
   confidentiality of the traffic that they forward.  T= he U-LLN network
   SHOULD NOT prevent an application from employing addition= al
   confidentiality mechanisms.”
JP> I do agree with the requirement but this is not a routing requiremen= t. Could you focus on the routing security issues ? Or are you referring to = the routing traffic confidentiality ? This is what you do right after:
“ The U-LLN MUST be protected against attempts to inject false or
   modified packets.  For example, an attacker SHOULD b= e prevented from
   manipulating or disabling the routing function by comprom= ising
   routing update messages.  Moreover, it SHOULD NOT be= possible to
   coerce the network into routing packets which have been m= odified in
   transit.  To this end the routing protocol(s) MUST s= upport message
   integrity.”
JP> I do not see any reference to the type of routing attacks that could= be performed on such networks because of the typical P2MP traffic pattern, = extensive use of wireless links, ...
JP> What I would suggest is to re-focus on the routing security issues w= ith the Security expert that will get appointed.

Reference section
###############

The current reference section reads:
11.2.  Informative References

   [I-D.brandt-roll-home-routing-reqs]
            &nb= sp; Brandt, A., "Home Automation Routing Requirement in Low
            &nb= sp; Power and Lossy Networks",
            &nb= sp; draft-brandt-roll-home-routing-reqs-01 (work in progress),
            &nb= sp; May 2008.

JP> Please update to draft-ietf-roll-home-routing-reqs and add the refer= ence to draft-ietf-roll-indus-routing-reqs

   [I-D.culler-rl2n-routing-reqs]
            &nb= sp; Vasseur, J. and D. Cullerot, "Routing Requirements for Low
            &nb= sp; Power And Lossy Networks",
            &nb= sp; draft-culler-rl2n-routing-reqs-01 (work in progress),
            &nb= sp; July 2007.

JP> This one can be removed.


Last comment: please check that you expand acronyms when first used.

Thanks.

JP. --B_3302198935_43092083-- --===============0990667676== 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 --===============0990667676==-- From roll-bounces@ietf.org Thu Aug 21 14:08: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 E67A428C0EB; Thu, 21 Aug 2008 14:08: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 706E928C156 for ; Thu, 21 Aug 2008 14:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=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 Km5kAstnxquN for ; Thu, 21 Aug 2008 14:03:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id D3E3C3A677E for ; Thu, 21 Aug 2008 14:03:01 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 62E524817D; Thu, 21 Aug 2008 23:02:06 +0200 (CEST) Received: from localhost (unknown [127.0.0.1]) by omfedm07.si.francetelecom.fr (ESMTP service) with SMTP id 5CDFA68015; Thu, 21 Aug 2008 23:02:06 +0200 (CEST) Received: from PMEXCC11.intranet-paris.francetelecom.fr (unknown [10.196.130.4]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 4C5F368015; Thu, 21 Aug 2008 23:01:57 +0200 (CEST) Received: from PMEXCB30.intranet-paris.francetelecom.fr ([10.196.130.38]) by PMEXCC11.intranet-paris.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.2499); Thu, 21 Aug 2008 23:01:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Aug 2008 23:01:59 +0200 Message-ID: <53DE7AEBE1DD5741A44C3634276819220344C1B3@PMEXCB30.intranet-paris.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-roll-urban-routing-reqs-01 thread-index: AckDxCXVl9keGlV0jkulakQaFFRIHQAAdXyA From: To: "JP Vasseur" , "Mischa Dohler" , "Tim Winter" , "WATTEYNE Thomas RD-TECH" , "MADHUSUDAN Giyyarpuram RD-TECH" , "CHEGARAY Gabriel RD-TECH" , "BARTHEL Dominique RD-TECH" , X-OriginalArrivalTime: 21 Aug 2008 21:01:56.0641 (UTC) FILETIME=[25590910:01C903D1] Cc: "David E. Culler" Subject: Re: [Roll] Review of draft-ietf-roll-urban-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="===============0444533850==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0444533850== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C903D1.24A82DD4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C903D1.24A82DD4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 Thanks to Jean-Philippe for this thorough review=2E Please find a first shot of personal comments inline, but I'll let my fellow co-authors further elaborate accordingly=2E [CJ] [snip]=20 Abstract ####### s/ for a wireless ROLL solution to be useful the protocol(s) ought to be energy-efficient, scalable, and autonomous/ the routing solution ought to be energy-efficient, scalable and autonomous=2E =09 JP> You may want to use a different word than "Autonomous"=2E Do you refer to the "self configuration" property ? [CJ] We chose "autonomous" because it was generic enough, while I think "self configuration" is too restrictive: it's not only a matter of configuration, it's also a matter of making (forwarding) decisions, self-healing capabilities, etc=2E Another word I would suggest is "self-organizing", if this is more specific=2E=20 =09 Section 1 ####### * "Section 6 discusses the routing requirements for networks comprising such constrained devices in a U-LLN environment=2E These requirements may be overlapping requirements derived from other application- specific requirements documents or as listed in [I-D=2Eculler-rl2n-routing-reqs]=2E" =09 JP> Please remove this reference (ID abandoned) and insert reference to http://www=2Eietf= =2Eorg/internet-drafts/draft-ietf-roll-home-routing-reqs-02 =2Etxt , http://www=2Eietf= =2Eorg/internet-drafts/draft-ietf-roll-indus-routing-reqs-0 1=2Etxt and http://www=2Eietf= =2Eorg/internet-drafts/draft-martocci-roll-commercial-routi ng-reqs-00=2Etxt =2E [CJ] OK=2E=20 =09 * s/ Section 7 provides an overview of security considerations/ Section 7 provides an overview of routing security considerations=20 [CJ] OK=2E=20 =09 Section 2 ######## =09 * S/ ROLL: Routing over Low power and Lossy networks/ ROLL: Routing Over Low power and Lossy networks [CJ] OK=2E=20 =09 * Schedule: An agreed execution, wake-up, transmission, reception, etc=2E, time-table between two or more field devices=2E The definition is a little bit too vague=2E If used in the generic sense, no need to add it to the terminology section=2E Otherwise, it ought to be more specific=2E [CJ] Schedule is indeed very generic, but I think the sue of the word makes perfect sense in the context of U-WSN networks=2E Being more specific would mean elaborating on use cases where schedule information is taken into account by field devices to perform some specific action=2E If this proposal makes sense, I'm not sure the terminology section is appropriate for such elaboration and would therefore suggest we (1) keep the "schedule" definition in this section and (2) further elaborate on a use case that illustrates the use of schedule information in section 5 of the draft=2E=20 =09 Section 3=2E1=2E1 ########### * S/ pre- planned location/ pre-planned location [CJ] OK=2E=20 =09 * What you refer to as a repeater is in fact a router=2E What I would suggest here is to reword this paragraph to indicate that some nodes are simple routers whereas other nodes are routers and lso perform sensing/actuating task=2E Insert this paragraph after the Actuators and Sensors paragraphs=2E [CJ] So you're suggesting to (1) remove section 3=2E1=2E2 (not 3=2E1=2E1, actually), and (2) indicate that some nodes are routers (not "simple", btw :-), others also perform sensing/actuating tasks, right? I'm fine with this suggestion, but I'd like to hear the feedback from my colleagues=2E It's also worth mentioning that a "repeater" has a very specific meaning in "classical" networking environments, remembering the old days of FOIRL and the like=2E=2E=2Ethat may be another reason to avoid= the use of this notion within the roll context=2E =09 * "Actuators may generally be mobile but are likely to be static in the majority of near-future roll-outs": seems a bit contradictory=2E Don't you want to simply say that in a near-future the majority will be static? [CJ] Not quite, because actuators can be devices used by people who move from one place to another to check how the sensor network is doing=2E I think both cases are valid, and would therefore stick to the current wording=2E=20 =09 * "Similar to the access points, actuator nodes do not suffer from any long-term resource constraints=2E" what about battery-operated actuators ? [CJ] I'll leave that one to my colleagues :-)=20 =09 Section 3=2E1=2E4 ########### * "pollution data, such as polluting gases (SO2, NOx, CO, Ozone), heavy metals (e=2Eg=2E Mercury), pH, radioactivity, etc;" =3D> please expand acronym when first used=2E [CJ] Hmmm=2E=2E=2EI don't see too many acronyms in that sentence, actually=2E This is chemistry stuff, unless you're suggesting we provide the "lettered" designation of these substances like carbon oxyde, etc=2E? I wouldn't go that way=2E=2E=2E=20 =09 * "These meters will be capable of advanced sensing functionalities such as measuring quality of service, providing granular interval data, or automating the detection of alarm conditions=2E" You may want to more accurately define the term "quality of service" since as you know, we used that term of other purposes in IETF documents=2E [CJ] Agreed=2E Since this is a list of examples, I would suggest something like "measuring the quality of the water provided to the customers"=2E =09 * In addition they may be capable of advanced interactive functionalities such as remote service disconnect or remote demand reset=2E" =3D> in this case, they are also acting as actuators=2E [CJ] Agreed=2E=20 =09 Section 3=2E2=20 ######### =09 * s/ between one other/between each other [CJ] OK=2E=20 =09 * "The network MUST be capable of supporting the organization of a large number of sensing nodes into regions containing on the order of 10^2 to 10^4 sensing nodes each=2E" JP> Thanks to make this "MUST" routing-specific and move it to the requirements section=2E [CJ] Agreed - would suggest this should be the introductory sentence of section 6=2E1=2E=20 =09 Section 3=2E3 ######### =09 * RFID: expand acronym (Radio Frequency IDentification) and add to the terminology section [CJ] OK=2E=20 =09 * s/battery-powered nodes/battery powered nodes [CJ] OK=2E=20 "Sensor nodes are capable of forwarding data=2E" In other words, they can act as routers=2E No need to repeat this here=2E [CJ] Fair enough=2E=20 =09 Section 3=2E4 ######### =09 * "2=2E packet errors due to medium access control;" JP> It is not really "packet error" here=2E [CJ] Do you mean "transmission erros"? If so, I would agree with you that this wording is better, but then I guess it should be used for first three cases, right?=20 =09 * Some available protocols may cause packets of neighbouring nodes to collide and hence cause a link outage=2E" JP> You may want to be more specific "Some" ? [CJ] Do you mean examples, because the previous sentence mentions the L2 protocols this sentence refers to? =09 * "if ISM bands are to be used=2E For instance, if the 2=2E4GHz ISM band is used to facilitate communication between U-LLN nodes, then heavily loaded WLAN hot-spots become a detrimental performance factor jeopardizing the functioning of the U-LLN=2E" JP> Please expand acronym when first used and add to the terminology section (ISM, WLAN, =2E=2E=2E) [CJ] OK=2E=20 =09 * Don't you want to say a few words about the varying BER leading to potentially even higher packet error loss ratio? [CJ] Expand the acronym ;-) I agree, bit error rate considerations should deserve a couple of sentences in this section=2E=20 =09 Section 4=2E1 ######### =09 * "Pre-programmed MAC": expand acronym [CJ] OK=2E=20 =09 * "the autonomous organization" =3D> self-organizing? [CJ] Much better indeed=2E=20 =09 * "For example, nodes in urban sensor nodes SHOULD be able to:" =3D> Several of the requirements that follow are nor routing specific=2E= You may either want to change the SHOULD for a "should" or just focus on the routing aspects and move them to the routing requirements section=2E [CJ] They may not be routing specific, but I think they do affect how routing policies are enforced=2E I woudl therefore suggest we stick to the proposed wording=2E=20 =09 * "o Dynamically compute, select and possibly optimize the (multiple) path(s) that will be used by the participating devices to forward the traffic towards the actuators and/or the access point according to the service-specific and traffic-specific QoS, traffic engineering and security policies that will have to be enforced at the scale of a routing domain (that is, a set of networking devices administered by a globally unique entity), or a region of such domain (e=2Eg=2E a metropolitan area composed of clusters of sensors)=2E" JP> You list important and stringent requirements here=2E Do you really need a routing algorithms capable of computing a path on a per QoS/service specific/=2E=2E=2E Basis ? [CJ] I don't read this sentence as you do=2E What I meant here is that entities that operate urban sensor networks specify their own policies (routing, te, security, QoS, etc=2E), which may be service-specific=2E The requirement suggests that the devices involved in the enforcement of such policies should behave accordingly, that is, compute, select, establish and maintain paths whose characteristics comply with these policies=2E But I agree this is a strong requirement, but not stronger than, say, the self-organization requirement=2E =09 Section 4=2E2 ######### =09 * "After the initialization phase and possibly some operational time, new nodes may be injected into the network as well as existing nodes removed from the network=2E The former might be because a removed node is replaced or denser readings/actuations are needed or routing protocols report connectivity problems=2E " JP> Just to avoid any mis-interpretation when referring to routing problem, you mean that it may be desirable to inject to node because connectivity is not sufficient (lack of enough redundant path, =2E=2E=2E) and not because of a routing issue per say=2E [CJ] Not necessarily because connectivity is insufficient (new services, network expansion, node maintenance, etc=2E), and not necessarily because there is a routing issue, indeed=2E=20 =09 * "Differentiation SHOULD be made between node disappearance, where the node disappears without prior notification, and user or node-initiated disassociation ("phased-out"), where the node has enough time to inform the network about its removal=2E" JP> Again this is not a routing requirement=2E Unless you refer to the ability for the routing protocol to advertise to the rest of the network that it will be removed in order for the other node to re-compute their path and avoid traffic disruption (e=2Eg=2E Similarly to what we do with the ISIS overload bit for example=2E) Is it what you mean ?=20 [CJ] This is indeed what we meant (at least that's my reading of this sentence, but I'll let my colleagues further comment on that)=2E If so, please clarify and move the routing requirement (SHOULD in capital letter to the routing requirement section)=2E [CJ] OK=2E=20 =09 * "The protocol(s) hence SHOULD support the pinpointing of problematic routing areas" JP> Could you clarify what you mean by "pinpointing" since it could be interpreted in many ways?=20 [CJ] Fair enough, we need to be more explicit=2E Maybe something like: "the protocol should be able to convey information about malfunctioning nodes which may affect or jeopardize the overall routing efficiency, so that self-configuration capabilities of the sensor network might be solicited to facilitate the appropriate reconfiguration=2E" =09 * The following section also requires some clarification - you wrote: "Furthermore, to inform the access point(s) of the node's arrival and association with the network as well as freshly associated nodes about packet forwarding schedules, roles, etc, appropriate (link state) updating mechanisms SHOULD be supported=2E" JP> Are you explicitly requiring a Link State routing protocol or a routing protocol that provides information about link states or =2E=2E= =2E ? [CJ] We meant "a protocol that can provide information about link status", indeed=2E=20 Note that a requirement document should stay solution agnostic and stay focus on the requirement=2E=20 [CJ] Fully agreed=2E=20 Is you requirement that any node needs to have visibility on other node characteristics with no attempt of aggregation? [CJ] Well, yes, presumably depending on design considerations: cluster head vs=2E clients within the cluster, for example=2E I think this is typical Self Organizing Networking capability=2E =09 Section 4=2E3 ######### =09 * "The protocol(s) hence MUST support a large number of highly directional unicast flows from the sensing nodes or sensing clusters towards the access point or highly directed multicast or anycast flows from the nodes towards multiple access points=2E" JP> I think that what you mean is that the routing protocol MUST be optimized for Multipoint-to-Point traffic patterns (from sensors/actuators to Sink)=2E As written, it is not clear whether you refer to it as a routing requirement ? [CJ] Agreed=2E=20 This in fact what you wrote in section 6=2E5: "To this end, the routing protocol(s) SHOULD support and utilize the fact of highly directed traffic flow to facilitate scalability and parameter constrained routing=2E" [CJ] Correct=2E=20 =09 * s/ More generally, entire routing areas may be avoided at e=2Eg=2E night but heavily used during the day when nodes are scavenging from sunlight/ More generally, entire routing areas may be avoided (e=2Eg=2E at night) but heavily used during the day when nodes are scavenging from sunlight=2E JP> Doesn't this translate to the requirement for time-based routing (some form of policy routing) ? [CJ] Correct, but I don't see any harm in providing a practical example=2E=20 =09 Section 4=2E4 ######### =09 "However, they are not very stringent where latencies SHOULD simply be sufficiently smaller than typical reporting intervals" JP> This is certainly true but not a routing requirement but a data plane requirement unless you refer to the ability to support QoS aware routing where each node may want to be able to compute different paths depending on the traffic requirements? [CJ] This is indeed related to the third bullet that appears in section 4=2E1=2E=20 =09 * Move "U-LLN network devices SHOULD support unicast and multicast routing capabilities" to the routing requirement section=2E You may want to leave the sentence here (without a SHOULD)=2E [CJ] OK=2E=20 =09 * You use the term "anycast" that has been discussed in the past, in particular in the context of the Home routing requirement document=2E I would suggest to define this term in the document, refer to RFC4291 or RFC1546, =2E=2E=2E [CJ] Fully agreed=2E=20 =09 Section 4=2E5 ######### =09 * "An alarm is likely being registered by a plurality of sensing nodes where the delivery of a single alert message with its location of origin suffices in most cases=2E" Then you provide the example of toxic gas level=2E This is one example where it might be desirable not to perform data aggregation/fusion and get multiple copies of the same message from different source to perform "triangulation" and better localize the incident=2E [CJ] Agreed, but I think this example precisely illustrates the issue=2E=20 =09 * "Routing within urban sensor networks SHOULD require the U-LLN nodes to dynamically compute, select and install different paths towards a same destination, depending on the nature of the traffic=2E >From this perspective, such nodes SHOULD inspect the contents of traffic payload for making routing and forwarding decisions:=20 =09 JP> This clarifies my previous question; you do refer to ability to compute different paths (with different characteristic)=2E Note that the path selection process performed by the sender and potentially routers along the path is not strictly speaking a routing requirement=2E Move this requirement to the requirement section=2E=20 [CJ] OK=2E=20 =09 * "for example, the analysis of the traffic payload SHOULD be derived into aggregation capabilities for the sake of forwarding efficiency=2E" JP> Can you clarify what you mean here? [CJ] The analysis of the payload of several packets should help in making forwarding decisions that will spare network resources=2E =09 * "Delays and latencies are important; however, again, deliveries within seconds SHOULD suffice in most of the cases=2E" JP> Clearly not a routing requirement! [CJ] Agreed=2E=20 =09 Section 5 ######## =09 * "The network SHOULD take into consideration that different application traffic may require different priorities when traversing the network, and that some traffic may be more sensitive to latency=2E" JP> If by priorities you mean different routes with different characteristics then this is fine and already covered=2E If you refer to packet marking to provide different QoS in the data plane, this is not a routing requirement=2E [CJ] Agreed - the former is the correct interpretation=2E=20 =09 * "An U-LLN SHOULD support occasional large scale traffic flows from sensing nodes to access points, such as system-wide alerts=2E " and "A node MUST be able to send its own alerts toward an access point while continuing to forward traffic on behalf of other devices who are also experiencing an alert condition=2E The network MUST be able to manage this sudden large traffic flow=2E" JP> Not routing requirements=2E Unless =2E=2E=2E You require the ability to compute multiple paths and use all of them (symmetrical or asymmetrical routing ???) to spread out the traffic and limit network delays ? [CJ] I think this is a kind of causality effect: the routing protocol must be able to accommodate traffic bursts by dynamically computing and selecting multiple paths towards the same destination=2E=20 =09 * You make an interesting reference to Smart Grid and DR/DSM=2E That said, you wrote "The network SHOULD support internetworking, while giving attention to security implications of interfacing, for example, a home network with a utility U-LLN=2E" JP> Don't you mean that the routing protocol must be able to potentially interact via potential route redistribution with other routing protocol used in the Internet, should these two protocols not be identical ? [CJ] Correct=2E=20 =20 =09 Section 6 ######### =09 * S/Current urban roll-outs are composed of sometimes more than a hundred nodes/ Current urban roll-outs are composed of sometimes more than one hundred nodes [CJ] OK=2E=20 =09 * " The routing protocols(s) SHOULD support the organization of a large number of nodes into regions of to-be-specified size=2E" JP> It will be difficult (or too easy ;-)) to be compliant with that SHOULD with a to-be-specified size=2E Or did you mean "configurable" ? [CJ] Configurable is indeed much better=2E=20 =09 * "To this end, the routing protocol(s) MUST support parameter constrained routing, where examples of such parameters (CPU, memory size, battery level, etc=2E) have been given in the previous paragraph=2E" JP> Please use the term "node constrained based routing" [CJ] I'm not sure I agree here, because "node-constrained" sounds more fuzzy to me=2E "environment-constrained"?=20 =09 * "For the latter, the protocol(s) MUST support multi- and any-cast addressing=2E The protocol(s) SHOULD also support the formation and identification of groups of field devices in the network=2E" JP> You may want to more accurately define the term "anycast"=20 [CJ] Would the couple of references you righfully mentioned earlier be sufficient? =09 * " To mandate fully interoperable implementations, the routing protocol(s) proposed in U-LLN MUST support different devices and underlying technologies without compromising the operability and energy efficiency of the network=2E" JP> This requires clarification here=2E Do you mean that the routing protocol MUST support node constrained based routing? If so, it is already stated above=2E The support of different L1/L2 is a given (route over)=2E [CJ] I would agree with Jean-Philippe, and suggest we remove this wording=2E=2E=2Ebut I'll let the co-authors further comment=2E=20 =09 * Section 6=2E8, as written, is not related to routing but data plane=2E Let me be more specific: =09 * "To this end, the routing protocol(s) SHOULD support minimum latency for alert reporting and time-critical data queries=2E" JP> The support of minimum latency path (data plane !) or the support for different metric path (control plane) ? [CJ] As written, I read it as the former interpretation and would suggest we remove the text=2E=20 =09 * "For regular data reporting, it SHOULD support latencies not exceeding a fraction of the smallest reporting interval=2E " JP> Not a routing requirement=2E Even if you are referring to a bound on the total path metric (the metric reflecting the delay in this case), this is an implementation issue=2E [CJ] Correct=2E=20 =09 * "Due to the different latency requirements, the routing protocol(s) SHOULD support the ability of dealing with different latency requirements=2E The routing protocol(s) SHOULD also support the ability to route according to different metrics (one of which could e=2Eg=2E be latency)=2E" JP> yes these are routing requirements although I would suggest to remove the first sentence, the requirement being captured in the second sentence=2E [CJ] Agreed=2E=20 =09 Section 7 ######### =09 * "As every network, U-LLNs are exposed to security threats that MUST be addressed=2E" JP> You cannot put a MUST here unless you list the routing security threats=2E [CJ] OK=2E=20 =09 * s/ potential security threats/ potential routing security threats =3D> JP> Please use the term "routing security" in place of "security" throughout the section=2E=20 [CJ] OK=2E=20 =09 * "U-LLN networks SHOULD support mechanisms to preserve the confidentiality of the traffic that they forward=2E The U-LLN network SHOULD NOT prevent an application from employing additional confidentiality mechanisms=2E" JP> I do agree with the requirement but this is not a routing requirement=2E=20 [CJ] Fair enough=2E=20 Could you focus on the routing security issues ? Or are you referring to the routing traffic confidentiality ? [CJ] No, this wording referred to the traffic forwarded by the network=2E =20 This is what you do right after: [CJ] Correct=2E=20 " The U-LLN MUST be protected against attempts to inject false or modified packets=2E For example, an attacker SHOULD be prevented from manipulating or disabling the routing function by compromising routing update messages=2E Moreover, it SHOULD NOT be possible to coerce the network into routing packets which have been modified in transit=2E To this end the routing protocol(s) MUST support message integrity=2E" JP> I do not see any reference to the type of routing attacks that could be performed on such networks because of the typical P2MP traffic pattern, extensive use of wireless links, =2E=2E=2E=20 [CJ] OK, but does that mean we should not consider such requirement? I don't think so, afaic=2E=20 JP> What I would suggest is to re-focus on the routing security issues with the Security expert that will get appointed=2E [CJ] OK=2E=20 =09 Reference section ############### =09 The current reference section reads: 11=2E2=2E Informative References =09 [I-D=2Ebrandt-roll-home-routing-reqs] Brandt, A=2E, "Home Automation Routing Requirement in Low Power and Lossy Networks", draft-brandt-roll-home-routing-reqs-01 (work in progress), May 2008=2E =09 JP> Please update to draft-ietf-roll-home-routing-reqs and add the reference to draft-ietf-roll-indus-routing-reqs [CJ] OK=2E=20 =09 [I-D=2Eculler-rl2n-routing-reqs] Vasseur, J=2E and D=2E Cullerot, "Routing Requirements for Low Power And Lossy Networks", draft-culler-rl2n-routing-reqs-01 (work in progress), July 2007=2E =09 JP> This one can be removed=2E [CJ] OK=2E=20 =09 =09 Last comment: please check that you expand acronyms when first used=2E [CJ] OK=2E =20 Cheers, =20 Christian=2E=20 =09 =09 ********************************* This message and any attachments (the "message") are confidential and= intended solely for the addressees=2E=20 Any unauthorised use or dissemination is prohibited=2E Messages are susceptible to alteration=2E=20 France Telecom Group shall not be liable for the message if altered,= changed or falsified=2E If you are not the intended addressee of this message, please cancel it= immediately and inform the sender=2E ******************************** ------_=_NextPart_001_01C903D1.24A82DD4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-roll-urban-routing-reqs-01

Dear all,
 
Thanks to Jean-Philippe for this thorough review= =2E Please=20 find a first shot of personal comments inline, but I'll let my fellow= co-authors=20 further elaborate accordingly=2E

[CJ] [snip] 
Abstract
#######
s/= for a=20 wireless ROLL solution to be useful the protocol(s) ought to be=20 energy-efficient, scalable, and autonomous/ the routing solution ought to= be=20 energy-efficient, scalable and autonomous=2E

JP> You may want= to use a=20 different word than “Autonomous”=2E Do you refer to the= “self configuration”=20 property ?
[CJ] We chose "autonomous" because it was generic= enough,=20 while I think "self configuration" is too restrictive: it's not only a= matter=20 of configuration, it's also a matter of making (forwarding) decisions,=20 self-healing capabilities, etc=2E Another word I would suggest is=20 "self-organizing", if this is more=20 specific=2E 

Section 1
#######
*= “Section 6=20 discusses the routing requirements for networks=20 comprising
   such constrained devices in a U-LLN=20 environment=2E  These requirements
   may be= overlapping=20 requirements derived from other= application-
   specific=20 requirements documents or as listed=20 in
   [I-D=2Eculler-rl2n-routing-reqs]= =2E”

JP> Please=20 remove this reference (ID abandoned) and insert reference to http://www=2Eietf= =2Eorg/internet-drafts/draft-ietf-roll-home-routing-reqs-02= =2Etxt, http://www=2Eietf= =2Eorg/internet-drafts/draft-ietf-roll-indus-routing-reqs-01= =2Etxt and http://www=2Eietf= =2Eorg/internet-drafts/draft-martocci-roll-commercial-routing-reqs-00= =2Etxt=2E
[CJ] OK=2E 

* s/ Section 7= provides=20 an overview of security considerations/ Section 7 provides an overview of= =20 routing security considerations
[CJ] OK=2E 

Section=20 2
########

* S/ ROLL: Routing over Low power and Lossy= networks/=20 ROLL: Routing Over Low power and Lossy networks
[CJ] OK=2E 

* Schedule:=  An=20 agreed execution, wake-up, transmission,=20 reception,
         etc= =2E,=20 time-table between two or more field devices=2E
The definition is a= little=20 bit too vague=2E If used in the generic sense, no need to add it to the=20 terminology section=2E Otherwise, it ought to be more specific= =2E
[CJ] Schedule is indeed very generic, but I= think the=20 sue of the word makes perfect sense in the context of U-WSN networks=2E= Being=20 more specific would mean elaborating on use cases where schedule= information=20 is taken into account by field devices to perform some specific action=2E= If=20 this proposal makes sense, I'm not sure the terminology section is= appropriate=20 for such elaboration and would therefore suggest we (1) keep the= "schedule"=20 definition in this section and (2) further elaborate on a use case that=20 illustrates the use of schedule information in section 5 of the=20 draft=2E 

Section 3=2E1=2E1
###########
*= S/ pre-=20 planned location/ pre-planned location
[CJ] OK= =2E 

*=20 What you refer to as a repeater is in fact a router=2E What I would= suggest here=20 is to reword this paragraph to indicate that some nodes are simple= routers=20 whereas other nodes are routers and lso perform sensing/actuating task=2E= Insert=20 this paragraph after the Actuators and Sensors paragraphs=2E
[CJ] So=20 you're suggesting to (1) remove section 3=2E1=2E2 (not 3=2E1=2E1,= actually), and (2)=20 indicate that some nodes are routers (not "simple", btw :-), others also= =20 perform sensing/actuating tasks, right? I'm fine with this suggestion,= but I'd=20 like to hear the feedback from my colleagues=2E It's also worth= mentioning that=20 a "repeater" has a very specific meaning in "classical" networking=20 environments, remembering the old days of FOIRL and the like=2E=2E=2Ethat= may be=20 another reason to avoid the use of this notion within the roll=20 context=2E

* “Actuators may generally be= mobile but are=20 likely to be static in the majority of near-future roll-outs”:= seems a bit=20 contradictory=2E Don’t you want to simply say that in a near-future= the majority=20 will be static?
[CJ] Not quite, because actuators can be= devices used=20 by people who move from one place to another to check how the sensor= =20 network is doing=2E I think both cases are valid, and would= therefore stick=20 to the current wording=2E 

* “Similar to= the access=20 points, actuator nodes do not suffer from any long-term resource= constraints=2E”=20 what about battery-operated actuators ?
[CJ] I'll=20 leave that one to my colleagues :-) 

Section=20 3=2E1=2E4
###########
* “pollution data, such as polluting= gases (SO2, NOx,=20 CO, Ozone),
 heavy metals (e=2Eg=2E  Mercury), pH,= radioactivity,=20 etc;” =3D> please expand acronym when first used=2E
[CJ] Hmmm=2E=2E=2EI don't see too many acronyms in= that sentence,=20 actually=2E This is chemistry stuff, unless you're suggesting= we provide=20 the "lettered" designation of these substances like carbon oxyde,= etc=2E? I=20 wouldn't go that way=2E=2E=2E 

* “These= meters will be=20 capable of
   advanced sensing functionalities such as= =20 measuring quality of
   service, providing granular= interval=20 data, or automating the
   detection of alarm=20 conditions=2E”
You may want to more accurately define the term= “quality of=20 service” since as you know, we used that term of other purposes in= IETF=20 documents=2E
[CJ] Agreed=2E Since this is a list of examples, I= would=20 suggest something like "measuring the quality of the water provided= to=20 the customers"=2E

* In addition they may be capable= =20 of
   advanced interactive functionalities such as= remote=20 service
   disconnect or remote demand reset=2E” = =3D> in this=20 case, they are also acting as actuators=2E
[CJ] Agreed=2E 

Section 3= =2E2=20
#########

* s/ between one other/between each other
[CJ] OK=2E 

* “The= network MUST be=20 capable of supporting the organization of
   a large= number=20 of sensing nodes into regions containing on the= order
   of=20 10^2 to 10^4 sensing nodes each=2E”
JP> Thanks to make this= “MUST”=20 routing-specific and move it to the requirements section=2E
[CJ] Agreed - would suggest this should be the= introductory=20 sentence of section 6=2E1=2E 

Section=20 3=2E3
#########

* RFID: expand acronym (Radio Frequency=20 IDentification) and add to the terminology section
[CJ] OK=2E 

*= s/battery-powered=20 nodes/battery powered nodes
[CJ] OK= =2E 
“Sensor=20 nodes are capable of forwarding data=2E” In other words, they can= act as=20 routers=2E No need to repeat this here=2E
[CJ] Fair=20 enough=2E 

Section 3=2E4
#########

*= “2=2E=20  packet errors due to medium access control;” JP> It is not= really=20 “packet error” here=2E
[CJ] Do you mean "transmission= erros"?=20 If so, I would agree with you that this wording is better, but then I= guess it=20 should be used for first three cases, right? 

*= Some=20 available protocols may cause packets of neighbouring nodes to collide= and=20 hence cause a link outage=2E” JP> You may want to be more= specific “Some”=20 ?
[CJ] Do you mean examples, because the previous= sentence=20 mentions the L2 protocols this sentence refers to?

*= “if=20 ISM bands are to be used=2E  For instance, if the 2=2E4GHz ISM band= =20 is
   used to facilitate communication between U-LLN= nodes,=20 then heavily
   loaded WLAN hot-spots become a= detrimental=20 performance factor
   jeopardizing the functioning of= the=20 U-LLN=2E”
JP> Please expand acronym when first used and add= to the=20 terminology section (ISM, WLAN, =2E=2E=2E)
[CJ] OK= =2E 

*=20 Don’t you want to say a few words about the varying BER leading to= potentially=20 even higher packet error loss ratio?
[CJ] Expand the acronym ;-) I= agree, bit=20 error rate considerations should deserve a couple of sentences in this=20 section=2E 

Section 4=2E1
#########

*= =20 “Pre-programmed MAC”: expand acronym
[CJ] OK= =2E 

*=20 “the autonomous organization” =3D>= self-organizing?
[CJ] Much=20 better indeed=2E 

* “For example, nodes= in urban=20 sensor nodes SHOULD be able to:” =3D> Several of the= requirements that follow=20 are nor routing specific=2E You may either want to change the SHOULD for= a=20 “should” or just focus on the routing aspects and move them= to the routing=20 requirements section=2E
[CJ] They may not be routing= specific,=20 but I think they do affect how routing policies are enforced=2E I woudl=20 therefore suggest we stick to the proposed=20 wording=2E 

* “o  Dynamically= compute, select and=20 possibly optimize the=20 (multiple)
      path(s) that will be= used by=20 the participating devices to=20 forward
      the traffic towards the=20 actuators and/or the access=20 point
      according to the= service-specific=20 and traffic-specific QoS,
      traffic= =20 engineering and security policies that will have to=20 be
      enforced at the scale of a= routing=20 domain (that is, a set= of
      networking=20 devices administered by a globally unique entity), or=20 a
      region of such domain (e=2Eg=2E= a=20 metropolitan area composed= of
      clusters=20 of sensors)=2E”
JP> You list important and stringent= requirements here=2E Do=20 you really need a routing algorithms capable of computing a path on a per= =20 QoS/service specific/=2E=2E=2E Basis ?
[CJ] I don't read this sentence= as you=20 do=2E What I meant here is that entities that operate urban sensor= networks=20 specify their own policies (routing, te, security, QoS, etc=2E), which= may be=20 service-specific=2E The requirement suggests that the devices involved in= the=20 enforcement of such policies should behave accordingly, that is, compute,= =20 select, establish and maintain paths whose characteristics comply with= these=20 policies=2E But I agree this is a strong requirement, but not stronger= than,=20 say, the self-organization requirement=2E

Section=20 4=2E2
#########

* “After the initialization phase and= possibly some=20 operational time,
   new nodes may be injected into the= =20 network as well as existing nodes
   removed from the=20 network=2E  The former might be because a removed=20 node
   is replaced or denser readings/actuations are= needed=20 or routing
   protocols report connectivity problems=2E= =20 “
JP> Just to avoid any mis-interpretation when referring to= routing=20 problem, you mean that it may be desirable to inject to node because=20 connectivity is not sufficient (lack of enough redundant path, =2E=2E=2E)= and not=20 because of a routing issue per say=2E
[CJ] Not necessarily because=20 connectivity is insufficient (new services, network expansion, node=20 maintenance, etc=2E), and not necessarily because there is a routing= issue,=20 indeed=2E 

*=20 “Differentiation
   SHOULD be made between node=20 disappearance, where the node disappears
   without= prior=20 notification, and user or node-initiated=20 disassociation
   ("phased-out"), where the node has= enough=20 time to inform the network
   about its removal= =2E”
JP>=20 Again this is not a routing requirement=2E Unless you refer to the= ability for=20 the routing protocol to advertise to the rest of the network that it will= be=20 removed in order for the other node to re-compute their path and avoid= traffic=20 disruption (e=2Eg=2E Similarly to what we do with the ISIS overload bit= for=20 example=2E) Is it what you mean ?
[CJ] This is indeed what we= meant (at=20 least that's my reading of this sentence, but I'll let my colleagues= further=20 comment on that)=2E If so, please clarify and move the= =20 routing requirement (SHOULD in capital letter to the routing requirement= =20 section)=2E
[CJ] OK=2E 

* “The= protocol(s)=20 hence SHOULD support the pinpointing of problematic routing= areas”
JP>=20 Could you clarify what you mean by “pinpointing” since it= could be interpreted=20 in many ways?
[CJ] Fair enough, we need to be more explicit= =2E Maybe=20 something like: "the protocol should be able to convey information about= =20 malfunctioning nodes which may affect or jeopardize the overall routing=20 efficiency, so that self-configuration capabilities of the sensor network= =20 might be solicited to facilitate the appropriate=20 reconfiguration=2E"

* The following section also= requires=20 some clarification – you wrote:
“Furthermore, to inform=20 the
   access point(s) of the node's arrival and= association=20 with the
   network as well as freshly associated nodes= =20 about packet forwarding
   schedules, roles, etc,=20 appropriate (link state) updating mechanisms
   SHOULD= be=20 supported=2E”
JP> Are you explicitly requiring a Link State= routing=20 protocol or a routing protocol that provides information about link= states or=20 =2E=2E=2E ?
[CJ] We meant "a protocol that can provide= information=20 about link status", indeed=2E 
Note that a= requirement=20 document should stay solution agnostic and stay focus on the requirement= =2E=20
[CJ] Fully=20 agreed=2E 
Is you requirement that= any node=20 needs to have visibility on other node characteristics with no attempt of= =20 aggregation?
[CJ] Well, yes, presumably depending on design= =20 considerations: cluster head vs=2E clients within the cluster, for=20 example=2E I think this is typical Self Organizing=20 Networking capability=2E

Section=20 4=2E3
#########

* “The protocol(s) hence MUST support a= large number=20 of highly
   directional unicast flows from the sensing= =20 nodes or sensing clusters
   towards the access point= or=20 highly directed multicast or anycast
   flows from the= nodes=20 towards multiple access points=2E”
JP> I think that what you= mean is that=20 the routing protocol MUST be optimized for Multipoint-to-Point traffic=20 patterns (from sensors/actuators to Sink)=2E As written, it is not clear= whether=20 you refer to it as a routing requirement ?
[CJ] Agreed=2E 
This in fact= what you=20 wrote in section 6=2E5: “To this end, the routing protocol(s)= SHOULD support and=20 utilize the fact of highly directed traffic flow to facilitate= scalability and=20 parameter constrained routing=2E”
[CJ] Correct=2E 

* s/ More= =20 generally, entire routing areas may be avoided at e=2Eg=2E night but= heavily used=20 during the day when nodes are scavenging from sunlight/ More generally,= entire=20 routing areas may be avoided (e=2Eg=2E at night) but heavily used during= the day=20 when nodes are scavenging from sunlight=2E
JP> Doesn’t this= translate to=20 the requirement for time-based routing (some form of policy routing)=20 ?
[CJ] Correct, but I don't see any harm in providing= a=20 practical example=2E 

Section=20 4=2E4
#########

“However, they are not very stringent=20 where
   latencies SHOULD simply be sufficiently= smaller=20 than typical
   reporting intervals”
JP>= This is=20 certainly true but not a routing requirement but a data plane requirement= =20 unless you refer to the ability to support QoS aware routing where each= node=20 may want to be able to compute different paths depending on the traffic=20 requirements?
[CJ] This is indeed related to the third bullet that= =20 appears in section 4=2E1=2E 

* Move= “U-LLN network=20 devices SHOULD support unicast and multicast routing capabilities”= to the=20 routing requirement section=2E You may want to leave the sentence here= (without=20 a SHOULD)=2E
[CJ] OK=2E 

* You use the= term=20 “anycast” that has been discussed in the past, in particular= in the context of=20 the Home routing requirement document=2E I would suggest to define this= term in=20 the document, refer to RFC4291 or RFC1546, =2E=2E=2E
[CJ] Fully agreed=2E

Section=20 4=2E5
#########

* “An alarm is likely=20 being
   registered by a plurality of sensing nodes= where=20 the delivery of a
   single alert message with its= location=20 of origin suffices in most
   cases=2E”
Then= you provide=20 the example of toxic gas level=2E This is one example where it might be=20 desirable not to perform data aggregation/fusion and get multiple copies= of=20 the same message from different source to perform= “triangulation” and better=20 localize the incident=2E
[CJ] Agreed, but I think this= example=20 precisely illustrates the issue=2E 

*= “Routing within=20 urban sensor networks SHOULD require the U-LLN= nodes
   to=20 dynamically compute, select and install different paths towards=20 a
   same destination, depending on the nature of the=20 traffic=2E  From this
   perspective, such nodes= SHOULD=20 inspect the contents of traffic
   payload for making=20 routing and forwarding decisions:

JP> This clarifies my= previous=20 question; you do refer to ability to compute different paths (with= different=20 characteristic)=2E Note that the path selection process performed by the= sender=20 and potentially routers along the path is not strictly speaking a routing= =20 requirement=2E
Move this requirement to the requirement section=2E=
[CJ] OK=2E 

* “for= example, the=20 analysis of the traffic payload SHOULD be derived into=20 aggregation
   capabilities for the sake of forwarding= =20 efficiency=2E”
JP> Can you clarify what you mean= here?
[CJ] The=20 analysis of the payload of several packets should help in making=20 forwarding decisions that will spare network resources= =2E

*=20 “Delays and latencies are
   important; however,= again,=20 deliveries within seconds SHOULD suffice
   in most of= the=20 cases=2E”
JP> Clearly not a routing requirement!
[CJ] Agreed=2E 

Section=20 5
########

* “The network SHOULD take into consideration= that=20 different application
   traffic may require different= =20 priorities when traversing the network,
   and that= some=20 traffic may be more sensitive to latency=2E”
JP> If by= priorities you mean=20 different routes with different characteristics then this is fine and= already=20 covered=2E If you refer to packet marking to provide different QoS in the= data=20 plane, this is not a routing requirement=2E
[CJ] Agreed - the former is the correct=20 interpretation=2E 

* “An U-LLN SHOULD= support=20 occasional large scale traffic flows from
   sensing= nodes=20 to access points, such as system-wide alerts=2E “ and “A node= MUST be able to=20 send its own alerts toward an access
   point while=20 continuing to forward traffic on behalf of other=20 devices
   who are also experiencing an alert condition= =2E=20  The network MUST be
   able to manage this sudden= =20 large traffic flow=2E”
JP> Not routing requirements=2E Unless= =2E=2E=2E You=20 require the ability to compute multiple paths and use all of them= (symmetrical=20 or asymmetrical routing ???) to spread out the traffic and limit network= =20 delays ?
[CJ] I think this is a kind of causality effect: the= =20 routing protocol must be able to accommodate traffic bursts by= dynamically=20 computing and selecting multiple paths towards the same=20 destination=2E 

* You make an interesting= reference to=20 Smart Grid and DR/DSM=2E That said, you wrote “The network SHOULD= support=20 internetworking, while giving attention to security implications of=20 interfacing, for example, a home network with a utility U-LLN= =2E”
JP>=20 Don’t you mean that the routing protocol must be able to= potentially interact=20 via potential route redistribution with other routing protocol used in= the=20 Internet, should these two protocols not be identical ?
[CJ] Correct= =2E 
 

Section=20 6
#########

* S/Current urban roll-outs are composed of= sometimes=20 more than a hundred nodes/ Current urban roll-outs are composed of= sometimes=20 more than one hundred nodes
[CJ] OK= =2E 

* “=20 The routing protocols(s) SHOULD support the organization of a large= number of=20 nodes into regions of to-be-specified size=2E”
JP> It will be= difficult=20 (or too easy ;-)) to be compliant with that SHOULD with a to-be-specified= =20 size=2E Or did you mean “configurable” ?
[CJ] Configurable is indeed= much=20 better=2E 

* “To this end, the routing= protocol(s)=20 MUST support parameter
   constrained routing, where=20 examples of such parameters (CPU, memory
   size,= battery=20 level, etc=2E) have been given in the previous paragraph= =2E”
JP> Please use=20 the term “node constrained based routing”
[CJ] I'm=20 not sure I agree here, because "node-constrained" sounds more fuzzy to me= =2E=20 "environment-constrained"? 

* “For the= latter, the=20 protocol(s) MUST support multi- and
   any-cast= addressing=2E=20  The protocol(s) SHOULD also support= the
   formation=20 and identification of groups of field devices in=20 the
   network=2E”
JP> You may want to more= accurately=20 define the term “anycast” 
[CJ] Would the couple of references you=20 righfully mentioned earlier be sufficient?

*= “ To=20 mandate fully interoperable implementations, the=20 routing
   protocol(s) proposed in U-LLN MUST support=20 different devices and
   underlying technologies= without=20 compromising the operability and
   energy efficiency= of the=20 network=2E”
JP> This requires clarification here=2E Do you= mean that the=20 routing protocol MUST support node constrained based routing? If so, it= is=20 already stated above=2E The support of different L1/L2 is a given (route= =20 over)=2E
[CJ] I would agree with Jean-Philippe, and suggest= we=20 remove this wording=2E=2E=2Ebut I'll let the co-authors further=20 comment=2E 

* Section 6=2E8, as written, is not= related=20 to routing but data plane=2E Let me be more specific:

* “To= this end, the=20 routing protocol(s) SHOULD support minimum= latency
   for=20 alert reporting and time-critical data queries=2E”
JP> The= support of=20 minimum latency path (data plane !) or the support for different metric= path=20 (control plane) ?
[CJ] As written, I read it as the former= interpretation and=20 would suggest we remove the text=2E 

*= “For regular=20 data
   reporting, it SHOULD support latencies not= exceeding=20 a fraction of
   the smallest reporting interval=2E=20  “
JP> Not a routing requirement=2E Even if you are= referring to a=20 bound on the total path metric (the metric reflecting the delay in this= case),=20 this is an implementation issue=2E
[CJ] Correct=2E 

*= “Due to the=20 different latency requirements, the routing protocol(s) SHOULD support= the=20 ability of dealing with different latency requirements=2E  The= routing=20 protocol(s) SHOULD also support the ability to route according to= different=20 metrics (one of which could e=2Eg=2E be latency)=2E”
JP> yes= these are routing=20 requirements although I would suggest to remove the first sentence, the=20 requirement being captured in the second sentence=2E
[CJ] Agreed=2E 

Section=20 7
#########

* “As every network, U-LLNs are exposed to= security=20 threats that MUST be addressed=2E”
JP> You cannot put a MUST= here unless=20 you list the routing security threats=2E
[CJ] OK= =2E 

* s/=20 potential security threats/ potential routing security threats =3D>= JP>=20 Please use the term “routing security” in place of= “security” throughout the=20 section=2E
[CJ] OK=2E 

* “U-LLN= networks=20 SHOULD support mechanisms to preserve= the
   confidentiality=20 of the traffic that they forward=2E  The U-LLN=20 network
   SHOULD NOT prevent an application from= employing=20 additional
   confidentiality mechanisms= =2E”
JP> I do=20 agree with the requirement but this is not a routing requirement=2E=
[CJ] Fair=20 enough=2E 
Could you focus on the= routing=20 security issues ? Or are you referring to the routing traffic= confidentiality=20 ?
[CJ] No, this wording referred to the traffic= forwarded by=20 the network=2E  
This is what you do right=20 after:
[CJ] Correct=2E 
“ The= U-LLN MUST be=20 protected against attempts to inject false= or
   modified=20 packets=2E  For example, an attacker SHOULD be prevented=20 from
   manipulating or disabling the routing function= by=20 compromising
   routing update messages=2E=  Moreover, it=20 SHOULD NOT be possible to
   coerce the network into= routing=20 packets which have been modified in
   transit=2E=  To=20 this end the routing protocol(s) MUST support=20 message
   integrity=2E”
JP> I do not see= any reference=20 to the type of routing attacks that could be performed on such networks=20 because of the typical P2MP traffic pattern, extensive use of wireless= links,=20 =2E=2E=2E
[CJ] OK, but does that mean we should not consider= such=20 requirement? I don't think so, afaic=2E 
JP>= What I=20 would suggest is to re-focus on the routing security issues with the= Security=20 expert that will get appointed=2E
[CJ] OK=2E 

Reference=20 section
###############

The current reference section=20 reads:
11=2E2=2E  Informative=20 References

   [I-D= =2Ebrandt-roll-home-routing-reqs]
      &n= bsp;       Brandt,=20 A=2E, "Home Automation Routing Requirement in=20 = Low
           &= nbsp;  Power=20 and Lossy=20 = Networks",
          =     draft-brandt-roll-home-routing-reqs-01=20 (work in=20 = progress),
          =     May=20 2008=2E

JP> Please update to draft-ietf-roll-home-routing-reqs= and add=20 the reference to draft-ietf-roll-indus-routing-reqs
[CJ] OK= =2E 

   [I-D= =2Eculler-rl2n-routing-reqs]
       &= nbsp;      Vasseur,=20 J=2E and D=2E Cullerot, "Routing Requirements for=20 = Low
           &= nbsp;  Power=20 And Lossy=20 = Networks",
          =     draft-culler-rl2n-routing-reqs-01=20 (work in=20 = progress),
          =     July=20 2007=2E

JP> This one can be removed=2E
[CJ] OK=2E 


Last= comment:=20 please check that you expand acronyms when first used=2E
[CJ] OK=2E
 
Cheers,
 
Christian= =2E 

*********************************
This message and any attachments (the "message") are confidential and= intended solely for the addressees=2E
Any unauthorised use or dissemination is prohibited=2E
Messages are susceptible to alteration=2E
France Telecom Group shall not be liable for the message if altered,= changed or falsified=2E
If you are not the intended addressee of this message, please cancel it= immediately and inform the sender=2E
********************************
------_=_NextPart_001_01C903D1.24A82DD4-- --===============0444533850== 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 --===============0444533850==-- From roll-bounces@ietf.org Thu Aug 21 14:18:17 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 076393A6B33; Thu, 21 Aug 2008 14:18:17 -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 BB8473A6B82 for ; Thu, 21 Aug 2008 14:13:12 -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 h3-fL+P1XBOn for ; Thu, 21 Aug 2008 14:13:12 -0700 (PDT) Received: from usstuh502.johnsondiversey.com (mail3.johnsondiversey.com [208.251.229.30]) by core3.amsl.com (Postfix) with ESMTP id EE2FF3A6ACB for ; Thu, 21 Aug 2008 14:13:11 -0700 (PDT) From: david.bruemmer@johnsondiversey.com To: roll@ietf.org Message-ID: Date: Thu, 21 Aug 2008 16:02:10 -0500 X-MIMETrack: Serialize by Router on USSTUH502/SVR/CMI(Release 7.0.3FP1|February 24, 2008) at 08/21/2008 16:14:21 MIME-Version: 1.0 Subject: [Roll] David Bruemmer is out of the office. 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 I will be out of the office starting 08/18/2008 and will not return until 08/25/2008. I will respond to your message when I return. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Aug 21 14:41:26 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 98FA93A6ABC; Thu, 21 Aug 2008 14:41:26 -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 4A2C23A687E for ; Thu, 21 Aug 2008 14:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599, GB_I_LETTER=-2, 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 lw53FpsFCRuq for ; Thu, 21 Aug 2008 14:34:25 -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 12CBB3A6A57 for ; Thu, 21 Aug 2008 14:34:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,247,1217808000"; d="scan'208,217";a="144071959" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 21 Aug 2008 21:33:18 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7LLXIQc021436; Thu, 21 Aug 2008 14:33:18 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m7LLXH3P012763; Thu, 21 Aug 2008 21:33:18 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, 21 Aug 2008 17:33:17 -0400 Received: from 10.61.97.215 ([10.61.97.215]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Aug 2008 21:33:17 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 21 Aug 2008 23:33:15 +0200 From: JP Vasseur To: Anders Brandt , Porcu Giorgio , Message-ID: Thread-Topic: Review of draft-ietf-roll-home-routing-reqs-02 Thread-Index: AckD1YTvR+kjwowIaE+CUmY/7HuZOg== Mime-version: 1.0 X-OriginalArrivalTime: 21 Aug 2008 21:33:17.0446 (UTC) FILETIME=[86651A60:01C903D5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24671; t=1219354398; x=1220218398; 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:=20Review=20of=20draft-ietf-roll-home-routing-reqs -02=20 |Sender:=20; bh=3m2rIZyLrxOTr4yIoTHo/8FCHUsib9jzFXEyG4wxVwc=; b=1AnHF9qgggB2X+ogbpb2Deq7gHqU3WOMc62Bswp107dsOh1FWOE24I/592 FnGWpXS4k3irwMGd94rkcBdVJDSlsdHj6FEcl50qnEd0woXaiMA0e2zxEzka p++SCNdSS3; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "David E. Culler" Subject: [Roll] Review of draft-ietf-roll-home-routing-reqs-02 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="===============0844671696==" 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. --===============0844671696== Content-type: multipart/alternative; boundary="B_3302206395_43592693" > 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_3302206395_43592693 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Dear WG, As discussed in Dublin, the plan is to try to Last Call all the application-specific routing requirements document before end of September. Thus, please provide your detailed comments as soon as possible. Here is my co-chair review on the Home Automation Routing Requirements. Comments are not by order of importance by in chronological order. First comments: as discussed in Dublin, could you please try to quickly address the routing security issues. Abstract ####### * S/ ROuting in Low power and Lossy networks (ROLL)/ Routing Over Low power and Lossy networks (ROLL) // Also in the terminology section // * =B3Examples include lighting control, heating control, sensors, leak detectors, healthcare systems and advanced remote controls.=B2 JP> Don=B9t you want to classify with sensor (water leak, motion, healthcare systems...), actuators (lighting, ....) * Thanks to substitute the term =B3multi-hop routing=B2 by =B3routing=B2 (explain that in a typical home all the nodes are not in direct range). It appears i= n several sections. * I think that the terminology section requires some work but I=B9ll send a separate email thread on the ROLL WG mailing list. For the time being, I would suggest to remove the ROLL Node, ROLL network, ... terminology. You may just want to a node where a node may be a sensor, actuator, ... Unless you need to refer to a particular function of the node. Please re-order sections so that Introduction becomes Section 1. Introduction Section ################# * s/ gas/water leak detectors/ gas/water leak sensor =3D> JP> Good to use the term sensor not to introduce new term (detector) * =B3Basic home control modules such as wall switches and plug-in modules may be turned into an advanced home automation solution via the use of an IP-enabled application responding to events generated by wall switches, motion sensors, light sensors, rain sensors, and so on. =B3 JP> You may want to explain that wall switched are then actuators. We could also have embedded power sensor in plug-in modules but I guess that you refer to actuators here. * =B3These requirements may be overlapping requirements derived from other application-specific requirements. =B3 JP> Good place to reference the other IDs: http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-02.tx= t ,=20 http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-01.t= x t and=20 http://www.ietf.org/internet-drafts/draft-martocci-roll-commercial-routing-= r eqs-00.txt. + Update the reference section Section 3 ######## * =B3Home automation applications represent a special segment of networked wireless devices with its unique set of requirements.=B2 JP> You may want to say that home networks may also comprise wired link (e.g.PLC) * =B3For instance a lamp may be turned on, not only be a wall switch but also from a movement sensor. =B3 JP> Don=B9t you want to move this to Section 3.1 and try to slightly generalize the Section 3.1 to =B3lighting application=B2. * =B3Geographical areas using central heating may turn off heating when not at home and use a reduced temperature during night time. The power grid may experience periods where more wind-generated power is produced than is needed. Typically this may happen during night hours. The washing machine and dish washer may just as well work while power is cheap. The electric car should also charge its batteries on cheap power. In periods where electricity demands exceed available supply, appliances such as air conditioning, climate control systems, washing machines etc. can be turned off to avoid overloading the power grid. =B3 JP> Great example. When you refer to this kind of application you may want to use the term DR (demand-response) and SDM (Demand Side management) also listed in the Urban routing requirement ID. * =B3Wireless remote control of the household appliances is well-suited for this application. =B3 and =B3 Moreover, in order to achieve effective electricity savings, the energy monitoring application running on the Wireless Sensor Network (WSN)=B2 JP> Well it is not just wireless but also wired (PLC). You may want to say =B3Remote control ...=B2. * Section 3.4: This is an important section. Two comments: - This is not just for lighting devices (referring to the title) - Distribution of unique address may not always be performed by a central contoller * =B3A=20 home automation controller sending commands to window shades via ROLL devices will have no problems delivering the packet to the router, but the router may have to wait for some time before the command can be delivered to the window shades if the receiver is sleeping;=B2 JP> You may want to clarify the paragraph above. I guess that in your example: the router is the node immediately upstream to the destination, an= d the window shades destination=3Dreceiver (actuator)? =3D> means buffering on routers. No need to ellaborate more though, since this is not related to routing requirements. The 250ms refer to the wake-up time ? * s/=B2which can be=20 triggered by the end-user that has received an alarm from a movement sensor or smoke detector - or the user simply wants to check the home status via video. =B3/=B2which can be triggered by the end-user that has received an alarm from sensor (movement=20 or smoke detector) or the user that simply wants to check the home status via video. =B3 * PDA: please expand acronym when first used. * s/=B3From a ROLL perspective, all the above-mentioned applications may run on battery.=B2/=B2Because all of the above-mentioned applications may run on battery, this leads to specific requirements for the routing protocol.=B2 * =B3A home security alarm system is comprised of various devices like vibration detectors, fire or carbon monoxide detection system, door or window contacts, glass-break detector, presence sensor, panic button, home security key.=B2 JP> Sorry to be =B3picky=B2 with the terminology but could you classify as sensors, actuators, ... ? Thanks. * =B3When a node (or a group of nodes) identifies a risk situation (e.g. intrusion, smoke, fire), it sends an alarm message to the control centre that could autonomously forward it via Internet or interact with the WSN (e.g. trying to obtain more detailed information or asking to other nodes close to the alarm event).=B2 JP> Define the =B3control centre=B2 as a local device. * s/=B3RAM memory=B2/RAM and expand the term RAM Section 4 ######### * s/=B2Home automation applications have a number of specific requirements related to the set of home networking applications and the perceived operation of the system.=B2/=B2Home automation applications have a number of specific routing requirements related to the set of home networking applications and the perceived operation of the system.=B2 * =B3Broadcast and groupcast in home automation MAY be used to deliver the illusion that all recipients respond simultaneously. Distant recipients out of direct range may not react to the (unacknowledged) groupcast. Acknowledged unicast delivery MUST be used subsequently. =B3 JP> These are not routing requirements. If you require the support of =B3groupcast routing=B2 (e.g. Minimization of packet duplication) then it is indeed a routing requirement, in which case there are other implications on addressing. Is it what is being required here ? Clearly the second statemen= t related to acknowledgment delivery is NOT a routing requirement. * Ah indeed I now read =B3The support of unicast, groupcast and broadcast als= o has an=20 implication on the addressing scheme and are outside the scope of this document that focuses on the routing requirements aspects. =B3 So do you want to clarify the routing specific requirement for Groupcast ? * Same issue here =B3It MUST be to possible to address a group of receivers known by the=20 sender even if the receivers do not know that they have been grouped by the sender.=B2 * =B3The routing protocol should either share the load between nodes to preserve battery or only route via mains-powered nodes if possible.=B2 JP> Is it a =B3should=B2 or a =B3SHOULD=B2. If a =B3SHOULD=B2 this translates to the support of load balancing (symmetrical or asymetrical), thus the computatio= n of multiple paths to the destination (of equal or unequal cost). * =B3The=20 routing protocol SHOULD make use of the fact that if not being able to deliver a packet, it is most likely that the sending node moved; rather than a failure occurred in that node or in a link on the path towards it. =B3 JP> And ?? * =B3The routing protocol MUST support the recognition of neighbors and periodical scanning.=B2 JP> By periodical scanning you mean =B3Keep alive=B2 ? Then you may want to indicate some frequency since it may contradict with your next statement: =B3This process SHOULD preserve energy capacity as much as possible=B2. * =B3Thus, the routing protocol MUST support 250 devices in a subnet. The routing protocol SHOULD support 2500 devices in a subnet. =B3 JP> Why in a subnet? You mean in the =B3network=B2 * Section 4.7 - I would suggest not to use the PAN terminology - s/=B2From ROLL perspective,=B2/=B2From a routing perspective=B2 * =B3The routing protocol MUST support the ability to isolate a misbehaving node thus preserving the correct operation of overall network. =B3 This is a fairly important requirement, although it may end up being an implementation issue, which will be determined once we will get to the routing solution. But this requirement is not about manageability but network stability. Could you make it a dedicated section ? Section 5 ######### * Just to avoid ambiguity, please clarify the term =B3any-to-one=B2 (which may interpreted as Multipoint-to-point) Section 7 ######### I would have similar comments on this section as for the Urban routing requirement documents. You may want to focus on routing security issues and work with the security expert that will be appointed. Other comments:=20 - Please capitalize each first letter of each word in titles (3.7.3. Healthcare routing considerations =3D> 3.7.3. Healthcare Routing Considerations ) - Add the other application specific routing requirements documents as informative references Thanks. JP. --B_3302206395_43592693 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Review of draft-ietf-roll-home-routing-reqs-02 Dear WG,

As discussed in Dublin, the plan is to try to Last Call all the application= -specific routing requirements document before end of September. Thus, pleas= e provide your detailed comments as soon as possible.

Here is my co-chair review on the Home Automation Routing Requirements.
Comments are not by order of importance by in chronological order.

First comments: as discussed in Dublin, could you please try to quickly add= ress the routing security issues.

Abstract
#######

* S/ ROuting in Low power and Lossy networks (ROLL)/ Routing Over Low power= and Lossy networks (ROLL) // Also in the terminology section //
* “Examples include lighting control,
   heating control, sensors, leak detectors, healthcare syst= ems and
   advanced remote controls.”
JP> Don’t you want to classify with sensor (water leak, motion, he= althcare systems...), actuators (lighting, ....)
* Thanks to substitute the term “multi-hop routing” by “r= outing” (explain that in a typical home all the nodes are not in direc= t range). It appears in several sections.
* I think that the terminology section requires some work but I’ll se= nd a separate email thread on the ROLL WG mailing list. For the time being, = I would suggest to remove the ROLL Node, ROLL network, ... terminology. You = may just want to a node where a node may be a sensor, actuator, ... Unless y= ou need to refer to a particular function of the node.

Please re-order sections so that Introduction becomes Section 1.

Introduction Section
#################

* s/ gas/water leak detectors/ gas/water leak sensor =3D> JP> Good to u= se the term sensor not to introduce new term (detector)
* “Basic home control
   modules such as wall switches and plug-in modules may be = turned into
   an advanced home automation solution via the use of an IP= -enabled
   application responding to events generated by wall switch= es, motion
   sensors, light sensors, rain sensors, and so on. “<= BR> JP> You may want to explain that wall switched are then actuators. We co= uld also have embedded power sensor in plug-in modules but I guess that you = refer to actuators here.
* “These requirements may be overlapping requirements
   derived from other application-specific requirements. = 220;
JP> Good place to reference the other IDs:  <= U>http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routin= g-reqs-02.txt, http://ww= w.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-01.txt= and http://www.ietf.or= g/internet-drafts/draft-martocci-roll-commercial-routing-reqs-00.txt= . + Update the reference section

Section 3
########

* “Home automation applications represent a special segment of networ= ked
   wireless devices with its unique set of requirements.R= 21;
JP> You may want to say that home networks may also comprise wired link = (e.g.PLC)
* “For instance a lamp may be turned on, not only be a
   wall switch but also from a movement sensor. “
JP> Don’t you want to move this to Section 3.1 and try to slightly= generalize the Section 3.1 to “lighting application”.
* “Geographical areas using central heating may turn off heating when=
   not at home and use a reduced temperature during night ti= me.

   The power grid may experience periods where more wind-gen= erated power
   is produced than is needed. Typically this may happen dur= ing night
   hours. The washing machine and dish washer may just as we= ll work
   while power is cheap. The electric car should also charge= its
   batteries on cheap power.

   In periods where electricity demands exceed available sup= ply,
   appliances such as air conditioning, climate control syst= ems, washing
   machines etc. can be turned off to avoid overloading the = power grid. “
JP> Great example. When you refer to this kind of application you may wa= nt to use the term DR (demand-response) and SDM (Demand Side management) als= o listed in the Urban routing requirement ID.
* “Wireless remote control of the household appliances is well-suited=
   for this application. “ and “ Moreover, in or= der to achieve
   effective electricity savings, the energy monitoring appl= ication
   running on the Wireless Sensor Network (WSN)”
JP> Well it is not just wireless but also wired (PLC). You may want to s= ay “Remote control ...”.
* Section 3.4: This is an important section. Two comments:
    - This is not just for lighting devices (referring = to the title)
    - Distribution of unique address may not always be = performed by a central contoller
* “A
   home automation controller sending commands to window sha= des via ROLL
   devices will have no problems delivering the packet to th= e router,
   but the router may have to wait for some time before the = command can
   be delivered to the window shades if the receiver is slee= ping;”
JP> You may want to clarify the paragraph above. I guess that in your ex= ample: the router is the node immediately upstream to the destination, and t= he window shades destination=3Dreceiver (actuator)? =3D> means buffering on r= outers. No need to ellaborate more though, since this is not related to rout= ing requirements. The 250ms refer to the wake-up time ?
* s/”which can be
   triggered by the end-user that has received an alarm from= a movement
   sensor or smoke detector - or the user simply wants to ch= eck the home
   status via video. “/”which can be
   triggered by the end-user that has received an alarm from= sensor (movement
   or smoke detector) or the user that simply wants to check= the home
   status via video. “   
* PDA: please expand acronym when first used.
* s/“From a ROLL perspective, all the above-mentioned applications ma= y run
   on battery.”/”Because all of the above-mentio= ned applications may run on battery, this leads to specific requirements for= the routing protocol.”
* “A home security alarm system is comprised of various devices like =
   vibration detectors, fire or carbon monoxide detection sy= stem, door
   or window contacts, glass-break detector, presence sensor= , panic
   button, home security key.”
JP> Sorry to be “picky” with the terminology but could you c= lassify as sensors, actuators, ... ? Thanks.
* “When a node (or a group of nodes) identifies a risk situation (e.g= .
   intrusion, smoke, fire), it sends an alarm message to the= control
   centre that could autonomously forward it via Internet or= interact
   with the WSN (e.g. trying to obtain more detailed informa= tion or
   asking to other nodes close to the alarm event).” JP> Define the “control centre” as a local device.
* s/“RAM memory”/RAM and expand the term RAM

Section 4
#########
* s/”Home automation applications have a number of specific requireme= nts
   related to the set of home networking applications and th= e perceived
   operation of the system.”/”Home automation ap= plications have a number of specific routing requirements
   related to the set of home networking applications and th= e perceived
   operation of the system.”
* “Broadcast and groupcast in home automation MAY be used to deliver = the
   illusion that all recipients respond simultaneously. Dist= ant
   recipients out of direct range may not react to the (unac= knowledged)
   groupcast.  Acknowledged unicast delivery MUST be us= ed subsequently. “
JP> These are not routing requirements. If you require the support of &#= 8220;groupcast routing” (e.g. Minimization of packet duplication) then= it is indeed a routing requirement, in which case there are other implicati= ons on addressing. Is it what is being required here ? Clearly the second st= atement related to acknowledgment delivery is NOT a routing requirement.
* Ah indeed I now read “The support of unicast, groupcast and broadca= st also has an
   implication on the addressing scheme and are outside the = scope of
   this document that focuses on the routing requirements as= pects. “ So do you want to clarify the routing specific requirement fo= r Groupcast ?
* Same issue here “It MUST be to possible to address a group of recei= vers known by the
   sender even if the receivers do not know that they have b= een grouped
   by the sender.”
* “The routing protocol should either share the load between
   nodes to preserve battery or only route via mains-powered= nodes if
   possible.”
JP> Is it a “should” or a “SHOULD”. If a “= SHOULD” this translates to the support of load balancing (symmetrical = or asymetrical), thus the computation of multiple paths to the destination (= of equal or unequal cost).
* “The
   routing protocol SHOULD make use of the fact that if not = being able
   to deliver a packet, it is most likely that the sending n= ode moved;
   rather than a failure occurred in that node or in a link = on the path
   towards it. “
JP> And ??
* “The routing protocol MUST support the recognition of neighbors and=
   periodical scanning.”
JP> By periodical scanning you mean “Keep alive” ? Then you = may want to indicate some frequency since it may contradict with your next s= tatement: “This process SHOULD preserve energy capacity as much as pos= sible”.
* “Thus, the routing protocol MUST support 250 devices in a subnet. <= BR>    The routing protocol SHOULD support 2500 devices in a sub= net. “
JP> Why in a subnet? You mean in the “network”
* Section 4.7
    - I would suggest not to use the PAN terminology     - s/”From ROLL perspective,”/”Fro= m a routing perspective”
* “The routing protocol MUST support the ability to isolate a
   misbehaving node thus preserving the correct operation of= overall
   network. “
This is a fairly important requirement, although it may end up being an imp= lementation issue, which will be determined once we will get to the routing = solution. But this requirement is not about manageability but network stabil= ity. Could you make it a dedicated section ?

Section 5
#########
* Just to avoid ambiguity, please clarify the term “any-to-one”= (which may interpreted as Multipoint-to-point)

Section 7
#########
I would have similar comments on this section as for the Urban routing requ= irement documents. You may want to focus on routing security issues and work= with the security expert that will be appointed.


Other comments:
- Please capitalize each first letter of each word in titles (3.7.3. Health= care routing considerations  =3D> 3.7.3. Healthcare Routing Considerat= ions )
- Add the other application specific routing requirements documents as info= rmative references

Thanks.

JP.
 --B_3302206395_43592693-- --===============0844671696== 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 --===============0844671696==-- From roll-bounces@ietf.org Thu Aug 21 16:15:25 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 ACF793A6BAB; Thu, 21 Aug 2008 16:15:25 -0700 (PDT) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D1F2A3A67A1; Thu, 21 Aug 2008 16: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: <20080821231501.D1F2A3A67A1@core3.amsl.com> Date: Thu, 21 Aug 2008 16:15:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D ACTION:draft-ietf-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 --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 : Overview of Existing Routing Protocols for Low Power and Lossy Networks Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis Filename : draft-ietf-roll-protocols-survey-00.txt Pages : 21 Date : 2008-8-5 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. Routing over such low power and lossy networks has 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 this class of networks. 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-ietf-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-protocols-survey-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-21161405.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 Fri Aug 22 01:30:54 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 7CC4C3A683C; Fri, 22 Aug 2008 01:30:54 -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 1AD1528C11C for ; Fri, 22 Aug 2008 01:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 9of1LqHI7cZM for ; Fri, 22 Aug 2008 01:20:24 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 16C873A6A51 for ; Fri, 22 Aug 2008 01:20:23 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Aug 2008 10:20:02 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EB68D7A@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Aligning Terminology across ROLL Routing RequirementsDocuments Thread-Index: AckDw9q7L5M0IvVf8EGd9qOQInzFGgAa9d2A References: From: "Anders Brandt" To: Subject: Re: [Roll] Aligning Terminology across ROLL Routing RequirementsDocuments 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="===============0387717101==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0387717101== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9042F.DFEB80D8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9042F.DFEB80D8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Great. I have been missing that too, but did not get all the way to writing a proposal ... =20 Cheers, Anders ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: 21. august 2008 21:27 To: roll@ietf.org Subject: [Roll] Aligning Terminology across ROLL Routing RequirementsDocuments Dear WG, Since there are quite a few inconsistencies between the terms used across the various ROLL WG ID, I will try to quickly prepare a short ID on Terminology that could be referenced in all ROLL documents.=20 Let me know if you have comments. Thanks. JP.=20 ------_=_NextPart_001_01C9042F.DFEB80D8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Aligning Terminology across ROLL Routing Requirements = Documents
Great.
I have been missing that too, but = did not get=20 all the way to writing a proposal ...
 
Cheers,
  = Anders

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent:=20 21. august 2008 21:27
To: roll@ietf.org
Subject: = [Roll]=20 Aligning Terminology across ROLL Routing=20 RequirementsDocuments

Dear WG,

Since there are quite a few=20 inconsistencies between the terms used across the various ROLL WG ID, I = will try=20 to quickly prepare a short ID on Terminology that could be referenced in = all=20 ROLL documents.

Let me know if you have=20 comments.

Thanks.

JP. ------_=_NextPart_001_01C9042F.DFEB80D8-- --===============0387717101== 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 --===============0387717101==-- From roll-bounces@ietf.org Fri Aug 22 02:40: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 624C83A68EC; Fri, 22 Aug 2008 02:40: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 D8E6F28C137 for ; Fri, 22 Aug 2008 02:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=2.187, BAYES_00=-2.599, GB_I_LETTER=-2, 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 nfXLMZwju7P4 for ; Fri, 22 Aug 2008 02:25:51 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 24BAD3A696D for ; Fri, 22 Aug 2008 02:25:49 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id m7M9NSQ9026430; Fri, 22 Aug 2008 11:23:28 +0200 Received: from CTTCPCMDOHLER (pcmdohler.cttc.es [84.88.61.89]) by castor (Postfix) with ESMTP id C8E7E2FC284; Fri, 22 Aug 2008 11:23:27 +0200 (CEST) From: "Mischa Dohler" To: , "'JP Vasseur'" , "'Tim Winter'" , "'WATTEYNE Thomas RD-TECH'" , "'MADHUSUDAN Giyyarpuram RD-TECH'" , "'CHEGARAY Gabriel RD-TECH'" , "'BARTHEL Dominique RD-TECH'" , Date: Fri, 22 Aug 2008 11:20:41 +0200 Organization: CTTC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <53DE7AEBE1DD5741A44C3634276819220344C1B3@PMEXCB30.intranet-paris.francetelecom.fr> Thread-Index: AckDxCXVl9keGlV0jkulakQaFFRIHQAAdXyAABs8CCA= Message-Id: <20080822092327.C8E7E2FC284@castor> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Fri, 22 Aug 2008 11:23:28 +0200 (CEST) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: "'David E. Culler'" Subject: Re: [Roll] Review of draft-ietf-roll-urban-routing-reqs-01 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="===============1115744616==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1115744616== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BE_01C90449.1CA63C70" This is a multi-part message in MIME format. ------=_NextPart_000_00BE_01C90449.1CA63C70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks, JP, indeed, for this in-depth review. I propose that Tim takes care of all the small typos identified by JP. Some comments in-line in addition to Christian ones. Thanks to all and kind regards, Mischa. _____ From: christian.jacquenet@orange-ftgroup.com [mailto:christian.jacquenet@orange-ftgroup.com] Sent: Thursday, August 21, 2008 11:02 PM To: JP Vasseur; Mischa Dohler; Tim Winter; WATTEYNE Thomas RD-TECH; MADHUSUDAN Giyyarpuram RD-TECH; CHEGARAY Gabriel RD-TECH; BARTHEL Dominique RD-TECH; roll@ietf.org Cc: David E. Culler Subject: RE: Review of draft-ietf-roll-urban-routing-reqs-01 Dear all, Thanks to Jean-Philippe for this thorough review. Please find a first shot of personal comments inline, but I'll let my fellow co-authors further elaborate accordingly. [CJ] [snip] Abstract ####### s/ for a wireless ROLL solution to be useful the protocol(s) ought to be energy-efficient, scalable, and autonomous/ the routing solution ought to be energy-efficient, scalable and autonomous. JP> You may want to use a different word than "Autonomous". Do you refer to the "self configuration" property ? [CJ] We chose "autonomous" because it was generic enough, while I think "self configuration" is too restrictive: it's not only a matter of configuration, it's also a matter of making (forwarding) decisions, self-healing capabilities, etc. Another word I would suggest is "self-organizing", if this is more specific. [Mischa] We had long discussions on this and finally converged to < autonomous >. Let's leave it. Section 1 ####### * "Section 6 discusses the routing requirements for networks comprising such constrained devices in a U-LLN environment. These requirements may be overlapping requirements derived from other application- specific requirements documents or as listed in [I-D.culler-rl2n-routing-reqs]." JP> Please remove this reference (ID abandoned) and insert reference to http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-02.txt , http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-01.tx t and http://www.ietf.org/internet-drafts/draft-martocci-roll-commercial-routing-r eqs-00.txt. [CJ] OK. * s/ Section 7 provides an overview of security considerations/ Section 7 provides an overview of routing security considerations [CJ] OK. Section 2 ######## * S/ ROLL: Routing over Low power and Lossy networks/ ROLL: Routing Over Low power and Lossy networks [CJ] OK. * Schedule: An agreed execution, wake-up, transmission, reception, etc., time-table between two or more field devices. The definition is a little bit too vague. If used in the generic sense, no need to add it to the terminology section. Otherwise, it ought to be more specific. [CJ] Schedule is indeed very generic, but I think the sue of the word makes perfect sense in the context of U-WSN networks. Being more specific would mean elaborating on use cases where schedule information is taken into account by field devices to perform some specific action. If this proposal makes sense, I'm not sure the terminology section is appropriate for such elaboration and would therefore suggest we (1) keep the "schedule" definition in this section and (2) further elaborate on a use case that illustrates the use of schedule information in section 5 of the draft. [Mischa] I don't see why this is vague. This is very clear to me. Let's leave it as is (I guess we do not need to find the maximum entropy of this document; the routing solution won't get better due to this :-)). Section 3.1.1 ########### * S/ pre- planned location/ pre-planned location [CJ] OK. * What you refer to as a repeater is in fact a router. What I would suggest here is to reword this paragraph to indicate that some nodes are simple routers whereas other nodes are routers and lso perform sensing/actuating task. Insert this paragraph after the Actuators and Sensors paragraphs. [CJ] So you're suggesting to (1) remove section 3.1.2 (not 3.1.1, actually), and (2) indicate that some nodes are routers (not "simple", btw :-), others also perform sensing/actuating tasks, right? I'm fine with this suggestion, but I'd like to hear the feedback from my colleagues. It's also worth mentioning that a "repeater" has a very specific meaning in "classical" networking environments, remembering the old days of FOIRL and the like...that may be another reason to avoid the use of this notion within the roll context. [Mischa] We had this discussion before and the reason outlined by Christian is exactly why the thingy is called repeater and not router. * "Actuators may generally be mobile but are likely to be static in the majority of near-future roll-outs": seems a bit contradictory. Don't you want to simply say that in a near-future the majority will be static? [CJ] Not quite, because actuators can be devices used by people who move from one place to another to check how the sensor network is doing. I think both cases are valid, and would therefore stick to the current wording. [Mischa] When I wrote this I had more in mind what JP said in shortened form. I personally hence propose to change as suggested by JP. * "Similar to the access points, actuator nodes do not suffer from any long-term resource constraints." what about battery-operated actuators ? [CJ] I'll leave that one to my colleagues :-) [Mischa] This is a difficult one. It clearly depends on the application, which even in the urban context can be infinite. There will be applications where acting nodes just switch something or reset something and hence need minimal energy allowing them to operate on batteries and hence be < resource constrained >. Other applications will require actuators which need to do heavy stuff with loads of energy, one hence needs the mains. I propose to change it to reflect the two cases < Actuator node may also suffer from any . > Section 3.1.4 ########### * "pollution data, such as polluting gases (SO2, NOx, CO, Ozone), heavy metals (e.g. Mercury), pH, radioactivity, etc;" => please expand acronym when first used. [CJ] Hmmm...I don't see too many acronyms in that sentence, actually. This is chemistry stuff, unless you're suggesting we provide the "lettered" designation of these substances like carbon oxyde, etc.? I wouldn't go that way... [Mischa] :-) I agree with Christian. Let's leave that basic stuff which I think is part of SI and hence does not need to spelled out. * "These meters will be capable of advanced sensing functionalities such as measuring quality of service, providing granular interval data, or automating the detection of alarm conditions." You may want to more accurately define the term "quality of service" since as you know, we used that term of other purposes in IETF documents. [CJ] Agreed. Since this is a list of examples, I would suggest something like "measuring the quality of the water provided to the customers". [Mischa] I agree with both. * In addition they may be capable of advanced interactive functionalities such as remote service disconnect or remote demand reset." => in this case, they are also acting as actuators. [CJ] Agreed. [Mischa] I agree. Section 3.2 ######### * s/ between one other/between each other [CJ] OK. * "The network MUST be capable of supporting the organization of a large number of sensing nodes into regions containing on the order of 10^2 to 10^4 sensing nodes each." JP> Thanks to make this "MUST" routing-specific and move it to the requirements section. [CJ] Agreed - would suggest this should be the introductory sentence of section 6.1. [Mischa] I agree with both. Section 3.3 ######### * RFID: expand acronym (Radio Frequency IDentification) and add to the terminology section [CJ] OK. * s/battery-powered nodes/battery powered nodes [CJ] OK. "Sensor nodes are capable of forwarding data." In other words, they can act as routers. No need to repeat this here. [CJ] Fair enough. Section 3.4 ######### * "2. packet errors due to medium access control;" JP> It is not really "packet error" here. [CJ] Do you mean "transmission erros"? If so, I would agree with you that this wording is better, but then I guess it should be used for first three cases, right? [Mischa] Collision resulting from poor MAC yield packet errors. We had discussed this section numerous times. I propose to leave it as is. * Some available protocols may cause packets of neighbouring nodes to collide and hence cause a link outage." JP> You may want to be more specific "Some" ? [CJ] Do you mean examples, because the previous sentence mentions the L2 protocols this sentence refers to? [Mischa] Yes, this is a L 2 issue and I am a little confused here : at one iterative point you insist to minimize if not delete all references to L2 and here you ask to be more specific. I give you an example for you to understand but propose this not to be included : reservation based MACs can guarantee a collision-free schedule whereas contention-based MACs, MACs with common schedules and preamble-based MACs cannot. Therefore < some >. * "if ISM bands are to be used. For instance, if the 2.4GHz ISM band is used to facilitate communication between U-LLN nodes, then heavily loaded WLAN hot-spots become a detrimental performance factor jeopardizing the functioning of the U-LLN." JP> Please expand acronym when first used and add to the terminology section (ISM, WLAN, ...) [CJ] OK. * Don't you want to say a few words about the varying BER leading to potentially even higher packet error loss ratio? [CJ] Expand the acronym ;-) I agree, bit error rate considerations should deserve a couple of sentences in this section. [Mischa] We purposedly don't talk about BER but about PER - they are VERY different, mainly because you can use different channel codes. For instance, a BCH code which is capable of correcting 5 errors does not care much about small BER variations. Large changes, however, will effect the performance but we are effecitvely interested in PER. I personally think that all needed information is in there. Section 4.1 ######### * "Pre-programmed MAC": expand acronym [CJ] OK. * "the autonomous organization" => self-organizing? [CJ] Much better indeed. * "For example, nodes in urban sensor nodes SHOULD be able to:" => Several of the requirements that follow are nor routing specific. You may either want to change the SHOULD for a "should" or just focus on the routing aspects and move them to the routing requirements section. [CJ] They may not be routing specific, but I think they do affect how routing policies are enforced. I woudl therefore suggest we stick to the proposed wording. [Mischa] I tend to agree with Christian. * "o Dynamically compute, select and possibly optimize the (multiple) path(s) that will be used by the participating devices to forward the traffic towards the actuators and/or the access point according to the service-specific and traffic-specific QoS, traffic engineering and security policies that will have to be enforced at the scale of a routing domain (that is, a set of networking devices administered by a globally unique entity), or a region of such domain (e.g. a metropolitan area composed of clusters of sensors)." JP> You list important and stringent requirements here. Do you really need a routing algorithms capable of computing a path on a per QoS/service specific/... Basis ? [CJ] I don't read this sentence as you do. What I meant here is that entities that operate urban sensor networks specify their own policies (routing, te, security, QoS, etc.), which may be service-specific. The requirement suggests that the devices involved in the enforcement of such policies should behave accordingly, that is, compute, select, establish and maintain paths whose characteristics comply with these policies. But I agree this is a strong requirement, but not stronger than, say, the self-organization requirement. [Mischa] We only need to make sure that this is not a MUST requirement because there are solutions out there which don't need all these computations. Section 4.2 ######### * "After the initialization phase and possibly some operational time, new nodes may be injected into the network as well as existing nodes removed from the network. The former might be because a removed node is replaced or denser readings/actuations are needed or routing protocols report connectivity problems. " JP> Just to avoid any mis-interpretation when referring to routing problem, you mean that it may be desirable to inject to node because connectivity is not sufficient (lack of enough redundant path, ...) and not because of a routing issue per say. [CJ] Not necessarily because connectivity is insufficient (new services, network expansion, node maintenance, etc.), and not necessarily because there is a routing issue, indeed. * "Differentiation SHOULD be made between node disappearance, where the node disappears without prior notification, and user or node-initiated disassociation ("phased-out"), where the node has enough time to inform the network about its removal." JP> Again this is not a routing requirement. Unless you refer to the ability for the routing protocol to advertise to the rest of the network that it will be removed in order for the other node to re-compute their path and avoid traffic disruption (e.g. Similarly to what we do with the ISIS overload bit for example.) Is it what you mean ? [CJ] This is indeed what we meant (at least that's my reading of this sentence, but I'll let my colleagues further comment on that). [Mischa] Yes, this is what we mean. If so, please clarify and move the routing requirement (SHOULD in capital letter to the routing requirement section). [CJ] OK. * "The protocol(s) hence SHOULD support the pinpointing of problematic routing areas" JP> Could you clarify what you mean by "pinpointing" since it could be interpreted in many ways? [CJ] Fair enough, we need to be more explicit. Maybe something like: "the protocol should be able to convey information about malfunctioning nodes which may affect or jeopardize the overall routing efficiency, so that self-configuration capabilities of the sensor network might be solicited to facilitate the appropriate reconfiguration." [Mischa] And I would add < This information may e.g. be in the form of exact or relative geographical position, etc. > * The following section also requires some clarification - you wrote: "Furthermore, to inform the access point(s) of the node's arrival and association with the network as well as freshly associated nodes about packet forwarding schedules, roles, etc, appropriate (link state) updating mechanisms SHOULD be supported." JP> Are you explicitly requiring a Link State routing protocol or a routing protocol that provides information about link states or ... ? [CJ] We meant "a protocol that can provide information about link status", indeed. [Mischa] I remind you however that this is SHOULD and not MUST. Note that a requirement document should stay solution agnostic and stay focus on the requirement. [CJ] Fully agreed. Is you requirement that any node needs to have visibility on other node characteristics with no attempt of aggregation? [CJ] Well, yes, presumably depending on design considerations: cluster head vs. clients within the cluster, for example. I think this is typical Self Organizing Networking capability. Section 4.3 ######### * "The protocol(s) hence MUST support a large number of highly directional unicast flows from the sensing nodes or sensing clusters towards the access point or highly directed multicast or anycast flows from the nodes towards multiple access points." JP> I think that what you mean is that the routing protocol MUST be optimized for Multipoint-to-Point traffic patterns (from sensors/actuators to Sink). As written, it is not clear whether you refer to it as a routing requirement ? [CJ] Agreed. [Mischa] No, our requirement is stronger. Multipoint can be from many < some where > nodes to one sink. What we mean is many < geographically close > nodes to one sink. This is an underlying property of WSNs and our routing solutions HEAVILY rely on this. This in fact what you wrote in section 6.5: "To this end, the routing protocol(s) SHOULD support and utilize the fact of highly directed traffic flow to facilitate scalability and parameter constrained routing." [CJ] Correct. * s/ More generally, entire routing areas may be avoided at e.g. night but heavily used during the day when nodes are scavenging from sunlight/ More generally, entire routing areas may be avoided (e.g. at night) but heavily used during the day when nodes are scavenging from sunlight. JP> Doesn't this translate to the requirement for time-based routing (some form of policy routing) ? [CJ] Correct, but I don't see any harm in providing a practical example. [Mischa] I agree with Christian. Section 4.4 ######### "However, they are not very stringent where latencies SHOULD simply be sufficiently smaller than typical reporting intervals" JP> This is certainly true but not a routing requirement but a data plane requirement unless you refer to the ability to support QoS aware routing where each node may want to be able to compute different paths depending on the traffic requirements? [CJ] This is indeed related to the third bullet that appears in section 4.1. * Move "U-LLN network devices SHOULD support unicast and multicast routing capabilities" to the routing requirement section. You may want to leave the sentence here (without a SHOULD). [CJ] OK. * You use the term "anycast" that has been discussed in the past, in particular in the context of the Home routing requirement document. I would suggest to define this term in the document, refer to RFC4291 or RFC1546, ... [CJ] Fully agreed. Section 4.5 ######### * "An alarm is likely being registered by a plurality of sensing nodes where the delivery of a single alert message with its location of origin suffices in most cases." Then you provide the example of toxic gas level. This is one example where it might be desirable not to perform data aggregation/fusion and get multiple copies of the same message from different source to perform "triangulation" and better localize the incident. [CJ] Agreed, but I think this example precisely illustrates the issue. * "Routing within urban sensor networks SHOULD require the U-LLN nodes to dynamically compute, select and install different paths towards a same destination, depending on the nature of the traffic. From this perspective, such nodes SHOULD inspect the contents of traffic payload for making routing and forwarding decisions: JP> This clarifies my previous question; you do refer to ability to compute different paths (with different characteristic). Note that the path selection process performed by the sender and potentially routers along the path is not strictly speaking a routing requirement. Move this requirement to the requirement section. [CJ] OK. * "for example, the analysis of the traffic payload SHOULD be derived into aggregation capabilities for the sake of forwarding efficiency." JP> Can you clarify what you mean here? [CJ] The analysis of the payload of several packets should help in making forwarding decisions that will spare network resources. * "Delays and latencies are important; however, again, deliveries within seconds SHOULD suffice in most of the cases." JP> Clearly not a routing requirement! [CJ] Agreed. Section 5 ######## * "The network SHOULD take into consideration that different application traffic may require different priorities when traversing the network, and that some traffic may be more sensitive to latency." JP> If by priorities you mean different routes with different characteristics then this is fine and already covered. If you refer to packet marking to provide different QoS in the data plane, this is not a routing requirement. [CJ] Agreed - the former is the correct interpretation. * "An U-LLN SHOULD support occasional large scale traffic flows from sensing nodes to access points, such as system-wide alerts. " and "A node MUST be able to send its own alerts toward an access point while continuing to forward traffic on behalf of other devices who are also experiencing an alert condition. The network MUST be able to manage this sudden large traffic flow." JP> Not routing requirements. Unless ... You require the ability to compute multiple paths and use all of them (symmetrical or asymmetrical routing ???) to spread out the traffic and limit network delays ? [CJ] I think this is a kind of causality effect: the routing protocol must be able to accommodate traffic bursts by dynamically computing and selecting multiple paths towards the same destination. [Mischa] Agreed. * You make an interesting reference to Smart Grid and DR/DSM. That said, you wrote "The network SHOULD support internetworking, while giving attention to security implications of interfacing, for example, a home network with a utility U-LLN." JP> Don't you mean that the routing protocol must be able to potentially interact via potential route redistribution with other routing protocol used in the Internet, should these two protocols not be identical ? [CJ] Correct. Section 6 ######### * S/Current urban roll-outs are composed of sometimes more than a hundred nodes/ Current urban roll-outs are composed of sometimes more than one hundred nodes [CJ] OK. * " The routing protocols(s) SHOULD support the organization of a large number of nodes into regions of to-be-specified size." JP> It will be difficult (or too easy ;-)) to be compliant with that SHOULD with a to-be-specified size. Or did you mean "configurable" ? [CJ] Configurable is indeed much better. * "To this end, the routing protocol(s) MUST support parameter constrained routing, where examples of such parameters (CPU, memory size, battery level, etc.) have been given in the previous paragraph." JP> Please use the term "node constrained based routing" [CJ] I'm not sure I agree here, because "node-constrained" sounds more fuzzy to me. "environment-constrained"? [Mischa] Parameter constrained is the right word. For instance node internal parameters (CPU, etc) and also environment parameters (avilability of sun and therefore availability of energy due to energy scavanging, etc) * "For the latter, the protocol(s) MUST support multi- and any-cast addressing. The protocol(s) SHOULD also support the formation and identification of groups of field devices in the network." JP> You may want to more accurately define the term "anycast" [CJ] Would the couple of references you righfully mentioned earlier be sufficient? * " To mandate fully interoperable implementations, the routing protocol(s) proposed in U-LLN MUST support different devices and underlying technologies without compromising the operability and energy efficiency of the network." JP> This requires clarification here. Do you mean that the routing protocol MUST support node constrained based routing? If so, it is already stated above. The support of different L1/L2 is a given (route over). [CJ] I would agree with Jean-Philippe, and suggest we remove this wording...but I'll let the co-authors further comment. [Mischa] Imagine a network composed of simple ZigBee nodes and a few WLAN nodes which have a ZigBee interface. An optimum solution will use the WLAN nodes as a virtual information backbone and connect the ZigBee nodes to the WLAN nodes. You can turn this as you want but an optimal routing solution would never treat nodes of different capabilities the same (eg build a flat routing structure). Therefore, any routing algorithm should ideally make use of this heterogeneity. I would be happy to change this MUST for SHOULD (which is what I had proposed, I think, a few weeks ago). * Section 6.8, as written, is not related to routing but data plane. Let me be more specific: * "To this end, the routing protocol(s) SHOULD support minimum latency for alert reporting and time-critical data queries." JP> The support of minimum latency path (data plane !) or the support for different metric path (control plane) ? [CJ] As written, I read it as the former interpretation and would suggest we remove the text. * "For regular data reporting, it SHOULD support latencies not exceeding a fraction of the smallest reporting interval. " JP> Not a routing requirement. Even if you are referring to a bound on the total path metric (the metric reflecting the delay in this case), this is an implementation issue. [CJ] Correct. * "Due to the different latency requirements, the routing protocol(s) SHOULD support the ability of dealing with different latency requirements. The routing protocol(s) SHOULD also support the ability to route according to different metrics (one of which could e.g. be latency)." JP> yes these are routing requirements although I would suggest to remove the first sentence, the requirement being captured in the second sentence. [CJ] Agreed. Section 7 ######### * "As every network, U-LLNs are exposed to security threats that MUST be addressed." JP> You cannot put a MUST here unless you list the routing security threats. [CJ] OK. * s/ potential security threats/ potential routing security threats => JP> Please use the term "routing security" in place of "security" throughout the section. [CJ] OK. * "U-LLN networks SHOULD support mechanisms to preserve the confidentiality of the traffic that they forward. The U-LLN network SHOULD NOT prevent an application from employing additional confidentiality mechanisms." JP> I do agree with the requirement but this is not a routing requirement. [CJ] Fair enough. Could you focus on the routing security issues ? Or are you referring to the routing traffic confidentiality ? [CJ] No, this wording referred to the traffic forwarded by the network. This is what you do right after: [CJ] Correct. " The U-LLN MUST be protected against attempts to inject false or modified packets. For example, an attacker SHOULD be prevented from manipulating or disabling the routing function by compromising routing update messages. Moreover, it SHOULD NOT be possible to coerce the network into routing packets which have been modified in transit. To this end the routing protocol(s) MUST support message integrity." JP> I do not see any reference to the type of routing attacks that could be performed on such networks because of the typical P2MP traffic pattern, extensive use of wireless links, ... [CJ] OK, but does that mean we should not consider such requirement? I don't think so, afaic. JP> What I would suggest is to re-focus on the routing security issues with the Security expert that will get appointed. [CJ] OK. Reference section ############### The current reference section reads: 11.2. Informative References [I-D.brandt-roll-home-routing-reqs] Brandt, A., "Home Automation Routing Requirement in Low Power and Lossy Networks", draft-brandt-roll-home-routing-reqs-01 (work in progress), May 2008. JP> Please update to draft-ietf-roll-home-routing-reqs and add the reference to draft-ietf-roll-indus-routing-reqs [CJ] OK. [I-D.culler-rl2n-routing-reqs] Vasseur, J. and D. Cullerot, "Routing Requirements for Low Power And Lossy Networks", draft-culler-rl2n-routing-reqs-01 (work in progress), July 2007. JP> This one can be removed. [CJ] OK. Last comment: please check that you expand acronyms when first used. [CJ] OK. Cheers, Christian. ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** ------=_NextPart_000_00BE_01C90449.1CA63C70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-roll-urban-routing-reqs-01

Thanks, JP, indeed, for this in-depth review. = I propose that Tim takes care of all the small typos identified by JP. = Some comments in-line in addition to Christian ones. Thanks to all and kind = regards, Mischa.

 

From: christian.jacquenet@orange-ftgroup.com [mailto:christian.jacquenet@orange-ftgroup.com]
Sent: Thursday, August = 21, 2008 11:02 PM
To: JP Vasseur; Mischa = Dohler; Tim Winter; WATTEYNE Thomas RD-TECH; MADHUSUDAN Giyyarpuram RD-TECH; = CHEGARAY Gabriel RD-TECH; BARTHEL Dominique RD-TECH; roll@ietf.org
Cc: David E. Culler
Subject: RE: Review of = draft-ietf-roll-urban-routing-reqs-01

 

Dear = all,

 

Thanks = to Jean-Philippe for this thorough review. Please find a first shot of = personal comments inline, but I'll let my fellow co-authors further elaborate accordingly.

 

[CJ] [snip] 
Abstract
#######
s/ for a wireless ROLL solution to be useful the protocol(s) ought to be energy-efficient, scalable, and autonomous/ the routing solution ought = to be energy-efficient, scalable and autonomous.

JP> You may want to use a different word than = “Autonomous”. Do you refer to the “self configuration” property ?
[CJ] We chose "autonomous" because it was generic enough, while I = think "self configuration" is too restrictive: it's not only a = matter of configuration, it's also a matter of making (forwarding) decisions, self-healing capabilities, etc. Another word I would suggest is "self-organizing", if this is more = specific. 
[Mischa] We had long = discussions on this and finally converged to « autonomous ». = Let’s leave it. 


Section 1
#######
* “Section 6 discusses the routing requirements for networks = comprising
   such constrained devices in a U-LLN environment. =  These requirements
   may be overlapping requirements derived from other application-
   specific requirements documents or as listed in
   [I-D.culler-rl2n-routing-reqs].”

JP> Please remove this reference (ID abandoned) and insert reference = to http://www.ietf.org/internet-drafts/draft-ietf= -roll-home-routing-reqs-02.txt, http://www.ietf.org/internet-drafts/draft-ietf= -roll-indus-routing-reqs-01.txt and http://www.ietf.org/internet-drafts/draft-mart= occi-roll-commercial-routing-reqs-00.txt<= font size=3D2 face=3DCalibri>.
[CJ] OK. 

* s/ Section 7 provides an overview of security considerations/ Section = 7 provides an overview of routing security considerations
[CJ] OK. 

Section 2
########

* S/ ROLL: Routing over Low power and Lossy networks/ ROLL: Routing Over = Low power and Lossy networks
[CJ] OK. 

* Schedule:  An agreed execution, wake-up, transmission, = reception,
         etc., time-table = between two or more field devices.
The definition is a little bit too vague. If used in the generic sense, = no need to add it to the terminology section. Otherwise, it ought to be more = specific.
[CJ] Schedule is indeed very generic, but I think the sue of the word makes = perfect sense in the context of U-WSN networks. Being more specific would mean elaborating on use cases where schedule information is taken into = account by field devices to perform some specific action. If this proposal makes = sense, I'm not sure the terminology section is appropriate for such elaboration = and would therefore suggest we (1) keep the "schedule" definition = in this section and (2) further elaborate on a use case that illustrates the use = of schedule information in section 5 of the draft. 

[Mischa] = I don’t see why this is vague. This is very clear to me. Let’s leave it as = is (I guess we do not need to find the maximum entropy of this document; the = routing solution won’t get better due to this J).



Section 3.1.1
###########
* S/ pre- planned location/ pre-planned location
[CJ] OK. 

* What you refer to as a repeater is in fact a router. What I would = suggest here is to reword this paragraph to indicate that some nodes are simple = routers whereas other nodes are routers and lso perform sensing/actuating task. = Insert this paragraph after the Actuators and Sensors paragraphs.
[CJ] So you're suggesting to (1) remove section 3.1.2 (not 3.1.1, actually), and = (2) indicate that some nodes are routers (not "simple", btw :-), = others also perform sensing/actuating tasks, right? I'm fine with this = suggestion, but I'd like to hear the feedback from my colleagues. It's also worth = mentioning that a "repeater" has a very specific meaning in "classical" networking environments, remembering the old days = of FOIRL and the like...that may be another reason to avoid the use of this = notion within the roll context.
[Mischa] We had this = discussion before and the reason outlined by Christian is exactly why the thingy is called repeater and not router.

 

* “Actuators may generally be mobile = but are likely to be static in the majority of near-future roll-outs”: = seems a bit contradictory. Don’t you want to simply say that in a = near-future the majority will be static?
[CJ] Not quite, because actuators can be devices used by people who move = from one place to another to check how the sensor network is doing. I = think both cases are valid, and would therefore stick to the current = wording. 

[Mischa] When I = wrote this I had more in mind what JP said in shortened form. I personally = hence propose to change as suggested by JP.<= /p>



* “Similar to the access points, actuator nodes do not suffer from = any long-term resource constraints.” what about battery-operated = actuators ?
[CJ] I'll leave that one to my colleagues :-) 
[Mischa] This is a difficult = one. It clearly depends on the application, which even in the urban context can = be infinite. There will be applications where acting nodes just switch = something or reset something and hence need minimal energy allowing them to = operate on batteries and hence be « resource constrained ». = Other applications will require actuators which need to do heavy stuff with = loads of energy, one hence needs the mains. I propose to change it to reflect the = two cases « Actuator node may also suffer from any = … »  


Section 3.1.4
###########
* “pollution data, such as polluting gases (SO2, NOx, CO, = Ozone),
 heavy metals (e.g.  Mercury), pH, radioactivity, etc;” = =3D> please expand acronym when first used.
[CJ] Hmmm...I don't see too many acronyms in that sentence, actually. This is = chemistry stuff, unless you're suggesting we provide = the "lettered" designation of these substances like carbon oxyde, etc.? I wouldn't go = that way... 

[Mischa] J I agree with Christian. Let’s leave that basic stuff = which I think is part of SI and hence does not need to spelled = out.<= /p>



* “These meters will be capable of
   advanced sensing functionalities such as measuring = quality of
   service, providing granular interval data, or = automating the
   detection of alarm conditions.”
You may want to more accurately define the term “quality of service” since as you know, we used that term of other purposes in = IETF documents.
[CJ] Agreed. Since this is a list of examples, I would suggest something like "measuring the quality of the water provided to the = customers".
[Mischa] I agree with = both.


* In addition they may be capable of
   advanced interactive functionalities such as remote = service
   disconnect or remote demand reset.” =3D> in = this case, they are also acting as actuators.
[CJ] Agreed. 
[Mischa] I = agree.


Section 3.2
#########

* s/ between one other/between each other
[CJ] OK. 

* “The network MUST be capable of supporting the organization = of
   a large number of sensing nodes into regions = containing on the order
   of 10^2 to 10^4 sensing nodes each.”
JP> Thanks to make this “MUST” routing-specific and move = it to the requirements section.
[CJ] Agreed - would suggest this should be the introductory sentence of section = 6.1. 
[Mischa] I agree with = both.


Section 3.3
#########

* RFID: expand acronym (Radio Frequency IDentification) and add to the terminology section
[CJ] OK. 

* s/battery-powered nodes/battery powered nodes
[CJ] OK. 
“Sensor nodes are capable of forwarding data.” In other = words, they can act as routers. No need to repeat this here.
[CJ] Fair enough. 

Section 3.4
#########

* “2.  packet errors due to medium access control;” = JP> It is not really “packet error” here.
[CJ] Do you mean "transmission erros"? If so, I would agree with you that = this wording is better, but then I guess it should be used for first three = cases, right? 
[Mischa] Collision resulting = from poor MAC yield packet errors. We had discussed this section numerous times. I propose to leave it as is.


* Some available protocols may cause packets of neighbouring nodes to = collide and hence cause a link outage.” JP> You may want to be more = specific “Some” ?
[CJ] Do you mean examples, because the previous sentence mentions the L2 protocols = this sentence refers to?
[Mischa] Yes, this is a = L 2 issue and I am a little confused here : at one iterative point you insist = to minimize if not delete all references to L2 and here you ask to be more specific. I give you an example for you to understand but propose this = not to be included : reservation based MACs can guarantee a collision-free schedule whereas contention-based MACs, MACs with common schedules and preamble-based MACs cannot. Therefore = « some ». 


* “if ISM bands are to be used.  For instance, if the 2.4GHz = ISM band is
   used to facilitate communication between U-LLN nodes, = then heavily
   loaded WLAN hot-spots become a detrimental performance = factor
   jeopardizing the functioning of the U-LLN.”
JP> Please expand acronym when first used and add to the terminology = section (ISM, WLAN, ...)
[CJ] OK. 

* Don’t you want to say a few words about the varying BER leading = to potentially even higher packet error loss ratio?
[CJ] Expand the acronym ;-) I agree, bit error rate considerations should deserve a = couple of sentences in this section. 
[Mischa] We purposedly = don’t talk about BER but about PER – they are VERY different, mainly because = you can use different channel codes. For instance, a BCH code which is capable = of correcting 5 errors does not care much about small BER variations. Large changes, however, will effect the performance but we are effecitvely = interested in PER. I personally think that all needed information is in there. =


Section 4.1
#########

* “Pre-programmed MAC”: expand acronym
[CJ] OK. 

* “the autonomous organization” =3D> self-organizing?
[CJ] Much better indeed. 

* “For example, nodes in urban sensor nodes SHOULD be able = to:” =3D> Several of the requirements that follow are nor routing = specific. You may either want to change the SHOULD for a “should” or just = focus on the routing aspects and move them to the routing requirements = section.
[CJ] They may not be routing specific, but I think they do affect how routing = policies are enforced. I woudl therefore suggest we stick to the proposed = wording. 
[Mischa] I tend to agree = with Christian.


* “o  Dynamically compute, select and possibly optimize the (multiple)
      path(s) that will be used by the participating devices to forward
      the traffic towards the actuators = and/or the access point
      according to the service-specific = and traffic-specific QoS,
      traffic engineering and security = policies that will have to be
      enforced at the scale of a routing = domain (that is, a set of
      networking devices administered by a globally unique entity), or a
      region of such domain (e.g. a = metropolitan area composed of
      clusters of sensors).”
JP> You list important and stringent requirements here. Do you really = need a routing algorithms capable of computing a path on a per QoS/service specific/... Basis ?
[CJ] I don't read this sentence as you do. What I meant here is that entities that = operate urban sensor networks specify their own policies (routing, te, security, = QoS, etc.), which may be service-specific. The requirement suggests that the = devices involved in the enforcement of such policies should behave accordingly, = that is, compute, select, establish and maintain paths whose characteristics = comply with these policies. But I agree this is a strong requirement, but not = stronger than, say, the self-organization requirement.
[Mischa] We only need to = make sure that this is not a MUST requirement because there are solutions out there = which don’t need all these computations.


Section 4.2
#########

* “After the initialization phase and possibly some operational = time,
   new nodes may be injected into the network as well as existing nodes
   removed from the network.  The former might be = because a removed node
   is replaced or denser readings/actuations are needed = or routing
   protocols report connectivity problems. “
JP> Just to avoid any mis-interpretation when referring to routing = problem, you mean that it may be desirable to inject to node because connectivity = is not sufficient (lack of enough redundant path, ...) and not because of a = routing issue per say.
[CJ] Not necessarily because connectivity is insufficient (new services, network expansion, node maintenance, etc.), and not necessarily because there is = a routing issue, indeed. 

* “Differentiation
   SHOULD be made between node disappearance, where the = node disappears
   without prior notification, and user or node-initiated disassociation
   ("phased-out"), where the node has enough = time to inform the network
   about its removal.”
JP> Again this is not a routing requirement. Unless you refer to the = ability for the routing protocol to advertise to the rest of the network that it = will be removed in order for the other node to re-compute their path and = avoid traffic disruption (e.g. Similarly to what we do with the ISIS overload = bit for example.) Is it what you mean ?
[CJ] This is indeed what we meant (at least that's my reading of this sentence, but = I'll let my colleagues further comment on that). 

[Mischa] Yes, = this is what we mean.<= /p>

If so, please clarify and move the routing requirement (SHOULD in capital letter to the routing requirement = section).
[CJ] OK. 

* “The protocol(s) hence SHOULD support the pinpointing of = problematic routing areas”
JP> Could you clarify what you mean by “pinpointing” = since it could be interpreted in many ways?
[CJ] Fair enough, we need to be more explicit. Maybe something like: = "the protocol should be able to convey information about malfunctioning nodes = which may affect or jeopardize the overall routing efficiency, so that self-configuration capabilities of the sensor network might be solicited = to facilitate the appropriate reconfiguration."

[Mischa] And I = would add « This information may e.g. be in the form of exact or = relative geographical position, etc. »<= /p>



* The following section also requires some clarification – you = wrote:
“Furthermore, to inform the
   access point(s) of the node's arrival and association = with the
   network as well as freshly associated nodes about = packet forwarding
   schedules, roles, etc, appropriate (link state) = updating mechanisms
   SHOULD be supported.”
JP> Are you explicitly requiring a Link State routing protocol or a = routing protocol that provides information about link states or ... ?
[CJ] We meant "a protocol that can provide information about link = status", indeed. 
[Mischa] I remind you = however that this is SHOULD and not MUST.

Note that a requirement document should stay solution agnostic and stay focus on the requirement.
[CJ] Fully agreed. 

Is you requirement that any node needs to = have visibility on other node characteristics with no attempt of = aggregation?
[CJ] Well, yes, presumably depending on design considerations: cluster head = vs. clients within the cluster, for example. I think this is typical = Self Organizing Networking capability.

Section 4.3
#########

* “The protocol(s) hence MUST support a large number of highly
   directional unicast flows from the sensing nodes or = sensing clusters
   towards the access point or highly directed multicast = or anycast
   flows from the nodes towards multiple access = points.”
JP> I think that what you mean is that the routing protocol MUST be optimized for Multipoint-to-Point traffic patterns (from = sensors/actuators to Sink). As written, it is not clear whether you refer to it as a routing requirement ?
[CJ] Agreed. 

[Mischa] No, = our requirement is stronger. Multipoint can be from many « some = where » nodes to one sink. What we mean is many « geographically = close » nodes to one sink. This is an underlying property of WSNs and our = routing solutions HEAVILY rely on this.


This in fact what you wrote in section 6.5: “To this end, the = routing protocol(s) SHOULD support and utilize the fact of highly directed = traffic flow to facilitate scalability and parameter constrained routing.”
[CJ] Correct. 

* s/ More generally, entire routing areas may be avoided at e.g. night = but heavily used during the day when nodes are scavenging from sunlight/ = More generally, entire routing areas may be avoided (e.g. at night) but = heavily used during the day when nodes are scavenging from sunlight.
JP> Doesn’t this translate to the requirement for time-based = routing (some form of policy routing) ?
[CJ] Correct, but I don't see any harm in providing a practical = example. 
[Mischa] I agree with = Christian.


Section 4.4
#########

“However, they are not very stringent where
   latencies SHOULD simply be sufficiently smaller than = typical
   reporting intervals”
JP> This is certainly true but not a routing requirement but a data = plane requirement unless you refer to the ability to support QoS aware routing = where each node may want to be able to compute different paths depending on = the traffic requirements?
[CJ] This is indeed related to the third bullet that appears in section = 4.1. 

* Move “U-LLN network devices SHOULD support unicast and multicast routing capabilities” to the routing requirement section. You may = want to leave the sentence here (without a SHOULD).
[CJ] OK. 

* You use the term “anycast” that has been discussed in the = past, in particular in the context of the Home routing requirement document. I = would suggest to define this term in the document, refer to RFC4291 or = RFC1546, ...
[CJ] Fully agreed.

Section 4.5
#########

* “An alarm is likely being
   registered by a plurality of sensing nodes where the = delivery of a
   single alert message with its location of origin = suffices in most
   cases.”
Then you provide the example of toxic gas level. This is one example = where it might be desirable not to perform data aggregation/fusion and get = multiple copies of the same message from different source to perform “triangulation” and better localize the incident.
[CJ] Agreed, but I think this example precisely illustrates the = issue. 

* “Routing within urban sensor networks SHOULD require the U-LLN = nodes
   to dynamically compute, select and install different = paths towards a
   same destination, depending on the nature of the = traffic.  From this
   perspective, such nodes SHOULD inspect the contents of traffic
   payload for making routing and forwarding decisions: =

JP> This clarifies my previous question; you do refer to ability to = compute different paths (with different characteristic). Note that the path = selection process performed by the sender and potentially routers along the path = is not strictly speaking a routing requirement.
Move this requirement to the requirement section.
[CJ] OK. 

* “for example, the analysis of the traffic payload SHOULD be = derived into aggregation
   capabilities for the sake of forwarding = efficiency.”
JP> Can you clarify what you mean here?
[CJ] The analysis of the payload of several packets should help in making forwarding decisions that will spare network = resources.

* “Delays and latencies are
   important; however, again, deliveries within seconds = SHOULD suffice
   in most of the cases.”
JP> Clearly not a routing requirement!
[CJ] Agreed. 

Section 5
########

* “The network SHOULD take into consideration that different = application
   traffic may require different priorities when = traversing the network,
   and that some traffic may be more sensitive to latency.”
JP> If by priorities you mean different routes with different characteristics then this is fine and already covered. If you refer to = packet marking to provide different QoS in the data plane, this is not a = routing requirement.
[CJ] Agreed - the former is the correct interpretation. 

* “An U-LLN SHOULD support occasional large scale traffic flows = from
   sensing nodes to access points, such as system-wide = alerts. “ and “A node MUST be able to send its own alerts toward an = access
   point while continuing to forward traffic on behalf of = other devices
   who are also experiencing an alert condition. =  The network MUST be
   able to manage this sudden large traffic = flow.”
JP> Not routing requirements. Unless ... You require the ability to = compute multiple paths and use all of them (symmetrical or asymmetrical routing = ???) to spread out the traffic and limit = network delays ?
[CJ] I think this is a kind of causality effect: the routing protocol must be able to accommodate traffic bursts by dynamically computing and selecting = multiple paths towards the same destination. 
[Mischa] = Agreed.


* You make an interesting reference to Smart Grid and DR/DSM. That said, = you wrote “The network SHOULD support internetworking, while giving = attention to security implications of interfacing, for example, a home network = with a utility U-LLN.”
JP> Don’t you mean that the routing protocol must be able to potentially interact via potential route redistribution with other = routing protocol used in the Internet, should these two protocols not be = identical ?
[CJ] Correct. 
 

Section 6
#########

* S/Current urban roll-outs are composed of sometimes more than a = hundred nodes/ Current urban roll-outs are composed of sometimes more than one = hundred nodes
[CJ] OK. 

* “ The routing protocols(s) SHOULD support the organization of a = large number of nodes into regions of to-be-specified size.”
JP> It will be difficult (or too easy ;-)) to be compliant with that = SHOULD with a to-be-specified size. Or did you mean “configurable” = ?
[CJ] Configurable is indeed much better. 

* “To this end, the routing protocol(s) MUST support parameter
   constrained routing, where examples of such parameters = (CPU, memory
   size, battery level, etc.) have been given in the = previous paragraph.”
JP> Please use the term “node constrained based = routing”
[CJ] I'm not sure I agree here, because "node-constrained" sounds more = fuzzy to me. "environment-constrained"? 
[Mischa] Parameter = constrained is the right word. For instance node internal parameters (CPU, etc) and also environment parameters (avilability of sun and therefore availability of = energy due to energy scavanging, = etc)


* “For the latter, the protocol(s) MUST support multi- and
   any-cast addressing.  The protocol(s) SHOULD also support the
   formation and identification of groups of field = devices in the
   network.”
JP> You may want to more accurately define the term = “anycast” 
[CJ] Would the couple of references you righfully mentioned earlier be = sufficient?

* “ To mandate fully interoperable implementations, the = routing
   protocol(s) proposed in U-LLN MUST support different = devices and
   underlying technologies without compromising the = operability and
   energy efficiency of the network.”
JP> This requires clarification here. Do you mean that the routing = protocol MUST support node constrained based routing? If so, it is already stated = above. The support of different L1/L2 is a given (route over).
[CJ] I would agree with Jean-Philippe, and suggest we remove this wording...but I'll = let the co-authors further comment. 
[Mischa] Imagine a network = composed of simple ZigBee nodes and a few WLAN nodes which have a ZigBee interface. = An optimum solution will use the WLAN nodes as a virtual information = backbone and connect the ZigBee nodes to the WLAN nodes. You can turn this as you = want but an optimal routing solution would never treat nodes of different = capabilities the same (eg build a flat routing structure). Therefore, any routing = algorithm should ideally make use of this heterogeneity. I would be happy to = change this MUST for SHOULD (which is what I had proposed, I think, a few weeks = ago).


* Section 6.8, as written, is not related to routing but data plane. Let = me be more specific:

* “To this end, the routing protocol(s) SHOULD support minimum = latency
   for alert reporting and time-critical data = queries.”
JP> The support of minimum latency path (data plane !) or the support = for different metric path (control plane) ?
[CJ] As written, I read it as the former interpretation and would suggest we = remove the text. 

* “For regular data
   reporting, it SHOULD support latencies not exceeding a fraction of
   the smallest reporting interval.  “
JP> Not a routing requirement. Even if you are referring to a bound = on the total path metric (the metric reflecting the delay in this case), this = is an implementation issue.
[CJ] Correct. 

* “Due to the different latency requirements, the routing = protocol(s) SHOULD support the ability of dealing with different latency = requirements.  The routing protocol(s) SHOULD also support the ability to route according to different metrics (one of which could e.g. be = latency).”
JP> yes these are routing requirements although I would suggest to = remove the first sentence, the requirement being captured in the second = sentence.
[CJ] Agreed. 

Section 7
#########

* “As every network, U-LLNs are exposed to security threats that = MUST be addressed.”
JP> You cannot put a MUST here unless you list the routing security = threats.
[CJ] OK. 

* s/ potential security threats/ potential routing security threats = =3D> JP> Please use the term “routing security” in place of “security” throughout the section.
[CJ] OK. 

* “U-LLN networks SHOULD support mechanisms to preserve the
   confidentiality of the traffic that they forward. =  The U-LLN network
   SHOULD NOT prevent an application from employing = additional
   confidentiality mechanisms.”
JP> I do agree with the requirement but this is not a routing = requirement.
[CJ] Fair enough. 

Could you focus on the routing security = issues ? Or are you referring to the routing traffic confidentiality ?
[CJ] No, this wording referred to the traffic forwarded by the = network.  
This is what you do right after:
[CJ] Correct. 
“ The U-LLN MUST be protected against attempts to inject false = or
   modified packets.  For example, an attacker = SHOULD be prevented from
   manipulating or disabling the routing function by compromising
   routing update messages.  Moreover, it SHOULD NOT = be possible to
   coerce the network into routing packets which have = been modified in
   transit.  To this end the routing protocol(s) = MUST support message
   integrity.”
JP> I do not see any reference to the type of routing attacks that = could be performed on such networks because of the typical P2MP traffic pattern, extensive use of wireless links, ...
[CJ] OK, but does that mean we should not consider such requirement? I don't think = so, afaic. 
JP> What I would suggest is to re-focus on the routing security = issues with the Security expert that will get appointed.
[CJ] OK. 

Reference section
###############

The current reference section reads:
11.2.  Informative References

   [I-D.brandt-roll-home-routing-reqs]
            &= nbsp; Brandt, A., "Home Automation Routing Requirement in Low
            &= nbsp; Power and Lossy Networks",
            &= nbsp; draft-brandt-roll-home-routing-reqs-01 (work in progress),
            &= nbsp; May 2008.

JP> Please update to draft-ietf-roll-home-routing-reqs and add the = reference to draft-ietf-roll-indus-routing-reqs
[CJ] OK. 

   [I-D.culler-rl2n-routing-reqs]
            &= nbsp; Vasseur, J. and D. Cullerot, "Routing Requirements for Low
            &= nbsp; Power And Lossy Networks",
            &= nbsp; draft-culler-rl2n-routing-reqs-01 (work in progress),
            &= nbsp; July 2007.

JP> This one can be removed.
[CJ] OK. 


Last comment: please check that you expand acronyms when first used.
[CJ] OK.

 

Cheers,

 

Christian. 

*********************************
This message and any attachments (the "message") are confidential and = intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, = changed or falsified.
If you are not the intended addressee of this message, please cancel it = immediately and inform the sender.
********************************
------=_NextPart_000_00BE_01C90449.1CA63C70-- --===============1115744616== 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 --===============1115744616==-- From roll-bounces@ietf.org Sun Aug 24 05:13: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 ED43A3A6B3E; Sun, 24 Aug 2008 05:13: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 8678F3A6B3E for ; Sun, 24 Aug 2008 05:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.152 X-Spam-Level: * X-Spam-Status: No, score=1.152 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001, MANGLED_TOOL=2.3, 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 8czpHGJehYJm for ; Sun, 24 Aug 2008 05:13:57 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id A9E4B3A689B for ; Sun, 24 Aug 2008 05:13:56 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7OCDpmo018903 for ; Sun, 24 Aug 2008 13:13:51 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7OCDoRM018897 for ; Sun, 24 Aug 2008 13:13:50 +0100 Message-ID: <046001c905e2$dd5b0f50$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Sun, 24 Aug 2008 13:13:46 +0100 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.3350 Subject: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel 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, As one of the two tourists who raised a hand in Dublin to express uneasiness about this I-D becoming a WG draft, I thought I should write a note about my concerns. I should caveat this by saying that I do appreciate the need for this work, and that the author-team will, I'm sure, do a fine job at delivering what the working group needs. My concerns were much more about getting the direction of the I-D right before accepting it as I think it is often harder to recast an I-D once it is within the working group. Below, please find my major discussion point. I have also done a review of the draft and found a bunch of issues/questions of more minor importance. Regards, Adrian === The analysis of the routing protocols is predicated on what they are currently used for. To some extent this is reasonable - the easiest analysis of a routing protocol is in its operational environment. But to use this analysis as the basis of a decision for use of a protocol in a new environment is not so reasonable. If you want to show that none of today's protocols has been designed for use in the ROLL environment, then I don't suppose anyone will be surprised. However, what we are really interested in is whether any of the existing protocols is suitable for adaptation for use in ROLL, whether the those adaptations would be contrived and technically hard (or flaky), and whether it would be more efficient to design a new protocol. For an example (and I'm not proposing this as the solution for ROLL), an IGP could easily be adapted to flood on only certain links, to discard certain LSAs, and to build a FIB according to specific rules. This would not be a large change to the protocol, although it would obviously not be interoperable. To discard from consideration any protocol based on its behavior in a certain environment without setting it in the context of your forwarding paradigm and without examining the potential to adapt a protocol to that environment is wrong. If all you wanted to do was show that no current variant of any existing routing protocol is immediately applicable to ROLL, then that would be easy and would not be a surprise. But to imply that protocols are not open for adaptation is more serious. This is not to say that inventing a new protocol would be wrong or not fun. Only that your reasons for discarding protocols are poorly founded. You have focused on the operation of the routing protocol, not the purpose of the routing protocol. To give a better understanding of why you are discarding a protocol, you must show what you want to achieve as your forwarding paradigm. The requirements documents make some start at this. For example, draft-ietf-roll-urban-routing-reqs talks about: - routing to minimise power usage - routing to consider node and link capabilities - routing protocol to scale within CPU, memory and power limits - routing according to different metrics (latency is cited) Such considerations are a good start to understanding the forwarding paradigm in ROLL, but would not be good enough to use to devise a new routing protocol, so I don't see how they can be good enough to determine whether an existing protocol should be discarded, modified, or used. ============= More specific comments on the draft follow. --- Do we have a commitment from the WG that any new protocol developed will be held to the same standards? That is, that the new protocol MUST achieve a "pass" in very column of the table in section 4. Or is there scope for pragmatism allowing trade-offs in the new protocol such that in some environments it achieves a pass in some columns, and in other environments it achieves a pass in other columns. Maybe you could add this as a statement in the Abstract and Introduction --- Why do you include the requirements language boilerplate? I don't think you use (or should use) such language in this document. --- Section 1 Can you strip out terms not used in the document? --- Section 2 You quote CPU power in MHz. Although that is the practical electronic limit, maybe MIPS would be a better measure. --- Section 3 para 2 "If a protocol cannot meet even these minimalist criteria..." I think your use of "cannot" is correct in the context of the sentence, but I think your I-D examines "does not" "...is unlikely to be good candidate..." Too much prevarication! --- Section 3 para 3 "...the protocol does not appear to contain sufficient flexibility..." The problem with this is that it is very mushy! It is OK to discard a protocol that is not flexible enough to handle your requirements. It is not OK to discard a protocol because you don't appear to know how to extend it. A example comes in the somewhat contentious table in section 4 :-) Here, for OSPF, you say that there is a "fail" for conveying node costs. But there is already LSA available for carrying node capabilities, and there are opaque LSAs available for carrying additional "unconventional" information. All this sort of ties to my main point. Of course, the protocols don't do exactly what you want already, but a more thorough survey is needed if you what to use this I-D as the reason for excluding protocols. --- Section 3.2 para 1 "...with size ranging from a minimum..." I think you mean "...with maximum size ranging from a minimum..." "very large networks" Can you de-fluff this? Some people might think that 250 nodes is very large ;-) "network depths" Would be worth including your definition here. -- Section 3.2 para 1 Is every network node a router? draft-ietf-roll-urban-routing-reqs says "Sensor nodes are capable of forwarding data." If every node is a router and participates in the routing protocol, this creates a very different environment from saying that most sensors are hosts, and some are routers. I appreciate that "capable" does not imply "do". --- Associated with the previous point, I think you might spend a little more time discussing the definition of a link in ROLL. It is clear that in a wireless n/w a link may exist between any two nodes in range. If that is what you mean, then it would help to make it clear. On the other hand, "link" could be defined as an active neighbor relationship between a pair of routers. Or something else. This becomes important as we try to understand how the protocol must scale, and what it is supposed to do. I presume that the concept of "parallel links" between neighbors is going to have no meaning at the moment. That is, you use only one frequency in any network. Maybe I presume wrong, in which case, you need to refine the definition of "network density" in section 3.1. --- Section 3.2 para 1 Final sentence is a bit mangled. --- Section 3.2 para 2 I can see why scaling with O(L) may be an issue, but it may depend on the definitions of links and routers. Also it may depend on what magnitude you expect for L. Perhaps you could give some ball-parks in the previous paragraph as you do for N and D. Without that, it is hard to justify the claim that scaling with O(L) is a problem. --- Section 3.3 Can you add SINR to your terminology? "...not trigger unnecessary responses..." I think that this is subjective and unhelpful. Can you rephrase to capture a quantifiable requirement? s/link changes to propagate across/link changes to be propagated across/ s/O(l)/O(L)/ --- Section 3.3 final para You have "transmissions", "broadcast", and "route updates". Can you use a consistent term? It may be less pretty English, but it would be a better way to avoid accusations of bias :-) Perhaps... More precisely, loss responses that require transmissions within the network of O(N) fail, while those that are limited to O(L) or O(D) pass. --- Section 3.4 para 1 "In terms of routing structure, any proposed L2N routing protocol ought to support the autonomous organization and configuration of the network at the lowest possible energy cost." Why "L2N"? I thought "Networks of low power wireless devices introduce novel IP routing issues." "ought" is not a recognized RFC 2119 word :-) I think "at the lowest possible energy cost" is a statement that this requirement trumps all others. Is that what you mean? I'm not convinced by the absolute statement you make here. Maybe, this is a question I should take to the requirements documents. Consider routing protocol A that is slightly more (say 5%) power-consuming than routing protocol B. But suppose protocol A gives rise to a data forwarding solution that is 50% more power-efficient? --- Section 3.4 para 2 "As low-power wireless networks can have very low data rates, protocols which require a minimum control packet rate can have unbounded control overhead." I know what you mean, but I had to parse several times. How about... The control overhead is the ratio of control data to payload data. A high control overhead indicates that precious network resources (bandwidth, power, or CPU) are being consumed by the control protocols instead of being used to transmit data. Where payload data rates are very low (as is often the case in low-power wireless networks) the control overhead can become unbounded for protocols that require some non-zero background control packet rate. --- Section 3.4 para 2 s/never meet the condition can be forced/never meet the condition could be forced/ --- Section 4 para 3 "multiple layer 2 hops away" Really? Again, I thought we were building an IP routing protocol. If your requirement is layer 2 routing, you need to make that visible up front. But, I can see why you are interested in L2 hops as well as L3 hops since they all consume power. This comes back to the question about whether all nodes are routers. Perhaps some repeaters are not routers? But can't we actually factor the L2 hops into the definition of the L3 hop? --- Section 4 para 3 "...nodes may only advertise..." This sounds prohibitive! --- Section 4 para 4 "Neighbor discovery is a critical component of any routing protocol." I think I disagree. It is clear that routing protocols need to know their neighbors. It is not clear that this requires that the discovery be part of the routing protocol. Later you have: "...key component of many protocols." This is less strong than the initial sentence. --- Section 4 "Protocols Today" Is this a section 4.1 headers? --- Section 4 "Protocols Today" para 2 I don't think the MPLS TE example is a good one. It is certainly not correct that the TED has to be fully distributed around the network. There are some very good examples of where "stub TE areas" do not need to know the TE information for the whole of the rest of the network. --- Section 4 Table I'm prepared to bet that a lot of people will be upset by the use of "fail" for their favorite protocols. It would seem that "?" is more appropriate in many cells. --- Section 5.1 Is it worth replacing "OSPF" with "OSPF or IS-IS"? --- Section 14. Your three ROLL requirements drafts are Normative References, I think. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Aug 25 09:15: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 C42AD3A682F; Mon, 25 Aug 2008 09:15: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 9F6FC3A67F6 for ; Mon, 25 Aug 2008 09:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MANGLED_TOOL=2.3, 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 U8ticrQ6WjRp for ; Mon, 25 Aug 2008 09:15:12 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 2E20D3A682F for ; Mon, 25 Aug 2008 09:15:12 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7PGDUK0029485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Aug 2008 09:13:37 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7PGDThu016575; Mon, 25 Aug 2008 11:13:29 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7PGDTY5016550; Mon, 25 Aug 2008 11:13:29 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 09:13:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 09:13:27 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01053026@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <046001c905e2$dd5b0f50$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckF4uWWv+jCr8q7RKKuNS7geV3eIgA6l4jA References: <046001c905e2$dd5b0f50$0300a8c0@your029b8cecfe> From: "Drake, John E" To: "Adrian Farrel" , X-OriginalArrivalTime: 25 Aug 2008 16:13:28.0978 (UTC) FILETIME=[82D43F20:01C906CD] Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 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 Adrian, An excellent note - I agree completely. We need fewer routing protocols, not more. Thanks, John >-----Original Message----- >From: Adrian Farrel [mailto:adrian@olddog.co.uk] >Sent: Sunday, August 24, 2008 5:14 AM >To: roll@ietf.org >Subject: [Roll] draft-ietf-roll-protocols-survey-00 > >Hi, > >As one of the two tourists who raised a hand in Dublin to >express uneasiness about this I-D becoming a WG draft, I >thought I should write a note about my concerns. > >I should caveat this by saying that I do appreciate the need >for this work, and that the author-team will, I'm sure, do a >fine job at delivering what the working group needs. My >concerns were much more about getting the direction of the I-D >right before accepting it as I think it is often harder to >recast an I-D once it is within the working group. > >Below, please find my major discussion point. I have also done >a review of the draft and found a bunch of issues/questions of >more minor importance. > >Regards, >Adrian > >=== > >The analysis of the routing protocols is predicated on what >they are currently used for. To some extent this is reasonable >- the easiest analysis of a routing protocol is in its >operational environment. But to use this analysis as the basis >of a decision for use of a protocol in a new environment is >not so reasonable. If you want to show that none of today's >protocols has been designed for use in the ROLL environment, >then I don't suppose anyone will be surprised. However, what >we are really interested in is whether any of the existing >protocols is suitable for adaptation for use in ROLL, whether >the those adaptations would be contrived and technically hard >(or flaky), and whether it would be more efficient to design a >new protocol. > >For an example (and I'm not proposing this as the solution for >ROLL), an IGP could easily be adapted to flood on only certain >links, to discard certain LSAs, and to build a FIB according >to specific rules. This would not be a large change to the >protocol, although it would obviously not be interoperable. > >To discard from consideration any protocol based on its >behavior in a certain environment without setting it in the >context of your forwarding paradigm and without examining the >potential to adapt a protocol to that environment is wrong. If >all you wanted to do was show that no current variant of any >existing routing protocol is immediately applicable to ROLL, >then that would be easy and would not be a surprise. But to >imply that protocols are not open for adaptation is more serious. > >This is not to say that inventing a new protocol would be >wrong or not fun. >Only that your reasons for discarding protocols are poorly >founded. You have focused on the operation of the routing >protocol, not the purpose of the routing protocol. To give a >better understanding of why you are discarding a protocol, you >must show what you want to achieve as your forwarding >paradigm. The requirements documents make some start at this. >For example, draft-ietf-roll-urban-routing-reqs talks about: >- routing to minimise power usage >- routing to consider node and link capabilities >- routing protocol to scale within CPU, memory and power limits >- routing according to different metrics (latency is cited) > >Such considerations are a good start to understanding the >forwarding paradigm in ROLL, but would not be good enough to >use to devise a new routing protocol, so I don't see how they >can be good enough to determine whether an existing protocol >should be discarded, modified, or used. > >============= > >More specific comments on the draft follow. > >--- > >Do we have a commitment from the WG that any new protocol >developed will be held to the same standards? That is, that >the new protocol MUST achieve a "pass" in very column of the >table in section 4. Or is there scope for pragmatism allowing >trade-offs in the new protocol such that in some environments >it achieves a pass in some columns, and in other environments >it achieves a pass in other columns. > >Maybe you could add this as a statement in the Abstract and >Introduction > >--- > >Why do you include the requirements language boilerplate? I >don't think you use (or should use) such language in this document. > >--- > >Section 1 > >Can you strip out terms not used in the document? > >--- > >Section 2 > >You quote CPU power in MHz. Although that is the practical >electronic limit, maybe MIPS would be a better measure. > >--- > >Section 3 para 2 > >"If a protocol cannot meet even these minimalist criteria..." >I think your use of "cannot" is correct in the context of the >sentence, but I think your I-D examines "does not" > >"...is unlikely to be good candidate..." >Too much prevarication! > >--- > >Section 3 para 3 > >"...the protocol does not appear to contain sufficient flexibility..." >The problem with this is that it is very mushy! >It is OK to discard a protocol that is not flexible enough to >handle your requirements. It is not OK to discard a protocol >because you don't appear to know how to extend it. > >A example comes in the somewhat contentious table in section 4 >:-) Here, for OSPF, you say that there is a "fail" for >conveying node costs. >But there is already LSA available for carrying node >capabilities, and there are opaque LSAs available for carrying >additional "unconventional" >information. > >All this sort of ties to my main point. Of course, the >protocols don't do exactly what you want already, but a more >thorough survey is needed if you what to use this I-D as the >reason for excluding protocols. > >--- > >Section 3.2 para 1 >"...with size ranging from a minimum..." >I think you mean "...with maximum size ranging from a minimum..." > >"very large networks" >Can you de-fluff this? Some people might think that 250 nodes >is very large >;-) > >"network depths" >Would be worth including your definition here. > >-- > >Section 3.2 para 1 > >Is every network node a router? >draft-ietf-roll-urban-routing-reqs says "Sensor nodes are >capable of forwarding data." If every node is a router and >participates in the routing protocol, this creates a very >different environment from saying that most sensors are hosts, >and some are routers. I appreciate that "capable" does not imply "do". > >--- > >Associated with the previous point, I think you might spend a >little more >time discussing the definition of a link in ROLL. It is clear >that in a >wireless n/w a link may exist between any two nodes in range. >If that is >what you mean, then it would help to make it clear. On the other hand, >"link" could be defined as an active neighbor relationship >between a pair of >routers. Or something else. > >This becomes important as we try to understand how the >protocol must scale, >and what it is supposed to do. > >I presume that the concept of "parallel links" between >neighbors is going to >have no meaning at the moment. That is, you use only one >frequency in any >network. Maybe I presume wrong, in which case, you need to refine the >definition of "network density" in section 3.1. > >--- > >Section 3.2 para 1 >Final sentence is a bit mangled. > >--- > >Section 3.2 para 2 > >I can see why scaling with O(L) may be an issue, but it may >depend on the >definitions of links and routers. Also it may depend on what >magnitude you >expect for L. Perhaps you could give some ball-parks in the previous >paragraph as you do for N and D. Without that, it is hard to >justify the >claim that scaling with O(L) is a problem. > >--- > >Section 3.3 > >Can you add SINR to your terminology? > >"...not trigger unnecessary responses..." >I think that this is subjective and unhelpful. Can you >rephrase to capture a >quantifiable requirement? > >s/link changes to propagate across/link changes to be >propagated across/ > >s/O(l)/O(L)/ > >--- > >Section 3.3 final para > >You have "transmissions", "broadcast", and "route updates". >Can you use a >consistent term? It may be less pretty English, but it would >be a better way >to avoid accusations of bias :-) > >Perhaps... >More precisely, loss responses that require transmissions >within the network >of O(N) fail, while those that are limited to O(L) or O(D) pass. > >--- > >Section 3.4 para 1 > >"In terms of routing structure, any proposed L2N routing >protocol ought to >support the autonomous organization and configuration of the >network at the >lowest possible energy cost." > >Why "L2N"? I thought "Networks of low power wireless devices >introduce novel >IP routing issues." > >"ought" is not a recognized RFC 2119 word :-) > >I think "at the lowest possible energy cost" is a statement that this >requirement trumps all others. Is that what you mean? > >I'm not convinced by the absolute statement you make here. >Maybe, this is a >question I should take to the requirements documents. Consider routing >protocol A that is slightly more (say 5%) power-consuming than routing >protocol B. But suppose protocol A gives rise to a data >forwarding solution >that is 50% more power-efficient? > >--- > >Section 3.4 para 2 > >"As low-power wireless networks can have very low data rates, >protocols >which require a minimum control packet rate can have unbounded control >overhead." > >I know what you mean, but I had to parse several times. How about... > >The control overhead is the ratio of control data to payload >data. A high >control overhead indicates that precious network resources (bandwidth, >power, or CPU) are being consumed by the control protocols >instead of being >used to transmit data. Where payload data rates are very low >(as is often >the case in low-power wireless networks) the control overhead >can become >unbounded for protocols that require some non-zero background >control packet >rate. > >--- > >Section 3.4 para 2 > >s/never meet the condition can be forced/never meet the >condition could be >forced/ > >--- > >Section 4 para 3 > >"multiple layer 2 hops away" >Really? >Again, I thought we were building an IP routing protocol. If your >requirement is layer 2 routing, you need to make that visible up front. >But, I can see why you are interested in L2 hops as well as L3 >hops since >they all consume power. > >This comes back to the question about whether all nodes are >routers. Perhaps >some repeaters are not routers? > >But can't we actually factor the L2 hops into the definition >of the L3 hop? > >--- > >Section 4 para 3 > >"...nodes may only advertise..." >This sounds prohibitive! > >--- > >Section 4 para 4 > >"Neighbor discovery is a critical component of any routing protocol." >I think I disagree. >It is clear that routing protocols need to know their >neighbors. It is not >clear that this requires that the discovery be part of the >routing protocol. > >Later you have: >"...key component of many protocols." >This is less strong than the initial sentence. > >--- > >Section 4 > >"Protocols Today" > >Is this a section 4.1 headers? > >--- > >Section 4 "Protocols Today" para 2 > >I don't think the MPLS TE example is a good one. It is >certainly not correct >that the TED has to be fully distributed around the network. >There are some very good examples of where "stub TE areas" do >not need to >know the TE information for the whole of the rest of the network. > >--- > >Section 4 Table > >I'm prepared to bet that a lot of people will be upset by the >use of "fail" >for their favorite protocols. It would seem that "?" is more >appropriate in >many cells. > >--- > >Section 5.1 >Is it worth replacing "OSPF" with "OSPF or IS-IS"? > >--- > >Section 14. >Your three ROLL requirements drafts are Normative References, I think. > >_______________________________________________ >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 Wed Aug 27 02:28: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 78C843A691F; Wed, 27 Aug 2008 02:28: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 5F5593A684F for ; Wed, 27 Aug 2008 02:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 yzJedD6KFdU2 for ; Wed, 27 Aug 2008 02:28:44 -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 7010E3A691F for ; Wed, 27 Aug 2008 02:28:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,278,1217808000"; d="scan'208";a="18821151" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Aug 2008 09:28:04 +0000 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 m7R9S4fV031713; Wed, 27 Aug 2008 05:28:04 -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 m7R9S4To013878; Wed, 27 Aug 2008 09:28:04 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); Wed, 27 Aug 2008 05:28:04 -0400 Received: from 10.21.94.91 ([10.21.94.91]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Aug 2008 09:24:18 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 27 Aug 2008 11:23:56 +0200 From: JP Vasseur To: "Drake, John E" , Adrian Farrel , Message-ID: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckF4uWWv+jCr8q7RKKuNS7geV3eIgA6l4jAAFZXU+0= In-Reply-To: <51661468CBD1354294533DA79E85955A01053026@XCH-SW-5V2.sw.nos.boeing.com> Mime-version: 1.0 X-OriginalArrivalTime: 27 Aug 2008 09:28:04.0219 (UTC) FILETIME=[34F814B0:01C90827] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13360; t=1219829284; x=1220693284; 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]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20 |To:=20=22Drake,=20John=20E=22=20 ,=0A=20=20=20=20=20=20=20=20Adrian=20Farrel=20,=20; bh=DPX+LEVZQWP0VpH/9d1tAxzRd4S6kMY4uBfjhgr2MCc=; b=k/GezIhX/6kihXZmOHdhmMBl/16aw6WSb8z+1HmIJ6onJgRpI/9S7+Ftti eCwycaS0tVP3MIfAmHiuVOYr7n/jK8oBMEjsxg0Rs8Y03VsuX6TtX6Jw2yB5 cSMMssPjML; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 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 John, I do not think that this was Adrian's point. Your feed-back is more than welcome but please argue a bit more ... Thanks. JP. On 8/25/08 6:13 PM, "Drake, John E" wrote: > Adrian, > > An excellent note - I agree completely. We need fewer routing > protocols, not more. > > Thanks, > > John > >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Sunday, August 24, 2008 5:14 AM >> To: roll@ietf.org >> Subject: [Roll] draft-ietf-roll-protocols-survey-00 >> >> Hi, >> >> As one of the two tourists who raised a hand in Dublin to >> express uneasiness about this I-D becoming a WG draft, I >> thought I should write a note about my concerns. >> >> I should caveat this by saying that I do appreciate the need >> for this work, and that the author-team will, I'm sure, do a >> fine job at delivering what the working group needs. My >> concerns were much more about getting the direction of the I-D >> right before accepting it as I think it is often harder to >> recast an I-D once it is within the working group. >> >> Below, please find my major discussion point. I have also done >> a review of the draft and found a bunch of issues/questions of >> more minor importance. >> >> Regards, >> Adrian >> >> === >> >> The analysis of the routing protocols is predicated on what >> they are currently used for. To some extent this is reasonable >> - the easiest analysis of a routing protocol is in its >> operational environment. But to use this analysis as the basis >> of a decision for use of a protocol in a new environment is >> not so reasonable. If you want to show that none of today's >> protocols has been designed for use in the ROLL environment, >> then I don't suppose anyone will be surprised. However, what >> we are really interested in is whether any of the existing >> protocols is suitable for adaptation for use in ROLL, whether >> the those adaptations would be contrived and technically hard >> (or flaky), and whether it would be more efficient to design a >> new protocol. >> >> For an example (and I'm not proposing this as the solution for >> ROLL), an IGP could easily be adapted to flood on only certain >> links, to discard certain LSAs, and to build a FIB according >> to specific rules. This would not be a large change to the >> protocol, although it would obviously not be interoperable. >> >> To discard from consideration any protocol based on its >> behavior in a certain environment without setting it in the >> context of your forwarding paradigm and without examining the >> potential to adapt a protocol to that environment is wrong. If >> all you wanted to do was show that no current variant of any >> existing routing protocol is immediately applicable to ROLL, >> then that would be easy and would not be a surprise. But to >> imply that protocols are not open for adaptation is more serious. >> >> This is not to say that inventing a new protocol would be >> wrong or not fun. >> Only that your reasons for discarding protocols are poorly >> founded. You have focused on the operation of the routing >> protocol, not the purpose of the routing protocol. To give a >> better understanding of why you are discarding a protocol, you >> must show what you want to achieve as your forwarding >> paradigm. The requirements documents make some start at this. >> For example, draft-ietf-roll-urban-routing-reqs talks about: >> - routing to minimise power usage >> - routing to consider node and link capabilities >> - routing protocol to scale within CPU, memory and power limits >> - routing according to different metrics (latency is cited) >> >> Such considerations are a good start to understanding the >> forwarding paradigm in ROLL, but would not be good enough to >> use to devise a new routing protocol, so I don't see how they >> can be good enough to determine whether an existing protocol >> should be discarded, modified, or used. >> >> ============= >> >> More specific comments on the draft follow. >> >> --- >> >> Do we have a commitment from the WG that any new protocol >> developed will be held to the same standards? That is, that >> the new protocol MUST achieve a "pass" in very column of the >> table in section 4. Or is there scope for pragmatism allowing >> trade-offs in the new protocol such that in some environments >> it achieves a pass in some columns, and in other environments >> it achieves a pass in other columns. >> >> Maybe you could add this as a statement in the Abstract and >> Introduction >> >> --- >> >> Why do you include the requirements language boilerplate? I >> don't think you use (or should use) such language in this document. >> >> --- >> >> Section 1 >> >> Can you strip out terms not used in the document? >> >> --- >> >> Section 2 >> >> You quote CPU power in MHz. Although that is the practical >> electronic limit, maybe MIPS would be a better measure. >> >> --- >> >> Section 3 para 2 >> >> "If a protocol cannot meet even these minimalist criteria..." >> I think your use of "cannot" is correct in the context of the >> sentence, but I think your I-D examines "does not" >> >> "...is unlikely to be good candidate..." >> Too much prevarication! >> >> --- >> >> Section 3 para 3 >> >> "...the protocol does not appear to contain sufficient flexibility..." >> The problem with this is that it is very mushy! >> It is OK to discard a protocol that is not flexible enough to >> handle your requirements. It is not OK to discard a protocol >> because you don't appear to know how to extend it. >> >> A example comes in the somewhat contentious table in section 4 >> :-) Here, for OSPF, you say that there is a "fail" for >> conveying node costs. >> But there is already LSA available for carrying node >> capabilities, and there are opaque LSAs available for carrying >> additional "unconventional" >> information. >> >> All this sort of ties to my main point. Of course, the >> protocols don't do exactly what you want already, but a more >> thorough survey is needed if you what to use this I-D as the >> reason for excluding protocols. >> >> --- >> >> Section 3.2 para 1 >> "...with size ranging from a minimum..." >> I think you mean "...with maximum size ranging from a minimum..." >> >> "very large networks" >> Can you de-fluff this? Some people might think that 250 nodes >> is very large >> ;-) >> >> "network depths" >> Would be worth including your definition here. >> >> -- >> >> Section 3.2 para 1 >> >> Is every network node a router? >> draft-ietf-roll-urban-routing-reqs says "Sensor nodes are >> capable of forwarding data." If every node is a router and >> participates in the routing protocol, this creates a very >> different environment from saying that most sensors are hosts, >> and some are routers. I appreciate that "capable" does not imply "do". >> >> --- >> >> Associated with the previous point, I think you might spend a >> little more >> time discussing the definition of a link in ROLL. It is clear >> that in a >> wireless n/w a link may exist between any two nodes in range. >> If that is >> what you mean, then it would help to make it clear. On the other hand, >> "link" could be defined as an active neighbor relationship >> between a pair of >> routers. Or something else. >> >> This becomes important as we try to understand how the >> protocol must scale, >> and what it is supposed to do. >> >> I presume that the concept of "parallel links" between >> neighbors is going to >> have no meaning at the moment. That is, you use only one >> frequency in any >> network. Maybe I presume wrong, in which case, you need to refine the >> definition of "network density" in section 3.1. >> >> --- >> >> Section 3.2 para 1 >> Final sentence is a bit mangled. >> >> --- >> >> Section 3.2 para 2 >> >> I can see why scaling with O(L) may be an issue, but it may >> depend on the >> definitions of links and routers. Also it may depend on what >> magnitude you >> expect for L. Perhaps you could give some ball-parks in the previous >> paragraph as you do for N and D. Without that, it is hard to >> justify the >> claim that scaling with O(L) is a problem. >> >> --- >> >> Section 3.3 >> >> Can you add SINR to your terminology? >> >> "...not trigger unnecessary responses..." >> I think that this is subjective and unhelpful. Can you >> rephrase to capture a >> quantifiable requirement? >> >> s/link changes to propagate across/link changes to be >> propagated across/ >> >> s/O(l)/O(L)/ >> >> --- >> >> Section 3.3 final para >> >> You have "transmissions", "broadcast", and "route updates". >> Can you use a >> consistent term? It may be less pretty English, but it would >> be a better way >> to avoid accusations of bias :-) >> >> Perhaps... >> More precisely, loss responses that require transmissions >> within the network >> of O(N) fail, while those that are limited to O(L) or O(D) pass. >> >> --- >> >> Section 3.4 para 1 >> >> "In terms of routing structure, any proposed L2N routing >> protocol ought to >> support the autonomous organization and configuration of the >> network at the >> lowest possible energy cost." >> >> Why "L2N"? I thought "Networks of low power wireless devices >> introduce novel >> IP routing issues." >> >> "ought" is not a recognized RFC 2119 word :-) >> >> I think "at the lowest possible energy cost" is a statement that this >> requirement trumps all others. Is that what you mean? >> >> I'm not convinced by the absolute statement you make here. >> Maybe, this is a >> question I should take to the requirements documents. Consider routing >> protocol A that is slightly more (say 5%) power-consuming than routing >> protocol B. But suppose protocol A gives rise to a data >> forwarding solution >> that is 50% more power-efficient? >> >> --- >> >> Section 3.4 para 2 >> >> "As low-power wireless networks can have very low data rates, >> protocols >> which require a minimum control packet rate can have unbounded control >> overhead." >> >> I know what you mean, but I had to parse several times. How about... >> >> The control overhead is the ratio of control data to payload >> data. A high >> control overhead indicates that precious network resources (bandwidth, >> power, or CPU) are being consumed by the control protocols >> instead of being >> used to transmit data. Where payload data rates are very low >> (as is often >> the case in low-power wireless networks) the control overhead >> can become >> unbounded for protocols that require some non-zero background >> control packet >> rate. >> >> --- >> >> Section 3.4 para 2 >> >> s/never meet the condition can be forced/never meet the >> condition could be >> forced/ >> >> --- >> >> Section 4 para 3 >> >> "multiple layer 2 hops away" >> Really? >> Again, I thought we were building an IP routing protocol. If your >> requirement is layer 2 routing, you need to make that visible up front. >> But, I can see why you are interested in L2 hops as well as L3 >> hops since >> they all consume power. >> >> This comes back to the question about whether all nodes are >> routers. Perhaps >> some repeaters are not routers? >> >> But can't we actually factor the L2 hops into the definition >> of the L3 hop? >> >> --- >> >> Section 4 para 3 >> >> "...nodes may only advertise..." >> This sounds prohibitive! >> >> --- >> >> Section 4 para 4 >> >> "Neighbor discovery is a critical component of any routing protocol." >> I think I disagree. >> It is clear that routing protocols need to know their >> neighbors. It is not >> clear that this requires that the discovery be part of the >> routing protocol. >> >> Later you have: >> "...key component of many protocols." >> This is less strong than the initial sentence. >> >> --- >> >> Section 4 >> >> "Protocols Today" >> >> Is this a section 4.1 headers? >> >> --- >> >> Section 4 "Protocols Today" para 2 >> >> I don't think the MPLS TE example is a good one. It is >> certainly not correct >> that the TED has to be fully distributed around the network. >> There are some very good examples of where "stub TE areas" do >> not need to >> know the TE information for the whole of the rest of the network. >> >> --- >> >> Section 4 Table >> >> I'm prepared to bet that a lot of people will be upset by the >> use of "fail" >> for their favorite protocols. It would seem that "?" is more >> appropriate in >> many cells. >> >> --- >> >> Section 5.1 >> Is it worth replacing "OSPF" with "OSPF or IS-IS"? >> >> --- >> >> Section 14. >> Your three ROLL requirements drafts are Normative References, I think. >> >> _______________________________________________ >> 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Aug 27 07:46:54 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 E73D93A6C0B; Wed, 27 Aug 2008 07:46:54 -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 813663A6C0B for ; Wed, 27 Aug 2008 07:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.145 X-Spam-Level: X-Spam-Status: No, score=-5.145 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 BTIxeZe+JDCd for ; Wed, 27 Aug 2008 07:46:52 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 82A173A683A for ; Wed, 27 Aug 2008 07:46:52 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7REjOVJ019126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Aug 2008 09:45:24 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7REjNkn026775; Wed, 27 Aug 2008 09:45:23 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7REjFA2026558; Wed, 27 Aug 2008 09:45:23 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 07:45:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 07:45:21 -0700 Message-ID: <51661468CBD1354294533DA79E85955A0109FD7B@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckF4uWWv+jCr8q7RKKuNS7geV3eIgA6l4jAAFZXU+0ACvR8MA== References: <51661468CBD1354294533DA79E85955A01053026@XCH-SW-5V2.sw.nos.boeing.com> From: "Drake, John E" To: "JP Vasseur" , "Adrian Farrel" , X-OriginalArrivalTime: 27 Aug 2008 14:45:23.0192 (UTC) FILETIME=[8914CF80:01C90853] Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 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 JP, I thought that was exactly Adrian's point. If you evaluate a bunch of routing protocols as they exist today in a new operational environment and conclude that none of them are appropriate, then you have no choice but to conclude that you need to invent at least one, but probably many, new routing protocols. It's not like this hasn't been done before. I took Adrian's note to say that doing this is not sufficient and that what needed to be done was to characterize the new operational environment, propose changes needed in each routing protocol to address the new operational environment, and then evaluate these changes. Thanks, John >-----Original Message----- >From: JP Vasseur [mailto:jvasseur@cisco.com] >Sent: Wednesday, August 27, 2008 2:24 AM >To: Drake, John E; Adrian Farrel; roll@ietf.org >Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 > >John, > >I do not think that this was Adrian's point. Your feed-back is >more than welcome but please argue a bit more ... > >Thanks. > >JP. > > >On 8/25/08 6:13 PM, "Drake, John E" wrote: > >> Adrian, >> >> An excellent note - I agree completely. We need fewer routing >> protocols, not more. >> >> Thanks, >> >> John >> >>> -----Original Message----- >>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>> Sent: Sunday, August 24, 2008 5:14 AM >>> To: roll@ietf.org >>> Subject: [Roll] draft-ietf-roll-protocols-survey-00 >>> >>> Hi, >>> >>> As one of the two tourists who raised a hand in Dublin to express >>> uneasiness about this I-D becoming a WG draft, I thought I should >>> write a note about my concerns. >>> >>> I should caveat this by saying that I do appreciate the >need for this >>> work, and that the author-team will, I'm sure, do a fine job at >>> delivering what the working group needs. My concerns were much more >>> about getting the direction of the I-D right before >accepting it as I >>> think it is often harder to recast an I-D once it is within the >>> working group. >>> >>> Below, please find my major discussion point. I have also done a >>> review of the draft and found a bunch of issues/questions of more >>> minor importance. >>> >>> Regards, >>> Adrian >>> >>> === >>> >>> The analysis of the routing protocols is predicated on what >they are >>> currently used for. To some extent this is reasonable >>> - the easiest analysis of a routing protocol is in its operational >>> environment. But to use this analysis as the basis of a >decision for >>> use of a protocol in a new environment is not so reasonable. If you >>> want to show that none of today's protocols has been >designed for use >>> in the ROLL environment, then I don't suppose anyone will be >>> surprised. However, what we are really interested in is whether any >>> of the existing protocols is suitable for adaptation for >use in ROLL, >>> whether the those adaptations would be contrived and >technically hard >>> (or flaky), and whether it would be more efficient to design a new >>> protocol. >>> >>> For an example (and I'm not proposing this as the solution >for ROLL), >>> an IGP could easily be adapted to flood on only certain links, to >>> discard certain LSAs, and to build a FIB according to >specific rules. >>> This would not be a large change to the protocol, although it would >>> obviously not be interoperable. >>> >>> To discard from consideration any protocol based on its >behavior in a >>> certain environment without setting it in the context of your >>> forwarding paradigm and without examining the potential to adapt a >>> protocol to that environment is wrong. If all you wanted to do was >>> show that no current variant of any existing routing protocol is >>> immediately applicable to ROLL, then that would be easy and >would not >>> be a surprise. But to imply that protocols are not open for >>> adaptation is more serious. >>> >>> This is not to say that inventing a new protocol would be wrong or >>> not fun. >>> Only that your reasons for discarding protocols are poorly founded. >>> You have focused on the operation of the routing protocol, not the >>> purpose of the routing protocol. To give a better understanding of >>> why you are discarding a protocol, you must show what you want to >>> achieve as your forwarding paradigm. The requirements >documents make >>> some start at this. >>> For example, draft-ietf-roll-urban-routing-reqs talks about: >>> - routing to minimise power usage >>> - routing to consider node and link capabilities >>> - routing protocol to scale within CPU, memory and power limits >>> - routing according to different metrics (latency is cited) >>> >>> Such considerations are a good start to understanding the >forwarding >>> paradigm in ROLL, but would not be good enough to use to >devise a new >>> routing protocol, so I don't see how they can be good enough to >>> determine whether an existing protocol should be discarded, >modified, >>> or used. >>> >>> ============= >>> >>> More specific comments on the draft follow. >>> >>> --- >>> >>> Do we have a commitment from the WG that any new protocol developed >>> will be held to the same standards? That is, that the new protocol >>> MUST achieve a "pass" in very column of the table in >section 4. Or is >>> there scope for pragmatism allowing trade-offs in the new protocol >>> such that in some environments it achieves a pass in some columns, >>> and in other environments it achieves a pass in other columns. >>> >>> Maybe you could add this as a statement in the Abstract and >>> Introduction >>> >>> --- >>> >>> Why do you include the requirements language boilerplate? I don't >>> think you use (or should use) such language in this document. >>> >>> --- >>> >>> Section 1 >>> >>> Can you strip out terms not used in the document? >>> >>> --- >>> >>> Section 2 >>> >>> You quote CPU power in MHz. Although that is the practical >electronic >>> limit, maybe MIPS would be a better measure. >>> >>> --- >>> >>> Section 3 para 2 >>> >>> "If a protocol cannot meet even these minimalist criteria..." >>> I think your use of "cannot" is correct in the context of the >>> sentence, but I think your I-D examines "does not" >>> >>> "...is unlikely to be good candidate..." >>> Too much prevarication! >>> >>> --- >>> >>> Section 3 para 3 >>> >>> "...the protocol does not appear to contain sufficient >flexibility..." >>> The problem with this is that it is very mushy! >>> It is OK to discard a protocol that is not flexible enough >to handle >>> your requirements. It is not OK to discard a protocol because you >>> don't appear to know how to extend it. >>> >>> A example comes in the somewhat contentious table in section 4 >>> :-) Here, for OSPF, you say that there is a "fail" for >conveying node >>> costs. >>> But there is already LSA available for carrying node capabilities, >>> and there are opaque LSAs available for carrying additional >>> "unconventional" >>> information. >>> >>> All this sort of ties to my main point. Of course, the protocols >>> don't do exactly what you want already, but a more thorough >survey is >>> needed if you what to use this I-D as the reason for excluding >>> protocols. >>> >>> --- >>> >>> Section 3.2 para 1 >>> "...with size ranging from a minimum..." >>> I think you mean "...with maximum size ranging from a minimum..." >>> >>> "very large networks" >>> Can you de-fluff this? Some people might think that 250 >nodes is very >>> large >>> ;-) >>> >>> "network depths" >>> Would be worth including your definition here. >>> >>> -- >>> >>> Section 3.2 para 1 >>> >>> Is every network node a router? >>> draft-ietf-roll-urban-routing-reqs says "Sensor nodes are >capable of >>> forwarding data." If every node is a router and participates in the >>> routing protocol, this creates a very different environment from >>> saying that most sensors are hosts, and some are routers. I >>> appreciate that "capable" does not imply "do". >>> >>> --- >>> >>> Associated with the previous point, I think you might spend >a little >>> more time discussing the definition of a link in ROLL. It is clear >>> that in a wireless n/w a link may exist between any two nodes in >>> range. >>> If that is >>> what you mean, then it would help to make it clear. On the other >>> hand, "link" could be defined as an active neighbor relationship >>> between a pair of routers. Or something else. >>> >>> This becomes important as we try to understand how the >protocol must >>> scale, and what it is supposed to do. >>> >>> I presume that the concept of "parallel links" between neighbors is >>> going to have no meaning at the moment. That is, you use only one >>> frequency in any network. Maybe I presume wrong, in which case, you >>> need to refine the definition of "network density" in section 3.1. >>> >>> --- >>> >>> Section 3.2 para 1 >>> Final sentence is a bit mangled. >>> >>> --- >>> >>> Section 3.2 para 2 >>> >>> I can see why scaling with O(L) may be an issue, but it may >depend on >>> the definitions of links and routers. Also it may depend on what >>> magnitude you expect for L. Perhaps you could give some >ball-parks in >>> the previous paragraph as you do for N and D. Without that, it is >>> hard to justify the claim that scaling with O(L) is a problem. >>> >>> --- >>> >>> Section 3.3 >>> >>> Can you add SINR to your terminology? >>> >>> "...not trigger unnecessary responses..." >>> I think that this is subjective and unhelpful. Can you rephrase to >>> capture a quantifiable requirement? >>> >>> s/link changes to propagate across/link changes to be propagated >>> across/ >>> >>> s/O(l)/O(L)/ >>> >>> --- >>> >>> Section 3.3 final para >>> >>> You have "transmissions", "broadcast", and "route updates". >>> Can you use a >>> consistent term? It may be less pretty English, but it would be a >>> better way to avoid accusations of bias :-) >>> >>> Perhaps... >>> More precisely, loss responses that require transmissions >within the >>> network of O(N) fail, while those that are limited to O(L) or O(D) >>> pass. >>> >>> --- >>> >>> Section 3.4 para 1 >>> >>> "In terms of routing structure, any proposed L2N routing protocol >>> ought to support the autonomous organization and >configuration of the >>> network at the lowest possible energy cost." >>> >>> Why "L2N"? I thought "Networks of low power wireless devices >>> introduce novel IP routing issues." >>> >>> "ought" is not a recognized RFC 2119 word :-) >>> >>> I think "at the lowest possible energy cost" is a statement >that this >>> requirement trumps all others. Is that what you mean? >>> >>> I'm not convinced by the absolute statement you make here. >>> Maybe, this is a >>> question I should take to the requirements documents. Consider >>> routing protocol A that is slightly more (say 5%) power-consuming >>> than routing protocol B. But suppose protocol A gives rise >to a data >>> forwarding solution that is 50% more power-efficient? >>> >>> --- >>> >>> Section 3.4 para 2 >>> >>> "As low-power wireless networks can have very low data rates, >>> protocols which require a minimum control packet rate can have >>> unbounded control overhead." >>> >>> I know what you mean, but I had to parse several times. How about... >>> >>> The control overhead is the ratio of control data to >payload data. A >>> high control overhead indicates that precious network resources >>> (bandwidth, power, or CPU) are being consumed by the control >>> protocols instead of being used to transmit data. Where >payload data >>> rates are very low (as is often the case in low-power wireless >>> networks) the control overhead can become unbounded for protocols >>> that require some non-zero background control packet rate. >>> >>> --- >>> >>> Section 3.4 para 2 >>> >>> s/never meet the condition can be forced/never meet the condition >>> could be forced/ >>> >>> --- >>> >>> Section 4 para 3 >>> >>> "multiple layer 2 hops away" >>> Really? >>> Again, I thought we were building an IP routing protocol. If your >>> requirement is layer 2 routing, you need to make that >visible up front. >>> But, I can see why you are interested in L2 hops as well as L3 hops >>> since they all consume power. >>> >>> This comes back to the question about whether all nodes are >routers. >>> Perhaps some repeaters are not routers? >>> >>> But can't we actually factor the L2 hops into the definition of the >>> L3 hop? >>> >>> --- >>> >>> Section 4 para 3 >>> >>> "...nodes may only advertise..." >>> This sounds prohibitive! >>> >>> --- >>> >>> Section 4 para 4 >>> >>> "Neighbor discovery is a critical component of any routing >protocol." >>> I think I disagree. >>> It is clear that routing protocols need to know their neighbors. It >>> is not clear that this requires that the discovery be part of the >>> routing protocol. >>> >>> Later you have: >>> "...key component of many protocols." >>> This is less strong than the initial sentence. >>> >>> --- >>> >>> Section 4 >>> >>> "Protocols Today" >>> >>> Is this a section 4.1 headers? >>> >>> --- >>> >>> Section 4 "Protocols Today" para 2 >>> >>> I don't think the MPLS TE example is a good one. It is >certainly not >>> correct that the TED has to be fully distributed around the network. >>> There are some very good examples of where "stub TE areas" do not >>> need to know the TE information for the whole of the rest of the >>> network. >>> >>> --- >>> >>> Section 4 Table >>> >>> I'm prepared to bet that a lot of people will be upset by >the use of >>> "fail" >>> for their favorite protocols. It would seem that "?" is more >>> appropriate in many cells. >>> >>> --- >>> >>> Section 5.1 >>> Is it worth replacing "OSPF" with "OSPF or IS-IS"? >>> >>> --- >>> >>> Section 14. >>> Your three ROLL requirements drafts are Normative >References, I think. >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Aug 27 08:37: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 34B843A6AD5; Wed, 27 Aug 2008 08:37: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 D6CC128B56A for ; Wed, 27 Aug 2008 08:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_TOOL=2.3] 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 r880FkQVztlD for ; Wed, 27 Aug 2008 08:37:55 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 6CAC03A67EF for ; Wed, 27 Aug 2008 08:37:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,279,1217800800"; d="scan'208";a="16326837" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Aug 2008 17:37:54 +0200 Message-ID: <48B574CF.9070607@inria.fr> Date: Wed, 27 Aug 2008 17:37:51 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: roll@ietf.org References: <51661468CBD1354294533DA79E85955A01053026@XCH-SW-5V2.sw.nos.boeing.com> <51661468CBD1354294533DA79E85955A0109FD7B@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <51661468CBD1354294533DA79E85955A0109FD7B@XCH-SW-5V2.sw.nos.boeing.com> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 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 I guess I agree with John. I think this document is incomplete. The = working group should consider the approach based on extending some = existing protocol(s) to meet the specific requirements addressed in = ROLL. To be really useful, the document should include some text = providing a framework for this approach, aside from the "from scratch" way. regards, Emmanuel Drake, John E a =E9crit : > JP, > = > I thought that was exactly Adrian's point. > = > If you evaluate a bunch of routing protocols as they exist today in a > new operational environment and conclude that none of them are > appropriate, then you have no choice but to conclude that you need to > invent at least one, but probably many, new routing protocols. It's not > like this hasn't been done before. > = > I took Adrian's note to say that doing this is not sufficient and that > what needed to be done was to characterize the new operational > environment, propose changes needed in each routing protocol to address > the new operational environment, and then evaluate these changes. > = > Thanks, > = > John = > = >> -----Original Message----- >> From: JP Vasseur [mailto:jvasseur@cisco.com] = >> Sent: Wednesday, August 27, 2008 2:24 AM >> To: Drake, John E; Adrian Farrel; roll@ietf.org >> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >> >> John, >> >> I do not think that this was Adrian's point. Your feed-back is = >> more than welcome but please argue a bit more ... >> >> Thanks. >> >> JP. >> >> >> On 8/25/08 6:13 PM, "Drake, John E" wrote: >> >>> Adrian, >>> >>> An excellent note - I agree completely. We need fewer routing = >>> protocols, not more. >>> >>> Thanks, >>> >>> John >>> >>>> -----Original Message----- >>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>> Sent: Sunday, August 24, 2008 5:14 AM >>>> To: roll@ietf.org >>>> Subject: [Roll] draft-ietf-roll-protocols-survey-00 >>>> >>>> Hi, >>>> >>>> As one of the two tourists who raised a hand in Dublin to express = >>>> uneasiness about this I-D becoming a WG draft, I thought I should = >>>> write a note about my concerns. >>>> >>>> I should caveat this by saying that I do appreciate the = >> need for this = >>>> work, and that the author-team will, I'm sure, do a fine job at = >>>> delivering what the working group needs. My concerns were much more = >>>> about getting the direction of the I-D right before = >> accepting it as I = >>>> think it is often harder to recast an I-D once it is within the = >>>> working group. >>>> >>>> Below, please find my major discussion point. I have also done a = >>>> review of the draft and found a bunch of issues/questions of more = >>>> minor importance. >>>> >>>> Regards, >>>> Adrian >>>> >>>> =3D=3D=3D >>>> >>>> The analysis of the routing protocols is predicated on what = >> they are = >>>> currently used for. To some extent this is reasonable >>>> - the easiest analysis of a routing protocol is in its operational = >>>> environment. But to use this analysis as the basis of a = >> decision for = >>>> use of a protocol in a new environment is not so reasonable. If you = >>>> want to show that none of today's protocols has been = >> designed for use = >>>> in the ROLL environment, then I don't suppose anyone will be = >>>> surprised. However, what we are really interested in is whether any = >>>> of the existing protocols is suitable for adaptation for = >> use in ROLL, = >>>> whether the those adaptations would be contrived and = >> technically hard = >>>> (or flaky), and whether it would be more efficient to design a new = >>>> protocol. >>>> >>>> For an example (and I'm not proposing this as the solution = >> for ROLL), = >>>> an IGP could easily be adapted to flood on only certain links, to = >>>> discard certain LSAs, and to build a FIB according to = >> specific rules. = >>>> This would not be a large change to the protocol, although it would = >>>> obviously not be interoperable. >>>> >>>> To discard from consideration any protocol based on its = >> behavior in a = >>>> certain environment without setting it in the context of your = >>>> forwarding paradigm and without examining the potential to adapt a = >>>> protocol to that environment is wrong. If all you wanted to do was = >>>> show that no current variant of any existing routing protocol is = >>>> immediately applicable to ROLL, then that would be easy and = >> would not = >>>> be a surprise. But to imply that protocols are not open for = >>>> adaptation is more serious. >>>> >>>> This is not to say that inventing a new protocol would be wrong or = >>>> not fun. >>>> Only that your reasons for discarding protocols are poorly founded. = >>>> You have focused on the operation of the routing protocol, not the = >>>> purpose of the routing protocol. To give a better understanding of = >>>> why you are discarding a protocol, you must show what you want to = >>>> achieve as your forwarding paradigm. The requirements = >> documents make = >>>> some start at this. >>>> For example, draft-ietf-roll-urban-routing-reqs talks about: >>>> - routing to minimise power usage >>>> - routing to consider node and link capabilities >>>> - routing protocol to scale within CPU, memory and power limits >>>> - routing according to different metrics (latency is cited) >>>> >>>> Such considerations are a good start to understanding the = >> forwarding = >>>> paradigm in ROLL, but would not be good enough to use to = >> devise a new = >>>> routing protocol, so I don't see how they can be good enough to = >>>> determine whether an existing protocol should be discarded, = >> modified, = >>>> or used. >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> More specific comments on the draft follow. >>>> >>>> --- >>>> >>>> Do we have a commitment from the WG that any new protocol developed = >>>> will be held to the same standards? That is, that the new protocol = >>>> MUST achieve a "pass" in very column of the table in = >> section 4. Or is = >>>> there scope for pragmatism allowing trade-offs in the new protocol = >>>> such that in some environments it achieves a pass in some columns, = >>>> and in other environments it achieves a pass in other columns. >>>> >>>> Maybe you could add this as a statement in the Abstract and = >>>> Introduction >>>> >>>> --- >>>> >>>> Why do you include the requirements language boilerplate? I don't = >>>> think you use (or should use) such language in this document. >>>> >>>> --- >>>> >>>> Section 1 >>>> >>>> Can you strip out terms not used in the document? >>>> >>>> --- >>>> >>>> Section 2 >>>> >>>> You quote CPU power in MHz. Although that is the practical = >> electronic = >>>> limit, maybe MIPS would be a better measure. >>>> >>>> --- >>>> >>>> Section 3 para 2 >>>> >>>> "If a protocol cannot meet even these minimalist criteria..." >>>> I think your use of "cannot" is correct in the context of the = >>>> sentence, but I think your I-D examines "does not" >>>> >>>> "...is unlikely to be good candidate..." >>>> Too much prevarication! >>>> >>>> --- >>>> >>>> Section 3 para 3 >>>> >>>> "...the protocol does not appear to contain sufficient = >> flexibility..." >>>> The problem with this is that it is very mushy! >>>> It is OK to discard a protocol that is not flexible enough = >> to handle = >>>> your requirements. It is not OK to discard a protocol because you = >>>> don't appear to know how to extend it. >>>> >>>> A example comes in the somewhat contentious table in section 4 >>>> :-) Here, for OSPF, you say that there is a "fail" for = >> conveying node = >>>> costs. >>>> But there is already LSA available for carrying node capabilities, = >>>> and there are opaque LSAs available for carrying additional = >>>> "unconventional" >>>> information. >>>> >>>> All this sort of ties to my main point. Of course, the protocols = >>>> don't do exactly what you want already, but a more thorough = >> survey is = >>>> needed if you what to use this I-D as the reason for excluding = >>>> protocols. >>>> >>>> --- >>>> >>>> Section 3.2 para 1 >>>> "...with size ranging from a minimum..." >>>> I think you mean "...with maximum size ranging from a minimum..." >>>> >>>> "very large networks" >>>> Can you de-fluff this? Some people might think that 250 = >> nodes is very = >>>> large >>>> ;-) >>>> >>>> "network depths" >>>> Would be worth including your definition here. >>>> >>>> -- >>>> >>>> Section 3.2 para 1 >>>> >>>> Is every network node a router? >>>> draft-ietf-roll-urban-routing-reqs says "Sensor nodes are = >> capable of = >>>> forwarding data." If every node is a router and participates in the = >>>> routing protocol, this creates a very different environment from = >>>> saying that most sensors are hosts, and some are routers. I = >>>> appreciate that "capable" does not imply "do". >>>> >>>> --- >>>> >>>> Associated with the previous point, I think you might spend = >> a little = >>>> more time discussing the definition of a link in ROLL. It is clear = >>>> that in a wireless n/w a link may exist between any two nodes in = >>>> range. >>>> If that is >>>> what you mean, then it would help to make it clear. On the other = >>>> hand, "link" could be defined as an active neighbor relationship = >>>> between a pair of routers. Or something else. >>>> >>>> This becomes important as we try to understand how the = >> protocol must = >>>> scale, and what it is supposed to do. >>>> >>>> I presume that the concept of "parallel links" between neighbors is = >>>> going to have no meaning at the moment. That is, you use only one = >>>> frequency in any network. Maybe I presume wrong, in which case, you = >>>> need to refine the definition of "network density" in section 3.1. >>>> >>>> --- >>>> >>>> Section 3.2 para 1 >>>> Final sentence is a bit mangled. >>>> >>>> --- >>>> >>>> Section 3.2 para 2 >>>> >>>> I can see why scaling with O(L) may be an issue, but it may = >> depend on = >>>> the definitions of links and routers. Also it may depend on what = >>>> magnitude you expect for L. Perhaps you could give some = >> ball-parks in = >>>> the previous paragraph as you do for N and D. Without that, it is = >>>> hard to justify the claim that scaling with O(L) is a problem. >>>> >>>> --- >>>> >>>> Section 3.3 >>>> >>>> Can you add SINR to your terminology? >>>> >>>> "...not trigger unnecessary responses..." >>>> I think that this is subjective and unhelpful. Can you rephrase to = >>>> capture a quantifiable requirement? >>>> >>>> s/link changes to propagate across/link changes to be propagated = >>>> across/ >>>> >>>> s/O(l)/O(L)/ >>>> >>>> --- >>>> >>>> Section 3.3 final para >>>> >>>> You have "transmissions", "broadcast", and "route updates". >>>> Can you use a >>>> consistent term? It may be less pretty English, but it would be a = >>>> better way to avoid accusations of bias :-) >>>> >>>> Perhaps... >>>> More precisely, loss responses that require transmissions = >> within the = >>>> network of O(N) fail, while those that are limited to O(L) or O(D) = >>>> pass. >>>> >>>> --- >>>> >>>> Section 3.4 para 1 >>>> >>>> "In terms of routing structure, any proposed L2N routing protocol = >>>> ought to support the autonomous organization and = >> configuration of the = >>>> network at the lowest possible energy cost." >>>> >>>> Why "L2N"? I thought "Networks of low power wireless devices = >>>> introduce novel IP routing issues." >>>> >>>> "ought" is not a recognized RFC 2119 word :-) >>>> >>>> I think "at the lowest possible energy cost" is a statement = >> that this = >>>> requirement trumps all others. Is that what you mean? >>>> >>>> I'm not convinced by the absolute statement you make here. >>>> Maybe, this is a >>>> question I should take to the requirements documents. Consider = >>>> routing protocol A that is slightly more (say 5%) power-consuming = >>>> than routing protocol B. But suppose protocol A gives rise = >> to a data = >>>> forwarding solution that is 50% more power-efficient? >>>> >>>> --- >>>> >>>> Section 3.4 para 2 >>>> >>>> "As low-power wireless networks can have very low data rates, = >>>> protocols which require a minimum control packet rate can have = >>>> unbounded control overhead." >>>> >>>> I know what you mean, but I had to parse several times. How about... >>>> >>>> The control overhead is the ratio of control data to = >> payload data. A = >>>> high control overhead indicates that precious network resources = >>>> (bandwidth, power, or CPU) are being consumed by the control = >>>> protocols instead of being used to transmit data. Where = >> payload data = >>>> rates are very low (as is often the case in low-power wireless = >>>> networks) the control overhead can become unbounded for protocols = >>>> that require some non-zero background control packet rate. >>>> >>>> --- >>>> >>>> Section 3.4 para 2 >>>> >>>> s/never meet the condition can be forced/never meet the condition = >>>> could be forced/ >>>> >>>> --- >>>> >>>> Section 4 para 3 >>>> >>>> "multiple layer 2 hops away" >>>> Really? >>>> Again, I thought we were building an IP routing protocol. If your = >>>> requirement is layer 2 routing, you need to make that = >> visible up front. >>>> But, I can see why you are interested in L2 hops as well as L3 hops = >>>> since they all consume power. >>>> >>>> This comes back to the question about whether all nodes are = >> routers. = >>>> Perhaps some repeaters are not routers? >>>> >>>> But can't we actually factor the L2 hops into the definition of the = >>>> L3 hop? >>>> >>>> --- >>>> >>>> Section 4 para 3 >>>> >>>> "...nodes may only advertise..." >>>> This sounds prohibitive! >>>> >>>> --- >>>> >>>> Section 4 para 4 >>>> >>>> "Neighbor discovery is a critical component of any routing = >> protocol." >>>> I think I disagree. >>>> It is clear that routing protocols need to know their neighbors. It = >>>> is not clear that this requires that the discovery be part of the = >>>> routing protocol. >>>> >>>> Later you have: >>>> "...key component of many protocols." >>>> This is less strong than the initial sentence. >>>> >>>> --- >>>> >>>> Section 4 >>>> >>>> "Protocols Today" >>>> >>>> Is this a section 4.1 headers? >>>> >>>> --- >>>> >>>> Section 4 "Protocols Today" para 2 >>>> >>>> I don't think the MPLS TE example is a good one. It is = >> certainly not = >>>> correct that the TED has to be fully distributed around the network. >>>> There are some very good examples of where "stub TE areas" do not = >>>> need to know the TE information for the whole of the rest of the = >>>> network. >>>> >>>> --- >>>> >>>> Section 4 Table >>>> >>>> I'm prepared to bet that a lot of people will be upset by = >> the use of = >>>> "fail" >>>> for their favorite protocols. It would seem that "?" is more = >>>> appropriate in many cells. >>>> >>>> --- >>>> >>>> Section 5.1 >>>> Is it worth replacing "OSPF" with "OSPF or IS-IS"? >>>> >>>> --- >>>> >>>> Section 14. >>>> Your three ROLL requirements drafts are Normative = >> References, I think. >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > 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 Wed Aug 27 08:43: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 429C63A688A; Wed, 27 Aug 2008 08:43: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 84C273A6B63 for ; Wed, 27 Aug 2008 08:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.041 X-Spam-Level: X-Spam-Status: No, score=-0.041 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 35z9Xqdcw84B for ; Wed, 27 Aug 2008 08:43:44 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 2C8D23A6C02 for ; Wed, 27 Aug 2008 08:43:44 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7RFhRrU011941; Wed, 27 Aug 2008 16:43:29 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7RFhQjw011923; Wed, 27 Aug 2008 16:43:26 +0100 Message-ID: <065801c9085b$a4a20ee0$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Drake, John E" , "JP Vasseur" , References: <51661468CBD1354294533DA79E85955A01053026@XCH-SW-5V2.sw.nos.boeing.com> <51661468CBD1354294533DA79E85955A0109FD7B@XCH-SW-5V2.sw.nos.boeing.com> Date: Wed, 27 Aug 2008 16:36:37 +0100 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.3350 Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel 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 Right. I am not saying that a new protocol is not needed. I am saying that I'd like to see some more discussion of what the routing protocol is trying to achieve. The work to describe how the protocol itself must behave is pretty good. But the work describing what information must be distributed, how up-to-date it must be, and how it will be used is missing. I am sure that this is all work in progress and will emerge in due course. A ----- Original Message ----- From: "Drake, John E" To: "JP Vasseur" ; "Adrian Farrel" ; Sent: Wednesday, August 27, 2008 3:45 PM Subject: RE: [Roll] draft-ietf-roll-protocols-survey-00 JP, I thought that was exactly Adrian's point. If you evaluate a bunch of routing protocols as they exist today in a new operational environment and conclude that none of them are appropriate, then you have no choice but to conclude that you need to invent at least one, but probably many, new routing protocols. It's not like this hasn't been done before. I took Adrian's note to say that doing this is not sufficient and that what needed to be done was to characterize the new operational environment, propose changes needed in each routing protocol to address the new operational environment, and then evaluate these changes. Thanks, John >-----Original Message----- >From: JP Vasseur [mailto:jvasseur@cisco.com] >Sent: Wednesday, August 27, 2008 2:24 AM >To: Drake, John E; Adrian Farrel; roll@ietf.org >Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 > >John, > >I do not think that this was Adrian's point. Your feed-back is >more than welcome but please argue a bit more ... > >Thanks. > >JP. > > >On 8/25/08 6:13 PM, "Drake, John E" wrote: > >> Adrian, >> >> An excellent note - I agree completely. We need fewer routing >> protocols, not more. >> >> Thanks, >> >> John >> >>> -----Original Message----- >>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>> Sent: Sunday, August 24, 2008 5:14 AM >>> To: roll@ietf.org >>> Subject: [Roll] draft-ietf-roll-protocols-survey-00 >>> >>> Hi, >>> >>> As one of the two tourists who raised a hand in Dublin to express >>> uneasiness about this I-D becoming a WG draft, I thought I should >>> write a note about my concerns. >>> >>> I should caveat this by saying that I do appreciate the >need for this >>> work, and that the author-team will, I'm sure, do a fine job at >>> delivering what the working group needs. My concerns were much more >>> about getting the direction of the I-D right before >accepting it as I >>> think it is often harder to recast an I-D once it is within the >>> working group. >>> >>> Below, please find my major discussion point. I have also done a >>> review of the draft and found a bunch of issues/questions of more >>> minor importance. >>> >>> Regards, >>> Adrian >>> >>> === >>> >>> The analysis of the routing protocols is predicated on what >they are >>> currently used for. To some extent this is reasonable >>> - the easiest analysis of a routing protocol is in its operational >>> environment. But to use this analysis as the basis of a >decision for >>> use of a protocol in a new environment is not so reasonable. If you >>> want to show that none of today's protocols has been >designed for use >>> in the ROLL environment, then I don't suppose anyone will be >>> surprised. However, what we are really interested in is whether any >>> of the existing protocols is suitable for adaptation for >use in ROLL, >>> whether the those adaptations would be contrived and >technically hard >>> (or flaky), and whether it would be more efficient to design a new >>> protocol. >>> >>> For an example (and I'm not proposing this as the solution >for ROLL), >>> an IGP could easily be adapted to flood on only certain links, to >>> discard certain LSAs, and to build a FIB according to >specific rules. >>> This would not be a large change to the protocol, although it would >>> obviously not be interoperable. >>> >>> To discard from consideration any protocol based on its >behavior in a >>> certain environment without setting it in the context of your >>> forwarding paradigm and without examining the potential to adapt a >>> protocol to that environment is wrong. If all you wanted to do was >>> show that no current variant of any existing routing protocol is >>> immediately applicable to ROLL, then that would be easy and >would not >>> be a surprise. But to imply that protocols are not open for >>> adaptation is more serious. >>> >>> This is not to say that inventing a new protocol would be wrong or >>> not fun. >>> Only that your reasons for discarding protocols are poorly founded. >>> You have focused on the operation of the routing protocol, not the >>> purpose of the routing protocol. To give a better understanding of >>> why you are discarding a protocol, you must show what you want to >>> achieve as your forwarding paradigm. The requirements >documents make >>> some start at this. >>> For example, draft-ietf-roll-urban-routing-reqs talks about: >>> - routing to minimise power usage >>> - routing to consider node and link capabilities >>> - routing protocol to scale within CPU, memory and power limits >>> - routing according to different metrics (latency is cited) >>> >>> Such considerations are a good start to understanding the >forwarding >>> paradigm in ROLL, but would not be good enough to use to >devise a new >>> routing protocol, so I don't see how they can be good enough to >>> determine whether an existing protocol should be discarded, >modified, >>> or used. >>> >>> ============= >>> >>> More specific comments on the draft follow. >>> >>> --- >>> >>> Do we have a commitment from the WG that any new protocol developed >>> will be held to the same standards? That is, that the new protocol >>> MUST achieve a "pass" in very column of the table in >section 4. Or is >>> there scope for pragmatism allowing trade-offs in the new protocol >>> such that in some environments it achieves a pass in some columns, >>> and in other environments it achieves a pass in other columns. >>> >>> Maybe you could add this as a statement in the Abstract and >>> Introduction >>> >>> --- >>> >>> Why do you include the requirements language boilerplate? I don't >>> think you use (or should use) such language in this document. >>> >>> --- >>> >>> Section 1 >>> >>> Can you strip out terms not used in the document? >>> >>> --- >>> >>> Section 2 >>> >>> You quote CPU power in MHz. Although that is the practical >electronic >>> limit, maybe MIPS would be a better measure. >>> >>> --- >>> >>> Section 3 para 2 >>> >>> "If a protocol cannot meet even these minimalist criteria..." >>> I think your use of "cannot" is correct in the context of the >>> sentence, but I think your I-D examines "does not" >>> >>> "...is unlikely to be good candidate..." >>> Too much prevarication! >>> >>> --- >>> >>> Section 3 para 3 >>> >>> "...the protocol does not appear to contain sufficient >flexibility..." >>> The problem with this is that it is very mushy! >>> It is OK to discard a protocol that is not flexible enough >to handle >>> your requirements. It is not OK to discard a protocol because you >>> don't appear to know how to extend it. >>> >>> A example comes in the somewhat contentious table in section 4 >>> :-) Here, for OSPF, you say that there is a "fail" for >conveying node >>> costs. >>> But there is already LSA available for carrying node capabilities, >>> and there are opaque LSAs available for carrying additional >>> "unconventional" >>> information. >>> >>> All this sort of ties to my main point. Of course, the protocols >>> don't do exactly what you want already, but a more thorough >survey is >>> needed if you what to use this I-D as the reason for excluding >>> protocols. >>> >>> --- >>> >>> Section 3.2 para 1 >>> "...with size ranging from a minimum..." >>> I think you mean "...with maximum size ranging from a minimum..." >>> >>> "very large networks" >>> Can you de-fluff this? Some people might think that 250 >nodes is very >>> large >>> ;-) >>> >>> "network depths" >>> Would be worth including your definition here. >>> >>> -- >>> >>> Section 3.2 para 1 >>> >>> Is every network node a router? >>> draft-ietf-roll-urban-routing-reqs says "Sensor nodes are >capable of >>> forwarding data." If every node is a router and participates in the >>> routing protocol, this creates a very different environment from >>> saying that most sensors are hosts, and some are routers. I >>> appreciate that "capable" does not imply "do". >>> >>> --- >>> >>> Associated with the previous point, I think you might spend >a little >>> more time discussing the definition of a link in ROLL. It is clear >>> that in a wireless n/w a link may exist between any two nodes in >>> range. >>> If that is >>> what you mean, then it would help to make it clear. On the other >>> hand, "link" could be defined as an active neighbor relationship >>> between a pair of routers. Or something else. >>> >>> This becomes important as we try to understand how the >protocol must >>> scale, and what it is supposed to do. >>> >>> I presume that the concept of "parallel links" between neighbors is >>> going to have no meaning at the moment. That is, you use only one >>> frequency in any network. Maybe I presume wrong, in which case, you >>> need to refine the definition of "network density" in section 3.1. >>> >>> --- >>> >>> Section 3.2 para 1 >>> Final sentence is a bit mangled. >>> >>> --- >>> >>> Section 3.2 para 2 >>> >>> I can see why scaling with O(L) may be an issue, but it may >depend on >>> the definitions of links and routers. Also it may depend on what >>> magnitude you expect for L. Perhaps you could give some >ball-parks in >>> the previous paragraph as you do for N and D. Without that, it is >>> hard to justify the claim that scaling with O(L) is a problem. >>> >>> --- >>> >>> Section 3.3 >>> >>> Can you add SINR to your terminology? >>> >>> "...not trigger unnecessary responses..." >>> I think that this is subjective and unhelpful. Can you rephrase to >>> capture a quantifiable requirement? >>> >>> s/link changes to propagate across/link changes to be propagated >>> across/ >>> >>> s/O(l)/O(L)/ >>> >>> --- >>> >>> Section 3.3 final para >>> >>> You have "transmissions", "broadcast", and "route updates". >>> Can you use a >>> consistent term? It may be less pretty English, but it would be a >>> better way to avoid accusations of bias :-) >>> >>> Perhaps... >>> More precisely, loss responses that require transmissions >within the >>> network of O(N) fail, while those that are limited to O(L) or O(D) >>> pass. >>> >>> --- >>> >>> Section 3.4 para 1 >>> >>> "In terms of routing structure, any proposed L2N routing protocol >>> ought to support the autonomous organization and >configuration of the >>> network at the lowest possible energy cost." >>> >>> Why "L2N"? I thought "Networks of low power wireless devices >>> introduce novel IP routing issues." >>> >>> "ought" is not a recognized RFC 2119 word :-) >>> >>> I think "at the lowest possible energy cost" is a statement >that this >>> requirement trumps all others. Is that what you mean? >>> >>> I'm not convinced by the absolute statement you make here. >>> Maybe, this is a >>> question I should take to the requirements documents. Consider >>> routing protocol A that is slightly more (say 5%) power-consuming >>> than routing protocol B. But suppose protocol A gives rise >to a data >>> forwarding solution that is 50% more power-efficient? >>> >>> --- >>> >>> Section 3.4 para 2 >>> >>> "As low-power wireless networks can have very low data rates, >>> protocols which require a minimum control packet rate can have >>> unbounded control overhead." >>> >>> I know what you mean, but I had to parse several times. How about... >>> >>> The control overhead is the ratio of control data to >payload data. A >>> high control overhead indicates that precious network resources >>> (bandwidth, power, or CPU) are being consumed by the control >>> protocols instead of being used to transmit data. Where >payload data >>> rates are very low (as is often the case in low-power wireless >>> networks) the control overhead can become unbounded for protocols >>> that require some non-zero background control packet rate. >>> >>> --- >>> >>> Section 3.4 para 2 >>> >>> s/never meet the condition can be forced/never meet the condition >>> could be forced/ >>> >>> --- >>> >>> Section 4 para 3 >>> >>> "multiple layer 2 hops away" >>> Really? >>> Again, I thought we were building an IP routing protocol. If your >>> requirement is layer 2 routing, you need to make that >visible up front. >>> But, I can see why you are interested in L2 hops as well as L3 hops >>> since they all consume power. >>> >>> This comes back to the question about whether all nodes are >routers. >>> Perhaps some repeaters are not routers? >>> >>> But can't we actually factor the L2 hops into the definition of the >>> L3 hop? >>> >>> --- >>> >>> Section 4 para 3 >>> >>> "...nodes may only advertise..." >>> This sounds prohibitive! >>> >>> --- >>> >>> Section 4 para 4 >>> >>> "Neighbor discovery is a critical component of any routing >protocol." >>> I think I disagree. >>> It is clear that routing protocols need to know their neighbors. It >>> is not clear that this requires that the discovery be part of the >>> routing protocol. >>> >>> Later you have: >>> "...key component of many protocols." >>> This is less strong than the initial sentence. >>> >>> --- >>> >>> Section 4 >>> >>> "Protocols Today" >>> >>> Is this a section 4.1 headers? >>> >>> --- >>> >>> Section 4 "Protocols Today" para 2 >>> >>> I don't think the MPLS TE example is a good one. It is >certainly not >>> correct that the TED has to be fully distributed around the network. >>> There are some very good examples of where "stub TE areas" do not >>> need to know the TE information for the whole of the rest of the >>> network. >>> >>> --- >>> >>> Section 4 Table >>> >>> I'm prepared to bet that a lot of people will be upset by >the use of >>> "fail" >>> for their favorite protocols. It would seem that "?" is more >>> appropriate in many cells. >>> >>> --- >>> >>> Section 5.1 >>> Is it worth replacing "OSPF" with "OSPF or IS-IS"? >>> >>> --- >>> >>> Section 14. >>> Your three ROLL requirements drafts are Normative >References, I think. >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Aug 27 09:38:31 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 3A5AD3A6A76; Wed, 27 Aug 2008 09:38:31 -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 3C6D53A694C for ; Wed, 27 Aug 2008 09:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.874 X-Spam-Level: X-Spam-Status: No, score=-4.874 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 eXdwkOHsxa8Y for ; Wed, 27 Aug 2008 09:38:27 -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 1FB5E3A67E9 for ; Wed, 27 Aug 2008 09:38:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,279,1217808000"; d="scan'208";a="18902470" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Aug 2008 16:38:03 +0000 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 m7RGc38x008883; Wed, 27 Aug 2008 12:38:03 -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 m7RGc3n5019065; Wed, 27 Aug 2008 16:38:03 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); Wed, 27 Aug 2008 12:38:03 -0400 Received: from 10.55.206.229 ([10.55.206.229]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Aug 2008 16:38:02 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 27 Aug 2008 18:38:01 +0200 From: JP Vasseur To: "Drake, John E" , Adrian Farrel , Message-ID: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckF4uWWv+jCr8q7RKKuNS7geV3eIgA6l4jAAFZXU+0ACvR8MAAENIb7 In-Reply-To: <51661468CBD1354294533DA79E85955A0109FD7B@XCH-SW-5V2.sw.nos.boeing.com> Mime-version: 1.0 X-OriginalArrivalTime: 27 Aug 2008 16:38:03.0214 (UTC) FILETIME=[465E4EE0:01C90863] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15588; t=1219855083; x=1220719083; 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]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20 |To:=20=22Drake,=20John=20E=22=20 ,=0A=20=20=20=20=20=20=20=20Adrian=20Farrel=20,=20; bh=9GgUO4lwoVURrWFgTlMaOFHZ+hBSmA/Mq9NdHb/Yb+s=; b=fQ1iECJoIfHlofslYIjSCVMlzfBU6qU6Oi5XsyNU+o4C2ktwViNSz95Etu vPoZchfoFK3xZO4YfgwLGcw6FD56NP7ptF92z+lNT72ou16vC9plOxfzlb/G MYQUM03dKq; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 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 John, On 8/27/08 4:45 PM, "Drake, John E" wrote: > JP, > > I thought that was exactly Adrian's point. Ok let's have him express his opinion. > > If you evaluate a bunch of routing protocols as they exist today in a > new operational environment and conclude that none of them are > appropriate, then you have no choice but to conclude that you need to > invent at least one, but probably many, new routing protocols. It's not > like this hasn't been done before. > > I took Adrian's note to say that doing this is not sufficient and that > what needed to be done was to characterize the new operational > environment, propose changes needed in each routing protocol to address > the new operational environment, and then evaluate these changes. > John, I fully respect your opinion. Feel free to propose these changes in light of the routing requirements expressed in the related WG document. Please make sure to fully understand them though, these networks have fairly unique characteristics that do require significant background. JP. > Thanks, > > John > >> -----Original Message----- >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: Wednesday, August 27, 2008 2:24 AM >> To: Drake, John E; Adrian Farrel; roll@ietf.org >> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >> >> John, >> >> I do not think that this was Adrian's point. Your feed-back is >> more than welcome but please argue a bit more ... >> >> Thanks. >> >> JP. >> >> >> On 8/25/08 6:13 PM, "Drake, John E" wrote: >> >>> Adrian, >>> >>> An excellent note - I agree completely. We need fewer routing >>> protocols, not more. >>> >>> Thanks, >>> >>> John >>> >>>> -----Original Message----- >>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>> Sent: Sunday, August 24, 2008 5:14 AM >>>> To: roll@ietf.org >>>> Subject: [Roll] draft-ietf-roll-protocols-survey-00 >>>> >>>> Hi, >>>> >>>> As one of the two tourists who raised a hand in Dublin to express >>>> uneasiness about this I-D becoming a WG draft, I thought I should >>>> write a note about my concerns. >>>> >>>> I should caveat this by saying that I do appreciate the >> need for this >>>> work, and that the author-team will, I'm sure, do a fine job at >>>> delivering what the working group needs. My concerns were much more >>>> about getting the direction of the I-D right before >> accepting it as I >>>> think it is often harder to recast an I-D once it is within the >>>> working group. >>>> >>>> Below, please find my major discussion point. I have also done a >>>> review of the draft and found a bunch of issues/questions of more >>>> minor importance. >>>> >>>> Regards, >>>> Adrian >>>> >>>> === >>>> >>>> The analysis of the routing protocols is predicated on what >> they are >>>> currently used for. To some extent this is reasonable >>>> - the easiest analysis of a routing protocol is in its operational >>>> environment. But to use this analysis as the basis of a >> decision for >>>> use of a protocol in a new environment is not so reasonable. If you >>>> want to show that none of today's protocols has been >> designed for use >>>> in the ROLL environment, then I don't suppose anyone will be >>>> surprised. However, what we are really interested in is whether any >>>> of the existing protocols is suitable for adaptation for >> use in ROLL, >>>> whether the those adaptations would be contrived and >> technically hard >>>> (or flaky), and whether it would be more efficient to design a new >>>> protocol. >>>> >>>> For an example (and I'm not proposing this as the solution >> for ROLL), >>>> an IGP could easily be adapted to flood on only certain links, to >>>> discard certain LSAs, and to build a FIB according to >> specific rules. >>>> This would not be a large change to the protocol, although it would >>>> obviously not be interoperable. >>>> >>>> To discard from consideration any protocol based on its >> behavior in a >>>> certain environment without setting it in the context of your >>>> forwarding paradigm and without examining the potential to adapt a >>>> protocol to that environment is wrong. If all you wanted to do was >>>> show that no current variant of any existing routing protocol is >>>> immediately applicable to ROLL, then that would be easy and >> would not >>>> be a surprise. But to imply that protocols are not open for >>>> adaptation is more serious. >>>> >>>> This is not to say that inventing a new protocol would be wrong or >>>> not fun. >>>> Only that your reasons for discarding protocols are poorly founded. >>>> You have focused on the operation of the routing protocol, not the >>>> purpose of the routing protocol. To give a better understanding of >>>> why you are discarding a protocol, you must show what you want to >>>> achieve as your forwarding paradigm. The requirements >> documents make >>>> some start at this. >>>> For example, draft-ietf-roll-urban-routing-reqs talks about: >>>> - routing to minimise power usage >>>> - routing to consider node and link capabilities >>>> - routing protocol to scale within CPU, memory and power limits >>>> - routing according to different metrics (latency is cited) >>>> >>>> Such considerations are a good start to understanding the >> forwarding >>>> paradigm in ROLL, but would not be good enough to use to >> devise a new >>>> routing protocol, so I don't see how they can be good enough to >>>> determine whether an existing protocol should be discarded, >> modified, >>>> or used. >>>> >>>> ============= >>>> >>>> More specific comments on the draft follow. >>>> >>>> --- >>>> >>>> Do we have a commitment from the WG that any new protocol developed >>>> will be held to the same standards? That is, that the new protocol >>>> MUST achieve a "pass" in very column of the table in >> section 4. Or is >>>> there scope for pragmatism allowing trade-offs in the new protocol >>>> such that in some environments it achieves a pass in some columns, >>>> and in other environments it achieves a pass in other columns. >>>> >>>> Maybe you could add this as a statement in the Abstract and >>>> Introduction >>>> >>>> --- >>>> >>>> Why do you include the requirements language boilerplate? I don't >>>> think you use (or should use) such language in this document. >>>> >>>> --- >>>> >>>> Section 1 >>>> >>>> Can you strip out terms not used in the document? >>>> >>>> --- >>>> >>>> Section 2 >>>> >>>> You quote CPU power in MHz. Although that is the practical >> electronic >>>> limit, maybe MIPS would be a better measure. >>>> >>>> --- >>>> >>>> Section 3 para 2 >>>> >>>> "If a protocol cannot meet even these minimalist criteria..." >>>> I think your use of "cannot" is correct in the context of the >>>> sentence, but I think your I-D examines "does not" >>>> >>>> "...is unlikely to be good candidate..." >>>> Too much prevarication! >>>> >>>> --- >>>> >>>> Section 3 para 3 >>>> >>>> "...the protocol does not appear to contain sufficient >> flexibility..." >>>> The problem with this is that it is very mushy! >>>> It is OK to discard a protocol that is not flexible enough >> to handle >>>> your requirements. It is not OK to discard a protocol because you >>>> don't appear to know how to extend it. >>>> >>>> A example comes in the somewhat contentious table in section 4 >>>> :-) Here, for OSPF, you say that there is a "fail" for >> conveying node >>>> costs. >>>> But there is already LSA available for carrying node capabilities, >>>> and there are opaque LSAs available for carrying additional >>>> "unconventional" >>>> information. >>>> >>>> All this sort of ties to my main point. Of course, the protocols >>>> don't do exactly what you want already, but a more thorough >> survey is >>>> needed if you what to use this I-D as the reason for excluding >>>> protocols. >>>> >>>> --- >>>> >>>> Section 3.2 para 1 >>>> "...with size ranging from a minimum..." >>>> I think you mean "...with maximum size ranging from a minimum..." >>>> >>>> "very large networks" >>>> Can you de-fluff this? Some people might think that 250 >> nodes is very >>>> large >>>> ;-) >>>> >>>> "network depths" >>>> Would be worth including your definition here. >>>> >>>> -- >>>> >>>> Section 3.2 para 1 >>>> >>>> Is every network node a router? >>>> draft-ietf-roll-urban-routing-reqs says "Sensor nodes are >> capable of >>>> forwarding data." If every node is a router and participates in the >>>> routing protocol, this creates a very different environment from >>>> saying that most sensors are hosts, and some are routers. I >>>> appreciate that "capable" does not imply "do". >>>> >>>> --- >>>> >>>> Associated with the previous point, I think you might spend >> a little >>>> more time discussing the definition of a link in ROLL. It is clear >>>> that in a wireless n/w a link may exist between any two nodes in >>>> range. >>>> If that is >>>> what you mean, then it would help to make it clear. On the other >>>> hand, "link" could be defined as an active neighbor relationship >>>> between a pair of routers. Or something else. >>>> >>>> This becomes important as we try to understand how the >> protocol must >>>> scale, and what it is supposed to do. >>>> >>>> I presume that the concept of "parallel links" between neighbors is >>>> going to have no meaning at the moment. That is, you use only one >>>> frequency in any network. Maybe I presume wrong, in which case, you >>>> need to refine the definition of "network density" in section 3.1. >>>> >>>> --- >>>> >>>> Section 3.2 para 1 >>>> Final sentence is a bit mangled. >>>> >>>> --- >>>> >>>> Section 3.2 para 2 >>>> >>>> I can see why scaling with O(L) may be an issue, but it may >> depend on >>>> the definitions of links and routers. Also it may depend on what >>>> magnitude you expect for L. Perhaps you could give some >> ball-parks in >>>> the previous paragraph as you do for N and D. Without that, it is >>>> hard to justify the claim that scaling with O(L) is a problem. >>>> >>>> --- >>>> >>>> Section 3.3 >>>> >>>> Can you add SINR to your terminology? >>>> >>>> "...not trigger unnecessary responses..." >>>> I think that this is subjective and unhelpful. Can you rephrase to >>>> capture a quantifiable requirement? >>>> >>>> s/link changes to propagate across/link changes to be propagated >>>> across/ >>>> >>>> s/O(l)/O(L)/ >>>> >>>> --- >>>> >>>> Section 3.3 final para >>>> >>>> You have "transmissions", "broadcast", and "route updates". >>>> Can you use a >>>> consistent term? It may be less pretty English, but it would be a >>>> better way to avoid accusations of bias :-) >>>> >>>> Perhaps... >>>> More precisely, loss responses that require transmissions >> within the >>>> network of O(N) fail, while those that are limited to O(L) or O(D) >>>> pass. >>>> >>>> --- >>>> >>>> Section 3.4 para 1 >>>> >>>> "In terms of routing structure, any proposed L2N routing protocol >>>> ought to support the autonomous organization and >> configuration of the >>>> network at the lowest possible energy cost." >>>> >>>> Why "L2N"? I thought "Networks of low power wireless devices >>>> introduce novel IP routing issues." >>>> >>>> "ought" is not a recognized RFC 2119 word :-) >>>> >>>> I think "at the lowest possible energy cost" is a statement >> that this >>>> requirement trumps all others. Is that what you mean? >>>> >>>> I'm not convinced by the absolute statement you make here. >>>> Maybe, this is a >>>> question I should take to the requirements documents. Consider >>>> routing protocol A that is slightly more (say 5%) power-consuming >>>> than routing protocol B. But suppose protocol A gives rise >> to a data >>>> forwarding solution that is 50% more power-efficient? >>>> >>>> --- >>>> >>>> Section 3.4 para 2 >>>> >>>> "As low-power wireless networks can have very low data rates, >>>> protocols which require a minimum control packet rate can have >>>> unbounded control overhead." >>>> >>>> I know what you mean, but I had to parse several times. How about... >>>> >>>> The control overhead is the ratio of control data to >> payload data. A >>>> high control overhead indicates that precious network resources >>>> (bandwidth, power, or CPU) are being consumed by the control >>>> protocols instead of being used to transmit data. Where >> payload data >>>> rates are very low (as is often the case in low-power wireless >>>> networks) the control overhead can become unbounded for protocols >>>> that require some non-zero background control packet rate. >>>> >>>> --- >>>> >>>> Section 3.4 para 2 >>>> >>>> s/never meet the condition can be forced/never meet the condition >>>> could be forced/ >>>> >>>> --- >>>> >>>> Section 4 para 3 >>>> >>>> "multiple layer 2 hops away" >>>> Really? >>>> Again, I thought we were building an IP routing protocol. If your >>>> requirement is layer 2 routing, you need to make that >> visible up front. >>>> But, I can see why you are interested in L2 hops as well as L3 hops >>>> since they all consume power. >>>> >>>> This comes back to the question about whether all nodes are >> routers. >>>> Perhaps some repeaters are not routers? >>>> >>>> But can't we actually factor the L2 hops into the definition of the >>>> L3 hop? >>>> >>>> --- >>>> >>>> Section 4 para 3 >>>> >>>> "...nodes may only advertise..." >>>> This sounds prohibitive! >>>> >>>> --- >>>> >>>> Section 4 para 4 >>>> >>>> "Neighbor discovery is a critical component of any routing >> protocol." >>>> I think I disagree. >>>> It is clear that routing protocols need to know their neighbors. It >>>> is not clear that this requires that the discovery be part of the >>>> routing protocol. >>>> >>>> Later you have: >>>> "...key component of many protocols." >>>> This is less strong than the initial sentence. >>>> >>>> --- >>>> >>>> Section 4 >>>> >>>> "Protocols Today" >>>> >>>> Is this a section 4.1 headers? >>>> >>>> --- >>>> >>>> Section 4 "Protocols Today" para 2 >>>> >>>> I don't think the MPLS TE example is a good one. It is >> certainly not >>>> correct that the TED has to be fully distributed around the network. >>>> There are some very good examples of where "stub TE areas" do not >>>> need to know the TE information for the whole of the rest of the >>>> network. >>>> >>>> --- >>>> >>>> Section 4 Table >>>> >>>> I'm prepared to bet that a lot of people will be upset by >> the use of >>>> "fail" >>>> for their favorite protocols. It would seem that "?" is more >>>> appropriate in many cells. >>>> >>>> --- >>>> >>>> Section 5.1 >>>> Is it worth replacing "OSPF" with "OSPF or IS-IS"? >>>> >>>> --- >>>> >>>> Section 14. >>>> Your three ROLL requirements drafts are Normative >> References, I think. >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Aug 27 09:42:10 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 A33BC3A6AC3; Wed, 27 Aug 2008 09:42:10 -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 A5B4B3A694C for ; Wed, 27 Aug 2008 09:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.682 X-Spam-Level: X-Spam-Status: No, score=-4.682 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 mTmt++1h4IT8 for ; Wed, 27 Aug 2008 09:42:07 -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 C70843A6AC3 for ; Wed, 27 Aug 2008 09:42:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,279,1217808000"; d="scan'208";a="78616872" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2008 16:41:34 +0000 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 m7RGfYGQ007139; Wed, 27 Aug 2008 09:41:34 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7RGfOGt008208; Wed, 27 Aug 2008 16:41:34 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, 27 Aug 2008 12:41:32 -0400 Received: from 10.55.206.229 ([10.55.206.229]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Aug 2008 16:41:32 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 27 Aug 2008 18:41:31 +0200 From: JP Vasseur To: Adrian Farrel , "Drake, John E" , Message-ID: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckIY8I3xZ/MdTsAeUWxNceWkLcHvw== In-Reply-To: <065801c9085b$a4a20ee0$0300a8c0@your029b8cecfe> Mime-version: 1.0 X-OriginalArrivalTime: 27 Aug 2008 16:41:32.0874 (UTC) FILETIME=[C355E2A0:01C90863] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16314; t=1219855294; x=1220719294; 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]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20; bh=ddJbcv8itWZtO7zPAnrMw0NNgnV8uiyxwQDgNX2sL3Y=; b=GQdqH0RrR+Txai3Nmm/W736UAG0tAACt50ZZfpO/E0LOmBpW9acfE13D31 P4XQPCj+4xbcWexqS3hVcSA8GDM3bncHtXs1aFzidvDmvFJXF6t+X9xQlhUQ +Cg28Y89Am; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 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 Adrian, On 8/27/08 5:36 PM, "Adrian Farrel" wrote: > Right. > > I am not saying that a new protocol is not needed. I am saying that I'd like > to see some more discussion of what the routing protocol is trying to > achieve. > > The work to describe how the protocol itself must behave is pretty good. Right. But > the work describing what information must be distributed, how up-to-date it > must be, and how it will be used is missing. > > I am sure that this is all work in progress and will emerge in due course. Absolutely, although there is already some of that in the existing documents and others (such as the routing metrics - an individual submission at this points). Required protocol characteristics are described (e.g. Constrained based routing, node constraints, protocol overhead, ...). Cheers, JP. > > A > ----- Original Message ----- > From: "Drake, John E" > To: "JP Vasseur" ; "Adrian Farrel" > ; > Sent: Wednesday, August 27, 2008 3:45 PM > Subject: RE: [Roll] draft-ietf-roll-protocols-survey-00 > > > JP, > > I thought that was exactly Adrian's point. > > If you evaluate a bunch of routing protocols as they exist today in a > new operational environment and conclude that none of them are > appropriate, then you have no choice but to conclude that you need to > invent at least one, but probably many, new routing protocols. It's not > like this hasn't been done before. > > I took Adrian's note to say that doing this is not sufficient and that > what needed to be done was to characterize the new operational > environment, propose changes needed in each routing protocol to address > the new operational environment, and then evaluate these changes. > > Thanks, > > John > >> -----Original Message----- >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: Wednesday, August 27, 2008 2:24 AM >> To: Drake, John E; Adrian Farrel; roll@ietf.org >> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >> >> John, >> >> I do not think that this was Adrian's point. Your feed-back is >> more than welcome but please argue a bit more ... >> >> Thanks. >> >> JP. >> >> >> On 8/25/08 6:13 PM, "Drake, John E" wrote: >> >>> Adrian, >>> >>> An excellent note - I agree completely. We need fewer routing >>> protocols, not more. >>> >>> Thanks, >>> >>> John >>> >>>> -----Original Message----- >>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>> Sent: Sunday, August 24, 2008 5:14 AM >>>> To: roll@ietf.org >>>> Subject: [Roll] draft-ietf-roll-protocols-survey-00 >>>> >>>> Hi, >>>> >>>> As one of the two tourists who raised a hand in Dublin to express >>>> uneasiness about this I-D becoming a WG draft, I thought I should >>>> write a note about my concerns. >>>> >>>> I should caveat this by saying that I do appreciate the >> need for this >>>> work, and that the author-team will, I'm sure, do a fine job at >>>> delivering what the working group needs. My concerns were much more >>>> about getting the direction of the I-D right before >> accepting it as I >>>> think it is often harder to recast an I-D once it is within the >>>> working group. >>>> >>>> Below, please find my major discussion point. I have also done a >>>> review of the draft and found a bunch of issues/questions of more >>>> minor importance. >>>> >>>> Regards, >>>> Adrian >>>> >>>> === >>>> >>>> The analysis of the routing protocols is predicated on what >> they are >>>> currently used for. To some extent this is reasonable >>>> - the easiest analysis of a routing protocol is in its operational >>>> environment. But to use this analysis as the basis of a >> decision for >>>> use of a protocol in a new environment is not so reasonable. If you >>>> want to show that none of today's protocols has been >> designed for use >>>> in the ROLL environment, then I don't suppose anyone will be >>>> surprised. However, what we are really interested in is whether any >>>> of the existing protocols is suitable for adaptation for >> use in ROLL, >>>> whether the those adaptations would be contrived and >> technically hard >>>> (or flaky), and whether it would be more efficient to design a new >>>> protocol. >>>> >>>> For an example (and I'm not proposing this as the solution >> for ROLL), >>>> an IGP could easily be adapted to flood on only certain links, to >>>> discard certain LSAs, and to build a FIB according to >> specific rules. >>>> This would not be a large change to the protocol, although it would >>>> obviously not be interoperable. >>>> >>>> To discard from consideration any protocol based on its >> behavior in a >>>> certain environment without setting it in the context of your >>>> forwarding paradigm and without examining the potential to adapt a >>>> protocol to that environment is wrong. If all you wanted to do was >>>> show that no current variant of any existing routing protocol is >>>> immediately applicable to ROLL, then that would be easy and >> would not >>>> be a surprise. But to imply that protocols are not open for >>>> adaptation is more serious. >>>> >>>> This is not to say that inventing a new protocol would be wrong or >>>> not fun. >>>> Only that your reasons for discarding protocols are poorly founded. >>>> You have focused on the operation of the routing protocol, not the >>>> purpose of the routing protocol. To give a better understanding of >>>> why you are discarding a protocol, you must show what you want to >>>> achieve as your forwarding paradigm. The requirements >> documents make >>>> some start at this. >>>> For example, draft-ietf-roll-urban-routing-reqs talks about: >>>> - routing to minimise power usage >>>> - routing to consider node and link capabilities >>>> - routing protocol to scale within CPU, memory and power limits >>>> - routing according to different metrics (latency is cited) >>>> >>>> Such considerations are a good start to understanding the >> forwarding >>>> paradigm in ROLL, but would not be good enough to use to >> devise a new >>>> routing protocol, so I don't see how they can be good enough to >>>> determine whether an existing protocol should be discarded, >> modified, >>>> or used. >>>> >>>> ============= >>>> >>>> More specific comments on the draft follow. >>>> >>>> --- >>>> >>>> Do we have a commitment from the WG that any new protocol developed >>>> will be held to the same standards? That is, that the new protocol >>>> MUST achieve a "pass" in very column of the table in >> section 4. Or is >>>> there scope for pragmatism allowing trade-offs in the new protocol >>>> such that in some environments it achieves a pass in some columns, >>>> and in other environments it achieves a pass in other columns. >>>> >>>> Maybe you could add this as a statement in the Abstract and >>>> Introduction >>>> >>>> --- >>>> >>>> Why do you include the requirements language boilerplate? I don't >>>> think you use (or should use) such language in this document. >>>> >>>> --- >>>> >>>> Section 1 >>>> >>>> Can you strip out terms not used in the document? >>>> >>>> --- >>>> >>>> Section 2 >>>> >>>> You quote CPU power in MHz. Although that is the practical >> electronic >>>> limit, maybe MIPS would be a better measure. >>>> >>>> --- >>>> >>>> Section 3 para 2 >>>> >>>> "If a protocol cannot meet even these minimalist criteria..." >>>> I think your use of "cannot" is correct in the context of the >>>> sentence, but I think your I-D examines "does not" >>>> >>>> "...is unlikely to be good candidate..." >>>> Too much prevarication! >>>> >>>> --- >>>> >>>> Section 3 para 3 >>>> >>>> "...the protocol does not appear to contain sufficient >> flexibility..." >>>> The problem with this is that it is very mushy! >>>> It is OK to discard a protocol that is not flexible enough >> to handle >>>> your requirements. It is not OK to discard a protocol because you >>>> don't appear to know how to extend it. >>>> >>>> A example comes in the somewhat contentious table in section 4 >>>> :-) Here, for OSPF, you say that there is a "fail" for >> conveying node >>>> costs. >>>> But there is already LSA available for carrying node capabilities, >>>> and there are opaque LSAs available for carrying additional >>>> "unconventional" >>>> information. >>>> >>>> All this sort of ties to my main point. Of course, the protocols >>>> don't do exactly what you want already, but a more thorough >> survey is >>>> needed if you what to use this I-D as the reason for excluding >>>> protocols. >>>> >>>> --- >>>> >>>> Section 3.2 para 1 >>>> "...with size ranging from a minimum..." >>>> I think you mean "...with maximum size ranging from a minimum..." >>>> >>>> "very large networks" >>>> Can you de-fluff this? Some people might think that 250 >> nodes is very >>>> large >>>> ;-) >>>> >>>> "network depths" >>>> Would be worth including your definition here. >>>> >>>> -- >>>> >>>> Section 3.2 para 1 >>>> >>>> Is every network node a router? >>>> draft-ietf-roll-urban-routing-reqs says "Sensor nodes are >> capable of >>>> forwarding data." If every node is a router and participates in the >>>> routing protocol, this creates a very different environment from >>>> saying that most sensors are hosts, and some are routers. I >>>> appreciate that "capable" does not imply "do". >>>> >>>> --- >>>> >>>> Associated with the previous point, I think you might spend >> a little >>>> more time discussing the definition of a link in ROLL. It is clear >>>> that in a wireless n/w a link may exist between any two nodes in >>>> range. >>>> If that is >>>> what you mean, then it would help to make it clear. On the other >>>> hand, "link" could be defined as an active neighbor relationship >>>> between a pair of routers. Or something else. >>>> >>>> This becomes important as we try to understand how the >> protocol must >>>> scale, and what it is supposed to do. >>>> >>>> I presume that the concept of "parallel links" between neighbors is >>>> going to have no meaning at the moment. That is, you use only one >>>> frequency in any network. Maybe I presume wrong, in which case, you >>>> need to refine the definition of "network density" in section 3.1. >>>> >>>> --- >>>> >>>> Section 3.2 para 1 >>>> Final sentence is a bit mangled. >>>> >>>> --- >>>> >>>> Section 3.2 para 2 >>>> >>>> I can see why scaling with O(L) may be an issue, but it may >> depend on >>>> the definitions of links and routers. Also it may depend on what >>>> magnitude you expect for L. Perhaps you could give some >> ball-parks in >>>> the previous paragraph as you do for N and D. Without that, it is >>>> hard to justify the claim that scaling with O(L) is a problem. >>>> >>>> --- >>>> >>>> Section 3.3 >>>> >>>> Can you add SINR to your terminology? >>>> >>>> "...not trigger unnecessary responses..." >>>> I think that this is subjective and unhelpful. Can you rephrase to >>>> capture a quantifiable requirement? >>>> >>>> s/link changes to propagate across/link changes to be propagated >>>> across/ >>>> >>>> s/O(l)/O(L)/ >>>> >>>> --- >>>> >>>> Section 3.3 final para >>>> >>>> You have "transmissions", "broadcast", and "route updates". >>>> Can you use a >>>> consistent term? It may be less pretty English, but it would be a >>>> better way to avoid accusations of bias :-) >>>> >>>> Perhaps... >>>> More precisely, loss responses that require transmissions >> within the >>>> network of O(N) fail, while those that are limited to O(L) or O(D) >>>> pass. >>>> >>>> --- >>>> >>>> Section 3.4 para 1 >>>> >>>> "In terms of routing structure, any proposed L2N routing protocol >>>> ought to support the autonomous organization and >> configuration of the >>>> network at the lowest possible energy cost." >>>> >>>> Why "L2N"? I thought "Networks of low power wireless devices >>>> introduce novel IP routing issues." >>>> >>>> "ought" is not a recognized RFC 2119 word :-) >>>> >>>> I think "at the lowest possible energy cost" is a statement >> that this >>>> requirement trumps all others. Is that what you mean? >>>> >>>> I'm not convinced by the absolute statement you make here. >>>> Maybe, this is a >>>> question I should take to the requirements documents. Consider >>>> routing protocol A that is slightly more (say 5%) power-consuming >>>> than routing protocol B. But suppose protocol A gives rise >> to a data >>>> forwarding solution that is 50% more power-efficient? >>>> >>>> --- >>>> >>>> Section 3.4 para 2 >>>> >>>> "As low-power wireless networks can have very low data rates, >>>> protocols which require a minimum control packet rate can have >>>> unbounded control overhead." >>>> >>>> I know what you mean, but I had to parse several times. How about... >>>> >>>> The control overhead is the ratio of control data to >> payload data. A >>>> high control overhead indicates that precious network resources >>>> (bandwidth, power, or CPU) are being consumed by the control >>>> protocols instead of being used to transmit data. Where >> payload data >>>> rates are very low (as is often the case in low-power wireless >>>> networks) the control overhead can become unbounded for protocols >>>> that require some non-zero background control packet rate. >>>> >>>> --- >>>> >>>> Section 3.4 para 2 >>>> >>>> s/never meet the condition can be forced/never meet the condition >>>> could be forced/ >>>> >>>> --- >>>> >>>> Section 4 para 3 >>>> >>>> "multiple layer 2 hops away" >>>> Really? >>>> Again, I thought we were building an IP routing protocol. If your >>>> requirement is layer 2 routing, you need to make that >> visible up front. >>>> But, I can see why you are interested in L2 hops as well as L3 hops >>>> since they all consume power. >>>> >>>> This comes back to the question about whether all nodes are >> routers. >>>> Perhaps some repeaters are not routers? >>>> >>>> But can't we actually factor the L2 hops into the definition of the >>>> L3 hop? >>>> >>>> --- >>>> >>>> Section 4 para 3 >>>> >>>> "...nodes may only advertise..." >>>> This sounds prohibitive! >>>> >>>> --- >>>> >>>> Section 4 para 4 >>>> >>>> "Neighbor discovery is a critical component of any routing >> protocol." >>>> I think I disagree. >>>> It is clear that routing protocols need to know their neighbors. It >>>> is not clear that this requires that the discovery be part of the >>>> routing protocol. >>>> >>>> Later you have: >>>> "...key component of many protocols." >>>> This is less strong than the initial sentence. >>>> >>>> --- >>>> >>>> Section 4 >>>> >>>> "Protocols Today" >>>> >>>> Is this a section 4.1 headers? >>>> >>>> --- >>>> >>>> Section 4 "Protocols Today" para 2 >>>> >>>> I don't think the MPLS TE example is a good one. It is >> certainly not >>>> correct that the TED has to be fully distributed around the network. >>>> There are some very good examples of where "stub TE areas" do not >>>> need to know the TE information for the whole of the rest of the >>>> network. >>>> >>>> --- >>>> >>>> Section 4 Table >>>> >>>> I'm prepared to bet that a lot of people will be upset by >> the use of >>>> "fail" >>>> for their favorite protocols. It would seem that "?" is more >>>> appropriate in many cells. >>>> >>>> --- >>>> >>>> Section 5.1 >>>> Is it worth replacing "OSPF" with "OSPF or IS-IS"? >>>> >>>> --- >>>> >>>> Section 14. >>>> Your three ROLL requirements drafts are Normative >> References, I think. >>>> >>>> _______________________________________________ >>>> 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 >> >> > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Aug 27 09:58:54 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 C9C0D3A694C; Wed, 27 Aug 2008 09:58:54 -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 826193A682B for ; Wed, 27 Aug 2008 09:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.106 X-Spam-Level: X-Spam-Status: No, score=-5.106 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 t-XgNg03jzuF for ; Wed, 27 Aug 2008 09:58:51 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 9D3E83A694C for ; Wed, 27 Aug 2008 09:58:51 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7RGvf4N026210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Aug 2008 11:57:41 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7RGvfks016717; Wed, 27 Aug 2008 11:57:41 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7RGvM8h015966; Wed, 27 Aug 2008 11:57:41 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 09:57:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 09:57:35 -0700 Message-ID: <51661468CBD1354294533DA79E85955A0109FE32@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckF4uWWv+jCr8q7RKKuNS7geV3eIgA6l4jAAFZXU+0ACvR8MAAENIb7AACOAHA= References: <51661468CBD1354294533DA79E85955A0109FD7B@XCH-SW-5V2.sw.nos.boeing.com> From: "Drake, John E" To: "JP Vasseur" , "Adrian Farrel" , X-OriginalArrivalTime: 27 Aug 2008 16:57:37.0200 (UTC) FILETIME=[021E5B00:01C90866] Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 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 Comment inline >-----Original Message----- >From: JP Vasseur [mailto:jvasseur@cisco.com] >Sent: Wednesday, August 27, 2008 9:38 AM >To: Drake, John E; Adrian Farrel; roll@ietf.org >Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 > >Hi John, > > >On 8/27/08 4:45 PM, "Drake, John E" wrote: > >> JP, >> >> I thought that was exactly Adrian's point. > >Ok let's have him express his opinion. > >> >> If you evaluate a bunch of routing protocols as they exist >today in a >> new operational environment and conclude that none of them are >> appropriate, then you have no choice but to conclude that >you need to >> invent at least one, but probably many, new routing protocols. It's >> not like this hasn't been done before. >> >> I took Adrian's note to say that doing this is not >sufficient and that >> what needed to be done was to characterize the new operational >> environment, propose changes needed in each routing protocol to >> address the new operational environment, and then evaluate >these changes. >> > >John, I fully respect your opinion. Feel free to propose these >changes in light of the routing requirements expressed in the >related WG document. >Please make sure to fully understand them though, these >networks have fairly unique characteristics that do require >significant background. JD: I would think this is the responsibility of the authors who are requesting that their I-D be adopted by the working group. > >JP. > >> Thanks, >> >> John >> >>> -----Original Message----- >>> From: JP Vasseur [mailto:jvasseur@cisco.com] >>> Sent: Wednesday, August 27, 2008 2:24 AM >>> To: Drake, John E; Adrian Farrel; roll@ietf.org >>> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >>> >>> John, >>> >>> I do not think that this was Adrian's point. Your feed-back is more >>> than welcome but please argue a bit more ... >>> >>> Thanks. >>> >>> JP. >>> >>> >>> On 8/25/08 6:13 PM, "Drake, John E" > wrote: >>> >>>> Adrian, >>>> >>>> An excellent note - I agree completely. We need fewer routing >>>> protocols, not more. >>>> >>>> Thanks, >>>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>> Sent: Sunday, August 24, 2008 5:14 AM >>>>> To: roll@ietf.org >>>>> Subject: [Roll] draft-ietf-roll-protocols-survey-00 >>>>> >>>>> Hi, >>>>> >>>>> As one of the two tourists who raised a hand in Dublin to express >>>>> uneasiness about this I-D becoming a WG draft, I thought I should >>>>> write a note about my concerns. >>>>> >>>>> I should caveat this by saying that I do appreciate the >>> need for this >>>>> work, and that the author-team will, I'm sure, do a fine job at >>>>> delivering what the working group needs. My concerns were >much more >>>>> about getting the direction of the I-D right before >>> accepting it as I >>>>> think it is often harder to recast an I-D once it is within the >>>>> working group. >>>>> >>>>> Below, please find my major discussion point. I have also done a >>>>> review of the draft and found a bunch of issues/questions of more >>>>> minor importance. >>>>> >>>>> Regards, >>>>> Adrian >>>>> >>>>> === >>>>> >>>>> The analysis of the routing protocols is predicated on what >>> they are >>>>> currently used for. To some extent this is reasonable >>>>> - the easiest analysis of a routing protocol is in its >operational >>>>> environment. But to use this analysis as the basis of a >>> decision for >>>>> use of a protocol in a new environment is not so >reasonable. If you >>>>> want to show that none of today's protocols has been >>> designed for use >>>>> in the ROLL environment, then I don't suppose anyone will be >>>>> surprised. However, what we are really interested in is >whether any >>>>> of the existing protocols is suitable for adaptation for >>> use in ROLL, >>>>> whether the those adaptations would be contrived and >>> technically hard >>>>> (or flaky), and whether it would be more efficient to >design a new >>>>> protocol. >>>>> >>>>> For an example (and I'm not proposing this as the solution >>> for ROLL), >>>>> an IGP could easily be adapted to flood on only certain links, to >>>>> discard certain LSAs, and to build a FIB according to >>> specific rules. >>>>> This would not be a large change to the protocol, >although it would >>>>> obviously not be interoperable. >>>>> >>>>> To discard from consideration any protocol based on its >>> behavior in a >>>>> certain environment without setting it in the context of your >>>>> forwarding paradigm and without examining the potential >to adapt a >>>>> protocol to that environment is wrong. If all you wanted >to do was >>>>> show that no current variant of any existing routing protocol is >>>>> immediately applicable to ROLL, then that would be easy and >>> would not >>>>> be a surprise. But to imply that protocols are not open for >>>>> adaptation is more serious. >>>>> >>>>> This is not to say that inventing a new protocol would be >wrong or >>>>> not fun. >>>>> Only that your reasons for discarding protocols are >poorly founded. >>>>> You have focused on the operation of the routing >protocol, not the >>>>> purpose of the routing protocol. To give a better >understanding of >>>>> why you are discarding a protocol, you must show what you want to >>>>> achieve as your forwarding paradigm. The requirements >>> documents make >>>>> some start at this. >>>>> For example, draft-ietf-roll-urban-routing-reqs talks about: >>>>> - routing to minimise power usage >>>>> - routing to consider node and link capabilities >>>>> - routing protocol to scale within CPU, memory and power limits >>>>> - routing according to different metrics (latency is cited) >>>>> >>>>> Such considerations are a good start to understanding the >>> forwarding >>>>> paradigm in ROLL, but would not be good enough to use to >>> devise a new >>>>> routing protocol, so I don't see how they can be good enough to >>>>> determine whether an existing protocol should be discarded, >>> modified, >>>>> or used. >>>>> >>>>> ============= >>>>> >>>>> More specific comments on the draft follow. >>>>> >>>>> --- >>>>> >>>>> Do we have a commitment from the WG that any new protocol >developed >>>>> will be held to the same standards? That is, that the new >protocol >>>>> MUST achieve a "pass" in very column of the table in >>> section 4. Or is >>>>> there scope for pragmatism allowing trade-offs in the new >protocol >>>>> such that in some environments it achieves a pass in some >columns, >>>>> and in other environments it achieves a pass in other columns. >>>>> >>>>> Maybe you could add this as a statement in the Abstract and >>>>> Introduction >>>>> >>>>> --- >>>>> >>>>> Why do you include the requirements language boilerplate? I don't >>>>> think you use (or should use) such language in this document. >>>>> >>>>> --- >>>>> >>>>> Section 1 >>>>> >>>>> Can you strip out terms not used in the document? >>>>> >>>>> --- >>>>> >>>>> Section 2 >>>>> >>>>> You quote CPU power in MHz. Although that is the practical >>> electronic >>>>> limit, maybe MIPS would be a better measure. >>>>> >>>>> --- >>>>> >>>>> Section 3 para 2 >>>>> >>>>> "If a protocol cannot meet even these minimalist criteria..." >>>>> I think your use of "cannot" is correct in the context of the >>>>> sentence, but I think your I-D examines "does not" >>>>> >>>>> "...is unlikely to be good candidate..." >>>>> Too much prevarication! >>>>> >>>>> --- >>>>> >>>>> Section 3 para 3 >>>>> >>>>> "...the protocol does not appear to contain sufficient >>> flexibility..." >>>>> The problem with this is that it is very mushy! >>>>> It is OK to discard a protocol that is not flexible enough >>> to handle >>>>> your requirements. It is not OK to discard a protocol because you >>>>> don't appear to know how to extend it. >>>>> >>>>> A example comes in the somewhat contentious table in section 4 >>>>> :-) Here, for OSPF, you say that there is a "fail" for >>> conveying node >>>>> costs. >>>>> But there is already LSA available for carrying node >capabilities, >>>>> and there are opaque LSAs available for carrying additional >>>>> "unconventional" >>>>> information. >>>>> >>>>> All this sort of ties to my main point. Of course, the protocols >>>>> don't do exactly what you want already, but a more thorough >>> survey is >>>>> needed if you what to use this I-D as the reason for excluding >>>>> protocols. >>>>> >>>>> --- >>>>> >>>>> Section 3.2 para 1 >>>>> "...with size ranging from a minimum..." >>>>> I think you mean "...with maximum size ranging from a minimum..." >>>>> >>>>> "very large networks" >>>>> Can you de-fluff this? Some people might think that 250 >>> nodes is very >>>>> large >>>>> ;-) >>>>> >>>>> "network depths" >>>>> Would be worth including your definition here. >>>>> >>>>> -- >>>>> >>>>> Section 3.2 para 1 >>>>> >>>>> Is every network node a router? >>>>> draft-ietf-roll-urban-routing-reqs says "Sensor nodes are >>> capable of >>>>> forwarding data." If every node is a router and >participates in the >>>>> routing protocol, this creates a very different environment from >>>>> saying that most sensors are hosts, and some are routers. I >>>>> appreciate that "capable" does not imply "do". >>>>> >>>>> --- >>>>> >>>>> Associated with the previous point, I think you might spend >>> a little >>>>> more time discussing the definition of a link in ROLL. It >is clear >>>>> that in a wireless n/w a link may exist between any two nodes in >>>>> range. >>>>> If that is >>>>> what you mean, then it would help to make it clear. On the other >>>>> hand, "link" could be defined as an active neighbor relationship >>>>> between a pair of routers. Or something else. >>>>> >>>>> This becomes important as we try to understand how the >>> protocol must >>>>> scale, and what it is supposed to do. >>>>> >>>>> I presume that the concept of "parallel links" between >neighbors is >>>>> going to have no meaning at the moment. That is, you use only one >>>>> frequency in any network. Maybe I presume wrong, in which >case, you >>>>> need to refine the definition of "network density" in section 3.1. >>>>> >>>>> --- >>>>> >>>>> Section 3.2 para 1 >>>>> Final sentence is a bit mangled. >>>>> >>>>> --- >>>>> >>>>> Section 3.2 para 2 >>>>> >>>>> I can see why scaling with O(L) may be an issue, but it may >>> depend on >>>>> the definitions of links and routers. Also it may depend on what >>>>> magnitude you expect for L. Perhaps you could give some >>> ball-parks in >>>>> the previous paragraph as you do for N and D. Without that, it is >>>>> hard to justify the claim that scaling with O(L) is a problem. >>>>> >>>>> --- >>>>> >>>>> Section 3.3 >>>>> >>>>> Can you add SINR to your terminology? >>>>> >>>>> "...not trigger unnecessary responses..." >>>>> I think that this is subjective and unhelpful. Can you >rephrase to >>>>> capture a quantifiable requirement? >>>>> >>>>> s/link changes to propagate across/link changes to be propagated >>>>> across/ >>>>> >>>>> s/O(l)/O(L)/ >>>>> >>>>> --- >>>>> >>>>> Section 3.3 final para >>>>> >>>>> You have "transmissions", "broadcast", and "route updates". >>>>> Can you use a >>>>> consistent term? It may be less pretty English, but it would be a >>>>> better way to avoid accusations of bias :-) >>>>> >>>>> Perhaps... >>>>> More precisely, loss responses that require transmissions >>> within the >>>>> network of O(N) fail, while those that are limited to >O(L) or O(D) >>>>> pass. >>>>> >>>>> --- >>>>> >>>>> Section 3.4 para 1 >>>>> >>>>> "In terms of routing structure, any proposed L2N routing protocol >>>>> ought to support the autonomous organization and >>> configuration of the >>>>> network at the lowest possible energy cost." >>>>> >>>>> Why "L2N"? I thought "Networks of low power wireless devices >>>>> introduce novel IP routing issues." >>>>> >>>>> "ought" is not a recognized RFC 2119 word :-) >>>>> >>>>> I think "at the lowest possible energy cost" is a statement >>> that this >>>>> requirement trumps all others. Is that what you mean? >>>>> >>>>> I'm not convinced by the absolute statement you make here. >>>>> Maybe, this is a >>>>> question I should take to the requirements documents. Consider >>>>> routing protocol A that is slightly more (say 5%) power-consuming >>>>> than routing protocol B. But suppose protocol A gives rise >>> to a data >>>>> forwarding solution that is 50% more power-efficient? >>>>> >>>>> --- >>>>> >>>>> Section 3.4 para 2 >>>>> >>>>> "As low-power wireless networks can have very low data rates, >>>>> protocols which require a minimum control packet rate can have >>>>> unbounded control overhead." >>>>> >>>>> I know what you mean, but I had to parse several times. >How about... >>>>> >>>>> The control overhead is the ratio of control data to >>> payload data. A >>>>> high control overhead indicates that precious network resources >>>>> (bandwidth, power, or CPU) are being consumed by the control >>>>> protocols instead of being used to transmit data. Where >>> payload data >>>>> rates are very low (as is often the case in low-power wireless >>>>> networks) the control overhead can become unbounded for protocols >>>>> that require some non-zero background control packet rate. >>>>> >>>>> --- >>>>> >>>>> Section 3.4 para 2 >>>>> >>>>> s/never meet the condition can be forced/never meet the condition >>>>> could be forced/ >>>>> >>>>> --- >>>>> >>>>> Section 4 para 3 >>>>> >>>>> "multiple layer 2 hops away" >>>>> Really? >>>>> Again, I thought we were building an IP routing protocol. If your >>>>> requirement is layer 2 routing, you need to make that >>> visible up front. >>>>> But, I can see why you are interested in L2 hops as well >as L3 hops >>>>> since they all consume power. >>>>> >>>>> This comes back to the question about whether all nodes are >>> routers. >>>>> Perhaps some repeaters are not routers? >>>>> >>>>> But can't we actually factor the L2 hops into the >definition of the >>>>> L3 hop? >>>>> >>>>> --- >>>>> >>>>> Section 4 para 3 >>>>> >>>>> "...nodes may only advertise..." >>>>> This sounds prohibitive! >>>>> >>>>> --- >>>>> >>>>> Section 4 para 4 >>>>> >>>>> "Neighbor discovery is a critical component of any routing >>> protocol." >>>>> I think I disagree. >>>>> It is clear that routing protocols need to know their >neighbors. It >>>>> is not clear that this requires that the discovery be part of the >>>>> routing protocol. >>>>> >>>>> Later you have: >>>>> "...key component of many protocols." >>>>> This is less strong than the initial sentence. >>>>> >>>>> --- >>>>> >>>>> Section 4 >>>>> >>>>> "Protocols Today" >>>>> >>>>> Is this a section 4.1 headers? >>>>> >>>>> --- >>>>> >>>>> Section 4 "Protocols Today" para 2 >>>>> >>>>> I don't think the MPLS TE example is a good one. It is >>> certainly not >>>>> correct that the TED has to be fully distributed around >the network. >>>>> There are some very good examples of where "stub TE areas" do not >>>>> need to know the TE information for the whole of the rest of the >>>>> network. >>>>> >>>>> --- >>>>> >>>>> Section 4 Table >>>>> >>>>> I'm prepared to bet that a lot of people will be upset by >>> the use of >>>>> "fail" >>>>> for their favorite protocols. It would seem that "?" is more >>>>> appropriate in many cells. >>>>> >>>>> --- >>>>> >>>>> Section 5.1 >>>>> Is it worth replacing "OSPF" with "OSPF or IS-IS"? >>>>> >>>>> --- >>>>> >>>>> Section 14. >>>>> Your three ROLL requirements drafts are Normative >>> References, I think. >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Aug 27 10:05:51 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 D801B3A6AC3; Wed, 27 Aug 2008 10:05:51 -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 780C03A6AC3 for ; Wed, 27 Aug 2008 10:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.587 X-Spam-Level: X-Spam-Status: No, score=-4.587 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 lgFdmFWjRlny for ; Wed, 27 Aug 2008 10:05:45 -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 265CB3A6868 for ; Wed, 27 Aug 2008 10:05:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,279,1217808000"; d="scan'208";a="18885580" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Aug 2008 17:05:29 +0000 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 m7RH5TNX027362; Wed, 27 Aug 2008 13:05:29 -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 m7RH5T80027317; Wed, 27 Aug 2008 17:05: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); Wed, 27 Aug 2008 13:05:29 -0400 Received: from 10.55.206.229 ([10.55.206.229]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Aug 2008 17:05:29 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 27 Aug 2008 19:05:22 +0200 From: JP Vasseur To: "Drake, John E" , Adrian Farrel , Message-ID: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckF4uWWv+jCr8q7RKKuNS7geV3eIgA6l4jAAFZXU+0ACvR8MAAENIb7AACOAHAAAGaHlQ== In-Reply-To: <51661468CBD1354294533DA79E85955A0109FE32@XCH-SW-5V2.sw.nos.boeing.com> Mime-version: 1.0 X-OriginalArrivalTime: 27 Aug 2008 17:05:29.0324 (UTC) FILETIME=[1B86C2C0:01C90867] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17253; t=1219856729; x=1220720729; 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]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20 |To:=20=22Drake,=20John=20E=22=20 ,=0A=20=20=20=20=20=20=20=20Adrian=20Farrel=20,=20; bh=C9kckedFD8wWlT9HyoRr7WFSS7k3KVekFx+cbTZa2qI=; b=DM95Ik/q3ErC6Xj3Y9mkxSw+J2+1OuTEq+wCJZtoWz30RG3TtxY2/7Cnkw VryxsvqcGAZ1j6eg//UQPOK7IOa7Ri44HQBjAJX/kHfOPi8Hy+6z0ffdIXEy dRcBsSBFXa; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 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 John, On 8/27/08 6:57 PM, "Drake, John E" wrote: > Comment inline > >> -----Original Message----- >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: Wednesday, August 27, 2008 9:38 AM >> To: Drake, John E; Adrian Farrel; roll@ietf.org >> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >> >> Hi John, >> >> >> On 8/27/08 4:45 PM, "Drake, John E" wrote: >> >>> JP, >>> >>> I thought that was exactly Adrian's point. >> >> Ok let's have him express his opinion. >> >>> >>> If you evaluate a bunch of routing protocols as they exist >> today in a >>> new operational environment and conclude that none of them are >>> appropriate, then you have no choice but to conclude that >> you need to >>> invent at least one, but probably many, new routing protocols. It's >>> not like this hasn't been done before. >>> >>> I took Adrian's note to say that doing this is not >> sufficient and that >>> what needed to be done was to characterize the new operational >>> environment, propose changes needed in each routing protocol to >>> address the new operational environment, and then evaluate >> these changes. >>> >> >> John, I fully respect your opinion. Feel free to propose these >> changes in light of the routing requirements expressed in the >> related WG document. >> Please make sure to fully understand them though, these >> networks have fairly unique characteristics that do require >> significant background. > > JD: I would think this is the responsibility of the authors who are > requesting that their I-D be adopted by the working group. This is already a WG document and there was a consensus within the WG. JP. > >> >> JP. >> >>> Thanks, >>> >>> John >>> >>>> -----Original Message----- >>>> From: JP Vasseur [mailto:jvasseur@cisco.com] >>>> Sent: Wednesday, August 27, 2008 2:24 AM >>>> To: Drake, John E; Adrian Farrel; roll@ietf.org >>>> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >>>> >>>> John, >>>> >>>> I do not think that this was Adrian's point. Your feed-back is more >>>> than welcome but please argue a bit more ... >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> >>>> On 8/25/08 6:13 PM, "Drake, John E" >> wrote: >>>> >>>>> Adrian, >>>>> >>>>> An excellent note - I agree completely. We need fewer routing >>>>> protocols, not more. >>>>> >>>>> Thanks, >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>>> Sent: Sunday, August 24, 2008 5:14 AM >>>>>> To: roll@ietf.org >>>>>> Subject: [Roll] draft-ietf-roll-protocols-survey-00 >>>>>> >>>>>> Hi, >>>>>> >>>>>> As one of the two tourists who raised a hand in Dublin to express >>>>>> uneasiness about this I-D becoming a WG draft, I thought I should >>>>>> write a note about my concerns. >>>>>> >>>>>> I should caveat this by saying that I do appreciate the >>>> need for this >>>>>> work, and that the author-team will, I'm sure, do a fine job at >>>>>> delivering what the working group needs. My concerns were >> much more >>>>>> about getting the direction of the I-D right before >>>> accepting it as I >>>>>> think it is often harder to recast an I-D once it is within the >>>>>> working group. >>>>>> >>>>>> Below, please find my major discussion point. I have also done a >>>>>> review of the draft and found a bunch of issues/questions of more >>>>>> minor importance. >>>>>> >>>>>> Regards, >>>>>> Adrian >>>>>> >>>>>> === >>>>>> >>>>>> The analysis of the routing protocols is predicated on what >>>> they are >>>>>> currently used for. To some extent this is reasonable >>>>>> - the easiest analysis of a routing protocol is in its >> operational >>>>>> environment. But to use this analysis as the basis of a >>>> decision for >>>>>> use of a protocol in a new environment is not so >> reasonable. If you >>>>>> want to show that none of today's protocols has been >>>> designed for use >>>>>> in the ROLL environment, then I don't suppose anyone will be >>>>>> surprised. However, what we are really interested in is >> whether any >>>>>> of the existing protocols is suitable for adaptation for >>>> use in ROLL, >>>>>> whether the those adaptations would be contrived and >>>> technically hard >>>>>> (or flaky), and whether it would be more efficient to >> design a new >>>>>> protocol. >>>>>> >>>>>> For an example (and I'm not proposing this as the solution >>>> for ROLL), >>>>>> an IGP could easily be adapted to flood on only certain links, to >>>>>> discard certain LSAs, and to build a FIB according to >>>> specific rules. >>>>>> This would not be a large change to the protocol, >> although it would >>>>>> obviously not be interoperable. >>>>>> >>>>>> To discard from consideration any protocol based on its >>>> behavior in a >>>>>> certain environment without setting it in the context of your >>>>>> forwarding paradigm and without examining the potential >> to adapt a >>>>>> protocol to that environment is wrong. If all you wanted >> to do was >>>>>> show that no current variant of any existing routing protocol is >>>>>> immediately applicable to ROLL, then that would be easy and >>>> would not >>>>>> be a surprise. But to imply that protocols are not open for >>>>>> adaptation is more serious. >>>>>> >>>>>> This is not to say that inventing a new protocol would be >> wrong or >>>>>> not fun. >>>>>> Only that your reasons for discarding protocols are >> poorly founded. >>>>>> You have focused on the operation of the routing >> protocol, not the >>>>>> purpose of the routing protocol. To give a better >> understanding of >>>>>> why you are discarding a protocol, you must show what you want to >>>>>> achieve as your forwarding paradigm. The requirements >>>> documents make >>>>>> some start at this. >>>>>> For example, draft-ietf-roll-urban-routing-reqs talks about: >>>>>> - routing to minimise power usage >>>>>> - routing to consider node and link capabilities >>>>>> - routing protocol to scale within CPU, memory and power limits >>>>>> - routing according to different metrics (latency is cited) >>>>>> >>>>>> Such considerations are a good start to understanding the >>>> forwarding >>>>>> paradigm in ROLL, but would not be good enough to use to >>>> devise a new >>>>>> routing protocol, so I don't see how they can be good enough to >>>>>> determine whether an existing protocol should be discarded, >>>> modified, >>>>>> or used. >>>>>> >>>>>> ============= >>>>>> >>>>>> More specific comments on the draft follow. >>>>>> >>>>>> --- >>>>>> >>>>>> Do we have a commitment from the WG that any new protocol >> developed >>>>>> will be held to the same standards? That is, that the new >> protocol >>>>>> MUST achieve a "pass" in very column of the table in >>>> section 4. Or is >>>>>> there scope for pragmatism allowing trade-offs in the new >> protocol >>>>>> such that in some environments it achieves a pass in some >> columns, >>>>>> and in other environments it achieves a pass in other columns. >>>>>> >>>>>> Maybe you could add this as a statement in the Abstract and >>>>>> Introduction >>>>>> >>>>>> --- >>>>>> >>>>>> Why do you include the requirements language boilerplate? I don't >>>>>> think you use (or should use) such language in this document. >>>>>> >>>>>> --- >>>>>> >>>>>> Section 1 >>>>>> >>>>>> Can you strip out terms not used in the document? >>>>>> >>>>>> --- >>>>>> >>>>>> Section 2 >>>>>> >>>>>> You quote CPU power in MHz. Although that is the practical >>>> electronic >>>>>> limit, maybe MIPS would be a better measure. >>>>>> >>>>>> --- >>>>>> >>>>>> Section 3 para 2 >>>>>> >>>>>> "If a protocol cannot meet even these minimalist criteria..." >>>>>> I think your use of "cannot" is correct in the context of the >>>>>> sentence, but I think your I-D examines "does not" >>>>>> >>>>>> "...is unlikely to be good candidate..." >>>>>> Too much prevarication! >>>>>> >>>>>> --- >>>>>> >>>>>> Section 3 para 3 >>>>>> >>>>>> "...the protocol does not appear to contain sufficient >>>> flexibility..." >>>>>> The problem with this is that it is very mushy! >>>>>> It is OK to discard a protocol that is not flexible enough >>>> to handle >>>>>> your requirements. It is not OK to discard a protocol because you >>>>>> don't appear to know how to extend it. >>>>>> >>>>>> A example comes in the somewhat contentious table in section 4 >>>>>> :-) Here, for OSPF, you say that there is a "fail" for >>>> conveying node >>>>>> costs. >>>>>> But there is already LSA available for carrying node >> capabilities, >>>>>> and there are opaque LSAs available for carrying additional >>>>>> "unconventional" >>>>>> information. >>>>>> >>>>>> All this sort of ties to my main point. Of course, the protocols >>>>>> don't do exactly what you want already, but a more thorough >>>> survey is >>>>>> needed if you what to use this I-D as the reason for excluding >>>>>> protocols. >>>>>> >>>>>> --- >>>>>> >>>>>> Section 3.2 para 1 >>>>>> "...with size ranging from a minimum..." >>>>>> I think you mean "...with maximum size ranging from a minimum..." >>>>>> >>>>>> "very large networks" >>>>>> Can you de-fluff this? Some people might think that 250 >>>> nodes is very >>>>>> large >>>>>> ;-) >>>>>> >>>>>> "network depths" >>>>>> Would be worth including your definition here. >>>>>> >>>>>> -- >>>>>> >>>>>> Section 3.2 para 1 >>>>>> >>>>>> Is every network node a router? >>>>>> draft-ietf-roll-urban-routing-reqs says "Sensor nodes are >>>> capable of >>>>>> forwarding data." If every node is a router and >> participates in the >>>>>> routing protocol, this creates a very different environment from >>>>>> saying that most sensors are hosts, and some are routers. I >>>>>> appreciate that "capable" does not imply "do". >>>>>> >>>>>> --- >>>>>> >>>>>> Associated with the previous point, I think you might spend >>>> a little >>>>>> more time discussing the definition of a link in ROLL. It >> is clear >>>>>> that in a wireless n/w a link may exist between any two nodes in >>>>>> range. >>>>>> If that is >>>>>> what you mean, then it would help to make it clear. On the other >>>>>> hand, "link" could be defined as an active neighbor relationship >>>>>> between a pair of routers. Or something else. >>>>>> >>>>>> This becomes important as we try to understand how the >>>> protocol must >>>>>> scale, and what it is supposed to do. >>>>>> >>>>>> I presume that the concept of "parallel links" between >> neighbors is >>>>>> going to have no meaning at the moment. That is, you use only one >>>>>> frequency in any network. Maybe I presume wrong, in which >> case, you >>>>>> need to refine the definition of "network density" in section 3.1. >>>>>> >>>>>> --- >>>>>> >>>>>> Section 3.2 para 1 >>>>>> Final sentence is a bit mangled. >>>>>> >>>>>> --- >>>>>> >>>>>> Section 3.2 para 2 >>>>>> >>>>>> I can see why scaling with O(L) may be an issue, but it may >>>> depend on >>>>>> the definitions of links and routers. Also it may depend on what >>>>>> magnitude you expect for L. Perhaps you could give some >>>> ball-parks in >>>>>> the previous paragraph as you do for N and D. Without that, it is >>>>>> hard to justify the claim that scaling with O(L) is a problem. >>>>>> >>>>>> --- >>>>>> >>>>>> Section 3.3 >>>>>> >>>>>> Can you add SINR to your terminology? >>>>>> >>>>>> "...not trigger unnecessary responses..." >>>>>> I think that this is subjective and unhelpful. Can you >> rephrase to >>>>>> capture a quantifiable requirement? >>>>>> >>>>>> s/link changes to propagate across/link changes to be propagated >>>>>> across/ >>>>>> >>>>>> s/O(l)/O(L)/ >>>>>> >>>>>> --- >>>>>> >>>>>> Section 3.3 final para >>>>>> >>>>>> You have "transmissions", "broadcast", and "route updates". >>>>>> Can you use a >>>>>> consistent term? It may be less pretty English, but it would be a >>>>>> better way to avoid accusations of bias :-) >>>>>> >>>>>> Perhaps... >>>>>> More precisely, loss responses that require transmissions >>>> within the >>>>>> network of O(N) fail, while those that are limited to >> O(L) or O(D) >>>>>> pass. >>>>>> >>>>>> --- >>>>>> >>>>>> Section 3.4 para 1 >>>>>> >>>>>> "In terms of routing structure, any proposed L2N routing protocol >>>>>> ought to support the autonomous organization and >>>> configuration of the >>>>>> network at the lowest possible energy cost." >>>>>> >>>>>> Why "L2N"? I thought "Networks of low power wireless devices >>>>>> introduce novel IP routing issues." >>>>>> >>>>>> "ought" is not a recognized RFC 2119 word :-) >>>>>> >>>>>> I think "at the lowest possible energy cost" is a statement >>>> that this >>>>>> requirement trumps all others. Is that what you mean? >>>>>> >>>>>> I'm not convinced by the absolute statement you make here. >>>>>> Maybe, this is a >>>>>> question I should take to the requirements documents. Consider >>>>>> routing protocol A that is slightly more (say 5%) power-consuming >>>>>> than routing protocol B. But suppose protocol A gives rise >>>> to a data >>>>>> forwarding solution that is 50% more power-efficient? >>>>>> >>>>>> --- >>>>>> >>>>>> Section 3.4 para 2 >>>>>> >>>>>> "As low-power wireless networks can have very low data rates, >>>>>> protocols which require a minimum control packet rate can have >>>>>> unbounded control overhead." >>>>>> >>>>>> I know what you mean, but I had to parse several times. >> How about... >>>>>> >>>>>> The control overhead is the ratio of control data to >>>> payload data. A >>>>>> high control overhead indicates that precious network resources >>>>>> (bandwidth, power, or CPU) are being consumed by the control >>>>>> protocols instead of being used to transmit data. Where >>>> payload data >>>>>> rates are very low (as is often the case in low-power wireless >>>>>> networks) the control overhead can become unbounded for protocols >>>>>> that require some non-zero background control packet rate. >>>>>> >>>>>> --- >>>>>> >>>>>> Section 3.4 para 2 >>>>>> >>>>>> s/never meet the condition can be forced/never meet the condition >>>>>> could be forced/ >>>>>> >>>>>> --- >>>>>> >>>>>> Section 4 para 3 >>>>>> >>>>>> "multiple layer 2 hops away" >>>>>> Really? >>>>>> Again, I thought we were building an IP routing protocol. If your >>>>>> requirement is layer 2 routing, you need to make that >>>> visible up front. >>>>>> But, I can see why you are interested in L2 hops as well >> as L3 hops >>>>>> since they all consume power. >>>>>> >>>>>> This comes back to the question about whether all nodes are >>>> routers. >>>>>> Perhaps some repeaters are not routers? >>>>>> >>>>>> But can't we actually factor the L2 hops into the >> definition of the >>>>>> L3 hop? >>>>>> >>>>>> --- >>>>>> >>>>>> Section 4 para 3 >>>>>> >>>>>> "...nodes may only advertise..." >>>>>> This sounds prohibitive! >>>>>> >>>>>> --- >>>>>> >>>>>> Section 4 para 4 >>>>>> >>>>>> "Neighbor discovery is a critical component of any routing >>>> protocol." >>>>>> I think I disagree. >>>>>> It is clear that routing protocols need to know their >> neighbors. It >>>>>> is not clear that this requires that the discovery be part of the >>>>>> routing protocol. >>>>>> >>>>>> Later you have: >>>>>> "...key component of many protocols." >>>>>> This is less strong than the initial sentence. >>>>>> >>>>>> --- >>>>>> >>>>>> Section 4 >>>>>> >>>>>> "Protocols Today" >>>>>> >>>>>> Is this a section 4.1 headers? >>>>>> >>>>>> --- >>>>>> >>>>>> Section 4 "Protocols Today" para 2 >>>>>> >>>>>> I don't think the MPLS TE example is a good one. It is >>>> certainly not >>>>>> correct that the TED has to be fully distributed around >> the network. >>>>>> There are some very good examples of where "stub TE areas" do not >>>>>> need to know the TE information for the whole of the rest of the >>>>>> network. >>>>>> >>>>>> --- >>>>>> >>>>>> Section 4 Table >>>>>> >>>>>> I'm prepared to bet that a lot of people will be upset by >>>> the use of >>>>>> "fail" >>>>>> for their favorite protocols. It would seem that "?" is more >>>>>> appropriate in many cells. >>>>>> >>>>>> --- >>>>>> >>>>>> Section 5.1 >>>>>> Is it worth replacing "OSPF" with "OSPF or IS-IS"? >>>>>> >>>>>> --- >>>>>> >>>>>> Section 14. >>>>>> Your three ROLL requirements drafts are Normative >>>> References, I think. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >> >> _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Aug 27 10:48: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 D61A13A6C36; Wed, 27 Aug 2008 10:48: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 E4DAD3A6974 for ; Wed, 27 Aug 2008 10:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.052 X-Spam-Level: X-Spam-Status: No, score=-5.052 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 vwcFJb44FKc1 for ; Wed, 27 Aug 2008 10:48:15 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 7424D3A6C36 for ; Wed, 27 Aug 2008 10:48:15 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7RHlcxh019479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Aug 2008 10:47:39 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7RHlcL4009899; Wed, 27 Aug 2008 12:47:38 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7RHlaoh009798; Wed, 27 Aug 2008 12:47:38 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 10:47:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 10:47:35 -0700 Message-ID: <51661468CBD1354294533DA79E85955A0109FE71@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckF4uWWv+jCr8q7RKKuNS7geV3eIgA6l4jAAFZXU+0ACvR8MAAENIb7AACOAHAAAGaHlQABSNJw References: <51661468CBD1354294533DA79E85955A0109FE32@XCH-SW-5V2.sw.nos.boeing.com> From: "Drake, John E" To: "JP Vasseur" , "Adrian Farrel" , X-OriginalArrivalTime: 27 Aug 2008 17:47:37.0535 (UTC) FILETIME=[FE7524F0:01C9086C] Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 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 JP, Oopsie, my mistake. However, I think my comment still stands, particularly if the working group plans to use this I-D for deciding whether to invent at least one, but probably many, new routing protocols. Thanks, John >-----Original Message----- >From: JP Vasseur [mailto:jvasseur@cisco.com] >Sent: Wednesday, August 27, 2008 10:05 AM >To: Drake, John E; Adrian Farrel; roll@ietf.org >Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 > >John, > > >On 8/27/08 6:57 PM, "Drake, John E" wrote: > >> Comment inline >> >>> -----Original Message----- >>> From: JP Vasseur [mailto:jvasseur@cisco.com] >>> Sent: Wednesday, August 27, 2008 9:38 AM >>> To: Drake, John E; Adrian Farrel; roll@ietf.org >>> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >>> >>> Hi John, >>> >>> >>> On 8/27/08 4:45 PM, "Drake, John E" > wrote: >>> >>>> JP, >>>> >>>> I thought that was exactly Adrian's point. >>> >>> Ok let's have him express his opinion. >>> >>>> >>>> If you evaluate a bunch of routing protocols as they exist >>> today in a >>>> new operational environment and conclude that none of them are >>>> appropriate, then you have no choice but to conclude that >>> you need to >>>> invent at least one, but probably many, new routing >protocols. It's >>>> not like this hasn't been done before. >>>> >>>> I took Adrian's note to say that doing this is not >>> sufficient and that >>>> what needed to be done was to characterize the new operational >>>> environment, propose changes needed in each routing protocol to >>>> address the new operational environment, and then evaluate >>> these changes. >>>> >>> >>> John, I fully respect your opinion. Feel free to propose these >>> changes in light of the routing requirements expressed in >the related >>> WG document. >>> Please make sure to fully understand them though, these >networks have >>> fairly unique characteristics that do require significant >background. >> >> JD: I would think this is the responsibility of the authors who are >> requesting that their I-D be adopted by the working group. > >This is already a WG document and there was a consensus within the WG. > >JP. > >> >>> >>> JP. >>> >>>> Thanks, >>>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: JP Vasseur [mailto:jvasseur@cisco.com] >>>>> Sent: Wednesday, August 27, 2008 2:24 AM >>>>> To: Drake, John E; Adrian Farrel; roll@ietf.org >>>>> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >>>>> >>>>> John, >>>>> >>>>> I do not think that this was Adrian's point. Your >feed-back is more >>>>> than welcome but please argue a bit more ... >>>>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>> >>>>> On 8/25/08 6:13 PM, "Drake, John E" >>> wrote: >>>>> >>>>>> Adrian, >>>>>> >>>>>> An excellent note - I agree completely. We need fewer routing >>>>>> protocols, not more. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>>>> Sent: Sunday, August 24, 2008 5:14 AM >>>>>>> To: roll@ietf.org >>>>>>> Subject: [Roll] draft-ietf-roll-protocols-survey-00 >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> As one of the two tourists who raised a hand in Dublin >to express >>>>>>> uneasiness about this I-D becoming a WG draft, I >thought I should >>>>>>> write a note about my concerns. >>>>>>> >>>>>>> I should caveat this by saying that I do appreciate the >>>>> need for this >>>>>>> work, and that the author-team will, I'm sure, do a fine job at >>>>>>> delivering what the working group needs. My concerns were >>> much more >>>>>>> about getting the direction of the I-D right before >>>>> accepting it as I >>>>>>> think it is often harder to recast an I-D once it is within the >>>>>>> working group. >>>>>>> >>>>>>> Below, please find my major discussion point. I have >also done a >>>>>>> review of the draft and found a bunch of >issues/questions of more >>>>>>> minor importance. >>>>>>> >>>>>>> Regards, >>>>>>> Adrian >>>>>>> >>>>>>> === >>>>>>> >>>>>>> The analysis of the routing protocols is predicated on what >>>>> they are >>>>>>> currently used for. To some extent this is reasonable >>>>>>> - the easiest analysis of a routing protocol is in its >>> operational >>>>>>> environment. But to use this analysis as the basis of a >>>>> decision for >>>>>>> use of a protocol in a new environment is not so >>> reasonable. If you >>>>>>> want to show that none of today's protocols has been >>>>> designed for use >>>>>>> in the ROLL environment, then I don't suppose anyone will be >>>>>>> surprised. However, what we are really interested in is >>> whether any >>>>>>> of the existing protocols is suitable for adaptation for >>>>> use in ROLL, >>>>>>> whether the those adaptations would be contrived and >>>>> technically hard >>>>>>> (or flaky), and whether it would be more efficient to >>> design a new >>>>>>> protocol. >>>>>>> >>>>>>> For an example (and I'm not proposing this as the solution >>>>> for ROLL), >>>>>>> an IGP could easily be adapted to flood on only certain >links, to >>>>>>> discard certain LSAs, and to build a FIB according to >>>>> specific rules. >>>>>>> This would not be a large change to the protocol, >>> although it would >>>>>>> obviously not be interoperable. >>>>>>> >>>>>>> To discard from consideration any protocol based on its >>>>> behavior in a >>>>>>> certain environment without setting it in the context of your >>>>>>> forwarding paradigm and without examining the potential >>> to adapt a >>>>>>> protocol to that environment is wrong. If all you wanted >>> to do was >>>>>>> show that no current variant of any existing routing >protocol is >>>>>>> immediately applicable to ROLL, then that would be easy and >>>>> would not >>>>>>> be a surprise. But to imply that protocols are not open for >>>>>>> adaptation is more serious. >>>>>>> >>>>>>> This is not to say that inventing a new protocol would be >>> wrong or >>>>>>> not fun. >>>>>>> Only that your reasons for discarding protocols are >>> poorly founded. >>>>>>> You have focused on the operation of the routing >>> protocol, not the >>>>>>> purpose of the routing protocol. To give a better >>> understanding of >>>>>>> why you are discarding a protocol, you must show what >you want to >>>>>>> achieve as your forwarding paradigm. The requirements >>>>> documents make >>>>>>> some start at this. >>>>>>> For example, draft-ietf-roll-urban-routing-reqs talks about: >>>>>>> - routing to minimise power usage >>>>>>> - routing to consider node and link capabilities >>>>>>> - routing protocol to scale within CPU, memory and power limits >>>>>>> - routing according to different metrics (latency is cited) >>>>>>> >>>>>>> Such considerations are a good start to understanding the >>>>> forwarding >>>>>>> paradigm in ROLL, but would not be good enough to use to >>>>> devise a new >>>>>>> routing protocol, so I don't see how they can be good enough to >>>>>>> determine whether an existing protocol should be discarded, >>>>> modified, >>>>>>> or used. >>>>>>> >>>>>>> ============= >>>>>>> >>>>>>> More specific comments on the draft follow. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Do we have a commitment from the WG that any new protocol >>> developed >>>>>>> will be held to the same standards? That is, that the new >>> protocol >>>>>>> MUST achieve a "pass" in very column of the table in >>>>> section 4. Or is >>>>>>> there scope for pragmatism allowing trade-offs in the new >>> protocol >>>>>>> such that in some environments it achieves a pass in some >>> columns, >>>>>>> and in other environments it achieves a pass in other columns. >>>>>>> >>>>>>> Maybe you could add this as a statement in the Abstract and >>>>>>> Introduction >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Why do you include the requirements language >boilerplate? I don't >>>>>>> think you use (or should use) such language in this document. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 1 >>>>>>> >>>>>>> Can you strip out terms not used in the document? >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 2 >>>>>>> >>>>>>> You quote CPU power in MHz. Although that is the practical >>>>> electronic >>>>>>> limit, maybe MIPS would be a better measure. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 3 para 2 >>>>>>> >>>>>>> "If a protocol cannot meet even these minimalist criteria..." >>>>>>> I think your use of "cannot" is correct in the context of the >>>>>>> sentence, but I think your I-D examines "does not" >>>>>>> >>>>>>> "...is unlikely to be good candidate..." >>>>>>> Too much prevarication! >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 3 para 3 >>>>>>> >>>>>>> "...the protocol does not appear to contain sufficient >>>>> flexibility..." >>>>>>> The problem with this is that it is very mushy! >>>>>>> It is OK to discard a protocol that is not flexible enough >>>>> to handle >>>>>>> your requirements. It is not OK to discard a protocol >because you >>>>>>> don't appear to know how to extend it. >>>>>>> >>>>>>> A example comes in the somewhat contentious table in section 4 >>>>>>> :-) Here, for OSPF, you say that there is a "fail" for >>>>> conveying node >>>>>>> costs. >>>>>>> But there is already LSA available for carrying node >>> capabilities, >>>>>>> and there are opaque LSAs available for carrying additional >>>>>>> "unconventional" >>>>>>> information. >>>>>>> >>>>>>> All this sort of ties to my main point. Of course, the >protocols >>>>>>> don't do exactly what you want already, but a more thorough >>>>> survey is >>>>>>> needed if you what to use this I-D as the reason for excluding >>>>>>> protocols. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 3.2 para 1 >>>>>>> "...with size ranging from a minimum..." >>>>>>> I think you mean "...with maximum size ranging from a >minimum..." >>>>>>> >>>>>>> "very large networks" >>>>>>> Can you de-fluff this? Some people might think that 250 >>>>> nodes is very >>>>>>> large >>>>>>> ;-) >>>>>>> >>>>>>> "network depths" >>>>>>> Would be worth including your definition here. >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Section 3.2 para 1 >>>>>>> >>>>>>> Is every network node a router? >>>>>>> draft-ietf-roll-urban-routing-reqs says "Sensor nodes are >>>>> capable of >>>>>>> forwarding data." If every node is a router and >>> participates in the >>>>>>> routing protocol, this creates a very different >environment from >>>>>>> saying that most sensors are hosts, and some are routers. I >>>>>>> appreciate that "capable" does not imply "do". >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Associated with the previous point, I think you might spend >>>>> a little >>>>>>> more time discussing the definition of a link in ROLL. It >>> is clear >>>>>>> that in a wireless n/w a link may exist between any two >nodes in >>>>>>> range. >>>>>>> If that is >>>>>>> what you mean, then it would help to make it clear. On >the other >>>>>>> hand, "link" could be defined as an active neighbor >relationship >>>>>>> between a pair of routers. Or something else. >>>>>>> >>>>>>> This becomes important as we try to understand how the >>>>> protocol must >>>>>>> scale, and what it is supposed to do. >>>>>>> >>>>>>> I presume that the concept of "parallel links" between >>> neighbors is >>>>>>> going to have no meaning at the moment. That is, you >use only one >>>>>>> frequency in any network. Maybe I presume wrong, in which >>> case, you >>>>>>> need to refine the definition of "network density" in >section 3.1. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 3.2 para 1 >>>>>>> Final sentence is a bit mangled. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 3.2 para 2 >>>>>>> >>>>>>> I can see why scaling with O(L) may be an issue, but it may >>>>> depend on >>>>>>> the definitions of links and routers. Also it may >depend on what >>>>>>> magnitude you expect for L. Perhaps you could give some >>>>> ball-parks in >>>>>>> the previous paragraph as you do for N and D. Without >that, it is >>>>>>> hard to justify the claim that scaling with O(L) is a problem. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 3.3 >>>>>>> >>>>>>> Can you add SINR to your terminology? >>>>>>> >>>>>>> "...not trigger unnecessary responses..." >>>>>>> I think that this is subjective and unhelpful. Can you >>> rephrase to >>>>>>> capture a quantifiable requirement? >>>>>>> >>>>>>> s/link changes to propagate across/link changes to be >propagated >>>>>>> across/ >>>>>>> >>>>>>> s/O(l)/O(L)/ >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 3.3 final para >>>>>>> >>>>>>> You have "transmissions", "broadcast", and "route updates". >>>>>>> Can you use a >>>>>>> consistent term? It may be less pretty English, but it >would be a >>>>>>> better way to avoid accusations of bias :-) >>>>>>> >>>>>>> Perhaps... >>>>>>> More precisely, loss responses that require transmissions >>>>> within the >>>>>>> network of O(N) fail, while those that are limited to >>> O(L) or O(D) >>>>>>> pass. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 3.4 para 1 >>>>>>> >>>>>>> "In terms of routing structure, any proposed L2N >routing protocol >>>>>>> ought to support the autonomous organization and >>>>> configuration of the >>>>>>> network at the lowest possible energy cost." >>>>>>> >>>>>>> Why "L2N"? I thought "Networks of low power wireless devices >>>>>>> introduce novel IP routing issues." >>>>>>> >>>>>>> "ought" is not a recognized RFC 2119 word :-) >>>>>>> >>>>>>> I think "at the lowest possible energy cost" is a statement >>>>> that this >>>>>>> requirement trumps all others. Is that what you mean? >>>>>>> >>>>>>> I'm not convinced by the absolute statement you make here. >>>>>>> Maybe, this is a >>>>>>> question I should take to the requirements documents. Consider >>>>>>> routing protocol A that is slightly more (say 5%) >power-consuming >>>>>>> than routing protocol B. But suppose protocol A gives rise >>>>> to a data >>>>>>> forwarding solution that is 50% more power-efficient? >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 3.4 para 2 >>>>>>> >>>>>>> "As low-power wireless networks can have very low data rates, >>>>>>> protocols which require a minimum control packet rate can have >>>>>>> unbounded control overhead." >>>>>>> >>>>>>> I know what you mean, but I had to parse several times. >>> How about... >>>>>>> >>>>>>> The control overhead is the ratio of control data to >>>>> payload data. A >>>>>>> high control overhead indicates that precious network resources >>>>>>> (bandwidth, power, or CPU) are being consumed by the control >>>>>>> protocols instead of being used to transmit data. Where >>>>> payload data >>>>>>> rates are very low (as is often the case in low-power wireless >>>>>>> networks) the control overhead can become unbounded for >protocols >>>>>>> that require some non-zero background control packet rate. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 3.4 para 2 >>>>>>> >>>>>>> s/never meet the condition can be forced/never meet the >condition >>>>>>> could be forced/ >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 4 para 3 >>>>>>> >>>>>>> "multiple layer 2 hops away" >>>>>>> Really? >>>>>>> Again, I thought we were building an IP routing >protocol. If your >>>>>>> requirement is layer 2 routing, you need to make that >>>>> visible up front. >>>>>>> But, I can see why you are interested in L2 hops as well >>> as L3 hops >>>>>>> since they all consume power. >>>>>>> >>>>>>> This comes back to the question about whether all nodes are >>>>> routers. >>>>>>> Perhaps some repeaters are not routers? >>>>>>> >>>>>>> But can't we actually factor the L2 hops into the >>> definition of the >>>>>>> L3 hop? >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 4 para 3 >>>>>>> >>>>>>> "...nodes may only advertise..." >>>>>>> This sounds prohibitive! >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 4 para 4 >>>>>>> >>>>>>> "Neighbor discovery is a critical component of any routing >>>>> protocol." >>>>>>> I think I disagree. >>>>>>> It is clear that routing protocols need to know their >>> neighbors. It >>>>>>> is not clear that this requires that the discovery be >part of the >>>>>>> routing protocol. >>>>>>> >>>>>>> Later you have: >>>>>>> "...key component of many protocols." >>>>>>> This is less strong than the initial sentence. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 4 >>>>>>> >>>>>>> "Protocols Today" >>>>>>> >>>>>>> Is this a section 4.1 headers? >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 4 "Protocols Today" para 2 >>>>>>> >>>>>>> I don't think the MPLS TE example is a good one. It is >>>>> certainly not >>>>>>> correct that the TED has to be fully distributed around >>> the network. >>>>>>> There are some very good examples of where "stub TE >areas" do not >>>>>>> need to know the TE information for the whole of the >rest of the >>>>>>> network. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 4 Table >>>>>>> >>>>>>> I'm prepared to bet that a lot of people will be upset by >>>>> the use of >>>>>>> "fail" >>>>>>> for their favorite protocols. It would seem that "?" is more >>>>>>> appropriate in many cells. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 5.1 >>>>>>> Is it worth replacing "OSPF" with "OSPF or IS-IS"? >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 14. >>>>>>> Your three ROLL requirements drafts are Normative >>>>> References, I think. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>> >>> > >_______________________________________________ >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 Wed Aug 27 11:03:46 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 17C6D3A6C2C; Wed, 27 Aug 2008 11:03:46 -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 322813A69C3 for ; Wed, 27 Aug 2008 11:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 ncj-TRk-9H83 for ; Wed, 27 Aug 2008 11:03:39 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 4F0543A6AC9 for ; Wed, 27 Aug 2008 11:03:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,279,1217800800"; d="scan'208";a="14319791" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Aug 2008 20:03:08 +0200 Message-ID: <48B596DB.5020808@inria.fr> Date: Wed, 27 Aug 2008 20:03:07 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 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 >>>> I took Adrian's note to say that doing this is not >>> sufficient and that >>>> what needed to be done was to characterize the new operational >>>> environment, propose changes needed in each routing protocol to >>>> address the new operational environment, and then evaluate >>> these changes. >>> John, I fully respect your opinion. Feel free to propose these >>> changes in light of the routing requirements expressed in the >>> related WG document. >>> Please make sure to fully understand them though, these >>> networks have fairly unique characteristics that do require >>> significant background. >> JD: I would think this is the responsibility of the authors who are >> requesting that their I-D be adopted by the working group. > > This is already a WG document and there was a consensus within the WG. > > JP. > The point here is that such a document is extremely difficult to write, especially if it is not balanced with the framework that was mentionned earlier in the discussion (about "existing protocol extensions" vs "from scratch design"). I think that such a balance is missing in the document, and there is a high risk that conclusions may thus be misleading. For example, there is this infamous "fail/pass" table at the end of section 4, which is too quickly justified in Section 13 (Annex A). It is no secret that in reality it is difficult to be so binary about most of the criteria that are being cited here. Just a couple of examples I noted at first glance: - OLSR is said to "fail" the "loss response" criteria. However in the quick justification in section 4, nothing is said about link hysteresis strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR "pass" this criteria. - OLSR is said to "fail" the "control cost" criteria. However, simple fisheye TTL strategy on OLSR control messages makes OLSR "pass" this criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journal of Communication and Networks, 2004. Actually this paper even proves that OLSR can thus reach the Gupta and Kumar bounds in terms of control overhead scalability. But I'm afraid these 2 examples are just the tip of the iceberg if the document really about to justify the "fail/pass" table in section 4. For now this document is thus blurry and not really usable. This is why in my opinion the document should be rewritten in a different, more balanced state of mind. The aim should be to remain constructive with what is already out there in terms of routing solutions, and to justify fully what is needed in addition to these existing solutions. Regards, Emmanuel _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Aug 27 11:22: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 26BB33A6AC9; Wed, 27 Aug 2008 11:22: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 C35A53A68F4 for ; Wed, 27 Aug 2008 11:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.679 X-Spam-Level: X-Spam-Status: No, score=-5.679 tagged_above=-999 required=5 tests=[AWL=0.920, 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 oC7v70Rs+iA9 for ; Wed, 27 Aug 2008 11:22:02 -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 5DC403A6AC9 for ; Wed, 27 Aug 2008 11:22:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,280,1217808000"; d="scan'208";a="147716766" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Aug 2008 18:21:41 +0000 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 m7RILfob029257; Wed, 27 Aug 2008 11:21:41 -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 m7RILWxb019705; Wed, 27 Aug 2008 18:21: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); Wed, 27 Aug 2008 14:21:34 -0400 Received: from 10.55.206.229 ([10.55.206.229]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Aug 2008 18:21:33 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 27 Aug 2008 20:21:30 +0200 From: JP Vasseur To: "Drake, John E" , Adrian Farrel , Message-ID: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckF4uWWv+jCr8q7RKKuNS7geV3eIgA6l4jAAFZXU+0ACvR8MAAENIb7AACOAHAAAGaHlQABSNJwAAFf3kk= In-Reply-To: <51661468CBD1354294533DA79E85955A0109FE71@XCH-SW-5V2.sw.nos.boeing.com> Mime-version: 1.0 X-OriginalArrivalTime: 27 Aug 2008 18:21:34.0505 (UTC) FILETIME=[BC961990:01C90871] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19451; t=1219861301; x=1220725301; 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[Roll]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20; bh=L5zmdTqo3urBNAdQcolKFWD50KbzZY+66nbTeXSeeU8=; b=iH7O8N+u0x/97KYrxsX+/YkNdejJSuv1xAaqty2w88OZv5qnebBujTkmed laAKmJ3Hvle+/TVJFXYjfzkkuqWIDU7nHab0MLGUvrFss3t7ySF9x0UDXGI1 mHNsYZCNOI; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 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 John, On 8/27/08 7:47 PM, "Drake, John E" wrote: > JP, > > Oopsie, my mistake. > > However, I think my comment still stands, particularly if the working > group plans to use this I-D for deciding whether to invent at least one, > but probably many, new routing protocols. Just to clarify: *should* the WG decide to design a new protocol (which would mean to re-charter), it will *not* be many protocols for sure. That would simply be a non sense. See my first presentation at the routing plenary meeting. Thanks. JP. > > Thanks, > > John > >> -----Original Message----- >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: Wednesday, August 27, 2008 10:05 AM >> To: Drake, John E; Adrian Farrel; roll@ietf.org >> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >> >> John, >> >> >> On 8/27/08 6:57 PM, "Drake, John E" wrote: >> >>> Comment inline >>> >>>> -----Original Message----- >>>> From: JP Vasseur [mailto:jvasseur@cisco.com] >>>> Sent: Wednesday, August 27, 2008 9:38 AM >>>> To: Drake, John E; Adrian Farrel; roll@ietf.org >>>> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >>>> >>>> Hi John, >>>> >>>> >>>> On 8/27/08 4:45 PM, "Drake, John E" >> wrote: >>>> >>>>> JP, >>>>> >>>>> I thought that was exactly Adrian's point. >>>> >>>> Ok let's have him express his opinion. >>>> >>>>> >>>>> If you evaluate a bunch of routing protocols as they exist >>>> today in a >>>>> new operational environment and conclude that none of them are >>>>> appropriate, then you have no choice but to conclude that >>>> you need to >>>>> invent at least one, but probably many, new routing >> protocols. It's >>>>> not like this hasn't been done before. >>>>> >>>>> I took Adrian's note to say that doing this is not >>>> sufficient and that >>>>> what needed to be done was to characterize the new operational >>>>> environment, propose changes needed in each routing protocol to >>>>> address the new operational environment, and then evaluate >>>> these changes. >>>>> >>>> >>>> John, I fully respect your opinion. Feel free to propose these >>>> changes in light of the routing requirements expressed in >> the related >>>> WG document. >>>> Please make sure to fully understand them though, these >> networks have >>>> fairly unique characteristics that do require significant >> background. >>> >>> JD: I would think this is the responsibility of the authors who are >>> requesting that their I-D be adopted by the working group. >> >> This is already a WG document and there was a consensus within the WG. >> >> JP. >> >>> >>>> >>>> JP. >>>> >>>>> Thanks, >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: JP Vasseur [mailto:jvasseur@cisco.com] >>>>>> Sent: Wednesday, August 27, 2008 2:24 AM >>>>>> To: Drake, John E; Adrian Farrel; roll@ietf.org >>>>>> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >>>>>> >>>>>> John, >>>>>> >>>>>> I do not think that this was Adrian's point. Your >> feed-back is more >>>>>> than welcome but please argue a bit more ... >>>>>> >>>>>> Thanks. >>>>>> >>>>>> JP. >>>>>> >>>>>> >>>>>> On 8/25/08 6:13 PM, "Drake, John E" >>>> wrote: >>>>>> >>>>>>> Adrian, >>>>>>> >>>>>>> An excellent note - I agree completely. We need fewer routing >>>>>>> protocols, not more. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>>>>> Sent: Sunday, August 24, 2008 5:14 AM >>>>>>>> To: roll@ietf.org >>>>>>>> Subject: [Roll] draft-ietf-roll-protocols-survey-00 >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> As one of the two tourists who raised a hand in Dublin >> to express >>>>>>>> uneasiness about this I-D becoming a WG draft, I >> thought I should >>>>>>>> write a note about my concerns. >>>>>>>> >>>>>>>> I should caveat this by saying that I do appreciate the >>>>>> need for this >>>>>>>> work, and that the author-team will, I'm sure, do a fine job at >>>>>>>> delivering what the working group needs. My concerns were >>>> much more >>>>>>>> about getting the direction of the I-D right before >>>>>> accepting it as I >>>>>>>> think it is often harder to recast an I-D once it is within the >>>>>>>> working group. >>>>>>>> >>>>>>>> Below, please find my major discussion point. I have >> also done a >>>>>>>> review of the draft and found a bunch of >> issues/questions of more >>>>>>>> minor importance. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Adrian >>>>>>>> >>>>>>>> === >>>>>>>> >>>>>>>> The analysis of the routing protocols is predicated on what >>>>>> they are >>>>>>>> currently used for. To some extent this is reasonable >>>>>>>> - the easiest analysis of a routing protocol is in its >>>> operational >>>>>>>> environment. But to use this analysis as the basis of a >>>>>> decision for >>>>>>>> use of a protocol in a new environment is not so >>>> reasonable. If you >>>>>>>> want to show that none of today's protocols has been >>>>>> designed for use >>>>>>>> in the ROLL environment, then I don't suppose anyone will be >>>>>>>> surprised. However, what we are really interested in is >>>> whether any >>>>>>>> of the existing protocols is suitable for adaptation for >>>>>> use in ROLL, >>>>>>>> whether the those adaptations would be contrived and >>>>>> technically hard >>>>>>>> (or flaky), and whether it would be more efficient to >>>> design a new >>>>>>>> protocol. >>>>>>>> >>>>>>>> For an example (and I'm not proposing this as the solution >>>>>> for ROLL), >>>>>>>> an IGP could easily be adapted to flood on only certain >> links, to >>>>>>>> discard certain LSAs, and to build a FIB according to >>>>>> specific rules. >>>>>>>> This would not be a large change to the protocol, >>>> although it would >>>>>>>> obviously not be interoperable. >>>>>>>> >>>>>>>> To discard from consideration any protocol based on its >>>>>> behavior in a >>>>>>>> certain environment without setting it in the context of your >>>>>>>> forwarding paradigm and without examining the potential >>>> to adapt a >>>>>>>> protocol to that environment is wrong. If all you wanted >>>> to do was >>>>>>>> show that no current variant of any existing routing >> protocol is >>>>>>>> immediately applicable to ROLL, then that would be easy and >>>>>> would not >>>>>>>> be a surprise. But to imply that protocols are not open for >>>>>>>> adaptation is more serious. >>>>>>>> >>>>>>>> This is not to say that inventing a new protocol would be >>>> wrong or >>>>>>>> not fun. >>>>>>>> Only that your reasons for discarding protocols are >>>> poorly founded. >>>>>>>> You have focused on the operation of the routing >>>> protocol, not the >>>>>>>> purpose of the routing protocol. To give a better >>>> understanding of >>>>>>>> why you are discarding a protocol, you must show what >> you want to >>>>>>>> achieve as your forwarding paradigm. The requirements >>>>>> documents make >>>>>>>> some start at this. >>>>>>>> For example, draft-ietf-roll-urban-routing-reqs talks about: >>>>>>>> - routing to minimise power usage >>>>>>>> - routing to consider node and link capabilities >>>>>>>> - routing protocol to scale within CPU, memory and power limits >>>>>>>> - routing according to different metrics (latency is cited) >>>>>>>> >>>>>>>> Such considerations are a good start to understanding the >>>>>> forwarding >>>>>>>> paradigm in ROLL, but would not be good enough to use to >>>>>> devise a new >>>>>>>> routing protocol, so I don't see how they can be good enough to >>>>>>>> determine whether an existing protocol should be discarded, >>>>>> modified, >>>>>>>> or used. >>>>>>>> >>>>>>>> ============= >>>>>>>> >>>>>>>> More specific comments on the draft follow. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Do we have a commitment from the WG that any new protocol >>>> developed >>>>>>>> will be held to the same standards? That is, that the new >>>> protocol >>>>>>>> MUST achieve a "pass" in very column of the table in >>>>>> section 4. Or is >>>>>>>> there scope for pragmatism allowing trade-offs in the new >>>> protocol >>>>>>>> such that in some environments it achieves a pass in some >>>> columns, >>>>>>>> and in other environments it achieves a pass in other columns. >>>>>>>> >>>>>>>> Maybe you could add this as a statement in the Abstract and >>>>>>>> Introduction >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Why do you include the requirements language >> boilerplate? I don't >>>>>>>> think you use (or should use) such language in this document. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 1 >>>>>>>> >>>>>>>> Can you strip out terms not used in the document? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 2 >>>>>>>> >>>>>>>> You quote CPU power in MHz. Although that is the practical >>>>>> electronic >>>>>>>> limit, maybe MIPS would be a better measure. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3 para 2 >>>>>>>> >>>>>>>> "If a protocol cannot meet even these minimalist criteria..." >>>>>>>> I think your use of "cannot" is correct in the context of the >>>>>>>> sentence, but I think your I-D examines "does not" >>>>>>>> >>>>>>>> "...is unlikely to be good candidate..." >>>>>>>> Too much prevarication! >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3 para 3 >>>>>>>> >>>>>>>> "...the protocol does not appear to contain sufficient >>>>>> flexibility..." >>>>>>>> The problem with this is that it is very mushy! >>>>>>>> It is OK to discard a protocol that is not flexible enough >>>>>> to handle >>>>>>>> your requirements. It is not OK to discard a protocol >> because you >>>>>>>> don't appear to know how to extend it. >>>>>>>> >>>>>>>> A example comes in the somewhat contentious table in section 4 >>>>>>>> :-) Here, for OSPF, you say that there is a "fail" for >>>>>> conveying node >>>>>>>> costs. >>>>>>>> But there is already LSA available for carrying node >>>> capabilities, >>>>>>>> and there are opaque LSAs available for carrying additional >>>>>>>> "unconventional" >>>>>>>> information. >>>>>>>> >>>>>>>> All this sort of ties to my main point. Of course, the >> protocols >>>>>>>> don't do exactly what you want already, but a more thorough >>>>>> survey is >>>>>>>> needed if you what to use this I-D as the reason for excluding >>>>>>>> protocols. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.2 para 1 >>>>>>>> "...with size ranging from a minimum..." >>>>>>>> I think you mean "...with maximum size ranging from a >> minimum..." >>>>>>>> >>>>>>>> "very large networks" >>>>>>>> Can you de-fluff this? Some people might think that 250 >>>>>> nodes is very >>>>>>>> large >>>>>>>> ;-) >>>>>>>> >>>>>>>> "network depths" >>>>>>>> Would be worth including your definition here. >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Section 3.2 para 1 >>>>>>>> >>>>>>>> Is every network node a router? >>>>>>>> draft-ietf-roll-urban-routing-reqs says "Sensor nodes are >>>>>> capable of >>>>>>>> forwarding data." If every node is a router and >>>> participates in the >>>>>>>> routing protocol, this creates a very different >> environment from >>>>>>>> saying that most sensors are hosts, and some are routers. I >>>>>>>> appreciate that "capable" does not imply "do". >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Associated with the previous point, I think you might spend >>>>>> a little >>>>>>>> more time discussing the definition of a link in ROLL. It >>>> is clear >>>>>>>> that in a wireless n/w a link may exist between any two >> nodes in >>>>>>>> range. >>>>>>>> If that is >>>>>>>> what you mean, then it would help to make it clear. On >> the other >>>>>>>> hand, "link" could be defined as an active neighbor >> relationship >>>>>>>> between a pair of routers. Or something else. >>>>>>>> >>>>>>>> This becomes important as we try to understand how the >>>>>> protocol must >>>>>>>> scale, and what it is supposed to do. >>>>>>>> >>>>>>>> I presume that the concept of "parallel links" between >>>> neighbors is >>>>>>>> going to have no meaning at the moment. That is, you >> use only one >>>>>>>> frequency in any network. Maybe I presume wrong, in which >>>> case, you >>>>>>>> need to refine the definition of "network density" in >> section 3.1. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.2 para 1 >>>>>>>> Final sentence is a bit mangled. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.2 para 2 >>>>>>>> >>>>>>>> I can see why scaling with O(L) may be an issue, but it may >>>>>> depend on >>>>>>>> the definitions of links and routers. Also it may >> depend on what >>>>>>>> magnitude you expect for L. Perhaps you could give some >>>>>> ball-parks in >>>>>>>> the previous paragraph as you do for N and D. Without >> that, it is >>>>>>>> hard to justify the claim that scaling with O(L) is a problem. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.3 >>>>>>>> >>>>>>>> Can you add SINR to your terminology? >>>>>>>> >>>>>>>> "...not trigger unnecessary responses..." >>>>>>>> I think that this is subjective and unhelpful. Can you >>>> rephrase to >>>>>>>> capture a quantifiable requirement? >>>>>>>> >>>>>>>> s/link changes to propagate across/link changes to be >> propagated >>>>>>>> across/ >>>>>>>> >>>>>>>> s/O(l)/O(L)/ >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.3 final para >>>>>>>> >>>>>>>> You have "transmissions", "broadcast", and "route updates". >>>>>>>> Can you use a >>>>>>>> consistent term? It may be less pretty English, but it >> would be a >>>>>>>> better way to avoid accusations of bias :-) >>>>>>>> >>>>>>>> Perhaps... >>>>>>>> More precisely, loss responses that require transmissions >>>>>> within the >>>>>>>> network of O(N) fail, while those that are limited to >>>> O(L) or O(D) >>>>>>>> pass. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.4 para 1 >>>>>>>> >>>>>>>> "In terms of routing structure, any proposed L2N >> routing protocol >>>>>>>> ought to support the autonomous organization and >>>>>> configuration of the >>>>>>>> network at the lowest possible energy cost." >>>>>>>> >>>>>>>> Why "L2N"? I thought "Networks of low power wireless devices >>>>>>>> introduce novel IP routing issues." >>>>>>>> >>>>>>>> "ought" is not a recognized RFC 2119 word :-) >>>>>>>> >>>>>>>> I think "at the lowest possible energy cost" is a statement >>>>>> that this >>>>>>>> requirement trumps all others. Is that what you mean? >>>>>>>> >>>>>>>> I'm not convinced by the absolute statement you make here. >>>>>>>> Maybe, this is a >>>>>>>> question I should take to the requirements documents. Consider >>>>>>>> routing protocol A that is slightly more (say 5%) >> power-consuming >>>>>>>> than routing protocol B. But suppose protocol A gives rise >>>>>> to a data >>>>>>>> forwarding solution that is 50% more power-efficient? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.4 para 2 >>>>>>>> >>>>>>>> "As low-power wireless networks can have very low data rates, >>>>>>>> protocols which require a minimum control packet rate can have >>>>>>>> unbounded control overhead." >>>>>>>> >>>>>>>> I know what you mean, but I had to parse several times. >>>> How about... >>>>>>>> >>>>>>>> The control overhead is the ratio of control data to >>>>>> payload data. A >>>>>>>> high control overhead indicates that precious network resources >>>>>>>> (bandwidth, power, or CPU) are being consumed by the control >>>>>>>> protocols instead of being used to transmit data. Where >>>>>> payload data >>>>>>>> rates are very low (as is often the case in low-power wireless >>>>>>>> networks) the control overhead can become unbounded for >> protocols >>>>>>>> that require some non-zero background control packet rate. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.4 para 2 >>>>>>>> >>>>>>>> s/never meet the condition can be forced/never meet the >> condition >>>>>>>> could be forced/ >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 4 para 3 >>>>>>>> >>>>>>>> "multiple layer 2 hops away" >>>>>>>> Really? >>>>>>>> Again, I thought we were building an IP routing >> protocol. If your >>>>>>>> requirement is layer 2 routing, you need to make that >>>>>> visible up front. >>>>>>>> But, I can see why you are interested in L2 hops as well >>>> as L3 hops >>>>>>>> since they all consume power. >>>>>>>> >>>>>>>> This comes back to the question about whether all nodes are >>>>>> routers. >>>>>>>> Perhaps some repeaters are not routers? >>>>>>>> >>>>>>>> But can't we actually factor the L2 hops into the >>>> definition of the >>>>>>>> L3 hop? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 4 para 3 >>>>>>>> >>>>>>>> "...nodes may only advertise..." >>>>>>>> This sounds prohibitive! >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 4 para 4 >>>>>>>> >>>>>>>> "Neighbor discovery is a critical component of any routing >>>>>> protocol." >>>>>>>> I think I disagree. >>>>>>>> It is clear that routing protocols need to know their >>>> neighbors. It >>>>>>>> is not clear that this requires that the discovery be >> part of the >>>>>>>> routing protocol. >>>>>>>> >>>>>>>> Later you have: >>>>>>>> "...key component of many protocols." >>>>>>>> This is less strong than the initial sentence. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 4 >>>>>>>> >>>>>>>> "Protocols Today" >>>>>>>> >>>>>>>> Is this a section 4.1 headers? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 4 "Protocols Today" para 2 >>>>>>>> >>>>>>>> I don't think the MPLS TE example is a good one. It is >>>>>> certainly not >>>>>>>> correct that the TED has to be fully distributed around >>>> the network. >>>>>>>> There are some very good examples of where "stub TE >> areas" do not >>>>>>>> need to know the TE information for the whole of the >> rest of the >>>>>>>> network. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 4 Table >>>>>>>> >>>>>>>> I'm prepared to bet that a lot of people will be upset by >>>>>> the use of >>>>>>>> "fail" >>>>>>>> for their favorite protocols. It would seem that "?" is more >>>>>>>> appropriate in many cells. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 5.1 >>>>>>>> Is it worth replacing "OSPF" with "OSPF or IS-IS"? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 14. >>>>>>>> Your three ROLL requirements drafts are Normative >>>>>> References, I think. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> >>>> >>>> >> >> _______________________________________________ >> 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 Aug 28 05:38:31 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 BA24D3A6C02; Thu, 28 Aug 2008 05:38:31 -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 4210E3A6C02 for ; Thu, 28 Aug 2008 05:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 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 gZG2V5m35eQ6 for ; Thu, 28 Aug 2008 05:38:29 -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 2D19B3A6B2A for ; Thu, 28 Aug 2008 05:38:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,286,1217808000"; d="scan'208";a="18525265" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Aug 2008 12:38:29 +0000 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 m7SCcTrM032196; Thu, 28 Aug 2008 14:38:29 +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 m7SCcTW3011228; Thu, 28 Aug 2008 12:38:29 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); Thu, 28 Aug 2008 14:38:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 14:37:53 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0625ED6C@xmb-ams-337.emea.cisco.com> In-Reply-To: <51661468CBD1354294533DA79E85955A0109FE71@XCH-SW-5V2.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckF4uWWv+jCr8q7RKKuNS7geV3eIgA6l4jAAFZXU+0ACvR8MAAENIb7AACOAHAAAGaHlQABSNJwACc9dbA= References: <51661468CBD1354294533DA79E85955A0109FE32@XCH-SW-5V2.sw.nos.boeing.com> <51661468CBD1354294533DA79E85955A0109FE71@XCH-SW-5V2.sw.nos.boeing.com> From: "Pascal Thubert (pthubert)" To: "Drake, John E" , "Jean Philippe Vasseur (jvasseur)" , "Adrian Farrel" , X-OriginalArrivalTime: 28 Aug 2008 12:38:29.0840 (UTC) FILETIME=[F9953D00:01C9090A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19962; t=1219927109; x=1220791109; 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]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20; bh=sM+LIKZ4ad3RpJYbbSmkDhGnvWpbVt1/eNgFchG97o4=; b=EkChRnd/29PF7eBKk8RY4hjj/cBtPubR3LAuXW0dyUYoRA/+PWyi2/vqC4 qUphGIFoz4QVptgVmKxSW0b10B0Apx2lXaUyEFfGffAIfsp7dTWw7bKjsUr3 RWURTUQiVz; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 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 Hi John: I suspect that this discussion is already solution space thus should happen= after rechartering. NEW to me means that we can't just pick an existing RFC and be done with it= . This is what ROLL is chartered to evaluate and this is why the protocols = survey is promoted to WG doc. To work on something NEW we need to recharter. = IOW, even if the solution is heavily based on existing work, with say, a sp= ecific set of features made mandatory (a profile of some sort), and eventua= lly a few new ones added, we need to specify that in an RFC and we need a g= roup chartered to do so. = Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Dr= ake, John E >Sent: mercredi 27 ao=FBt 2008 19:48 >To: Jean Philippe Vasseur (jvasseur); Adrian Farrel; roll@ietf.org >Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 > >JP, > >Oopsie, my mistake. > >However, I think my comment still stands, particularly if the working >group plans to use this I-D for deciding whether to invent at least one, >but probably many, new routing protocols. > >Thanks, > >John > >>-----Original Message----- >>From: JP Vasseur [mailto:jvasseur@cisco.com] >>Sent: Wednesday, August 27, 2008 10:05 AM >>To: Drake, John E; Adrian Farrel; roll@ietf.org >>Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >> >>John, >> >> >>On 8/27/08 6:57 PM, "Drake, John E" wrote: >> >>> Comment inline >>> >>>> -----Original Message----- >>>> From: JP Vasseur [mailto:jvasseur@cisco.com] >>>> Sent: Wednesday, August 27, 2008 9:38 AM >>>> To: Drake, John E; Adrian Farrel; roll@ietf.org >>>> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >>>> >>>> Hi John, >>>> >>>> >>>> On 8/27/08 4:45 PM, "Drake, John E" >> wrote: >>>> >>>>> JP, >>>>> >>>>> I thought that was exactly Adrian's point. >>>> >>>> Ok let's have him express his opinion. >>>> >>>>> >>>>> If you evaluate a bunch of routing protocols as they exist >>>> today in a >>>>> new operational environment and conclude that none of them are >>>>> appropriate, then you have no choice but to conclude that >>>> you need to >>>>> invent at least one, but probably many, new routing >>protocols. It's >>>>> not like this hasn't been done before. >>>>> >>>>> I took Adrian's note to say that doing this is not >>>> sufficient and that >>>>> what needed to be done was to characterize the new operational >>>>> environment, propose changes needed in each routing protocol to >>>>> address the new operational environment, and then evaluate >>>> these changes. >>>>> >>>> >>>> John, I fully respect your opinion. Feel free to propose these >>>> changes in light of the routing requirements expressed in >>the related >>>> WG document. >>>> Please make sure to fully understand them though, these >>networks have >>>> fairly unique characteristics that do require significant >>background. >>> >>> JD: I would think this is the responsibility of the authors who are >>> requesting that their I-D be adopted by the working group. >> >>This is already a WG document and there was a consensus within the WG. >> >>JP. >> >>> >>>> >>>> JP. >>>> >>>>> Thanks, >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: JP Vasseur [mailto:jvasseur@cisco.com] >>>>>> Sent: Wednesday, August 27, 2008 2:24 AM >>>>>> To: Drake, John E; Adrian Farrel; roll@ietf.org >>>>>> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 >>>>>> >>>>>> John, >>>>>> >>>>>> I do not think that this was Adrian's point. Your >>feed-back is more >>>>>> than welcome but please argue a bit more ... >>>>>> >>>>>> Thanks. >>>>>> >>>>>> JP. >>>>>> >>>>>> >>>>>> On 8/25/08 6:13 PM, "Drake, John E" >>>> wrote: >>>>>> >>>>>>> Adrian, >>>>>>> >>>>>>> An excellent note - I agree completely. We need fewer routing >>>>>>> protocols, not more. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>>>>> Sent: Sunday, August 24, 2008 5:14 AM >>>>>>>> To: roll@ietf.org >>>>>>>> Subject: [Roll] draft-ietf-roll-protocols-survey-00 >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> As one of the two tourists who raised a hand in Dublin >>to express >>>>>>>> uneasiness about this I-D becoming a WG draft, I >>thought I should >>>>>>>> write a note about my concerns. >>>>>>>> >>>>>>>> I should caveat this by saying that I do appreciate the >>>>>> need for this >>>>>>>> work, and that the author-team will, I'm sure, do a fine job at >>>>>>>> delivering what the working group needs. My concerns were >>>> much more >>>>>>>> about getting the direction of the I-D right before >>>>>> accepting it as I >>>>>>>> think it is often harder to recast an I-D once it is within the >>>>>>>> working group. >>>>>>>> >>>>>>>> Below, please find my major discussion point. I have >>also done a >>>>>>>> review of the draft and found a bunch of >>issues/questions of more >>>>>>>> minor importance. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Adrian >>>>>>>> >>>>>>>> =3D=3D=3D >>>>>>>> >>>>>>>> The analysis of the routing protocols is predicated on what >>>>>> they are >>>>>>>> currently used for. To some extent this is reasonable >>>>>>>> - the easiest analysis of a routing protocol is in its >>>> operational >>>>>>>> environment. But to use this analysis as the basis of a >>>>>> decision for >>>>>>>> use of a protocol in a new environment is not so >>>> reasonable. If you >>>>>>>> want to show that none of today's protocols has been >>>>>> designed for use >>>>>>>> in the ROLL environment, then I don't suppose anyone will be >>>>>>>> surprised. However, what we are really interested in is >>>> whether any >>>>>>>> of the existing protocols is suitable for adaptation for >>>>>> use in ROLL, >>>>>>>> whether the those adaptations would be contrived and >>>>>> technically hard >>>>>>>> (or flaky), and whether it would be more efficient to >>>> design a new >>>>>>>> protocol. >>>>>>>> >>>>>>>> For an example (and I'm not proposing this as the solution >>>>>> for ROLL), >>>>>>>> an IGP could easily be adapted to flood on only certain >>links, to >>>>>>>> discard certain LSAs, and to build a FIB according to >>>>>> specific rules. >>>>>>>> This would not be a large change to the protocol, >>>> although it would >>>>>>>> obviously not be interoperable. >>>>>>>> >>>>>>>> To discard from consideration any protocol based on its >>>>>> behavior in a >>>>>>>> certain environment without setting it in the context of your >>>>>>>> forwarding paradigm and without examining the potential >>>> to adapt a >>>>>>>> protocol to that environment is wrong. If all you wanted >>>> to do was >>>>>>>> show that no current variant of any existing routing >>protocol is >>>>>>>> immediately applicable to ROLL, then that would be easy and >>>>>> would not >>>>>>>> be a surprise. But to imply that protocols are not open for >>>>>>>> adaptation is more serious. >>>>>>>> >>>>>>>> This is not to say that inventing a new protocol would be >>>> wrong or >>>>>>>> not fun. >>>>>>>> Only that your reasons for discarding protocols are >>>> poorly founded. >>>>>>>> You have focused on the operation of the routing >>>> protocol, not the >>>>>>>> purpose of the routing protocol. To give a better >>>> understanding of >>>>>>>> why you are discarding a protocol, you must show what >>you want to >>>>>>>> achieve as your forwarding paradigm. The requirements >>>>>> documents make >>>>>>>> some start at this. >>>>>>>> For example, draft-ietf-roll-urban-routing-reqs talks about: >>>>>>>> - routing to minimise power usage >>>>>>>> - routing to consider node and link capabilities >>>>>>>> - routing protocol to scale within CPU, memory and power limits >>>>>>>> - routing according to different metrics (latency is cited) >>>>>>>> >>>>>>>> Such considerations are a good start to understanding the >>>>>> forwarding >>>>>>>> paradigm in ROLL, but would not be good enough to use to >>>>>> devise a new >>>>>>>> routing protocol, so I don't see how they can be good enough to >>>>>>>> determine whether an existing protocol should be discarded, >>>>>> modified, >>>>>>>> or used. >>>>>>>> >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>> >>>>>>>> More specific comments on the draft follow. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Do we have a commitment from the WG that any new protocol >>>> developed >>>>>>>> will be held to the same standards? That is, that the new >>>> protocol >>>>>>>> MUST achieve a "pass" in very column of the table in >>>>>> section 4. Or is >>>>>>>> there scope for pragmatism allowing trade-offs in the new >>>> protocol >>>>>>>> such that in some environments it achieves a pass in some >>>> columns, >>>>>>>> and in other environments it achieves a pass in other columns. >>>>>>>> >>>>>>>> Maybe you could add this as a statement in the Abstract and >>>>>>>> Introduction >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Why do you include the requirements language >>boilerplate? I don't >>>>>>>> think you use (or should use) such language in this document. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 1 >>>>>>>> >>>>>>>> Can you strip out terms not used in the document? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 2 >>>>>>>> >>>>>>>> You quote CPU power in MHz. Although that is the practical >>>>>> electronic >>>>>>>> limit, maybe MIPS would be a better measure. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3 para 2 >>>>>>>> >>>>>>>> "If a protocol cannot meet even these minimalist criteria..." >>>>>>>> I think your use of "cannot" is correct in the context of the >>>>>>>> sentence, but I think your I-D examines "does not" >>>>>>>> >>>>>>>> "...is unlikely to be good candidate..." >>>>>>>> Too much prevarication! >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3 para 3 >>>>>>>> >>>>>>>> "...the protocol does not appear to contain sufficient >>>>>> flexibility..." >>>>>>>> The problem with this is that it is very mushy! >>>>>>>> It is OK to discard a protocol that is not flexible enough >>>>>> to handle >>>>>>>> your requirements. It is not OK to discard a protocol >>because you >>>>>>>> don't appear to know how to extend it. >>>>>>>> >>>>>>>> A example comes in the somewhat contentious table in section 4 >>>>>>>> :-) Here, for OSPF, you say that there is a "fail" for >>>>>> conveying node >>>>>>>> costs. >>>>>>>> But there is already LSA available for carrying node >>>> capabilities, >>>>>>>> and there are opaque LSAs available for carrying additional >>>>>>>> "unconventional" >>>>>>>> information. >>>>>>>> >>>>>>>> All this sort of ties to my main point. Of course, the >>protocols >>>>>>>> don't do exactly what you want already, but a more thorough >>>>>> survey is >>>>>>>> needed if you what to use this I-D as the reason for excluding >>>>>>>> protocols. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.2 para 1 >>>>>>>> "...with size ranging from a minimum..." >>>>>>>> I think you mean "...with maximum size ranging from a >>minimum..." >>>>>>>> >>>>>>>> "very large networks" >>>>>>>> Can you de-fluff this? Some people might think that 250 >>>>>> nodes is very >>>>>>>> large >>>>>>>> ;-) >>>>>>>> >>>>>>>> "network depths" >>>>>>>> Would be worth including your definition here. >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Section 3.2 para 1 >>>>>>>> >>>>>>>> Is every network node a router? >>>>>>>> draft-ietf-roll-urban-routing-reqs says "Sensor nodes are >>>>>> capable of >>>>>>>> forwarding data." If every node is a router and >>>> participates in the >>>>>>>> routing protocol, this creates a very different >>environment from >>>>>>>> saying that most sensors are hosts, and some are routers. I >>>>>>>> appreciate that "capable" does not imply "do". >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Associated with the previous point, I think you might spend >>>>>> a little >>>>>>>> more time discussing the definition of a link in ROLL. It >>>> is clear >>>>>>>> that in a wireless n/w a link may exist between any two >>nodes in >>>>>>>> range. >>>>>>>> If that is >>>>>>>> what you mean, then it would help to make it clear. On >>the other >>>>>>>> hand, "link" could be defined as an active neighbor >>relationship >>>>>>>> between a pair of routers. Or something else. >>>>>>>> >>>>>>>> This becomes important as we try to understand how the >>>>>> protocol must >>>>>>>> scale, and what it is supposed to do. >>>>>>>> >>>>>>>> I presume that the concept of "parallel links" between >>>> neighbors is >>>>>>>> going to have no meaning at the moment. That is, you >>use only one >>>>>>>> frequency in any network. Maybe I presume wrong, in which >>>> case, you >>>>>>>> need to refine the definition of "network density" in >>section 3.1. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.2 para 1 >>>>>>>> Final sentence is a bit mangled. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.2 para 2 >>>>>>>> >>>>>>>> I can see why scaling with O(L) may be an issue, but it may >>>>>> depend on >>>>>>>> the definitions of links and routers. Also it may >>depend on what >>>>>>>> magnitude you expect for L. Perhaps you could give some >>>>>> ball-parks in >>>>>>>> the previous paragraph as you do for N and D. Without >>that, it is >>>>>>>> hard to justify the claim that scaling with O(L) is a problem. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.3 >>>>>>>> >>>>>>>> Can you add SINR to your terminology? >>>>>>>> >>>>>>>> "...not trigger unnecessary responses..." >>>>>>>> I think that this is subjective and unhelpful. Can you >>>> rephrase to >>>>>>>> capture a quantifiable requirement? >>>>>>>> >>>>>>>> s/link changes to propagate across/link changes to be >>propagated >>>>>>>> across/ >>>>>>>> >>>>>>>> s/O(l)/O(L)/ >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.3 final para >>>>>>>> >>>>>>>> You have "transmissions", "broadcast", and "route updates". >>>>>>>> Can you use a >>>>>>>> consistent term? It may be less pretty English, but it >>would be a >>>>>>>> better way to avoid accusations of bias :-) >>>>>>>> >>>>>>>> Perhaps... >>>>>>>> More precisely, loss responses that require transmissions >>>>>> within the >>>>>>>> network of O(N) fail, while those that are limited to >>>> O(L) or O(D) >>>>>>>> pass. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.4 para 1 >>>>>>>> >>>>>>>> "In terms of routing structure, any proposed L2N >>routing protocol >>>>>>>> ought to support the autonomous organization and >>>>>> configuration of the >>>>>>>> network at the lowest possible energy cost." >>>>>>>> >>>>>>>> Why "L2N"? I thought "Networks of low power wireless devices >>>>>>>> introduce novel IP routing issues." >>>>>>>> >>>>>>>> "ought" is not a recognized RFC 2119 word :-) >>>>>>>> >>>>>>>> I think "at the lowest possible energy cost" is a statement >>>>>> that this >>>>>>>> requirement trumps all others. Is that what you mean? >>>>>>>> >>>>>>>> I'm not convinced by the absolute statement you make here. >>>>>>>> Maybe, this is a >>>>>>>> question I should take to the requirements documents. Consider >>>>>>>> routing protocol A that is slightly more (say 5%) >>power-consuming >>>>>>>> than routing protocol B. But suppose protocol A gives rise >>>>>> to a data >>>>>>>> forwarding solution that is 50% more power-efficient? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.4 para 2 >>>>>>>> >>>>>>>> "As low-power wireless networks can have very low data rates, >>>>>>>> protocols which require a minimum control packet rate can have >>>>>>>> unbounded control overhead." >>>>>>>> >>>>>>>> I know what you mean, but I had to parse several times. >>>> How about... >>>>>>>> >>>>>>>> The control overhead is the ratio of control data to >>>>>> payload data. A >>>>>>>> high control overhead indicates that precious network resources >>>>>>>> (bandwidth, power, or CPU) are being consumed by the control >>>>>>>> protocols instead of being used to transmit data. Where >>>>>> payload data >>>>>>>> rates are very low (as is often the case in low-power wireless >>>>>>>> networks) the control overhead can become unbounded for >>protocols >>>>>>>> that require some non-zero background control packet rate. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 3.4 para 2 >>>>>>>> >>>>>>>> s/never meet the condition can be forced/never meet the >>condition >>>>>>>> could be forced/ >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 4 para 3 >>>>>>>> >>>>>>>> "multiple layer 2 hops away" >>>>>>>> Really? >>>>>>>> Again, I thought we were building an IP routing >>protocol. If your >>>>>>>> requirement is layer 2 routing, you need to make that >>>>>> visible up front. >>>>>>>> But, I can see why you are interested in L2 hops as well >>>> as L3 hops >>>>>>>> since they all consume power. >>>>>>>> >>>>>>>> This comes back to the question about whether all nodes are >>>>>> routers. >>>>>>>> Perhaps some repeaters are not routers? >>>>>>>> >>>>>>>> But can't we actually factor the L2 hops into the >>>> definition of the >>>>>>>> L3 hop? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 4 para 3 >>>>>>>> >>>>>>>> "...nodes may only advertise..." >>>>>>>> This sounds prohibitive! >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 4 para 4 >>>>>>>> >>>>>>>> "Neighbor discovery is a critical component of any routing >>>>>> protocol." >>>>>>>> I think I disagree. >>>>>>>> It is clear that routing protocols need to know their >>>> neighbors. It >>>>>>>> is not clear that this requires that the discovery be >>part of the >>>>>>>> routing protocol. >>>>>>>> >>>>>>>> Later you have: >>>>>>>> "...key component of many protocols." >>>>>>>> This is less strong than the initial sentence. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 4 >>>>>>>> >>>>>>>> "Protocols Today" >>>>>>>> >>>>>>>> Is this a section 4.1 headers? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 4 "Protocols Today" para 2 >>>>>>>> >>>>>>>> I don't think the MPLS TE example is a good one. It is >>>>>> certainly not >>>>>>>> correct that the TED has to be fully distributed around >>>> the network. >>>>>>>> There are some very good examples of where "stub TE >>areas" do not >>>>>>>> need to know the TE information for the whole of the >>rest of the >>>>>>>> network. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 4 Table >>>>>>>> >>>>>>>> I'm prepared to bet that a lot of people will be upset by >>>>>> the use of >>>>>>>> "fail" >>>>>>>> for their favorite protocols. It would seem that "?" is more >>>>>>>> appropriate in many cells. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 5.1 >>>>>>>> Is it worth replacing "OSPF" with "OSPF or IS-IS"? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Section 14. >>>>>>>> Your three ROLL requirements drafts are Normative >>>>>> References, I think. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> >>>> >>>> >> >>_______________________________________________ >>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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Aug 29 11:47:36 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 52A273A6926; Fri, 29 Aug 2008 11:47: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 08E083A6926 for ; Fri, 29 Aug 2008 11:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.942 X-Spam-Level: X-Spam-Status: No, score=-5.942 tagged_above=-999 required=5 tests=[AWL=0.657, 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 Aqq57DPO1F0r for ; Fri, 29 Aug 2008 11:47:34 -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 08F933A6833 for ; Fri, 29 Aug 2008 11:47:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,293,1217808000"; d="scan'208";a="149246187" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Aug 2008 18:47:38 +0000 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 m7TIlbSv025813 for ; Fri, 29 Aug 2008 11:47:37 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7TIlZCj010505 for ; Fri, 29 Aug 2008 18:47:37 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, 29 Aug 2008 14:47:36 -0400 Received: from 10.61.64.42 ([10.61.64.42]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 29 Aug 2008 18:47:36 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Fri, 29 Aug 2008 20:47:35 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: ROLL WG Interim Meeting, October 6, 2008, San Jose Thread-Index: AckKB7OKzv77k8fIoE2esF1neVRDEQ== In-Reply-To: <20080829184419.CC5FA3A6A9A@core3.amsl.com> Mime-version: 1.0 X-OriginalArrivalTime: 29 Aug 2008 18:47:36.0463 (UTC) FILETIME=[B46979F0:01C90A07] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=811; t=1220035657; x=1220899657; 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=20ROLL=20WG=20Interim=20Meeting,=20Octobe r=206,=202008,=20San=20Jose=20 |Sender:=20; bh=fDfC3AhOV0bcyrkuONv5dHmKtop9ZIT0E+iwev1KcGQ=; b=z2sWeExofeE0Pu49R9i1MkKkOqdYzx15R+pBOeoLicK/q2s7+7ZmcFKJoH LtgDjK0GDgDNAwPmYAjJn8DIst8o1oXAIh/XUpMtq1Opi+OAkJJ02EKVCpI7 tsEDDbCAbM; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Roll] FW: ROLL WG Interim Meeting, October 6, 2008, San Jose 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 ------ Forwarded Message From: IESG Secretary Date: Fri, 29 Aug 2008 11:44:19 -0700 (PDT) To: IETF Announcement list Cc: JP Vasseur Subject: ROLL WG Interim Meeting, October 6, 2008, San Jose In light of the fast progress of the ROLL Working Group and in order not to delay the progress of the Working Group having it to wait for IETF-73, we are pleased to announce an Interim ROLL Working meeting that will take place on October 6, in San Jose, hosted by Cisco Systems (details to be announced soon), from 2pm to 4:30pm. Agenda: - Discussion of draft-ietf-roll-protocols-survey. For logistic reasons, if you plan to attend, please send an email to JP Vasseur, ROLL WG co-chair. ------ End of Forwarded Message _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll