From jpv@cisco.com Tue Nov 2 22:35:49 2010 Return-Path: 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 EEB303A6A79 for ; Tue, 2 Nov 2010 22:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.53 X-Spam-Level: X-Spam-Status: No, score=-109.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 UsuEwZBgA9dV for ; Tue, 2 Nov 2010 22:35:46 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E20933A6A87 for ; Tue, 2 Nov 2010 22:35:44 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8FAK6R0EyrR7H+/2dsb2JhbAAvoStxoDmbaYVFBIpVgwgG X-IronPort-AV: E=Sophos;i="4.58,287,1286150400"; d="scan'208";a="280053941" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 03 Nov 2010 05:35:51 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA35ZpGu005827; Wed, 3 Nov 2010 05:35:51 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 22:35:50 -0700 Received: from [172.31.12.27] ([10.21.78.220]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Nov 2010 22:35:50 -0700 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Nov 2010 20:23:14 +0100 Message-Id: <2B346340-55D3-4735-8D40-4D7773BA90E5@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 03 Nov 2010 05:35:50.0313 (UTC) FILETIME=[F95B4190:01CB7B18] Subject: [Roll] IETF-79 - Discussion on ROLL WG re-chartering 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: , X-List-Received-Date: Wed, 03 Nov 2010 05:35:50 -0000 Dear all, As you may have noticed, we have a 25mn slot to discuss re-chartering. This is going to be an open discussion and your chance to express your = opinion on which new items you would like the WG to work on. In the meantime, feel = free to voice your opinion on the mailing list, this will help us structure the = discussion. Thanks. JP.= From prvs=9175f1469=mukul@uwm.edu Wed Nov 3 18:43:25 2010 Return-Path: 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 C53853A6774 for ; Wed, 3 Nov 2010 18:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 WmZVn35R4NR5 for ; Wed, 3 Nov 2010 18:43:24 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id D23ED3A63CB for ; Wed, 3 Nov 2010 18:43:24 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.133]) by ip1mta.uwm.edu with ESMTP; 03 Nov 2010 20:43:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id E3FCE12E3BC for ; Wed, 3 Nov 2010 20:43:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ODC9KgR9s-R for ; Wed, 3 Nov 2010 20:43:32 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id C0C4412E3BB for ; Wed, 3 Nov 2010 20:43:32 -0500 (CDT) Date: Wed, 3 Nov 2010 20:43:32 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1097993149.1188193.1288835012157.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <711948738.1188155.1288834947483.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] draft-goyal-roll-p2p-measurement 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: , X-List-Received-Date: Thu, 04 Nov 2010 01:43:25 -0000 Hi all Kindly send us any comments you may have on this draft. The p2p extension to RPL needs the measurement mechanism described in this draft to determine the good enough criteria for route discovery. Thanks Mukul From nkong@cnnic.cn Thu Nov 4 02:46:31 2010 Return-Path: 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 5B9003A692F for ; Thu, 4 Nov 2010 02:46:31 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.029 X-Spam-Level: ** X-Spam-Status: No, score=2.029 tagged_above=-999 required=5 tests=[AWL=1.224, BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] 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 lDHndbQFRWte for ; Thu, 4 Nov 2010 02:46:30 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id DC4F43A69CA for ; Thu, 4 Nov 2010 02:46:29 -0700 (PDT) Received: (eyou send program); Thu, 04 Nov 2010 17:46:39 +0800 Message-ID: <488863999.03758@cnnic.cn> X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 04 Nov 2010 17:46:39 +0800 Message-ID: From: "Ning Kong" To: Date: Thu, 4 Nov 2010 17:46:28 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AE_01CB7C48.35941DA0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3502.922 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3502.922 Cc: Gyu Myoung Lee , Bruce Nordman Subject: [Roll] Doodle: Discussion of the PS draft and Charter for IoT RG in Beijing 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: , X-List-Received-Date: Thu, 04 Nov 2010 09:46:31 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_01AE_01CB7C48.35941DA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable ? Hi folks,=20 Sorry for cross-posting! There have been two bar BoF meetings for IoT (Internet of Things) at = IETF 77 and IETF 78. Gyu Myoung, Bruce and I would like to arrange an = informal meeting to discuss the PS draft = (draft-lee-iot-problem-statement-00) and Charter (coming soon) for IoT = RG at IETF 79. We cordially invite you to join us. In case you would like to attend this meeting, please indicate your = availabilities by 7 November 2010, on Doodle: = http://doodle.com/4t7phhfeqc9a5duh=20 We will decide whether this meeting should be announced as a bar BoF at = IETF 79 based on the result of the Doodle.=20 If you have any problem or suggestions, please feel free to let me know. = Cheers,=20 Ning=20 ------=_NextPart_000_01AE_01CB7C48.35941DA0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
Hi = folks,=20
 
Sorry for = cross-posting!
 
There have been two bar = BoF meetings=20 for IoT (Internet of Things) at IETF 77 and IETF 78. Gyu Myoung, Bruce = and I=20 would like to arrange an informal meeting to discuss the PS draft=20 (draft-lee-iot-problem-statement-00) and Charter (coming soon) for IoT = RG at=20 IETF 79. We cordially invite you to join us.
 
In case you would like = to attend this=20 meeting, please indicate your availabilities by 7 November 2010, on = Doodle:=20 http://doodle.com/4t7phhfeqc9a5duh
We will decide whether = this meeting=20 should be announced as a bar BoF at IETF 79 based on the result of the = Doodle.=20
 
If you have any problem = or=20 suggestions, please feel free to let me know.
 
 
Cheers,
Ning

= ------=_NextPart_000_01AE_01CB7C48.35941DA0-- From pal@cs.stanford.edu Sat Nov 6 00:06:07 2010 Return-Path: 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 178F73A6852 for ; Sat, 6 Nov 2010 00:06:07 -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 TOmnCZyy50bu for ; Sat, 6 Nov 2010 00:06:06 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 662E53A6849 for ; Sat, 6 Nov 2010 00:06:06 -0700 (PDT) Received: from 3-252.77-83.cust.bluewin.ch ([83.77.252.3] helo=[192.168.90.25]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PEcqy-0005bc-Sq; Sat, 06 Nov 2010 00:06:21 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <2B346340-55D3-4735-8D40-4D7773BA90E5@cisco.com> Date: Sat, 6 Nov 2010 08:06:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B346340-55D3-4735-8D40-4D7773BA90E5@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Cc: ROLL WG Subject: Re: [Roll] IETF-79 - Discussion on ROLL WG re-chartering 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: , X-List-Received-Date: Sat, 06 Nov 2010 07:06:07 -0000 On Nov 2, 2010, at 8:23 PM, JP Vasseur wrote: > Dear all, >=20 > As you may have noticed, we have a 25mn slot to discuss re-chartering. > This is going to be an open discussion and your chance to express your = opinion on > which new items you would like the WG to work on. In the meantime, = feel free to voice > your opinion on the mailing list, this will help us structure the = discussion. I think we should do a small amount of work on selecting some = lightweight cryptographic algorithms (e.g., IPR unencumbered yet less = expensive than RSA). Phil= From N.Brouwers@tudelft.nl Mon Oct 25 04:30:59 2010 Return-Path: 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 B46C33A69D7; Mon, 25 Oct 2010 04:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.22 X-Spam-Level: ** X-Spam-Status: No, score=2.22 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 SZkN5U6GWwYh; Mon, 25 Oct 2010 04:30:58 -0700 (PDT) Received: from mailservice.tudelft.nl (mailservice.tudelft.nl [130.161.131.5]) by core3.amsl.com (Postfix) with ESMTP id 4AFB53A69E6; Mon, 25 Oct 2010 04:30:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amavis (Postfix) with ESMTP id 37DA57F8091; Mon, 25 Oct 2010 13:32:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at tudelft.nl Received: from mailservice.tudelft.nl ([130.161.131.69]) by localhost (tudelft.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zemwjY6iWs9V; Mon, 25 Oct 2010 13:32:39 +0200 (CEST) Received: from srv027.tudelft.net (srv027.tudelft.net [131.180.0.81]) by mx1.tudelft.nl (Postfix) with ESMTP id 3E13A7F8059; Mon, 25 Oct 2010 13:32:39 +0200 (CEST) Received: from SRV564.tudelft.net ([131.180.5.67]) by srv027.tudelft.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 13:32:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7438.477A1368" Date: Mon, 25 Oct 2010 13:32:17 +0200 Message-ID: <947C04CD618D16429440FED56EAE47BA2C6EA6@SRV564.tudelft.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ACM SenSys 2010: Final Call for Participation Thread-Index: Act0OEd3Em+lcQcMRySflsFBsiorbQ== From: "Niels Brouwers - EWI" To: X-OriginalArrivalTime: 25 Oct 2010 11:32:17.0741 (UTC) FILETIME=[478A07D0:01CB7438] X-Mailman-Approved-At: Sat, 06 Nov 2010 08:12:46 -0700 Subject: [Roll] ACM SenSys 2010: Final Call for Participation 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: , X-List-Received-Date: Mon, 25 Oct 2010 11:30:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7438.477A1368 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ACM SenSys 2010: Final Call for Participation The 8th ACM Conference on Embedded Networked Sensor Systems November = 3-5, 2010 SenSys 2010 will take place at ETH Zurich from November 3-5. SenSys is = the premiere international conference in sensor networks and it is the = first time this event is hosted in Europe. The conference is 2.5 days, = single track, features an extensive demo and poster session on Thursday, = two single day workshops preceding the main event (PhoneSense and = BuildSys), a doctoral colloquium and a keynote by Alex (Sandy) Pentland, = MIT: "Building a Nervous System for Humanity". If you are interested in the current state-of-the-art in sensor network = systems, want to meet fellow researchers or simply just want to sniff = into a new area we would be delighted to you at the event. Information on the program, registration, etc. is available at = http://sensys.acm.org/2010/ ------_=_NextPart_001_01CB7438.477A1368 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ACM SenSys 2010: Final Call for Participation

ACM SenSys 2010: Final Call for Participation

The 8th ACM Conference on Embedded Networked Sensor Systems November = 3-5, 2010

SenSys 2010 will take place at ETH Zurich from November 3-5. SenSys is = the premiere international conference in sensor networks and it is the = first time this event is hosted in Europe. The conference is 2.5 days, = single track, features an extensive demo and poster session on Thursday, = two single day workshops preceding the main event (PhoneSense and = BuildSys), a doctoral colloquium and a keynote by Alex (Sandy) Pentland, = MIT: "Building a Nervous System for Humanity".

If you are interested in the current state-of-the-art in sensor network = systems, want to meet fellow researchers or simply just want to sniff = into a new area we would be delighted to you at the event.

Information on the program, registration, etc. is available at http://sensys.acm.org/2010/

------_=_NextPart_001_01CB7438.477A1368-- From azdvir@gmail.com Sun Nov 7 14:49:28 2010 Return-Path: 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 1DD6628C0D7 for ; Sun, 7 Nov 2010 14:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 FnL5XCOMprbq for ; Sun, 7 Nov 2010 14:49:25 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2EE833A68E4 for ; Sun, 7 Nov 2010 14:49:25 -0800 (PST) Received: by fxm9 with SMTP id 9so3719969fxm.31 for ; Sun, 07 Nov 2010 14:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=GESPEGaPRF+qcjM+Gp3xWeJdAqqs8YwyLxXyhSSQQcg=; b=sHCoEa1CHWTrxSTeeesY406VWICLzzuW0Yt0YRgOy0p4ClKDQavfjwgMNpJn/3DCXY tVBH4d42eSw77puA+yvfiqAWUZQP/PixDMmYhDHGxY+oRbIozVdrTLXtLFkLBTPztpRS 0M1lN9uta7vod22/ZS7haFhNic6tfahMDumOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=eU798G+htxLr0yfv3pZISYzxaCd8uvQyVBhQw4gudog8/xbemYc5Yw300OONQcNns8 Ds6GEHG9Sb4MeF6yUDyGWi6bjpL2qKm/6mRUunnQAJqGNTI/YGKdGU7p8xvc4r5X9F/O NOQIXNrqDsIzOYfsTZPk70ywXy4jprr6H3VpY= Received: by 10.223.118.132 with SMTP id v4mr3121503faq.87.1289170183924; Sun, 07 Nov 2010 14:49:43 -0800 (PST) Received: from amitPC ([195.228.111.1]) by mx.google.com with ESMTPS id o7sm1803468fal.27.2010.11.07.14.49.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 07 Nov 2010 14:49:43 -0800 (PST) From: "amit dvir" To: Date: Sun, 7 Nov 2010 23:49:46 +0100 Message-ID: <002e01cb7ece$14579d00$3d06d700$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01CB7ED6.761C0500" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Act+zhHoZcgMN6DOQIKacm00ZsUPGA== Content-Language: he X-Mailman-Approved-At: Sun, 07 Nov 2010 15:56:27 -0800 Subject: [Roll] DAO Multicast Ack 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: , X-List-Received-Date: Sun, 07 Nov 2010 22:49:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002F_01CB7ED6.761C0500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, I was wondering why there is no a DAO Multicast Ack message, even as an OPTIONAL? Can someone explain the motivation behind this? What do you think about adding this kind of message as OPTIONAL? Regards, Amit ------=_NextPart_000_002F_01CB7ED6.761C0500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

I was wondering why there is no a DAO Multicast Ack message, even as an = OPTIONAL?

Can someone explain the motivation behind this?

What do you think about adding this kind of message as = OPTIONAL?

Regards,<= /o:p>

Amit

 

------=_NextPart_000_002F_01CB7ED6.761C0500-- From Internet-Drafts@ietf.org Sun Nov 7 19:45:30 2010 Return-Path: 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 44E243A6971; Sun, 7 Nov 2010 19:45:30 -0800 (PST) X-Quarantine-ID: <0wOAX63GT7Cw> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: unexpected end of preamble X-Spam-Flag: NO X-Spam-Score: -99.339 X-Spam-Level: X-Spam-Status: No, score=-99.339 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, MISSING_MIME_HB_SEP=2.119, SARE_BOUNDARY_LC=1.666, USER_IN_WHITELIST=-100] 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 0wOAX63GT7Cw; Sun, 7 Nov 2010 19:45:27 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5B03A6970; Sun, 7 Nov 2010 19:45:21 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextpart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101108034521.20349.76245.idtracker@localhost> Date: Sun, 07 Nov 2010 19:45:21 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-15.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: , X-List-Received-Date: Mon, 08 Nov 2010 03:45:30 -0000 --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 : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-15.txt Pages : 144 Date : 2010-11-07 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to- multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-15.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-rpl-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-07193841.I-D@ietf.org> --NextPart-- From azdvir@gmail.com Mon Nov 8 00:25:32 2010 Return-Path: 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 1FDAA3A6774 for ; Mon, 8 Nov 2010 00:25:32 -0800 (PST) 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 H+SmBq32W78k for ; Mon, 8 Nov 2010 00:25:31 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C91133A6452 for ; Mon, 8 Nov 2010 00:25:30 -0800 (PST) Received: by bwz12 with SMTP id 12so5084845bwz.31 for ; Mon, 08 Nov 2010 00:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=R+zdr60Aa3bEVIdwCrBSI4NWyMeE+CQcPIVDyI55Dk0=; b=CSANAJg5jljRP0QnMpCMTeV6wLO7HQKUHsqjjwbm0+P7Xz3LayaTMqXooOs3nuJ0cI j3wYPxDwC+hrY2wGWSlygBhNtMIccfc56lWr79Nas4o6GHLuVBcbzlsQDIz19dWXJaEe P0qxwwG1fLh/qXA0kOl//WIFi+8lRNk/yZIc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; b=rBfqMYJHJO3UlBRoGIy8RAlGsU88r14n3uj0lgMzxSEIe3KBrSn+CdTH0DrQ0VBUiq iYQgotYlvkwxcThCVrgllt5JmcyX3ud9/jIFBu4SsqJTXKj6KXVop8RdtyWxJ5kDXyPt rsBp7wGl1iTU/KE1wnvPToeMdEsZfYgrzUiSU= Received: by 10.204.79.129 with SMTP id p1mr4740626bkk.59.1289204750623; Mon, 08 Nov 2010 00:25:50 -0800 (PST) Received: from amitPC (dsppc07.mit.bme.hu [152.66.253.166]) by mx.google.com with ESMTPS id t10sm3600748bkj.16.2010.11.08.00.25.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 00:25:49 -0800 (PST) From: "amit dvir" To: References: <003801cb7ece$14c0e620$3e42b260$@com> In-Reply-To: <003801cb7ece$14c0e620$3e42b260$@com> Date: Mon, 8 Nov 2010 09:25:47 +0100 Message-ID: <00dd01cb7f1e$8cc30a90$a6491fb0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DE_01CB7F26.EE877290" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Act+zhHoZcgMN6DOQIKacm00ZsUPGAAT3uQQ Content-Language: he Subject: [Roll] DAO Multicast Ack 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: , X-List-Received-Date: Mon, 08 Nov 2010 08:25:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00DE_01CB7F26.EE877290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, I was wondering why there is no a DAO Multicast Ack message, even as an OPTIONAL? Can someone explain the motivation behind this? What do you think about adding this kind of message as OPTIONAL? Regards, Amit ------=_NextPart_000_00DE_01CB7F26.EE877290 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

I was wondering why there is no a DAO Multicast Ack message, even as an = OPTIONAL?

Can someone explain the motivation behind this?

What do you think about adding this kind of message as = OPTIONAL?

Regards,<= /o:p>

Amit

 

------=_NextPart_000_00DE_01CB7F26.EE877290-- From Internet-Drafts@ietf.org Mon Nov 8 07:00:03 2010 Return-Path: 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 0F1DD3A68BE; Mon, 8 Nov 2010 07:00:03 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: unexpected end of preamble X-Spam-Flag: NO X-Spam-Score: -99.235 X-Spam-Level: X-Spam-Status: No, score=-99.235 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, MISSING_MIME_HB_SEP=2.119, SARE_BOUNDARY_LC=1.666, USER_IN_WHITELIST=-100] 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-DhJuRc5vbo; Mon, 8 Nov 2010 07:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579A13A677D; Mon, 8 Nov 2010 07:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextpart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101108150002.29000.27174.idtracker@localhost> Date: Mon, 08 Nov 2010 07:00:02 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-security-framework-02.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: , X-List-Received-Date: Mon, 08 Nov 2010 15:00:03 -0000 --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 : A Security Framework for Routing over Low Power and Lossy Networks Author(s) : T. Tsao, et al. Filename : draft-ietf-roll-security-framework-02.txt Pages : 44 Date : 2010-11-08 This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-security-framework-02.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-security-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-08065658.I-D@ietf.org> --NextPart-- From prvs=9210dfccf=Tzeta.Tsao@cooperindustries.com Mon Nov 8 07:02:50 2010 Return-Path: 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 BEA7B3A68B0 for ; Mon, 8 Nov 2010 07:02:50 -0800 (PST) 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 mRKf4OwzPogD for ; Mon, 8 Nov 2010 07:02:50 -0800 (PST) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by core3.amsl.com (Postfix) with ESMTP id DBD973A67D0 for ; Mon, 8 Nov 2010 07:02:49 -0800 (PST) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,314,1286164800"; d="scan'208";a="76188524" Received: from cipt0175.nam.ci.root ([10.132.108.175]) by cooperlighting-sw.cooperlighting.com with ESMTP; 08 Nov 2010 10:03:10 -0500 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0175.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 10:03:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Nov 2010 10:03:08 -0500 Message-ID: <9BB070DB2D281946859EA89837931EEE353498@EVS4.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-roll-security-framework-02 Thread-Index: Act/VT8A4agUis9AS6uOr9AaqBfL1QAADnsg From: "Tsao, Tzeta" To: "ROLL WG" X-OriginalArrivalTime: 08 Nov 2010 15:03:10.0957 (UTC) FILETIME=[0F3A11D0:01CB7F56] Subject: [Roll] FW: New Version Notification for draft-ietf-roll-security-framework-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: , X-List-Received-Date: Mon, 08 Nov 2010 15:02:50 -0000 WG, We have posted draft-ietf-roll-security-framework-02, which should be available from the repository shortly; the changes are more editorial in nature hopefully to better address the comments we received. Thanks, Tzeta -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Monday, November 08, 2010 9:57 AM To: Tsao, Tzeta Cc: Alexander, Roger; mischa.dohler@cttc.es; vanesa.daza@upf.edu; angel.lozano@upf.edu Subject: New Version Notification for draft-ietf-roll-security-framework-02=20 A new version of I-D, draft-ietf-roll-security-framework-02.txt has been successfully submitted by Tzeta Tsao and posted to the IETF repository. Filename: draft-ietf-roll-security-framework Revision: 02 Title: A Security Framework for Routing over Low Power and Lossy Networks Creation_date: 2010-11-08 WG ID: roll Number_of_pages: 44 Abstract: This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). =20 The IETF Secretariat. From jpv@cisco.com Mon Nov 8 16:52:03 2010 Return-Path: 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 105993A6920 for ; Mon, 8 Nov 2010 16:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 1yMp3fszpClp for ; Mon, 8 Nov 2010 16:52:02 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 61EB43A6914 for ; Mon, 8 Nov 2010 16:52:02 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAsq2EyrR7H+/2dsb2JhbACiHXGhI5t2hUgEhFaFf4MKBg X-IronPort-AV: E=Sophos;i="4.59,172,1288569600"; d="scan'208";a="213849192" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2010 00:52:25 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA90qMLG016764 for ; Tue, 9 Nov 2010 00:52:25 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 16:52:22 -0800 Received: from [172.31.12.9] ([10.21.83.99]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 16:52:22 -0800 From: JP Vasseur Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 9 Nov 2010 08:52:17 +0800 Message-Id: <0C33DD8F-F0B1-4380-8DE2-3854318022F9@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 09 Nov 2010 00:52:22.0530 (UTC) FILETIME=[5E680620:01CB7FA8] Subject: [Roll] URGENT - If you have a "presentation slot" for the ROLL WG Meeting please then them to me TODAY - Thanks - JP. 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: , X-List-Received-Date: Tue, 09 Nov 2010 00:52:03 -0000 From pthubert@cisco.com Mon Nov 8 17:19:21 2010 Return-Path: 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 CB6783A690C for ; Mon, 8 Nov 2010 17:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.612 X-Spam-Level: X-Spam-Status: No, score=-9.612 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 oNgFmdIxvm+n for ; Mon, 8 Nov 2010 17:19:20 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CB2D33A68A0 for ; Mon, 8 Nov 2010 17:19:20 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYFAI4w2EyrRN+J/2dsb2JhbACBbqAvcaEYm3iFSASNZQ X-IronPort-AV: E=Sophos;i="4.59,172,1288569600"; d="scan'208,217";a="616770297" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 09 Nov 2010 01:19:43 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oA91JgtH020028; Tue, 9 Nov 2010 01:19:43 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 02:19:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7FAC.2F8E5AE9" Date: Tue, 9 Nov 2010 02:19:05 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03215A9D@XMB-AMS-107.cisco.com> In-Reply-To: <00dd01cb7f1e$8cc30a90$a6491fb0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DAO Multicast Ack Thread-Index: Act+zhHoZcgMN6DOQIKacm00ZsUPGAAT3uQQACOSzZA= References: <003801cb7ece$14c0e620$3e42b260$@com> <00dd01cb7f1e$8cc30a90$a6491fb0$@com> From: "Pascal Thubert (pthubert)" To: "amit dvir" , X-OriginalArrivalTime: 09 Nov 2010 01:19:42.0304 (UTC) FILETIME=[2FC9AE00:01CB7FAC] Subject: Re: [Roll] DAO Multicast Ack 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: , X-List-Received-Date: Tue, 09 Nov 2010 01:19:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7FAC.2F8E5AE9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Amit: =20 I think that the model is the same as WIFI, we made unicast reliable but not multicast.=20 The multicast DAO is really an optimization for P2p between 1 hop neighbors, sent just in case. Why would you want that neighbors ack it? =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of amit dvir Sent: Monday, November 08, 2010 9:26 AM To: roll@ietf.org Subject: [Roll] DAO Multicast Ack =20 Dear all, I was wondering why there is no a DAO Multicast Ack message, even as an OPTIONAL? Can someone explain the motivation behind this? What do you think about adding this kind of message as OPTIONAL? Regards, Amit =20 ------_=_NextPart_001_01CB7FAC.2F8E5AE9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Amit:

 

I think that the model is the same as WIFI, we = made unicast reliable but not multicast.

The multicast DAO is really an optimization for = P2p between 1 hop neighbors, sent just in case. Why would you want that = neighbors ack it?

 

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = amit dvir
Sent: Monday, November 08, 2010 9:26 = AM
To: roll@ietf.org
Subject: [Roll] DAO Multicast = Ack

 

Dear all,

I was = wondering why there is no a DAO Multicast Ack message, even as an = OPTIONAL?

Can someone = explain the motivation behind this?

What do you = think about adding this kind of message as OPTIONAL?

Regards,<= /o:p>

Amit

 

------_=_NextPart_001_01CB7FAC.2F8E5AE9-- From Internet-Drafts@ietf.org Mon Nov 8 18:15:29 2010 Return-Path: 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 B33C528C1DC; Mon, 8 Nov 2010 18:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.344 X-Spam-Level: X-Spam-Status: No, score=-101.344 tagged_above=-999 required=5 tests=[AWL=1.255, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 rjjDWJ9i-paf; Mon, 8 Nov 2010 18:15:28 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DD228C168; Mon, 8 Nov 2010 18:15:23 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101109021523.26008.35013.idtracker@localhost> Date: Mon, 08 Nov 2010 18:15:23 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-15.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: , X-List-Received-Date: Tue, 09 Nov 2010 02:15:29 -0000 --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 : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-15.txt Pages : 144 Date : 2010-11-07 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to- multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-15.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-rpl-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-07193841.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Nov 8 18:16:32 2010 Return-Path: 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 A8D9328C29F; Mon, 8 Nov 2010 18:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.892 X-Spam-Level: X-Spam-Status: No, score=-101.892 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 gmQ20Dmux3n8; Mon, 8 Nov 2010 18:16:28 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B9728C1C1; Mon, 8 Nov 2010 18:15:36 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101109021536.26008.33689.idtracker@localhost> Date: Mon, 08 Nov 2010 18:15:36 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-security-framework-02.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: , X-List-Received-Date: Tue, 09 Nov 2010 02:16:32 -0000 --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 : A Security Framework for Routing over Low Power and Lossy Networks Author(s) : T. Tsao, et al. Filename : draft-ietf-roll-security-framework-02.txt Pages : 44 Date : 2010-11-08 This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-security-framework-02.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-security-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-08065658.I-D@ietf.org> --NextPart-- From jpv@cisco.com Tue Nov 9 03:33:00 2010 Return-Path: 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 32BA63A686E for ; Tue, 9 Nov 2010 03:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.506 X-Spam-Level: X-Spam-Status: No, score=-107.506 tagged_above=-999 required=5 tests=[AWL=-1.907, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 lsteH0kfyROv for ; Tue, 9 Nov 2010 03:32:55 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5CDDC3A6803 for ; Tue, 9 Nov 2010 03:32:55 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: draft-ietf-roll-routing-metrics-12.txt : 63793 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHfA2EyrR7H+/2dsb2JhbACiHnGjMZtjgwQIgj4EhFZXhSiDDAY X-IronPort-AV: E=Sophos;i="4.59,174,1288569600"; d="txt'?scan'208";a="616997036" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 09 Nov 2010 11:33:18 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA9BXCjV007837 for ; Tue, 9 Nov 2010 11:33:18 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 12:33:01 +0100 Received: from [172.31.12.10] ([10.61.99.128]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 12:32:59 +0100 From: JP Vasseur Content-Type: multipart/mixed; boundary=Apple-Mail-45--389951722 Date: Tue, 9 Nov 2010 19:32:57 +0800 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 09 Nov 2010 11:32:59.0646 (UTC) FILETIME=[DCB679E0:01CB8001] Subject: [Roll] Routing Metrics ID Revision 12 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: , X-List-Received-Date: Tue, 09 Nov 2010 11:33:00 -0000 --Apple-Mail-45--389951722 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, Sorry for sending to the list but the revision 12 of the metric ID has = been submitted, not yet on the repository. Here it is all, all editorials changes. Thanks. JP. --Apple-Mail-45--389951722 Content-Disposition: attachment; filename=draft-ietf-roll-routing-metrics-12.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-roll-routing-metrics-12.txt" Content-Transfer-Encoding: quoted-printable Networking Working Group JP. Vasseur, Ed. Internet-Draft Cisco Systems, Inc Intended status: Standards Track M. Kim, Ed. Expires: May 12, 2011 Corporate Technology Group, KT K. Pister Dust Networks N. Dejean Coronis SAS D. Barthel France Telecom Orange November 8, 2010 Routing Metrics used for Path Calculation in Low Power and Lossy Networks draft-ietf-roll-routing-metrics-12 Abstract Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Vasseur, et al. Expires May 12, 2011 [Page 1] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 This Internet-Draft will expire on May 12, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Vasseur, et al. Expires May 12, 2011 [Page 2] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Object formats . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. DAG Metric Container format . . . . . . . . . . . . . . . 7 2.2. Use of multiple DAG Metric Containers . . . . . . . . . . 10 2.3. Metric usage . . . . . . . . . . . . . . . . . . . . . . . 10 3. Node Metric/Constraint objects . . . . . . . . . . . . . . . . 11 3.1. Node State and Attributes object . . . . . . . . . . . . . 11 3.2. Node Energy object . . . . . . . . . . . . . . . . . . . . 12 3.3. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 16 4. Link Metric/Constraint objects . . . . . . . . . . . . . . . . 16 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 19 4.3.1. The Link Quality Level reliability metric . . . . . . 20 4.3.2. The Expected Transmission Count (ETX) reliability object . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4. Link Color object . . . . . . . . . . . . . . . . . . . . 23 4.4.1. Link Color object description . . . . . . . . . . . . 23 4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 24 5. Computation of dynamic metrics and attributes . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6.1. Routing Metric/Constraint type . . . . . . . . . . . . . . 26 6.2. Routing Metric/Constraint common header . . . . . . . . . 26 6.3. NSA object . . . . . . . . . . . . . . . . . . . . . . . . 27 6.4. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 27 7. Security considerations . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 9.2. Informative references . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Vasseur, et al. Expires May 12, 2011 [Page 3] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 1. Introduction This document makes use of the terminology defined in [I-D.ietf-roll-terminology]. Low power and Lossy Networks (LLNs) have specific routing characteristics compared with traditional wired or ad-hoc networks that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and [RFC5867]. Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have used quantitative static link metrics. Other mechanisms such as Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see [RFC2702] and [RFC3209]) make use of other link attributes such as the available reserved bandwidth (dynamic) or link affinities (most of the time static) to compute constrained shortest paths for Traffic Engineering Label Switched Paths (TE LSPs). This document specifies routing metrics and constraints to be used in path calculation by the Routing Protocol for Low Power and Lossy Networks (RPL) specified in [I-D.ietf-roll-rpl]. One of the prime objectives of this document is to propose a flexible mechanism for the advertisement of routing metrics and constraints used by RPL. Some RPL implementations may elect to adopt an extremely simple approach based on the use of a single metric with no constraint whereas other implementations may use a larger set of link and node routing metrics and constraints. This specification provides a high degree of flexibility and a set of routing metrics and constraints. New routing metrics and constraints could be defined in the future, as needed. RPL is a distance vector routing protocol variant that builds Directed Acyclic Graphs (DAGs) based on routing metrics and constraints. DAG formation rules are defined in [I-D.ietf-roll-rpl]: o The DODAG root as defined in [I-D.ietf-roll-rpl] may advertise a routing constraint used as a "filter" to prune links and nodes that do not satisfy specific properties. For example, it may be required for the path to only traverse nodes that are mains powered or links that have at least a minimum reliability or a specific "color" reflecting a user defined link characteristic (e.g the link layer supports encryption). o A routing metric is a quantitative value that is used to evaluate the path cost. Link and node metrics are usually (but not always) additive. Vasseur, et al. Expires May 12, 2011 [Page 4] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 The best path is the path with the lowest cost with respect to some metrics that satisfies all constraints (if any). It is also called the shortest constrained path (in the presence of constraints). Routing metrics falls into the following sets of characteristics: o Link versus Node metrics o Qualitative versus quantitative o Dynamic versus static Routing requirements documents (see [RFC5673], [RFC5826] [RFC5548] and [RFC5867]) observe that it must be possible to take into account a variety of node constraints/metrics during path computation. Some link or node characteristics (e.g. link reliability flag, remaining energy on the node) may either be used by RPL either as routing constraints or metrics. For example, the path may be computed to avoid links that do not provide a sufficient level of reliability (use as a constraint) or as the path offering most links with a specified reliability level (use as a metric). This document provides the flexibility to use link and node characterisics either as constraints and/or metrics. The use of link and node routing metrics and constraints is not exclusive (e.g. it is for example possible to advertise a "hop count" both as a metric to optimize the computed path and as a constraint (e.g. "Path should not exceed n hops")). Links in LLN commonly have rapidly changing node and link characteristics: thus routing metrics must be dynamic and techniques must be used to smooth out the dynimicity of these metrics so as to avoid routing oscillations. For instance, in addition to the dynamic nature of some links (e.g. wireless but also Powerline Communication (PLC) links), nodes' resources such as residual energy are changing continuously and may have to be taken into account during the path computation. It must be noted that the use of dynamic metrics is not new and has been experimented in ARPANET 2. The use of dynamic metrics is not trivial and great care must be given to the use of dynamic metrics since it may lead to potential routing instabilities. That being said, lots of experience has been gained over the years on the use of dynamic routing metrics, which have been deployed in a number of (non IP) networks. Very careful attention must be given to the pace at which routing Vasseur, et al. Expires May 12, 2011 [Page 5] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 metrics and attributes values change in order to preserve routing stability. When using a dynamic routing metric, a RPL implementation SHOULD make use of a multi-threshold scheme rather than fine granular metric updates reflecting each individual change to avoid spurious and unneccessary routing changes. The requirements on reporting frequency may differ among metrics, thus different reporting rates may be used for each metric. The set of routing metrics and constraints used by an RPL deployment is signaled along the Directed Acyclic Graph (DAG) that is built according to the Objective Function (rules governing how to build a DAG) and the routing metrics and constraints are advertised in the DAG Information Option (DIO) message specified in [I-D.ietf-roll-rpl]. RPL may be used to build DAGs with different characteristics. For example, it may be desirable to build a DAG with the goal to maximize reliability by using the link reliability metric to compute the "best" path. Another example might be to use the energy node characteristic (e.g. mains powered versus battery operated) as a node constraint when building the DAG so as to avoid battery powered nodes in the DAG while optimizing the link throughput. The specification of objective functions used to compute the DAG built by RPL is out of the scope of this document. This document defines routing metrics and constraints that are decoupled from the objective function. So a generic objective function could for example specify the rules to select the best parents in the DAG, the number of backup parents, etc and could be used with any routing metrics and/or constraints such as the ones specified in this document. Some metrics are either aggregated or recorded. An aggregated metric is adjusted as the DIO message travels along the DAG. For example, if the metric is the number of hops, each node updates the path cost that reflects the number of traversed hops along the DAG. By contrast, for a recorded metric, each node adds a sub-object reflecting the local valuation of the metric. For example, it might be desirable to record the link quality level along a path. In this case, each visited node adds a sub-object recording the local link quality level. In order to limit the number of sub-objects, the use of a counter may be desirable (e.g. record the number of links with a certain link quality level), thus compressing the information to reduce the message length. Upon receiving the DIO message from a set of parents, a node might decide according to the OF and local policy which node to choose as a parent based on the maximum number of links with a specific link reliability level, for example. Vasseur, et al. Expires May 12, 2011 [Page 6] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 Note that the routing metrics and constraints specified in this document are not specific to any particular link layer. An internal API between the MAC layer and RPL may be used to accurately reflect the metrics values of the link (wireless, wired, PLC). Since a set of metrics and constraints will be used for links and nodes in LLN, it is particularly critical to ensure the use of consistent metric calculation mechanisms for all links and nodes in the network, similarly to the case of inter-domain IP routing. 2. Object formats 2.1. DAG Metric Container format Routing metrics and constraints are carried within the DAG Metric Container object defined in [I-D.ietf-roll-rpl]. Should multiple metrics and/or constraints be present in the DAG Metric Container, their use to determine the "best" path can be defined by an Objective Function. 0 1 2 3 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | Type=3D2 | Option Len |Routing Metric/Constraint objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Figure 1: DAG Metric Container format The Routing Metric/Constraint objects represent a metric or a constraint of a particular type. They may appear in any order in the DAG Metric Container. They have a common format consisting of one or more bytes with a common header: Vasseur, et al. Expires May 12, 2011 [Page 7] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Routing-MC-Type| Flags |P|C|O|R| A | Prec | Length (bytes)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (object body) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Routing Metric/Constraint object generic format The object body carries one or more sub-objects defined later in this document. Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the Routing Metric/Constraint Type field uniquely identifies each Routing Metric/Constraint object and is managed by IANA. Length: this field defines the length of the object body, in bytes. The Flag field of the Routing Metric/Constraint object is managed by IANA. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. o C Flag. When set, this indicates that the Routing Metric/ Constraint object refers to a routing constraint. When cleared, the routing object refers to a routing metric. o O Flag: The O flag is used exclusively for routing constraints (C flag is set). When set, this indicates that the constraint specified in the body of the object is optional. When cleared, the constraint is mandatory. If the C flag is zero, the O flag MUST be set to zero on transmission and ignored on reception. o R Flag: The R Flag is only relevant for routing metric (C=3D0) and MUST be cleared for C=3D1. When set, this indicates that the routing metric is recorded along the path. Conversely, when cleared, the routing metric is aggregated. o A Field: The A field is only relevant for metrics and is used to indicate whether the aggregated routing metric is additive, multiplicative, reports a maximum or a minimum. * A=3D0x00: The routing metric is additive * A=3D0x01: The routing metric reports a maximum Vasseur, et al. Expires May 12, 2011 [Page 8] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 * A=3D0x02: The routing metric reports a minimum * A=3D0x03: The routing metric is multiplicative The A field has no meaning when the C Flag is set (i.e. when the Routing Metric/Constraint object refers to a routing constraint) and MUST be written to 0x00. o Prec field: The Prec field indicates the precedence of this Routing Metric/Constraint object relative to other objects in the container. This is useful when a DAG Metric Container contains several Routing Metric objects. The value 0 means the highest precedence. o P field: the P field is only used for recorded metrics. When cleared, all nodes along the path successfully recorded the corresponding metric. When set, this indicates than one or several nodes along the path could not record the metric of interest (either because of lack of knowledge or because this was prevented by policy). Example 1: A DAG formed by RPL where all nodes must be mains-powered and the best path is the one with lower aggregated ETX. In this case the DAG Metric container carries two Routing Metric/Constraint objects: one is an ETX metric object with header (C=3D0, O=3D0, A=3D00,= R=3D0) and the second one is a Node Energy constraint object with header (C=3D1, O=3D0, A=3D00, R=3D0). Note that a RPL instance may = use the metric object to report a maximum (A=3D0x01) or a minimum (A=3D0x02). If, for example, the best path is characterized by the path avoiding low quality links, then the path metric reports a maximum (A=3D0x01) (the higher is the ETX the lower link quality is): when the DIO message reporting link quality metric (ETX) is processed by a node, each node selecting the advertising node as a parent updates the value carried in the metric object by replacing it with its local link ETX value if and only if the latter is higher. As far as the constraint is concerned, if the constraint signalled in the DIO message is not satisfied, the advertising node is just not selected as a parent by the node that processes the DIO message. Example 2: A DAG formed by RPL where the link metric is the link quality level (defined in Section 4) and link quality levels must be recorded along the path. In this case, the DAG Metric Container carries a Routing Metric/Constraint object: link quality level metric (C=3D0, O=3D0, A=3D00, R=3D1) containing multiple sub-objects. A Routing Metric/Constraint object may also include one or more additional type-length-value (TLV) encoded data sets. Each Routing Metric/Constraint TLV has the same structure: Vasseur, et al. Expires May 12, 2011 [Page 9] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 Type: 1 byte Length: 1 byte Value: variable A Routing Metric/Constraint TLV is comprised of 1 byte for the type, 1 byte specifying the TLV length, and a value field. The TLV length field defines the length of the value field in bytes. Unrecognized TLVs MUST be ignored. IANA management of the Routing Metric/Constraint objects identifier codespace is described in Section 6. 2.2. Use of multiple DAG Metric Containers Since the length of RPL options is encoded using 1 octet, they cannot exceed 255 bytes, which also applies to the DAG Metric Container. In the vast majority of cases, the advertised routing metrics and constraints will not require that much space. However, there might be circumstances where larger space is required, should for example a set of routing metrics be recorded along a long path. In this case, as specified in [I-D.ietf-roll-rpl], routing metrics will be carried using multiple DAG Metric Containers objects. In the rest of this document, this use of multiple DAG Metric Containers objects will be considered as if they were actually just one long DAG Metric Container object. 2.3. Metric usage When the DAG Metric Container contains a single aggregated metric (scalar value), the order relation to select the best path is implicitly derived from the metric type. For example, lower is better for Hop Count, Link Latency and ETX. Conversely, for Node Energy or Throughput, higher is better. An example of using such a single aggregated metric is optimizing routing for node energy. The Node Energy metric (E-E field) defined in Section 3.2 is aggregated along paths with an explicit min function (A field), and the best path is selected through an implied Max function because the metric is Energy. When the DAG Metric Container contains several aggregated metrics, they are to be used as tie-breakers according to their precedence defined by their Prec field values. An example of such use of multiple aggregated metrics is the following: Hop-Count as the primary criterion, LQL as the secondary Vasseur, et al. Expires May 12, 2011 [Page 10] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 criterion and Node Energy as the ultimate tie-breaker. In such a case, the Hop-Count, LQL and Node Energy metric objects' Prec fields should bear strictly increasing values such as 0, 1 and 2, respectively. If several aggregated metrics happen to bear the same Prec value, the behavior is implementation-dependant. 3. Node Metric/Constraint objects 3.1. Node State and Attributes object The Node State and Attribute (NSA) object is used to provide information on node's characteristics. The NSA object MAY be present in the DAG Metric Container. There MUST be no more than one NSA object as a constraint per DAG Metric Container, and no more than one NSA object as a metric per DAG Metric Container. The NSA object may also contain a set of TLVs used to convey various node characteristics. No TLV is currently defined. The NSA Routing Metric/Constraint Type is to be assigned by IANA (recommended value=3D1). The format of the NSA object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | Flags |A|O| Optional TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 3: NSA object format 'O' flag: node workload may be hard to determine and express in some scalar form. However, node workload could be a useful metric to consider during path calculation, in particular when queuing delays must be minimized for highly sensitive traffic considering Medium Access Control (MAC) layer delay. Node workload MAY be set upon CPU overload, lack of memory or any other node related conditions. Using a simple 1-bit flag to characterize the node workload provides a sufficient level of granularity, similarly to the "overload" bit used in routing protocols such as IS-IS. Algorithms used to set the overload bit and to compute paths to potentially avoid nodes with their overload bit set are outside the scope of this document, but it Vasseur, et al. Expires May 12, 2011 [Page 11] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 is RECOMMENDED to avoid frequent changes of this bit to avoid routing oscillations. 'A' flag: data Aggregation Attribute: data fusion involves more complicated processing to improve the accuracy of the output data, while data aggregation mostly aims at reducing the amount of data. This is listed as a requirement in Section 6.2 of [RFC5548]. Some applications may make use of the aggregation node attribute in their routing decision so as to minimize the amount of traffic on the network, thus potentially increasing its lifetime in battery operated environments. Applications where highly directional data flow is expected on a regular basis may take advantage of data aggregation supported routing. The following two bits of the NSA object are currently defined: o A Flag: When set, this indicates that the node can act as a traffic aggregator. An implementation MAY decide to add optional TLVs (not currently defined) to further describe the node traffic aggregator functionality. o O Flag: When set, this indicates that the node is overloaded and may not be able to process traffic. The Flag field of the NSA Routing Metric/Constraint object is managed by IANA. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. 3.2. Node Energy object Whenever possible, a node with low residual energy should not be selected as a router, thus the support for constraint-based routing is needed. In such cases, the routing protocol engine may compute a longer path (constraint based) for some traffic in order to increase the network life duration. Power and energy are clearly critical resources in most LLNs. As yet there is no simple abstraction which adequately covers the broad range of power sources and energy storage devices used in existing LLN nodes. These include mains-powered, primary batteries, energy scavengers, and a variety of secondary storage mechanisms. Scavengers may provide a reliable low level of power, such as might be available from a 4-20mA loop; a reliable but periodic stream of power, such as provided by a well-positioned solar cell; or unpredictable power, such as might be provided by a vibrational energy scavenger on an intermittently powered pump. Routes which are viable when the sun is shining may disappear at night. A pump turning on may connect two previously disconnected sections of a Vasseur, et al. Expires May 12, 2011 [Page 12] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 network. Storage systems like rechargeable batteries often suffer substantial degradation if regularly used to full discharge, leading to different residual energy numbers for regular versus emergency operation. A route for emergency traffic may have a different optimum than one for regular reporting. Batteries used in LLNs often degrade substantially if their average current consumption exceeds a small fraction of the peak current that they can deliver. It is not uncommon for self-supporting nodes to have a combination of primary storage, energy scavenging, and secondary storage, leading to three different values for acceptable average current depending on the time frame being considered, e.g. milliseconds, seconds, and hours/years. Raw power and energy values are meaningless without knowledge of the energy cost of sending and receiving packets, and lifetime estimates have no value without some higher-level constraint on the lifetime required of a device. In some cases the path that exhausts the battery of a node on the bed table in a month may be preferable to a route that reduces the lifetime of a node in the wall to a decade. Given the complexity of trying to address such a broad collection of constraints, this document defines three levels of fidelity in the solution. The simplest solution relies on a 2-bit field encoding three types of power sources: "powered", "battery", "scavenger". This simple approach may be sufficient for many applications. The mid-complexity solution is a single parameter that can be used to encode the energetic happiness of both battery powered and scavenging nodes. For scavenging nodes, the 8 bit quantity is the power provided by the scavenger divided by the power consumed by the application, H=3DP_in/P_out, in units of percent. Nodes which are scavenging more power than they are consuming will register above 100. A good time period for averaging power in this calculation may be related to the discharge time of the energy storage device on the node, but specifying this is out of the scope of this document. For battery powered devices, H is the current expected lifetime divided by the desired minimum lifetime. The estimation of remaining battery energy and actual power consumption can be difficult, and the specifics of this calculation are out of scope of this document, but two examples are presented. If the node can measure its average power consumption, then H can be calculated as the ratio of desired max power (initial energy E_0 divided by desired lifetime T) to actual power, H=3DP_max/P_now. Alternatively, if the energy in the Vasseur, et al. Expires May 12, 2011 [Page 13] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 battery E_bat can be estimated, and the total elapsed lifetime, t, is available, then H can be calculated as the total stored energy remaining versus the target energy remaining: H=3D E_bat / [E_0 (T-t)/T]. An example of optimized route is max(min(H)) for all battery operated nodes along the route, subject to the constraint that H>=3D100 for = all scavengers along the route. Note that the estimated percentage of remaining energy indicated in the E-E field may not be useful in the presence of nodes powered by battery or energy scavengers when the amount of energy accumulated by the device significantly differ. Indeed, X% of remaining energy on a node that can store a large amount of energy cannot be easily compared to the same percentage of remaining energy on a node powered by a tiny source of energy. That being said, in networks where nodes have relatively close energy storage, such a percentage of remaining energy is useful. The Node Energy (NE) object is used to provide information related to node energy and may be used as a metric or as constraint. The NE object MAY be present in the DAG Metric Container. There MUST be no more than one NE object as a constraint per DAG Metric Container, and no more than one NE object as a metric per DAG Metric Container. The NE object Type is to be assigned by IANA (recommended value=3D2). The format of the NE object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | NE Sub-objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 4: NE object format Vasseur, et al. Expires May 12, 2011 [Page 14] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 The format of the NE sub-object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Flags |I| T |E| E-E | Optional TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 5: NE sub-object format The NE sub-object may also contain a set of TLVs used to convey various nodes' characteristics. The following flags are currently defined: o I (Included): the I bit is only relevant when the node type is used as a constraint. For example, the path must only traverse mains-powered nodes. Conversely, battery operated nodes must be excluded. The I bit is used to stipulate inclusion versus exclusion. When set, this indicates that nodes of the type specified in the node type field MUST be included. Conversely, when cleared, this indicates that nodes of type specified in the node type field MUST be excluded. o T (node Type): 2-bit field indicating the node type. E=3D0x00 designates a mains-powered node, E=3D0x01 a battery-powered node = and E=3D0x02 a node powered by an energy scavenger. o E (Estimation): when the E bit is set for a metric, the estimated percentage of remaining energy on the node is indicated in the E-E 8-bit field. When cleared, the estimated percentage of remaining energy is not provided. When the E bit is set for a constraint, the E-E field defines a threshold for the inclusion/exclusion: if an inclusion, nodes with values higher than the threshold are to be included; if an exclusion, nodes with values lower than the threshold are to be excluded. E-E (Estimated-Energy): 8-bit unsigned integer field indicating an estimated percentage of remaining energy. The E-E field is only relevant when the E flag is set, and MUST be set to 0 when the E flag is cleared. If the NE object comprises several sub-objects when used as a constraint, each sub-object adds or subtracts node subsets as the sub-objects are parsed in order. The initial set (full or empty) is defined by the I bit of the first sub-object: full if that I bit is an exclusion, empty is that I bit is an inclusion. Vasseur, et al. Expires May 12, 2011 [Page 15] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 No TLV is currently defined. Future addenda to this document may include more complex solutions involving a half dozen TLV parameters representing energy storage, consumption, and generation capabilities of the node, as well as desired lifetime. 3.3. Hop-Count object The HoP-Count (HP) object is used to report the number of traversed nodes along the path. The HP object MAY be present in the DAG Metric Container. There MUST be no more than one HP object as a constraint per DAG Metric Container, and no more than one HP object as a metric per DAG Metric Container. The HP object may also contain a set of TLVs used to convey various node characteristics. No TLV is currently defined. The HP routing metric object Type is to be assigned by IANA (recommended value=3D3) The format of the Hop Count object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | Flags | Hop Count | Optional TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 6: Hop Count object format No Flag is currently defined. The HP object may be used as a constraint or a metric. When used as a constraint, the DAG root indicates the maximum number of hops that a path may traverse. When that number is reached, no other node can join that path. When used as a metric, each visited node simply increments the Hop Count field. 4. Link Metric/Constraint objects Vasseur, et al. Expires May 12, 2011 [Page 16] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 4.1. Throughput Many LLNs support a wide range of throughputs. For some links, this may be due to variable coding. For the deeply duty-cycled links found in many LLNs, the variability comes as a result of trading power consumption for bit rate. There are several MAC layer protocols which allow for the effective bit rate and power consumption of a link to vary over more than three orders of magnitude, with a corresponding change in power consumption. For efficient operation, it may be desirable for nodes to report the range of throughput that their links can handle in addition to the currently available throughput. The Throughput object MAY be present in the DAG Metric Container. There MUST be no more than one Throughput object as a constraint per DAG Metric Container, and no more than one Throughput object as a metric per DAG Metric Container. The Throughput object is made of throughput sub-objects and MUST at least comprise one Throughput sub-object. The first Throughput sub- object MUST be the most recently estimated actual throughput. The actual estimation of the throughput is outside the scope of this document. Each Throughput sub-object has a fixed length of 4 bytes. The Throughput object does not contain any additional TLV. The Throughput object Type is to be assigned by IANA (recommended value=3D4) Vasseur, et al. Expires May 12, 2011 [Page 17] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 The format of the Throughput object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sub-object) ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Throughput object body format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Throughput | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Throughput sub-object format Throughput: 32 bits. The Throughput is encoded in 32 bits in unsigned integer format, expressed in bytes per second. 4.2. Latency Similarly to throughput, the latency of many LLN MAC sub-layers can vary over many orders of magnitude, again with a corresponding change in current consumption. Some LLN MAC link layers will allow the latency to be adjusted globally on the subnet, on a link-by-link basis, or not at all. Some will insist that it be fixed for a given link, but allow it to be variable from link to link. The Latency object MAY be present in the DAG Metric Container. There MUST be no more than one Latency object as a constraint per DAG Metric Container, and no more than one Latency object as a metric per DAG Metric Container. The Latency object is made of Latency sub-objects and MUST at least comprise one Latency sub-object. Each Latency sub-object has a fixed length of 4 bytes. The Latency object does not contain any additional TLV. The Latency object Type is to be assigned by IANA (recommended value=3D5) The Latency object is a metric or constraint. Vasseur, et al. Expires May 12, 2011 [Page 18] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 The format of the Latency object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sub-object) ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Latency object body format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Latency sub-object format Latency: 32 bits. The Latency is encoded in 32 bits in unsigned integer format, expressed in microseconds. The Latency object may be used as a constraint or a path metric. For example, one may want the latency not to exceed some value. In this case, the Latency object common header indicates that the provided value relates to a constraint. In another example, the Latency object may be used as an aggregated additive metric where the value is updated along the path to reflect the path latency. 4.3. Link reliability In LLNs, link reliability is degraded by external interference and multi-path interference (wireless links). Multipath typically affects both directions on the link equally, whereas external interference is sometimes unidirectional. Time scales vary from milliseconds to days, and are often periodic and linked to human activity. Packet error rates can generally be measured directly, and other metrics (e.g. bit error rate, mean time between failures) are typically derived from that. Note that such variability is not specific to wireless link but also applies to PLC links. A change in link quality can affect network connectivity, thus, link quality may be taken into account as a critical routing metric. A number of link reliability metrics could be defined reflecting several reliability aspects. Two link reliability metrics are defined in this document: the Link Quality Level (LQL) and the Expected Transmission count Metric (ETX). Vasseur, et al. Expires May 12, 2011 [Page 19] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 Note that an RPL implementation MAY either use the LQL, the ETX or both. 4.3.1. The Link Quality Level reliability metric The Link Quality Level (LQL) object is used to quantify the link reliability using a discrete value, from 0 to 7 where 0 indicates that the link quality level is unknown and 1 reports the highest link quality level. The mechanisms and algorithms used to compute the LQL are implementation specific and outside of the scope of this document. The LQL can either be used as a metric or a constraint. When used as a metric, the LQL metric can be recorded or aggregated. For example, the DAG Metric object may request all traversed nodes to record the LQL of their incoming link into the LQL object. Each node can then use the LQL record to select its parent based on some user defined rules (e.g. something like "select the path with most links reporting a LQL value of 3 or less"). By contrast, the LQL link metric may be aggregated, in which case the sum of all LQLs may be reported (additive metric) or the minimum value may be reported along the path. When used as a recorded metric, counters are used to compress the information: for each encountered LQL value, only the number of matching links is reported. The LQL object MAY be present in the DAG Metric Container. There MUST be no more than one LQL object as a constraint per DAG Metric Container, and no more than one LQL object as a metric per DAG Metric Container. The LQL object MUST contain one or more sub-object used to report the number of links along with their LQL. The LQL object Type is to be assigned by IANA (recommended value=3D6) The format of the LQL object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | LQL sub-object +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 12: LQL object format When the LQL metric is recorded, the LQL object body comprises one or Vasseur, et al. Expires May 12, 2011 [Page 20] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 more LQL Type 1 sub-object. The format of the LQL Type 1 sub-object is as follows 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Val | Counter | +-+-+-+-+-+-+-+-+ Figure 13: LQL Type 1 sub-object format Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates the highest link quality. Counter: number of links with that value. When the LQL metric is aggregated, the LQL object body comprises one LQL Type 2 sub-object: The format of the LQL Type 2 sub-object is as follows 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aggregated LQL Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: LQL Type 2 sub-object format Aggregated LQL Value: when used as an additive metric (A=3D0x00), the aggregated LQL value reports the sum of all the LQL values for all links along the path. When used to report a minimum (A=3D0x02), the field reports the minimum LQL value of all links along the path, ignoring undetermined LQLs (Aggregated LQL Value =3D 0). When used = to report a maximum (A=3D0x01), the field reports the maximum LQL value = of all links along the path. When used to report a multiplication (A=3D0x03), and the LQL field of one of the links along the path is undetermined (LQL=3D0), the undetermined LQL will be ignored and not = be aggregated (i.e. no reset to Aggregated LQL Value field). 4.3.2. The Expected Transmission Count (ETX) reliability object The Expected Transmission Count (ETX) metric is the number of transmissions a node expects to make to a destination in order to successfully deliver a packet. In contrast with the LQL routing metric, the ETX provides a discrete value (wich may not be an integer) computed according to a specific formula: for example, an Vasseur, et al. Expires May 12, 2011 [Page 21] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 implementation may use the following formula: ETX=3D 1 / (Df * Dr) where Df is the measured probability that a packet is received by the neighbor and Dr is the measured probability that the acknowledgment packet is successfully received. This document does not mandate the use of a specific formula to compute the ETX value. The ETX object MAY be present in the DAG Metric Container. There MUST be no more than one ETX object as a constraint per DAG Metric Container, and no more than one ETX object as a metric per DAG Metric Container. The ETX object is made of ETX sub-objects and MUST at least comprise one ETX sub-object. Each ETX sub-object has a fixed length of 8 bits. The ETX object does not contain any additional TLV. The ETX object Type is to be assigned by IANA (recommended value=3D7) The format of the ETX object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sub-object) ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: ETX object body format 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: ETX sub-object format ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned integer format, rounded off to the nearest whole number. For example, if ETX =3D 3.569, the object value will be 457. If ETX > 511.9921875, the object value will be the maximum which is 65535. The ETX object may be used as a constraint or a path metric. For example, it may be required that the ETX must not exceed some specified value. In this case, the ETX object common header indicates that the value relates to a constraint. In another example, the ETX object may be used as an aggregated additive metric Vasseur, et al. Expires May 12, 2011 [Page 22] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 where the value is updated along the path to reflect the path quality: when a node receives the aggregated additive ETX value of the path (cummulative path ETX calculated as the sum of the link ETX of all of the traversed links from the advertising node to the DAG root), if it selects that node as its preferred parent, the node updates the path ETX by adding the ETX of the local link between itself and the preferred parent to the received path cost (path ETX) before potentially advertising itself the new path ETX. 4.4. Link Color object 4.4.1. Link Color object description The Link Color (LC) object is an administrative 10-bit link constraint (which may either be static or dynamically adjusted) used to avoid or attract specific links for specific traffic types. The LC object can either be used as a metric or as a constraint. When used as a metric, the LC metric can only be recorded. For example, the DAG may require recording the link colors for all traversed links. Each node can then use the LC to select the parent based on user defined rules (e.g. "select the path with the maximum number of links having their first bit set 1 (e.g. encrypted links)"). The LC object may also be used as a constraint. When used as a recorded metric, a counter is used to compress the information where the number of links for each Link Color is reported. The Link Color (LC) object MAY be present in the DAG Metric Container. There MUST be no more than one LC object as a constraint per DAG Metric Container, and no more than one LC object as a metric per DAG Metric Container. There MUST be a at least one LC sub-object per LC object. The LC object does not contain any additional TLV. The LC object Type is to be assigned by IANA (recommended value=3D8) Vasseur, et al. Expires May 12, 2011 [Page 23] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 The format of the LC object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | LC sub-objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 17: LC object format When the LC object is used as a recorded metric, the LC object body comprises one or more LC Type 1 sub-objects. The format of the LC Type 1 sub-object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Color | Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: LC Type 1 sub-object format When the LC object is used as a constraint, the LC object body comprises one or more LC Type 2 sub-objects. The format of the LC Type 2 sub-object body is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Color |I| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: LC Type 2 sub-object format I Bit: The I bit is only relevant when the Link Color is used as a constraint. When cleared, this indicates that links with the specified color must be included. When set, this indicates that links with the specified color must be excluded. The use of the LC object is outside the scope of this document. 4.4.2. Mode of operation The link color may be used as a constraint or a metric. Vasseur, et al. Expires May 12, 2011 [Page 24] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 o When used as constraint, the LC object may be inserted in the DAG Metric Container to indicate that links with a specific color should be included or excluded from the computed path. o When used as recorded metric, each node along the path may insert a LC object in the DAG Metric Container to report the color of the local link. If there is already a LC object reporting a similar color, the node MUST NOT add another identical LC sub-object and MUST increment the counter field. 5. Computation of dynamic metrics and attributes As already pointed out, dynamically calculated metrics are of the utmost importance in many circumstances in LLNs. This is mainly because a variety of metrics change on a frequent basis, thus implying the need to adapt the routing decisions. That being said, care must be given to the pace at which changes are reported in the network. The attributes will change according to their own time scales. RPL controls the reporting rate. To minimize metric updates, multi-threshold algorithms MAY be used to determine when updates should be sent. When practical, low-pass filtering and/or hysteresis should be used to avoid rapid fluctuations of these values. Finally, although the specification of path computation algorithms using dynamic metrics are out the scope of this document, it is RECOMMENDED to carefully design the route optimization algorithm to avoid too frequent computation of new routes upon metric values changes. Controlled adaptation of the routing metrics and rate at which paths are computed are critical to avoid undesirable routing instabilities resulting in increased latencies and packet loss because of temporary micro-loops. Furthermore, excessive route changes will adversely impact the traffic and power consumption in the network, thus potentially impacting its scalability. 6. IANA Considerations IANA is requested to establish a new top-level registry to contain all Routing Metric/Constraint objects codepoints and sub-registries. The allocation policy for each new registry is by IETF Consensus: new values are assigned through the IETF consensus process (see [RFC5226]). Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group Vasseur, et al. Expires May 12, 2011 [Page 25] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 if one exists). 6.1. Routing Metric/Constraint type IANA is requested to create a registry for Routing Metric/Constraint objects. Each Routing Metric/Constraint object has a type value. Value Meaning Reference 1 Node State and Attribute This document 2 Node Energy This document 3 Hop Count This document 4 Link Throughput This document 5 Link Latency This document 6 Link Quality Level This document 7 Link ETX This document 8 Link Color This document 6.2. Routing Metric/Constraint common header IANA is requested to create a registry to manage the codespace of the A field of the Routing Metric/Constraint common header. Codespace of the A field (Routing Metric/Constraint common header) Value Meaning Reference 0 Routing metric is additive This document 1 Routing metric reports a maximum This document 2 Routing metric reports a minimum This document 3 Routing metric is multiplicative This document IANA is requested to create a registry to manage the Flag field of the Routing Metric/Constraint common header. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: o Bit number o Capability Description o Defining RFC Several bits are defined for the Routing Metric/Constraint common header in this document. The following values have been assigned: Vasseur, et al. Expires May 12, 2011 [Page 26] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 Codespace of the Flag field (Routing Metric/Constraint common header) Bit Description Reference 12-15 Precedence This document 9-11 Additive/Max/Min/Multi This document 8 Recorded/Aggregated This document 7 Optional Constraint This document 6 Constraint/Metric This document 5 P (Partial) This document 6.3. NSA object IANA is requested to create a registry to manage the codespace of the Flag field of the NSA object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: o Bit number o Capability Description o Defining RFC Several bits are defined for the NSA object flag field in this document. The following values have been assigned: Codespace of the Flag field (NSA object) Bit Description Reference 14 Aggregator This document 15 Overloaded This document 6.4. Hop-Count object IANA is requested to create a registry to manage the codespace of the Flag field of the Hop-count object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: o Bit number o Capability Description o Defining RFC No Flag is currently defined. Vasseur, et al. Expires May 12, 2011 [Page 27] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 7. Security considerations Routing metrics should be handled in a secure and trustful manner. For instance, RPL should not allow a malicious node to falsely advertise that it has good metrics for routing, be added as a router for other nodes' traffic and intercept packets. Since the routing metrics/constraints are carried within RPL message, the security routing mechanisms defined in [I-D.ietf-roll-rpl] applies here. 8. Acknowledgements The authors would like to acknowledge the contributions of Young Jae Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter, Mukul Goyal, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads Westergreen, Mukul Goyal and David Culler for their review and valuable comments. 9. References 9.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 9.2. Informative references [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Networks, D., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-14 (work in progress), October 2010. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-04 (work in progress), September 2010. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. Vasseur, et al. Expires May 12, 2011 [Page 28] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010. [Khanna1989J A. Zinky, A. Khanna, and G. Vichniac. "Performance of=20 the Revised Routing Metric for ARPANET and MILNET.=20 Submitted to MILCOM 89, March 1989 Authors' Addresses JP Vasseur (editor) Cisco Systems, Inc 11, Rue Camille Desmoulins Issy Les Moulineaux, 92782 France Email: jpv@cisco.com Mijeom Kim (editor) Corporate Technology Group, KT 17 Woomyeon-dong, Seocho-gu Seoul, 137-792 Korea Email: mjkim@kt.com Vasseur, et al. Expires May 12, 2011 [Page 29] =0C Internet-Draft draft-ietf-roll-routing-metrics-12 November 2010 Kris Pister Dust Networks 30695 Huntwood Ave. Hayward, CA 95544 USA Email: kpister@dustnetworks.com Nicolas Dejean Coronis SAS Espace Concorde, 120 impasse JB Say Perols, 34470 France Email: nicolas.dejean@coronis.com Dominique Barthel France Telecom Orange 28 chemin du Vieux Chene, BP 98 Meylan, 38243 France Email: dominique.barthel@orange-ftgroup.com Vasseur, et al. Expires May 12, 2011 [Page 30] =0C --Apple-Mail-45--389951722-- From Internet-Drafts@ietf.org Tue Nov 9 19:00:07 2010 Return-Path: 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 C006E3A67B7; Tue, 9 Nov 2010 19:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 jRP1woiOLsOS; Tue, 9 Nov 2010 19:00:04 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76FC3A67F3; Tue, 9 Nov 2010 19:00:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101110030003.32415.97405.idtracker@localhost> Date: Tue, 09 Nov 2010 19:00:03 -0800 Cc: roll@ietf.org Subject: [Roll] I-D ACTION:draft-ietf-roll-routing-metrics-12.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: , X-List-Received-Date: Wed, 10 Nov 2010 03:00:07 -0000 --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 : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, M. Kim, K. Pister, N. Dejean, D. Barthel Filename : draft-ietf-roll-routing-metrics-12.txt Pages : 30 Date : 2010-11-9 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-12.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-routing-metrics-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-9185554.I-D@ietf.org> --NextPart-- From jpv@cisco.com Tue Nov 9 21:39:31 2010 Return-Path: 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 B6E003A67D6 for ; Tue, 9 Nov 2010 21:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 x1m1dkn2E1RW for ; Tue, 9 Nov 2010 21:39:28 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ACCE73A635F for ; Tue, 9 Nov 2010 21:39:28 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP++2UyrRN+J/2dsb2JhbACiO3GgDpschUoEhFeFf4MS X-IronPort-AV: E=Sophos;i="4.59,176,1288569600"; d="scan'208";a="617381086" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 10 Nov 2010 05:39:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oAA5dsLJ000026; Wed, 10 Nov 2010 05:39:54 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 21:39:54 -0800 Received: from dhcp-2640.meeting.ietf.org ([10.21.149.152]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 21:39:54 -0800 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <20101110030002.32415.14259.idtracker@localhost> Date: Wed, 10 Nov 2010 13:39:50 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <62BF2F6D-4D62-485C-97AC-2853093C5AB5@cisco.com> References: <20101110030002.32415.14259.idtracker@localhost> To: ROLL WG X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 10 Nov 2010 05:39:54.0248 (UTC) FILETIME=[B3A50880:01CB8099] Cc: draft-ietf-roll-routing-metrics@tools.ietf.org, adrian.farrel@huawei.com, roll-chairs@tools.ietf.org Subject: Re: [Roll] New Version Notification - draft-ietf-roll-routing-metrics-12.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: , X-List-Received-Date: Wed, 10 Nov 2010 05:39:31 -0000 Dear all, Just so you know, this revision -12 is purely editorial, and a = publication request has been sent for that document. Thanks. JP. On Nov 10, 2010, at 11:00 AM, ID Tracker wrote: > New version (-12) has been submitted for = draft-ietf-roll-routing-metrics-12.txt. > = http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-12.txt= >=20 >=20 >=20 > IETF Secretariat. From azdvir@gmail.com Wed Nov 10 03:39:09 2010 Return-Path: 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 C28C93A6A26 for ; Wed, 10 Nov 2010 03:39:09 -0800 (PST) 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 rZGdr-c5-YjZ for ; Wed, 10 Nov 2010 03:39:06 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C4E223A6A91 for ; Wed, 10 Nov 2010 03:39:05 -0800 (PST) Received: by bwz12 with SMTP id 12so745828bwz.31 for ; Wed, 10 Nov 2010 03:39:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=g3oHFuSP5nlrFIrbfOkkPe71l/Xb4fsLQRIp+bMoh0U=; b=FisMRwwo70bjYHiMgHZwhqaCszuZbTfcweUYs8Ji9Hk+m+S0nAa0vKYpmFFS3BWGAe EFLyA/eNLkar3wyrxg6OcTDLf0+hCBnHKqWIzNthZG06GxsHU3mCu6EgOP5SWY8+c/U4 Az4SOt8hnkPT5ixhPa0RjHFZu9eWVPrVdrqsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=xdaNjcvEdxXd65p61paGtDaI01/EZ5NqJYtep6BiQeWVkwBpjAkn+g1Gpp51MCaKIh FGAXofbeDXWy6RnHHFB/gP4fBUJ8gWCb/Kf+4/Tc5YNbuhMpcCv4H3madDoOP9VsvfHT jSIBo5YllBIIcSLMnshn5UKJGcA/P9KVN4RJg= Received: by 10.204.62.17 with SMTP id v17mr7939657bkh.67.1289389170699; Wed, 10 Nov 2010 03:39:30 -0800 (PST) Received: from amitPC (ip146.crysys.hit.bme.hu [152.66.249.146]) by mx.google.com with ESMTPS id v25sm244634bkt.6.2010.11.10.03.39.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Nov 2010 03:39:29 -0800 (PST) From: "amit dvir" To: Date: Wed, 10 Nov 2010 12:39:30 +0100 Message-ID: <009501cb80cb$f0962800$d1c27800$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0096_01CB80D4.525A9000" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuAy+zkASMo4mM+S4WwctA7aIEt8A== Content-Language: he Subject: [Roll] DODAG Version Number 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: , X-List-Received-Date: Wed, 10 Nov 2010 11:39:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0096_01CB80D4.525A9000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, We are a research group implementing the RPL. Regarding the DODAG Version Number, In section 7.2 the example is " For example, if A is 240, and B is 5, then (256 + 5 - 240) is 21. 21 is greater than SEQUENCE_WINDOW (16), thus 240 is greater than 16." 1) thus 240 is greater than 16? Shouldn't it be thus 240 is greater than 5 2) 240 is greater than 5, a. can it really happen in RPL that the version number is restarted? b. Can 240 appear after 5 as a version number? Regards, Dr. Amit Dvir Laboratory of Cryptography and Systems Security (CrySyS) Department of Telecommunications Budapest University of Technology and Economics ------=_NextPart_000_0096_01CB80D4.525A9000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = All,

We are = a research group implementing the RPL.

Regarding the DODAG Version Number,

 

In = section 7.2 the example is 

" For example, =
if A is 240, and B is 5, then (256 + 5 - 240) is 21. 21 is greater than =
SEQUENCE_WINDOW (16), thus 240 is  greater than 16."
 
1)      =
thus 240 is greater than 16? Shouldn’t it be =
thus 240 =
is  greater than 5
2)      =
240 is greater than 5, 
a.       =
can it really happen in RPL that the version number is =
restarted? 
b.      =
Can 240 appear after 5 as a version =
number?
 

Regards,

Dr. = Amit  Dvir

Laboratory of Cryptography and Systems Security = (CrySyS)
Department of Telecommunications
Budapest University of Technology and = Economics

------=_NextPart_000_0096_01CB80D4.525A9000-- From rmarchap@cisco.com Wed Nov 10 17:50:13 2010 Return-Path: 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 9911A3A68B2 for ; Wed, 10 Nov 2010 17:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 WPKPhnzOaRNQ for ; Wed, 10 Nov 2010 17:50:08 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 66EE63A68C5 for ; Wed, 10 Nov 2010 17:50:08 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA/b2kyrR7H+/2dsb2JhbACBcKBNcaQ9m0iFSgSEWokP X-IronPort-AV: E=Sophos;i="4.59,180,1288569600"; d="scan'208,217";a="215288778" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2010 01:50:36 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAB1oarF002894; Thu, 11 Nov 2010 01:50:36 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 17:50:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8142.D5CE2960" Date: Wed, 10 Nov 2010 17:50:33 -0800 Message-ID: <7B822F730F822147977ED5B684ACE4900BE00C97@xmb-sjc-21b.amer.cisco.com> In-Reply-To: <009501cb80cb$f0962800$d1c27800$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DODAG Version Number Thread-Index: AcuAy+zkASMo4mM+S4WwctA7aIEt8AAdlJAg References: <009501cb80cb$f0962800$d1c27800$@com> From: "Rajesh Marchappanavar (rmarchap)" To: "amit dvir" , X-OriginalArrivalTime: 11 Nov 2010 01:50:36.0807 (UTC) FILETIME=[D5FBE170:01CB8142] Subject: Re: [Roll] DODAG Version Number 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: , X-List-Received-Date: Thu, 11 Nov 2010 01:50:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB8142.D5CE2960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of amit dvir Sent: Wednesday, November 10, 2010 5:10 PM To: roll@ietf.org Subject: [Roll] DODAG Version Number =20 Dear All, We are a research group implementing the RPL. Regarding the DODAG Version Number,=20 =20 In section 7.2 the example is=20 " For example, if A is 240, and B is 5, then (256 + 5 - 240) is 21. 21 is greater than SEQUENCE_WINDOW (16), thus 240 is greater than 16." =20 1) thus 240 is greater than 16? Shouldn't it be thus 240 is greater than 5 =20 [RM:] Yes correct. =20 2) 240 is greater than 5,=20 a. can it really happen in RPL that the version number is restarted?=20 =20 =20 [RM:] Yes, when the LBR (root) reboots. =20 b. Can 240 appear after 5 as a version number? =20 [RM:] After a few days of global repairs version number of a DAG might have wrapped around 255 and reached 5 and now the LBR reboots. =20 Cheers, Rajesh =20 Regards, Dr. Amit Dvir Laboratory of Cryptography and Systems Security (CrySyS) =20 Department of Telecommunications =20 Budapest University of Technology and Economics =20 ------_=_NextPart_001_01CB8142.D5CE2960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = amit dvir
Sent: Wednesday, November 10, 2010 5:10 PM
To: roll@ietf.org
Subject: [Roll] DODAG Version Number

 

Dear = All,

We are = a research group implementing the RPL.

Regarding the DODAG Version Number,

 

In = section 7.2 the example is 

" For example, =
if A is 240, and B is 5, then (256 + 5 - 240) is 21. 21 is greater than =
SEQUENCE_WINDOW (16), thus 240 is  greater than 16."
 
1)      =
thus 240 is =
greater than 16? Shouldn’t it be =
thus 240 =
is  greater than 5
 
[RM:] Yes =
correct.
 
2)      =
240 is greater =
than 5, 
a.       =
can it really =
happen in RPL that the version number is restarted? 
 
 
[RM:] Yes, when the =
LBR (root) reboots.
 
b.      =
Can 240 appear after 5 =
as a version number?
 
[RM:] After a few days =
of global repairs version number of a DAG might have wrapped around 255 =
and reached 5 and now the LBR =
reboots.
 
Cheers,
Rajesh
 

Regards,

Dr. = Amit  Dvir

Laboratory of Cryptography and Systems Security = (CrySyS)
Department of Telecommunications
Budapest University of Technology and = Economics

------_=_NextPart_001_01CB8142.D5CE2960-- From ulrich@herberg.name Wed Nov 10 22:13:02 2010 Return-Path: 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 31E823A6A02 for ; Wed, 10 Nov 2010 22:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT-949Y9Sjwb for ; Wed, 10 Nov 2010 22:13:01 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id BB0E03A68A7 for ; Wed, 10 Nov 2010 22:12:57 -0800 (PST) Received: by qyk31 with SMTP id 31so384387qyk.10 for ; Wed, 10 Nov 2010 22:13:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.215.130 with SMTP id he2mr461567qcb.47.1289455997755; Wed, 10 Nov 2010 22:13:17 -0800 (PST) Received: by 10.220.187.140 with HTTP; Wed, 10 Nov 2010 22:13:17 -0800 (PST) Date: Thu, 11 Nov 2010 14:13:17 +0800 Message-ID: From: Ulrich Herberg To: roll WG Content-Type: multipart/alternative; boundary=00163628447cb321810494c0de8d Subject: [Roll] Subnet Gateway Protocol 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: , X-List-Received-Date: Thu, 11 Nov 2010 06:13:02 -0000 --00163628447cb321810494c0de8d Content-Type: text/plain; charset=ISO-8859-1 Hi, I just became aware during the ROLL meeting, that there is a "Subnet Gateway Protocol" contained in RPL, but I did not really find a description of that in the draft (there is some general description in section 1.2, but that still leaves open many questions). A few that came to my mind: - how does the Subnet Gateway Protocol work in detail? - are classical link properties kept? (some being mentioned in RFC 4903) If a node sends a link-local multicast, will all other nodes within the same subnet receive the packets? Without TTL decrement? Is the same prefix on-link for all interfaces on the link? - Is ROLL chartered to include ND/autoconfiguration into RPL? Does it belong in the same spec? Ulrich P.S: I did not find the RPL slides in the "materials" list of the IETF web page. Will they be available for download? --00163628447cb321810494c0de8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I just became aware during the ROLL meeting, that there is a &qu= ot;Subnet Gateway Protocol" contained in RPL, but I did not really fin= d a description of that in the draft (there is some general description in = section 1.2, but that still leaves open many questions). A few that came to= my mind:
=A0 - how does the Subnet Gateway Protocol work in detail?
=A0 - are cla= ssical link properties kept? (some being mentioned in RFC 4903) If a node s= ends a link-local multicast, will all other nodes within the same subnet re= ceive the packets? Without TTL decrement? Is the same prefix on-link for al= l interfaces on the link?
=A0 - Is ROLL chartered to include ND/autoconfiguration into RPL? Does it b= elong in the same spec?


Ulrich

P.S: I did not find the R= PL slides in the "materials" list of the IETF web page. Will they= be available for download?
--00163628447cb321810494c0de8d-- From cabo@tzi.org Wed Nov 10 22:32:46 2010 Return-Path: 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 9A4213A6A0A for ; Wed, 10 Nov 2010 22:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 DcNSF5e55snp for ; Wed, 10 Nov 2010 22:32:45 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 2CAE93A69F5 for ; Wed, 10 Nov 2010 22:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAB6X5Us021995; Thu, 11 Nov 2010 07:33:05 +0100 (CET) Received: from dhcp-67f2.meeting.ietf.org (dhcp-67f2.meeting.ietf.org [130.129.103.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6BAC38FD; Thu, 11 Nov 2010 07:33:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 11 Nov 2010 14:32:59 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ulrich Herberg X-Mailer: Apple Mail (2.1081) Cc: roll WG Subject: Re: [Roll] Subnet Gateway Protocol 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: , X-List-Received-Date: Thu, 11 Nov 2010 06:32:46 -0000 Hi Ulrich, On Nov 11, 2010, at 14:13, Ulrich Herberg wrote: > Hi, >=20 > I just became aware during the ROLL meeting, that there is a "Subnet = Gateway Protocol" contained in RPL, but I did not really find a = description of that in the draft (there is some general description in = section 1.2, but that still leaves open many questions). A few that came = to my mind: > - how does the Subnet Gateway Protocol work in detail? I also don't know what an SGP is. But I do know how 6LoWPAN works and how its subnet is kept together. First of all, I probably don't need to point you to RFC 5889. > - are classical link properties kept? (some being mentioned in RFC = 4903) Not all of them. Because 6LoWPAN is not used for general Internet = access, this is a bit less of a problem than it would be for, say, = laptop Internet access. > If a node sends a link-local multicast, will all other nodes within = the same subnet receive the packets? No. Just the nodes in the radio range. > Without TTL decrement? (N/A) > Is the same prefix on-link for all interfaces on the link? No. (All prefixes are off-link.) > - Is ROLL chartered to include ND/autoconfiguration into RPL? Does = it belong in the same spec?=20 No. =20 No (but that's just my personal technical judgement). Gruesse, Carsten From jpv@cisco.com Thu Nov 11 01:34:35 2010 Return-Path: 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 E88C03A68A3 for ; Thu, 11 Nov 2010 01:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.553 X-Spam-Level: X-Spam-Status: No, score=-110.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 SUeh9BISVx1A for ; Thu, 11 Nov 2010 01:34:34 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5B9403A6873 for ; Thu, 11 Nov 2010 01:34:34 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFZH20yrR7Hu/2dsb2JhbACiQHGkOZtFhUoEhFiGAIMR X-IronPort-AV: E=Sophos;i="4.59,182,1288569600"; d="scan'208";a="379835153" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2010 09:35:03 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oAB9Z3aL010213; Thu, 11 Nov 2010 09:35:03 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 01:35:03 -0800 Received: from dhcp-2640.meeting.ietf.org ([10.21.147.171]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 01:35:02 -0800 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Thu, 11 Nov 2010 17:35:00 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ulrich Herberg X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 11 Nov 2010 09:35:02.0891 (UTC) FILETIME=[B776DBB0:01CB8183] Cc: roll WG Subject: Re: [Roll] Subnet Gateway Protocol 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: , X-List-Received-Date: Thu, 11 Nov 2010 09:34:36 -0000 Let me clarify - This is ONLY a term that was used during the = presentation trying to explain how PIO/RA works in reply to an IESG=20 DISCUSS. We're working on clarifying this soon, but there IS NO CHANGE = is how RPL works. Just clarification. Thanks. JP. On Nov 11, 2010, at 2:13 PM, Ulrich Herberg wrote: > Hi, >=20 > I just became aware during the ROLL meeting, that there is a "Subnet = Gateway Protocol" contained in RPL, but I did not really find a = description of that in the draft (there is some general description in = section 1.2, but that still leaves open many questions). A few that came = to my mind: > - how does the Subnet Gateway Protocol work in detail? > - are classical link properties kept? (some being mentioned in RFC = 4903) If a node sends a link-local multicast, will all other nodes = within the same subnet receive the packets? Without TTL decrement? Is = the same prefix on-link for all interfaces on the link? > - Is ROLL chartered to include ND/autoconfiguration into RPL? Does = it belong in the same spec?=20 >=20 >=20 > Ulrich >=20 > P.S: I did not find the RPL slides in the "materials" list of the IETF = web page. Will they be available for download? > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From dominique.barthel@orange-ftgroup.com Thu Nov 11 02:58:58 2010 Return-Path: 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 CDD3428C0ED for ; Thu, 11 Nov 2010 02:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 v1HRCZhzMJyP for ; Thu, 11 Nov 2010 02:58:57 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 3D0C03A689C for ; Thu, 11 Nov 2010 02:58:57 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 051BF760001 for ; Thu, 11 Nov 2010 12:03:44 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id E42777D8001 for ; Thu, 11 Nov 2010 12:03:43 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 11:59:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB818F.811E2EFE" Date: Thu, 11 Nov 2010 11:58:05 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF01CCA97E@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2P drafts Thread-Index: AcuBj1EK6wyAPjnbRCejZOirLzHfxw== From: To: X-OriginalArrivalTime: 11 Nov 2010 10:59:26.0248 (UTC) FILETIME=[8175D280:01CB818F] Subject: [Roll] P2P drafts 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: , X-List-Received-Date: Thu, 11 Nov 2010 10:58:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB818F.811E2EFE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Emmanuel, all Following your plea for feedback at the meeting today, here are some observations that occured to me while reading the two drafts: "p2p-rpl" and "p2p-measurement" Best, Dominique ------------------------ 1) "p2p-rpl" draft Section 5.2 page 10: you specify that one or more DMCs must be placed before the Route Discovery option and one or more after the RD. This implies that ordering of the options in the DIO must be maintained as DIOs are propagated in the network. We add a similar ordering requirement in the metrics draft earlier on, and it was considered an issue. If you maintain the idea of having differentiated propagation constraints and route constraints, I would suggest differentiating them explicitely. For example, there are still some bits available in the DMC format. Section 5.6 on page 13: <> In what I assume to be the frequent case, aggregated metric), the comparison between routes does not need to resort to the OF. The DMC contains all what is needed to compare route costs. If there is a single (aggregated) metric in use, lower is better or higher is better, depending on which metric we talk about. If there are multiple metrics in use, the precedence is provided in the DMC as well. Only in the case of recorded metrics does the OF intervene. That's the very reason for recorded metrics: plan ahead for cases where none of addition/multiplication/max/min would fit the application needs. However, the OF may decide when a node thinks it has gathered suffisant information to make a final decision. Therefore, I would recommend to write <> =20 Page 9: just curious about the values represented by the L field. They increase in uneven factors (2 to 10). Why not just buinary increase in seconds? Nit on page 19: s/complimentary/complementary/ 2) "p2p-measurement" draft Section 3 on page 5: Metric Container Options. I'm not sure whether you are referring to a Dag Metric Container, including its (Type=3D2,Length) header, or to a Routing Metric/Constraint object, starting with the Routing-MC-Type field. I assume the latter. Section 7 on page 11 <> If a metric was recorded instead of being aggregated enroute, then the A field in the DMC is meaning less. The computation that takes place at the end node to gauge of the quality of the path is defined in the Objective Function defined by the OCP. Therefore, I would recommend writing <> ------_=_NextPart_001_01CB818F.811E2EFE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable P2P drafts

Hello Emmanuel, all

Following your plea for feedback at the = meeting today, here are some observations that occured to me while = reading the two drafts: "p2p-rpl" and = "p2p-measurement"

Best,

Dominique

------------------------

1) "p2p-rpl" draft
Section 5.2 page 10: you specify that = one or more DMCs must be placed before the Route Discovery option and = one or more after the RD. This implies that ordering of the options in = the DIO must be maintained as DIOs are propagated in the network. We add = a similar ordering requirement in the metrics draft earlier on, and it = was considered an issue.

If you maintain the idea of having = differentiated propagation constraints and route constraints, I would = suggest differentiating them explicitely. For example, there are still = some bits available in the DMC format.

Section 5.6 on page 13: = <<selecting the "n" best good enough routes (using the = OCP specified in the Route Discovery option to do the = comparison)>>

In what I assume to be the frequent = case, aggregated metric), the comparison between routes does not need to = resort to the OF. The DMC contains all what is needed to compare route = costs. If there is a single (aggregated) metric in use, lower is better = or higher is better, depending on which metric we talk about. If there = are multiple metrics in use, the precedence is provided in the DMC as = well. Only in the case of recorded metrics does the OF intervene. That's = the very reason for recorded metrics: plan ahead for cases where none of = addition/multiplication/max/min would fit the application = needs.

However, the OF may decide when a node = thinks it has gathered suffisant information to make a final = decision.
Therefore, I would recommend to = write
<<selecting the "n" = best good enough routes discovered over a certain time period, = potentially using the OF specified in the Route Discovery = option.>>

 
Page 9: just curious about the values = represented by the L field. They increase in uneven factors (2 to 10). = Why not just buinary increase in seconds?

Nit on page 19: = s/complimentary/complementary/

2) "p2p-measurement" = draft
Section 3 on page 5: Metric Container = Options. I'm not sure whether you are referring to a Dag Metric = Container, including its (Type=3D2,Length) header, or to a Routing = Metric/Constraint object, starting with the Routing-MC-Type field. I = assume the latter.

Section 7 on page 11
<<If a routing metric object = contains local metric values recorded by enroute nodes, the origin node = MAY aggregate these local values into an end-to-end value as per the = aggregation rules for the metric.>>

If a metric was recorded instead of = being aggregated enroute, then the A field in the DMC is meaning less. = The computation that takes place at the end node to gauge of the quality = of the path is defined in the Objective Function defined by the = OCP.

Therefore, I would recommend = writing
<<If a routing metric object = contains local metric values recorded by enroute nodes, the origin node = MAY compute an end-to-end value out of these local values as per the = objective function in use.>>

------_=_NextPart_001_01CB818F.811E2EFE-- From prvs=9247ee8b5=mukul@uwm.edu Thu Nov 11 09:10:30 2010 Return-Path: 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 6CFE43A68AC for ; Thu, 11 Nov 2010 09:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, 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 aBPoefA2J2Np for ; Thu, 11 Nov 2010 09:10:22 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 4AA923A6822 for ; Thu, 11 Nov 2010 09:10:22 -0800 (PST) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 11 Nov 2010 11:10:52 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 9ED252B3F08; Thu, 11 Nov 2010 11:09:30 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d292m3xV+Hjh; Thu, 11 Nov 2010 11:09:30 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 365EF2B3F05; Thu, 11 Nov 2010 11:09:30 -0600 (CST) Date: Thu, 11 Nov 2010 11:10:51 -0600 (CST) From: Mukul Goyal To: dominique barthel Message-ID: <213048833.1488182.1289495451290.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF01CCA97E@ftrdmel0.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] P2P drafts 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: , X-List-Received-Date: Thu, 11 Nov 2010 17:10:30 -0000 Hi Dominique Thanks for your comments. Please see inline. [Dominique] 1) "p2p-rpl" draft Section 5.2 page 10: you specify that one or more DMCs must be placed before the Route Discovery option and one or more after the RD. This implies that ordering of the options in the DIO must be maintained as DIOs are propagated in the network. We add a similar ordering requirement in the metrics draft earlier on, and it was considered an issue. If you maintain the idea of having differentiated propagation constraints and route constraints, I would suggest differentiating them explicitely. For example, there are still some bits available in the DMC format. [Mukul] Would it make sense to directly include a DAG Metric Container for "route constraints" inside Route Discovery option? I guess we dont want P2P concepts to affect core definitions. [Dominique] Section 5.6 on page 13: <> In what I assume to be the frequent case, aggregated metric), the comparison between routes does not need to resort to the OF. The DMC contains all what is needed to compare route costs. If there is a single (aggregated) metric in use, lower is better or higher is better, depending on which metric we talk about. If there are multiple metrics in use, the precedence is provided in the DMC as well. Only in the case of recorded metrics does the OF intervene. That's the very reason for recorded metrics: plan ahead for cases where none of addition/multiplication/max/min would fit the application needs. However, the OF may decide when a node thinks it has gathered suffisant information to make a final decision. Therefore, I would recommend to write <> [Mukul] I am fine with this change. [Dominique] Page 9: just curious about the values represented by the L field. They increase in uneven factors (2 to 10). Why not just buinary increase in seconds? [Mukul] These values were considered most useful by us. I would be OK with taking some of the reserved bits and allowing specification of the minimum life time as the exponent of 2 in units of seconds. [Dominique] Nit on page 19: s/complimentary/complementary/ [Mukul] Thanks. [Dominique] 2) "p2p-measurement" draft Section 3 on page 5: Metric Container Options. I'm not sure whether you are referring to a Dag Metric Container, including its (Type=2,Length) header, or to a Routing Metric/Constraint object, starting with the Routing-MC-Type field. I assume the latter. [Mukul] This is referring to Dag Metric Container. Can a Routing Metric/Constraint object exist outside a DMC?? [Dominique] Section 7 on page 11 <> If a metric was recorded instead of being aggregated enroute, then the A field in the DMC is meaning less. The computation that takes place at the end node to gauge of the quality of the path is defined in the Objective Function defined by the OCP. Therefore, I would recommend writing <> [Mukul] Thanks for this correction. Thanks Mukul _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From sdhags@gmail.com Thu Nov 11 09:11:49 2010 Return-Path: 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 A27223A69E9 for ; Thu, 11 Nov 2010 09:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 UOab-JaY5oDj for ; Thu, 11 Nov 2010 09:11:47 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 9B41C3A68AC for ; Thu, 11 Nov 2010 09:11:45 -0800 (PST) Received: by qyk33 with SMTP id 33so882102qyk.10 for ; Thu, 11 Nov 2010 09:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=zv/P/HAIpcoP5vFE5IzK5FZ7oNs/9tJpSC6i7b07Kmk=; b=go0mzWUpti6rjYI5VLvBxUF944uJIuGqPq1VuUZQ+gnLOfEH4gTmp7/AVRtniTlFI5 a6DYN3a90nkXI37FbE+jsVwPh/YEW8weGOKlVlf50Ja//2W/Xh6qizM/wsNdNOAMFeyi /MYBYOJ9GumX6hlTxfJmB3HiYk2KEvfvpYvuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=XzZ1lZiKOZg/26kMB5kxp31lOK57L021o9wwF4G+bTx1M8JfXmls3RQe3xRFFGwljW 2tQpID4i/HoiBtoNjilIq3S2OqyRtV5EcAyYk7zWjVlMaVeR/agW8fwE8PjzdNvYUqye cX1vjEcHk9qkWcASk5Q3H7YpB+KOHUwg1cvSg= Received: by 10.229.233.19 with SMTP id jw19mr998301qcb.7.1289495535603; Thu, 11 Nov 2010 09:12:15 -0800 (PST) MIME-Version: 1.0 Sender: sdhags@gmail.com Received: by 10.229.211.199 with HTTP; Thu, 11 Nov 2010 09:11:55 -0800 (PST) From: Stephen Dawson-Haggerty Date: Thu, 11 Nov 2010 09:11:55 -0800 X-Google-Sender-Auth: Bw8zDEsS1pVeUYRG7MXWYFKAf5M Message-ID: To: ROLL WG Content-Type: text/plain; charset=UTF-8 Subject: [Roll] Non-storing mode address types 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: , X-List-Received-Date: Thu, 11 Nov 2010 17:11:49 -0000 Hi -- trying to figure out how to construct downward source routes using DAOs. The 6lowpan-nd draft says that "All other prefixes are assumed to be off-link ... They are therefore sent to one of the routers in the Default Router List." This presumably means up, not down, so the addresses in the routing header wold need to be link local? It seems more likely that RPL wanted them to be global, though? Related, the target option in the DAO specifies a global address, of course; it looks like the parent address is also a global address. This is what leads to my confusion about the source route because while you can construct a path of global addresses, I must be missing how the intermediate hops can resolve the next hops of the addresses. If the parent addresses were link-local, I think it would work, so long as the originating DAO also included a SLLA option; then the path would be composed of only link-layer addresses. This seems a little strange, though. I looked in 6.7.8 and 9 for guidance on this, but am still confused... Thanks, Steve -- stephen dawson-haggerty http://cs.berkeley.edu/~stevedh uc berkeley wireless and embedded systems lab berkeley, ca 94720 From pal@cs.stanford.edu Thu Nov 11 11:24:41 2010 Return-Path: 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 92E123A68BD for ; Thu, 11 Nov 2010 11:24:41 -0800 (PST) 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 bLkZ2VdnVn7c for ; Thu, 11 Nov 2010 11:24:40 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 853EC3A6853 for ; Thu, 11 Nov 2010 11:24:40 -0800 (PST) Received: from dn0a21026e.sunet ([10.33.2.110]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PGclh-0001Xi-Qp; Thu, 11 Nov 2010 11:25:11 -0800 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis X-Priority: 3 In-Reply-To: Date: Thu, 11 Nov 2010 11:25:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrian Farrel X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 72fea6e5439bae575da00cf3f782b6e6 Cc: draft-ietf-roll-trickle@tools.ietf.org, roll@ietf.org Subject: Re: [Roll] AD review of draft-ietf-roll-trickle-04 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: , X-List-Received-Date: Thu, 11 Nov 2010 19:24:41 -0000 Adrian, I've just submitted version -05 of the draft, which tries to address all = of your comments. The security considerations section does not have any = RECOMMEND statements, but rather instead just has a few comments on ways = in which an adversary might try to subvert the algorithm, and how = protocols might protect against such. Phil On Oct 9, 2010, at 4:09 AM, Adrian Farrel wrote: > I have performed an AD review of your draft. >=20 > Don't panic! >=20 > I review all drafts that I am responsible for before putting them = forward for IETF last call. The main objective is to catch nits and = minor issues that would show up during the last call or in IESG review. = The intention is to help polish your document and make sure > it is clean and shiny so that other reviewers will stick to the = technical details. >=20 > Thanks you for a really well-written and clear document. Excellent = work! >=20 > On reviewing it, there are a couple of small points I think it would = be helpful to sort out to ensure complete understanding from all your = readers. I'd like to see a quick respin of the document before I issue = the IETF last call. As soon as I see a new revision posted, I'll set the = ball in motion. >=20 > Of course, all of my issues are up for discussion. >=20 > Thanks for the work, > Adrian >=20 > --- >=20 > idnits (http://tools.ietf.org/tools/idnits/) reports >=20 > =3D=3D You're using the IETF Trust Provisions' Section 6.b License = Notice > from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. > (See http://trustee.ietf.org/license-info/) >=20 > Can you fix this, plase. >=20 > --- >=20 > Good that you pulled "trickle communication rate" out for attention as = a term. Could you also pull out "trickle transmission rate"? >=20 > --- >=20 > In section 3 >=20 > The Trickle > algorithm balances the load in such a scenario, as each node's > Trickle transmission rate is 1/nth of the Trickle communication rate. > Sparser networks require more transmissions per node, but utilization > of the radio channel over space will not increase. >=20 > No issues with the facts. > But this is the first mention of radio channels. Up to this point we = would have been quite happy thinking of fixed-line connectivity. > Can you tweak something? >=20 > --- >=20 > Section 4.1 >=20 > o The maximum interval size is described as a number of doublings of > the minimum interval size (the base-2 log(max/min)). For example, > a protocol might define the maximum interval as 16. If the > minimum interval is 100ms, then the maximum interval is 100ms * > 65536, 6,553.6 seconds, or approximately 109 minutes. >=20 > There is a slight discrepency in terminology here, and a little = tidying that could be done to the expression of the example. >=20 > The problem comes that you have "maximum interval sixe" as a number of = doublings, but you are also trying to state the amount of time it = implies. >=20 > Can I suggest... >=20 > o The maximum interval size is described as a number of doublings of > the minimum interval size (the base-2 log(max/min)). For example, > a protocol might define the maximum interval size as 16. If the > minimum interval size is 100ms, then the amount of time specified > by the maximum interval size of 16 is > 100ms * 2^16 =3D 6,553.6 seconds > or approximately 109 minutes. >=20 > A similar terminology problem shows up in 6.2 >=20 > Note that mismatched Imin values and matching > Imax doubling constants will lead to mismatched Imax values. >=20 > Can you go through the document and decide whether Imax is the = doubling constant or the time period. >=20 > --- >=20 > Section 4.2 >=20 > 5. If Trickle hears a transmission that is "inconsistent," the > Trickle timer resets. If I is greater than Imin, resetting a > Trickle timer sets I to Imin and begins a new interval. If I is > equal to Imin, resetting a Trickle timer does nothing. Trickle > can also reset the timer in response to external "events." >=20 > If "resetting a Trickle timer does nothing", how can you justify the = word "reset"? Doesn't a new interval always start when the timer is > reset? Or are you saying that the timer restarts, but the counter is = not reset to zero? >=20 > --- >=20 > Section 6.1 >=20 > OLD > Hence, the danger of > mismatched k values is uneven transmission load that can deplete the > energy of some nodes. > NEW > Hence, the danger of > mismatched k values is uneven transmission load that can deplete the > energy of some nodes in a lower-power network. > END >=20 > ...because there is no specific limitation to apply this to low-power = networks.. >=20 > --- >=20 > Section 6.5 >=20 > having the parameter describe (k-1) >=20 > Do you mean k=3D-1 ? >=20 > --- >=20 > Section 6.6 >=20 > Finally, a protocol SHOULD set k and Imin such that Imin is at least > two to three as long as it takes to transmit k packets. >=20 > s/three as/three times as/ >=20 > --- >=20 > Section 9 >=20 > I am worried about this section being so empty. I don't think the = algorithm needs any security work, but I do think that you can give = advice on the security implications for protocols that use the = algorithm. >=20 > For example, what would be the impact of a false positive or a false = negative? Given that impact, what precautions should a protocol that = uses Trickle take? >=20 > For example, in Section 6 you have: >=20 > It is RECOMMENDED that a protocol which uses Trickle include > mechanisms to inform nodes of configuration parameters at runtime. >=20 > What would happen if these mecahnisms were attacked? >=20 > In short, can you add some RECOMMENDations about what protocols that = use Trickle shold consider in their specifications. >=20 From Internet-Drafts@ietf.org Thu Nov 11 11:30:03 2010 Return-Path: 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 1D9C83A68BD; Thu, 11 Nov 2010 11:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 2bZZGH1Mniu5; Thu, 11 Nov 2010 11:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225EE3A6887; Thu, 11 Nov 2010 11:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101111193002.28642.48580.idtracker@localhost> Date: Thu, 11 Nov 2010 11:30:02 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-trickle-05.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: , X-List-Received-Date: Thu, 11 Nov 2010 19:30:03 -0000 --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 : The Trickle Algorithm Author(s) : P. Levis, et al. Filename : draft-ietf-roll-trickle-05.txt Pages : 13 Date : 2010-11-11 The Trickle algorithm allows nodes in a lossy shared medium (e.g., low power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-05.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-trickle-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-11112241.I-D@ietf.org> --NextPart-- From culler@cs.berkeley.edu Thu Nov 11 13:22:31 2010 Return-Path: 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 F00D83A6A71 for ; Thu, 11 Nov 2010 13:22:31 -0800 (PST) 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 JQ8ZPOANYHhG for ; Thu, 11 Nov 2010 13:22:31 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 2ACDA3A6A5E for ; Thu, 11 Nov 2010 13:22:31 -0800 (PST) Received: from [10.111.50.156] (adsl-67-117-89-242.dsl.sntc01.pacbell.net [67.117.89.242]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id oABLMWsd018496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Nov 2010 13:22:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: Date: Thu, 11 Nov 2010 13:22:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <484090EF-9061-4739-B222-A9130CF9E79A@cs.berkeley.edu> References: To: JP Vasseur X-Mailer: Apple Mail (2.1081) Cc: roll WG Subject: Re: [Roll] Subnet Gateway Protocol 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: , X-List-Received-Date: Thu, 11 Nov 2010 21:22:32 -0000 Indeed, the RPL document is what defines the protocol. It does not = contain a "subnet gateway protocol". On Nov 11, 2010, at 1:35 AM, JP Vasseur wrote: > Let me clarify - This is ONLY a term that was used during the = presentation trying to explain how PIO/RA works in reply to an IESG=20 > DISCUSS. We're working on clarifying this soon, but there IS NO CHANGE = is how RPL works. Just clarification. >=20 > Thanks. >=20 > JP. >=20 > On Nov 11, 2010, at 2:13 PM, Ulrich Herberg wrote: >=20 >> Hi, >>=20 >> I just became aware during the ROLL meeting, that there is a "Subnet = Gateway Protocol" contained in RPL, but I did not really find a = description of that in the draft (there is some general description in = section 1.2, but that still leaves open many questions). A few that came = to my mind: >> - how does the Subnet Gateway Protocol work in detail? >> - are classical link properties kept? (some being mentioned in RFC = 4903) If a node sends a link-local multicast, will all other nodes = within the same subnet receive the packets? Without TTL decrement? Is = the same prefix on-link for all interfaces on the link? >> - Is ROLL chartered to include ND/autoconfiguration into RPL? Does = it belong in the same spec?=20 >>=20 >>=20 >> Ulrich >>=20 >> P.S: I did not find the RPL slides in the "materials" list of the = IETF web page. Will they be available for download? >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll David Culler culler@cs.berkeley.edu Chair Computer Science Associate Chair EECS From coflynn@newae.com Thu Nov 11 14:35:17 2010 Return-Path: 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 087903A6358 for ; Thu, 11 Nov 2010 14:35:17 -0800 (PST) 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 L5DPGSGE3yRW for ; Thu, 11 Nov 2010 14:35:12 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id EC73B3A68E0 for ; Thu, 11 Nov 2010 14:35:11 -0800 (PST) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1PGfk5-0000be-NJ; Thu, 11 Nov 2010 17:35:42 -0500 From: "Colin O'Flynn" To: "'Stephen Dawson-Haggerty'" , "'ROLL WG'" References: In-Reply-To: Date: Thu, 11 Nov 2010 22:35:16 -0000 Message-ID: <003e01cb81f0$b9425f60$2bc71e20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuBw5pyvY9PT24JTRaJ1pd+XEfCrQAK7m2g Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Roll] Non-storing mode address types 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: , X-List-Received-Date: Thu, 11 Nov 2010 22:35:17 -0000 Hi Steve, That exact problem you mention was discussed on the 6LoWPAN mailing list. If you follow the way the standards are written, it won't work since global addresses are 'off-link' and you can never reach them! How it can be accomplished though use of the neighbor cache & NUD to determine if a link is reachable or not. The point of assuming the prefix is off-link is so you don't send NS for an unreachable node, but instead send to the default router. But if you have NC entries, you should consider the nodes on-link. See section 6.5.4 of 6lowpan-nd-14. Another method is just to always assume a node which you have received a downward source route to is reachable. Presumably RPL is taking care of ensuring that node is actually registered through you, so if you got a message which indicates the next-hop is that node, it should be reachable. HTH, -Colin O'Flynn -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Stephen Dawson-Haggerty Sent: November 11, 2010 5:12 PM To: ROLL WG Subject: [Roll] Non-storing mode address types Hi -- trying to figure out how to construct downward source routes using DAOs. The 6lowpan-nd draft says that "All other prefixes are assumed to be off-link ... They are therefore sent to one of the routers in the Default Router List." This presumably means up, not down, so the addresses in the routing header wold need to be link local? It seems more likely that RPL wanted them to be global, though? Related, the target option in the DAO specifies a global address, of course; it looks like the parent address is also a global address. This is what leads to my confusion about the source route because while you can construct a path of global addresses, I must be missing how the intermediate hops can resolve the next hops of the addresses. If the parent addresses were link-local, I think it would work, so long as the originating DAO also included a SLLA option; then the path would be composed of only link-layer addresses. This seems a little strange, though. I looked in 6.7.8 and 9 for guidance on this, but am still confused... Thanks, Steve -- stephen dawson-haggerty http://cs.berkeley.edu/~stevedh uc berkeley wireless and embedded systems lab berkeley, ca 94720 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From sdhags@gmail.com Thu Nov 11 14:46:34 2010 Return-Path: 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 12F8B3A6A69 for ; Thu, 11 Nov 2010 14:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 bfV2hqsbLLD4 for ; Thu, 11 Nov 2010 14:46:32 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id BB3323A67C3 for ; Thu, 11 Nov 2010 14:46:28 -0800 (PST) Received: by qwb7 with SMTP id 7so2513292qwb.31 for ; Thu, 11 Nov 2010 14:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=PMAex9c2M2tORwP1nIw411gmPFi6oXM0OqSJYxJ0gAw=; b=naC09lviT3JlW+yTfXjh86AteArOnKb9c4NB/8GeIGFgS3si0ZBlzfTDLQXOUYOf10 fiQAA9lANJgCFOTtFQ6S0lYHUJ9uLPNcixE5CnZiIz1Da+NksSwAwqq0yo8Z4kjzeB1r a9xFd/9xaNsGEQCJ/P9/yMbGlXfiITiJL4KSs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=lx5T4wV8ZqGtoAEHUlmWKhkZxdjyLGiLKID5Qg5EOvRyqOFfTzbBPwxYQamo99cToq JiIZ87TpTWjbTidOlk1SvrfVQtOpMGpUAFdXHmp3rasaxnGq3Wx52t1SpGSzu7dYnyQ4 4nk/wO66HknVcFIPfBqD6nSX3YhAwYQIviNp4= Received: by 10.229.183.21 with SMTP id ce21mr1250395qcb.197.1289515619332; Thu, 11 Nov 2010 14:46:59 -0800 (PST) MIME-Version: 1.0 Sender: sdhags@gmail.com Received: by 10.229.211.199 with HTTP; Thu, 11 Nov 2010 14:46:39 -0800 (PST) In-Reply-To: <003e01cb81f0$b9425f60$2bc71e20$@com> References: <003e01cb81f0$b9425f60$2bc71e20$@com> From: Stephen Dawson-Haggerty Date: Thu, 11 Nov 2010 14:46:39 -0800 X-Google-Sender-Auth: hnXJZrBBU5-qCvTXikNCVc-BQ8o Message-ID: To: "Colin O'Flynn" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ROLL WG Subject: Re: [Roll] Non-storing mode address types 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: , X-List-Received-Date: Thu, 11 Nov 2010 22:46:34 -0000 Ahh -- I only checked the roll mailing list archives... I don't really like the idea of keeping a neighbor cache for the downstream nodes, since it seems like it partially defeats the point of being "non-storing"; although you only would need one-hop neighbors that could still be a large set and you don't know which ones. I thought about just assuming it's on-link, but in that case we'll need to require that there is a mapping from the global address to the LL address. I think this will be mostly true, but seems like either RPL or 6lowpan should explicitly require it. It's also a little strange, I think, to make an exception and say that "other addresses are off link, unless they're in a routing header." Anyways, I'll go scan those 6lowpan archives, thanks for the clarification. Steve On Thu, Nov 11, 2010 at 2:35 PM, Colin O'Flynn wrote: > Hi Steve, > > That exact problem you mention was discussed on the 6LoWPAN mailing list.= If > you follow the way the standards are written, it won't work since global > addresses are 'off-link' and you can never reach them! > > How it can be accomplished though use of the neighbor cache & NUD to > determine if a link is reachable or not. The point of assuming the prefix= is > off-link is so you don't send NS for an unreachable node, but instead sen= d > to the default router. But if you have NC entries, you should consider th= e > nodes on-link. See section 6.5.4 of 6lowpan-nd-14. > > Another method is just to always assume a node which you have received a > downward source route to is reachable. Presumably RPL is taking care of > ensuring that node is actually registered through you, so if you got a > message which indicates the next-hop is that node, it should be reachable= . > > HTH, > > =C2=A0-Colin O'Flynn > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Stephen Dawson-Haggerty > Sent: November 11, 2010 5:12 PM > To: ROLL WG > Subject: [Roll] Non-storing mode address types > > Hi -- trying to figure out how to construct downward source routes using > DAOs. > > The 6lowpan-nd draft says that "All other prefixes are assumed to be > off-link ... They are therefore sent to one of the routers in the > Default Router List." =C2=A0This presumably means up, not down, so the > addresses in the routing header wold need to be link local? =C2=A0It seem= s > more likely that RPL wanted them to be global, though? > > Related, the target option in the DAO specifies a global address, of > course; it looks like the parent address is also a global address. > This is what leads to my confusion about the source route because > while you can construct a path of global addresses, I must be missing > how the intermediate hops can resolve the next hops of the addresses. > > If the parent addresses were link-local, I think it would work, so > long as the originating DAO also included a SLLA option; then the path > would be composed of only link-layer addresses. This seems a little > strange, though. I looked in 6.7.8 =C2=A0and 9 for guidance on this, but = am > still confused... > > Thanks, > Steve > > -- > stephen dawson-haggerty > http://cs.berkeley.edu/~stevedh > uc berkeley wireless and embedded systems lab > berkeley, ca 94720 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --=20 stephen dawson-haggerty http://cs.berkeley.edu/~stevedh uc berkeley wireless and embedded systems lab berkeley, ca 94720 From jonhui@cisco.com Thu Nov 11 15:49:01 2010 Return-Path: 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 EF1C63A67A3 for ; Thu, 11 Nov 2010 15:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 81UvLJvvyeyJ for ; Thu, 11 Nov 2010 15:49:00 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C06413A679F for ; Thu, 11 Nov 2010 15:49:00 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEMP3EyrR7Hu/2dsb2JhbACiSnGmJpsghUoEhFqFfosV X-IronPort-AV: E=Sophos;i="4.59,185,1288569600"; d="scan'208";a="215864132" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2010 23:49:32 +0000 Received: from sjc-vpn4-1135.cisco.com (sjc-vpn4-1135.cisco.com [10.21.84.110]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oABNnUqp013564; Thu, 11 Nov 2010 23:49:31 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: Date: Thu, 11 Nov 2010 15:49:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <003e01cb81f0$b9425f60$2bc71e20$@com> To: Stephen Dawson-Haggerty X-Mailer: Apple Mail (2.1082) Cc: ROLL WG Subject: Re: [Roll] Non-storing mode address types 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: , X-List-Received-Date: Thu, 11 Nov 2010 23:49:02 -0000 Steve, You can make the on-link assumption when using the RPL routing header. = Section 4.2 of draft-ietf-6man-rpl-routing-header requires routers to = ensure that the next entry is on-link. If the next entry is not = on-link, the router must drop the packet. BTW, I'm not convinced that using 6lowpan-nd between RPL routers even = the right approach. The current 6lowpan-nd spec is primarily focused on = the host-router interface, which makes much more sense to me than = applying the same protocol for router-router interfaces. -- Jonathan Hui On Nov 11, 2010, at 2:46 PM, Stephen Dawson-Haggerty wrote: > Ahh -- I only checked the roll mailing list archives... I don't really > like the idea of keeping a neighbor cache for the downstream nodes, > since it seems like it partially defeats the point of being > "non-storing"; although you only would need one-hop neighbors that > could still be a large set and you don't know which ones. >=20 > I thought about just assuming it's on-link, but in that case we'll > need to require that there is a mapping from the global address to the > LL address. I think this will be mostly true, but seems like either > RPL or 6lowpan should explicitly require it. It's also a little > strange, I think, to make an exception and say that "other addresses > are off link, unless they're in a routing header." >=20 > Anyways, I'll go scan those 6lowpan archives, thanks for the = clarification. >=20 > Steve >=20 > On Thu, Nov 11, 2010 at 2:35 PM, Colin O'Flynn = wrote: >> Hi Steve, >>=20 >> That exact problem you mention was discussed on the 6LoWPAN mailing = list. If >> you follow the way the standards are written, it won't work since = global >> addresses are 'off-link' and you can never reach them! >>=20 >> How it can be accomplished though use of the neighbor cache & NUD to >> determine if a link is reachable or not. The point of assuming the = prefix is >> off-link is so you don't send NS for an unreachable node, but instead = send >> to the default router. But if you have NC entries, you should = consider the >> nodes on-link. See section 6.5.4 of 6lowpan-nd-14. >>=20 >> Another method is just to always assume a node which you have = received a >> downward source route to is reachable. Presumably RPL is taking care = of >> ensuring that node is actually registered through you, so if you got = a >> message which indicates the next-hop is that node, it should be = reachable. >>=20 >> HTH, >>=20 >> -Colin O'Flynn >>=20 >>=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of >> Stephen Dawson-Haggerty >> Sent: November 11, 2010 5:12 PM >> To: ROLL WG >> Subject: [Roll] Non-storing mode address types >>=20 >> Hi -- trying to figure out how to construct downward source routes = using >> DAOs. >>=20 >> The 6lowpan-nd draft says that "All other prefixes are assumed to be >> off-link ... They are therefore sent to one of the routers in the >> Default Router List." This presumably means up, not down, so the >> addresses in the routing header wold need to be link local? It seems >> more likely that RPL wanted them to be global, though? >>=20 >> Related, the target option in the DAO specifies a global address, of >> course; it looks like the parent address is also a global address. >> This is what leads to my confusion about the source route because >> while you can construct a path of global addresses, I must be missing >> how the intermediate hops can resolve the next hops of the addresses. >>=20 >> If the parent addresses were link-local, I think it would work, so >> long as the originating DAO also included a SLLA option; then the = path >> would be composed of only link-layer addresses. This seems a little >> strange, though. I looked in 6.7.8 and 9 for guidance on this, but = am >> still confused... >>=20 >> Thanks, >> Steve >>=20 >> -- >> stephen dawson-haggerty >> http://cs.berkeley.edu/~stevedh >> uc berkeley wireless and embedded systems lab >> berkeley, ca 94720 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >=20 >=20 >=20 > --=20 > stephen dawson-haggerty > http://cs.berkeley.edu/~stevedh > uc berkeley wireless and embedded systems lab > berkeley, ca 94720 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From sdhags@gmail.com Thu Nov 11 15:58:14 2010 Return-Path: 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 B54AD28C0F4 for ; Thu, 11 Nov 2010 15:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 wsyFEO3TNBD8 for ; Thu, 11 Nov 2010 15:58:13 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 167473A635F for ; Thu, 11 Nov 2010 15:58:13 -0800 (PST) Received: by qyk8 with SMTP id 8so50113qyk.10 for ; Thu, 11 Nov 2010 15:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=7voNz2wW+IGuS4+pJxZEf04zbUNF4YZxDad0BFefguI=; b=Mfe6IoQc0KbrYg7SqU0xbDWpgPkWhwhEGdv26v7SxwLwbSCNj9CGWCjmxEPM3fGYxs FD0pTS/mhU1Qd9QJoU+hqpeLUTinryR1Sxco22YQ1V2U3sF9RhLu06gLcGwGj11GvGUY +INgoiPB/RKe1W0hj2np3O4qxpRGsDJOeQCWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=YBWREjcoz6sR244D7teF7tDlMTToZt28qrrNRbLTJ7G140l5jhG2Ta1mvRe98LaChN QDos7I+fB7FSINTbKsVKFabR5ysXL+9adPGIKJyCaKs0zf082VkMGLtmx/nyhrtrVhyA O+YRW7mEjD47oWG6iq4OztOFOhaj/ATE/MPdY= Received: by 10.229.222.65 with SMTP id if1mr1311728qcb.159.1289519923815; Thu, 11 Nov 2010 15:58:43 -0800 (PST) MIME-Version: 1.0 Sender: sdhags@gmail.com Received: by 10.229.211.199 with HTTP; Thu, 11 Nov 2010 15:58:23 -0800 (PST) In-Reply-To: References: <003e01cb81f0$b9425f60$2bc71e20$@com> From: Stephen Dawson-Haggerty Date: Thu, 11 Nov 2010 15:58:23 -0800 X-Google-Sender-Auth: 7DNfV4Bx7QXCPrDozCed73c43Qc Message-ID: To: Jonathan Hui Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ROLL WG Subject: Re: [Roll] Non-storing mode address types 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: , X-List-Received-Date: Thu, 11 Nov 2010 23:58:14 -0000 Okay, that sounds good; does that mean RPL routers might need to run ND to solve the link-layer address of the next hop? Could I also assume that the addresses RPL puts in the source header are derived from link-layer addresses (maybe if we're in the same prefix) so that I can just directly translate them? Let's face it, that's what I really want to do :). Steve On Thu, Nov 11, 2010 at 3:49 PM, Jonathan Hui wrote: > > Steve, > > You can make the on-link assumption when using the RPL routing header. = =C2=A0Section 4.2 of draft-ietf-6man-rpl-routing-header requires routers to= ensure that the next entry is on-link. =C2=A0If the next entry is not on-l= ink, the router must drop the packet. > > BTW, I'm not convinced that using 6lowpan-nd between RPL routers even the= right approach. =C2=A0The current 6lowpan-nd spec is primarily focused on = the host-router interface, which makes much more sense to me than applying = the same protocol for router-router interfaces. > > -- > Jonathan Hui > > On Nov 11, 2010, at 2:46 PM, Stephen Dawson-Haggerty wrote: > >> Ahh -- I only checked the roll mailing list archives... I don't really >> like the idea of keeping a neighbor cache for the downstream nodes, >> since it seems like it partially defeats the point of being >> "non-storing"; although you only would need one-hop neighbors that >> could still be a large set and you don't know which ones. >> >> I thought about just assuming it's on-link, but in that case we'll >> need to require that there is a mapping from the global address to the >> LL address. =C2=A0I think this will be mostly true, but seems like eithe= r >> RPL or 6lowpan should explicitly require it. =C2=A0It's also a little >> strange, I think, to make an exception and say that "other addresses >> are off link, unless they're in a routing header." >> >> Anyways, I'll go scan those 6lowpan archives, thanks for the clarificati= on. >> >> Steve >> >> On Thu, Nov 11, 2010 at 2:35 PM, Colin O'Flynn wrote= : >>> Hi Steve, >>> >>> That exact problem you mention was discussed on the 6LoWPAN mailing lis= t. If >>> you follow the way the standards are written, it won't work since globa= l >>> addresses are 'off-link' and you can never reach them! >>> >>> How it can be accomplished though use of the neighbor cache & NUD to >>> determine if a link is reachable or not. The point of assuming the pref= ix is >>> off-link is so you don't send NS for an unreachable node, but instead s= end >>> to the default router. But if you have NC entries, you should consider = the >>> nodes on-link. See section 6.5.4 of 6lowpan-nd-14. >>> >>> Another method is just to always assume a node which you have received = a >>> downward source route to is reachable. Presumably RPL is taking care of >>> ensuring that node is actually registered through you, so if you got a >>> message which indicates the next-hop is that node, it should be reachab= le. >>> >>> HTH, >>> >>> =C2=A0-Colin O'Flynn >>> >>> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>> Stephen Dawson-Haggerty >>> Sent: November 11, 2010 5:12 PM >>> To: ROLL WG >>> Subject: [Roll] Non-storing mode address types >>> >>> Hi -- trying to figure out how to construct downward source routes usin= g >>> DAOs. >>> >>> The 6lowpan-nd draft says that "All other prefixes are assumed to be >>> off-link ... They are therefore sent to one of the routers in the >>> Default Router List." =C2=A0This presumably means up, not down, so the >>> addresses in the routing header wold need to be link local? =C2=A0It se= ems >>> more likely that RPL wanted them to be global, though? >>> >>> Related, the target option in the DAO specifies a global address, of >>> course; it looks like the parent address is also a global address. >>> This is what leads to my confusion about the source route because >>> while you can construct a path of global addresses, I must be missing >>> how the intermediate hops can resolve the next hops of the addresses. >>> >>> If the parent addresses were link-local, I think it would work, so >>> long as the originating DAO also included a SLLA option; then the path >>> would be composed of only link-layer addresses. This seems a little >>> strange, though. I looked in 6.7.8 =C2=A0and 9 for guidance on this, bu= t am >>> still confused... >>> >>> Thanks, >>> Steve >>> >>> -- >>> stephen dawson-haggerty >>> http://cs.berkeley.edu/~stevedh >>> uc berkeley wireless and embedded systems lab >>> berkeley, ca 94720 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >> >> >> >> -- >> stephen dawson-haggerty >> http://cs.berkeley.edu/~stevedh >> uc berkeley wireless and embedded systems lab >> berkeley, ca 94720 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > --=20 stephen dawson-haggerty http://cs.berkeley.edu/~stevedh uc berkeley wireless and embedded systems lab berkeley, ca 94720 From ulrich@herberg.name Thu Nov 11 21:08:01 2010 Return-Path: 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 DF9E43A688E for ; Thu, 11 Nov 2010 21:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 PMNPMDRKzh3A for ; Thu, 11 Nov 2010 21:07:57 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id F41D53A6984 for ; Thu, 11 Nov 2010 21:07:56 -0800 (PST) Received: by qyk2 with SMTP id 2so254087qyk.10 for ; Thu, 11 Nov 2010 21:08:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.211.193 with SMTP id gp1mr2267635qab.131.1289538508333; Thu, 11 Nov 2010 21:08:28 -0800 (PST) Received: by 10.220.187.140 with HTTP; Thu, 11 Nov 2010 21:08:28 -0800 (PST) In-Reply-To: <484090EF-9061-4739-B222-A9130CF9E79A@cs.berkeley.edu> References: <484090EF-9061-4739-B222-A9130CF9E79A@cs.berkeley.edu> Date: Fri, 12 Nov 2010 13:08:28 +0800 Message-ID: From: Ulrich Herberg To: David Culler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG Subject: Re: [Roll] Subnet Gateway Protocol 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: , X-List-Received-Date: Fri, 12 Nov 2010 05:08:02 -0000 Thanks for the clarification. I have misunderstood the presentation that this would become part of RPL. I am still a bit confused about the following sentence in section 1.1 of RPL: "RPL also introduces the capability to bind a subnet together and route within that subnet." Does that preserve the subnet model (with respect to issues mentioned in RFC4903)? Why does RPL need to "route within a subnet"? In a subnet, routing is not required, TTL is not decremented. Ulrich On Fri, Nov 12, 2010 at 5:22 AM, David Culler wrot= e: > Indeed, the RPL document is what defines the protocol. =A0It does not con= tain a "subnet gateway protocol". > > On Nov 11, 2010, at 1:35 AM, JP Vasseur wrote: > >> Let me clarify - This is ONLY a term that was used during the presentati= on trying to explain how PIO/RA works in reply to an IESG >> DISCUSS. We're working on clarifying this soon, but there IS NO CHANGE i= s how RPL works. Just clarification. >> >> Thanks. >> >> JP. >> >> On Nov 11, 2010, at 2:13 PM, Ulrich Herberg wrote: >> >>> Hi, >>> >>> I just became aware during the ROLL meeting, that there is a "Subnet Ga= teway Protocol" contained in RPL, but I did not really find a description o= f that in the draft (there is some general description in section 1.2, but = that still leaves open many questions). A few that came to my mind: >>> =A0- how does the Subnet Gateway Protocol work in detail? >>> =A0- are classical link properties kept? (some being mentioned in RFC 4= 903) If a node sends a link-local multicast, will all other nodes within th= e same subnet receive the packets? Without TTL decrement? Is the same prefi= x on-link for all interfaces on the link? >>> =A0- Is ROLL chartered to include ND/autoconfiguration into RPL? Does i= t belong in the same spec? >>> >>> >>> Ulrich >>> >>> P.S: I did not find the RPL slides in the "materials" list of the IETF = web page. Will they be available for download? >>> _______________________________________________ >>> 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 > > David Culler > culler@cs.berkeley.edu > Chair Computer Science > Associate Chair EECS > > > > From cabo@tzi.org Thu Nov 11 22:51:50 2010 Return-Path: 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 B85AA3A67D6 for ; Thu, 11 Nov 2010 22:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 YiXC25tQPG7m for ; Thu, 11 Nov 2010 22:51:48 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id D41863A6A17 for ; Thu, 11 Nov 2010 22:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAC6q9Sx008115; Fri, 12 Nov 2010 07:52:09 +0100 (CET) Received: from dhcp-67f2.meeting.ietf.org (dhcp-67f2.meeting.ietf.org [130.129.103.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 11A3BEC9; Fri, 12 Nov 2010 07:52:07 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Fri, 12 Nov 2010 14:52:03 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <79B005E5-3DA0-4556-9B9F-48A9C658C115@tzi.org> References: <484090EF-9061-4739-B222-A9130CF9E79A@cs.berkeley.edu> To: Ulrich Herberg X-Mailer: Apple Mail (2.1081) Cc: roll WG Subject: Re: [Roll] Subnet Gateway Protocol 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: , X-List-Received-Date: Fri, 12 Nov 2010 06:51:50 -0000 On Nov 12, 2010, at 13:08, Ulrich Herberg wrote: > RFC4903 The more interesting RFC here may be RFC 5889. RFC 4903 describes why multi-link subnets are not trivial. RFC 5889 describes a model for multi-link subnets that is used e.g. in = 6LoWPANs. > Why does RPL need to "route within a subnet"? It may have to when the subnet is built out of of multiple links. > In a subnet, routing is not required, TTL is not decremented. One a single link, routing is not required (at least not at the L3 level = of that link -- it may very well be required *within the implementation* = of that link, which may be another network, based on its own IP = addresses or something else). A subnet composed out of multiple links does require some forwarding, = which may be supported by a routing protocol such as RPL. Gruesse, Carsten From coflynn@newae.com Thu Nov 11 23:47:37 2010 Return-Path: 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 E32533A6ACD for ; Thu, 11 Nov 2010 23:47:37 -0800 (PST) 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 PH3n95-gZjEa for ; Thu, 11 Nov 2010 23:47:30 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id F319A3A698C for ; Thu, 11 Nov 2010 23:47:29 -0800 (PST) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1PGoMb-0004Hn-0z; Fri, 12 Nov 2010 02:48:01 -0500 From: "Colin O'Flynn" To: "'Stephen Dawson-Haggerty'" , "'Jonathan Hui'" References: <003e01cb81f0$b9425f60$2bc71e20$@com> In-Reply-To: Date: Fri, 12 Nov 2010 07:47:56 -0000 Message-ID: <004401cb823d$ee045b70$ca0d1250$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuB/GBx/vq/Nql0RV6W25ceRLxb0AAQLong Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: 'ROLL WG' Subject: Re: [Roll] Non-storing mode address types 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: , X-List-Received-Date: Fri, 12 Nov 2010 07:47:38 -0000 Hi Steve, > Okay, that sounds good; does that mean RPL routers might need to run > ND to solve the link-layer address of the next hop? =20 Yes - 6lowpan-ND does say that between routers you can use classic = multicast RS to figure out a node's L2 address. > I think this will be mostly true, but seems like either > RPL or 6lowpan should explicitly require it. =20 No IETF spec is going to say that you can always assume the L2/IPv6 = address mapping. Doing so eliminates the possibility of assigning = addresses, and some networks might want to have fixed IPv6 addresses = even when the L2 addresses change. > Let's face it, that's what I > really want to do :). If in your network you know this is always the case, then you can get = away with making the assumption. There is probably some sort of '6lowpan = optimized sending algorithm' you could create if you really wanted, = where you try an L2 address based on the IPv6 address before doing ND. = With a 15.4 network you will instantly know if your packet was received = at the L2 layer anyway. In the generic case though you might still have = a different IPv6 address, so even if it was received at the L2 layer it = could be dropped at the IP layer. However - if in your network L2 and IP = mapping is kept, a packet being received at the L2 layer should always = mean it is accepted at the IP layer. Regards, -Colin -----Original Message----- From: sdhags@gmail.com [mailto:sdhags@gmail.com] On Behalf Of Stephen = Dawson-Haggerty Sent: November 11, 2010 11:58 PM To: Jonathan Hui Cc: Colin O'Flynn; ROLL WG Subject: Re: [Roll] Non-storing mode address types Okay, that sounds good; does that mean RPL routers might need to run ND to solve the link-layer address of the next hop? Could I also assume that the addresses RPL puts in the source header are derived from link-layer addresses (maybe if we're in the same prefix) so that I can just directly translate them? Let's face it, that's what I really want to do :). Steve On Thu, Nov 11, 2010 at 3:49 PM, Jonathan Hui wrote: > > Steve, > > You can make the on-link assumption when using the RPL routing header. = Section 4.2 of draft-ietf-6man-rpl-routing-header requires routers to = ensure that the next entry is on-link. If the next entry is not = on-link, the router must drop the packet. > > BTW, I'm not convinced that using 6lowpan-nd between RPL routers even = the right approach. The current 6lowpan-nd spec is primarily focused on = the host-router interface, which makes much more sense to me than = applying the same protocol for router-router interfaces. > > -- > Jonathan Hui > > On Nov 11, 2010, at 2:46 PM, Stephen Dawson-Haggerty wrote: > >> Ahh -- I only checked the roll mailing list archives... I don't = really >> like the idea of keeping a neighbor cache for the downstream nodes, >> since it seems like it partially defeats the point of being >> "non-storing"; although you only would need one-hop neighbors that >> could still be a large set and you don't know which ones. >> >> I thought about just assuming it's on-link, but in that case we'll >> need to require that there is a mapping from the global address to = the >> LL address. I think this will be mostly true, but seems like either >> RPL or 6lowpan should explicitly require it. It's also a little >> strange, I think, to make an exception and say that "other addresses >> are off link, unless they're in a routing header." >> >> Anyways, I'll go scan those 6lowpan archives, thanks for the = clarification. >> >> Steve >> >> On Thu, Nov 11, 2010 at 2:35 PM, Colin O'Flynn = wrote: >>> Hi Steve, >>> >>> That exact problem you mention was discussed on the 6LoWPAN mailing = list. If >>> you follow the way the standards are written, it won't work since = global >>> addresses are 'off-link' and you can never reach them! >>> >>> How it can be accomplished though use of the neighbor cache & NUD to >>> determine if a link is reachable or not. The point of assuming the = prefix is >>> off-link is so you don't send NS for an unreachable node, but = instead send >>> to the default router. But if you have NC entries, you should = consider the >>> nodes on-link. See section 6.5.4 of 6lowpan-nd-14. >>> >>> Another method is just to always assume a node which you have = received a >>> downward source route to is reachable. Presumably RPL is taking care = of >>> ensuring that node is actually registered through you, so if you got = a >>> message which indicates the next-hop is that node, it should be = reachable. >>> >>> HTH, >>> >>> -Colin O'Flynn >>> >>> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of >>> Stephen Dawson-Haggerty >>> Sent: November 11, 2010 5:12 PM >>> To: ROLL WG >>> Subject: [Roll] Non-storing mode address types >>> >>> Hi -- trying to figure out how to construct downward source routes = using >>> DAOs. >>> >>> The 6lowpan-nd draft says that "All other prefixes are assumed to be >>> off-link ... They are therefore sent to one of the routers in the >>> Default Router List." This presumably means up, not down, so the >>> addresses in the routing header wold need to be link local? It = seems >>> more likely that RPL wanted them to be global, though? >>> >>> Related, the target option in the DAO specifies a global address, of >>> course; it looks like the parent address is also a global address. >>> This is what leads to my confusion about the source route because >>> while you can construct a path of global addresses, I must be = missing >>> how the intermediate hops can resolve the next hops of the = addresses. >>> >>> If the parent addresses were link-local, I think it would work, so >>> long as the originating DAO also included a SLLA option; then the = path >>> would be composed of only link-layer addresses. This seems a little >>> strange, though. I looked in 6.7.8 and 9 for guidance on this, but = am >>> still confused... >>> >>> Thanks, >>> Steve >>> >>> -- >>> stephen dawson-haggerty >>> http://cs.berkeley.edu/~stevedh >>> uc berkeley wireless and embedded systems lab >>> berkeley, ca 94720 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >> >> >> >> -- >> stephen dawson-haggerty >> http://cs.berkeley.edu/~stevedh >> uc berkeley wireless and embedded systems lab >> berkeley, ca 94720 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > --=20 stephen dawson-haggerty http://cs.berkeley.edu/~stevedh uc berkeley wireless and embedded systems lab berkeley, ca 94720 From pthubert@cisco.com Fri Nov 12 10:38:38 2010 Return-Path: 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 DC8983A696B for ; Fri, 12 Nov 2010 10:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.894 X-Spam-Level: X-Spam-Status: No, score=-9.894 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 LVGqy2bjIQRV for ; Fri, 12 Nov 2010 10:38:29 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C17673A6A7A for ; Fri, 12 Nov 2010 10:38:23 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,188,1288569600"; d="scan'208";a="216249320" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 12 Nov 2010 18:38:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oACIcuKK018946; Fri, 12 Nov 2010 18:38:56 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Nov 2010 19:38:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 12 Nov 2010 19:38:51 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03330DCA@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Non-storing mode address types Thread-Index: AcuB/G6KOuUPULufQj+Mh2GA40JExAAms7/g References: <003e01cb81f0$b9425f60$2bc71e20$@com> From: "Pascal Thubert (pthubert)" To: "Stephen Dawson-Haggerty" , "Jonathan Hui" X-OriginalArrivalTime: 12 Nov 2010 18:38:55.0927 (UTC) FILETIME=[DCAEBC70:01CB8298] Cc: ROLL WG Subject: Re: [Roll] Non-storing mode address types 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: , X-List-Received-Date: Fri, 12 Nov 2010 18:38:39 -0000 SGkgU3RlcGhlbjoNCg0KTm90IG1pZ2h0LiBUaGV5IGRvIG5lZWQgdG8gcnVuIE5EIHRvIHNvbHZl IHRoZSBsaW5rLWxheWVyIGFkZHJlc3Mgb2YgdGhlIG5leHQgaG9wLiBBdm9pZGluZyB0aGUgTkQg ZXhjaGFuZ2UgYmV0d2VlbiBwYXJlbnQgYW5kIGNoaWxkIHdhcyB0aGUgd2hvbGUgcG9pbnQgb2Yg cGxhY2luZyB0aGUgU0xMQU8gaW4gdGhlIERBTy9ESU8uIFRoZSBsaXN0IHdhcyBub3QgdW5hbmlt b3VzIGluIHRoaW5raW5nIHRoYXQgd2FzIGEgZ29vZCBpZGVhLiANCg0KTWF5YmUgcmVhbCB3b3Js ZCBleHBlcmllbmNlIHdpbGwgbWFrZSB1cyBhZGQgdGhhdCBjYXBhYmlsaXR5IHRvIHRoZSBwcm90 b2NvbCBhcyBhbiBleHRlbnNpb24uIEZvciBub3cgeW91IGhhdmUgdG8gcGxheSB0aGUgTlMvTkEg Z2FtZSwgYW5kIHdoZXRoZXIgeW91IGRvIHRoZSByZWdpc3RyYXRpb24gb3IgdGhlIGNsYXNzaWNh bCBtY2FzdCB3YXkgaXMgbm90IFJQTCdzIGJ1c2luZXNzLiAgTm90ZSB0aGF0IFJQTCBkb2VzIG5v dCBwcm92aWRlIERBRCwgZWl0aGVyLg0KDQpQYXNjYWwNCmh0dHA6Ly93d3cueHRyYW5vcm1hbC5j b20vd2F0Y2gvNzAxMTM1Ny8NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mDQo+IFN0ZXBoZW4gRGF3c29uLUhhZ2dlcnR5DQo+IFNlbnQ6IEZyaWRheSwg Tm92ZW1iZXIgMTIsIDIwMTAgMTI6NTggQU0NCj4gVG86IEpvbmF0aGFuIEh1aQ0KPiBDYzogUk9M TCBXRw0KPiBTdWJqZWN0OiBSZTogW1JvbGxdIE5vbi1zdG9yaW5nIG1vZGUgYWRkcmVzcyB0eXBl cw0KPiANCj4gT2theSwgdGhhdCBzb3VuZHMgZ29vZDsgZG9lcyB0aGF0IG1lYW4gUlBMIHJvdXRl cnMgbWlnaHQgbmVlZCB0byBydW4gTkQNCj4gdG8gc29sdmUgdGhlIGxpbmstbGF5ZXIgYWRkcmVz cyBvZiB0aGUgbmV4dCBob3A/ICBDb3VsZCBJIGFsc28gYXNzdW1lIHRoYXQgdGhlDQo+IGFkZHJl c3NlcyBSUEwgcHV0cyBpbiB0aGUgc291cmNlIGhlYWRlciBhcmUgZGVyaXZlZCBmcm9tIGxpbmst bGF5ZXINCj4gYWRkcmVzc2VzIChtYXliZSBpZiB3ZSdyZSBpbiB0aGUgc2FtZSBwcmVmaXgpIHNv IHRoYXQgSSBjYW4ganVzdCBkaXJlY3RseQ0KPiB0cmFuc2xhdGUgdGhlbT8gIExldCdzIGZhY2Ug aXQsIHRoYXQncyB3aGF0IEkgcmVhbGx5IHdhbnQgdG8gZG8gOikuDQo+IA0KPiBTdGV2ZQ0KPiAN Cj4gT24gVGh1LCBOb3YgMTEsIDIwMTAgYXQgMzo0OSBQTSwgSm9uYXRoYW4gSHVpIDxqb25odWlA Y2lzY28uY29tPiB3cm90ZToNCj4gPg0KPiA+IFN0ZXZlLA0KPiA+DQo+ID4gWW91IGNhbiBtYWtl IHRoZSBvbi1saW5rIGFzc3VtcHRpb24gd2hlbiB1c2luZyB0aGUgUlBMIHJvdXRpbmcNCj4gaGVh ZGVyLiDCoFNlY3Rpb24gNC4yIG9mIGRyYWZ0LWlldGYtNm1hbi1ycGwtcm91dGluZy1oZWFkZXIg cmVxdWlyZXMgcm91dGVycw0KPiB0byBlbnN1cmUgdGhhdCB0aGUgbmV4dCBlbnRyeSBpcyBvbi1s aW5rLiDCoElmIHRoZSBuZXh0IGVudHJ5IGlzIG5vdCBvbi1saW5rLCB0aGUNCj4gcm91dGVyIG11 c3QgZHJvcCB0aGUgcGFja2V0Lg0KPiA+DQo+ID4gQlRXLCBJJ20gbm90IGNvbnZpbmNlZCB0aGF0 IHVzaW5nIDZsb3dwYW4tbmQgYmV0d2VlbiBSUEwgcm91dGVycyBldmVuDQo+IHRoZSByaWdodCBh cHByb2FjaC4gwqBUaGUgY3VycmVudCA2bG93cGFuLW5kIHNwZWMgaXMgcHJpbWFyaWx5IGZvY3Vz ZWQgb24gdGhlDQo+IGhvc3Qtcm91dGVyIGludGVyZmFjZSwgd2hpY2ggbWFrZXMgbXVjaCBtb3Jl IHNlbnNlIHRvIG1lIHRoYW4gYXBwbHlpbmcNCj4gdGhlIHNhbWUgcHJvdG9jb2wgZm9yIHJvdXRl ci1yb3V0ZXIgaW50ZXJmYWNlcy4NCj4gPg0KPiA+IC0tDQo+ID4gSm9uYXRoYW4gSHVpDQo+ID4N Cj4gPiBPbiBOb3YgMTEsIDIwMTAsIGF0IDI6NDYgUE0sIFN0ZXBoZW4gRGF3c29uLUhhZ2dlcnR5 IHdyb3RlOg0KPiA+DQo+ID4+IEFoaCAtLSBJIG9ubHkgY2hlY2tlZCB0aGUgcm9sbCBtYWlsaW5n IGxpc3QgYXJjaGl2ZXMuLi4gSSBkb24ndA0KPiA+PiByZWFsbHkgbGlrZSB0aGUgaWRlYSBvZiBr ZWVwaW5nIGEgbmVpZ2hib3IgY2FjaGUgZm9yIHRoZSBkb3duc3RyZWFtDQo+ID4+IG5vZGVzLCBz aW5jZSBpdCBzZWVtcyBsaWtlIGl0IHBhcnRpYWxseSBkZWZlYXRzIHRoZSBwb2ludCBvZiBiZWlu Zw0KPiA+PiAibm9uLXN0b3JpbmciOyBhbHRob3VnaCB5b3Ugb25seSB3b3VsZCBuZWVkIG9uZS1o b3AgbmVpZ2hib3JzIHRoYXQNCj4gPj4gY291bGQgc3RpbGwgYmUgYSBsYXJnZSBzZXQgYW5kIHlv dSBkb24ndCBrbm93IHdoaWNoIG9uZXMuDQo+ID4+DQo+ID4+IEkgdGhvdWdodCBhYm91dCBqdXN0 IGFzc3VtaW5nIGl0J3Mgb24tbGluaywgYnV0IGluIHRoYXQgY2FzZSB3ZSdsbA0KPiA+PiBuZWVk IHRvIHJlcXVpcmUgdGhhdCB0aGVyZSBpcyBhIG1hcHBpbmcgZnJvbSB0aGUgZ2xvYmFsIGFkZHJl c3MgdG8NCj4gPj4gdGhlIExMIGFkZHJlc3MuIMKgSSB0aGluayB0aGlzIHdpbGwgYmUgbW9zdGx5 IHRydWUsIGJ1dCBzZWVtcyBsaWtlDQo+ID4+IGVpdGhlciBSUEwgb3IgNmxvd3BhbiBzaG91bGQg ZXhwbGljaXRseSByZXF1aXJlIGl0LiDCoEl0J3MgYWxzbyBhDQo+ID4+IGxpdHRsZSBzdHJhbmdl LCBJIHRoaW5rLCB0byBtYWtlIGFuIGV4Y2VwdGlvbiBhbmQgc2F5IHRoYXQgIm90aGVyDQo+ID4+ IGFkZHJlc3NlcyBhcmUgb2ZmIGxpbmssIHVubGVzcyB0aGV5J3JlIGluIGEgcm91dGluZyBoZWFk ZXIuIg0KPiA+Pg0KPiA+PiBBbnl3YXlzLCBJJ2xsIGdvIHNjYW4gdGhvc2UgNmxvd3BhbiBhcmNo aXZlcywgdGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCj4gPj4NCj4gPj4gU3RldmUNCj4g Pj4NCj4gPj4gT24gVGh1LCBOb3YgMTEsIDIwMTAgYXQgMjozNSBQTSwgQ29saW4gTydGbHlubiA8 Y29mbHlubkBuZXdhZS5jb20+DQo+IHdyb3RlOg0KPiA+Pj4gSGkgU3RldmUsDQo+ID4+Pg0KPiA+ Pj4gVGhhdCBleGFjdCBwcm9ibGVtIHlvdSBtZW50aW9uIHdhcyBkaXNjdXNzZWQgb24gdGhlIDZM b1dQQU4gbWFpbGluZw0KPiA+Pj4gbGlzdC4gSWYgeW91IGZvbGxvdyB0aGUgd2F5IHRoZSBzdGFu ZGFyZHMgYXJlIHdyaXR0ZW4sIGl0IHdvbid0IHdvcmsNCj4gPj4+IHNpbmNlIGdsb2JhbCBhZGRy ZXNzZXMgYXJlICdvZmYtbGluaycgYW5kIHlvdSBjYW4gbmV2ZXIgcmVhY2ggdGhlbSENCj4gPj4+ DQo+ID4+PiBIb3cgaXQgY2FuIGJlIGFjY29tcGxpc2hlZCB0aG91Z2ggdXNlIG9mIHRoZSBuZWln aGJvciBjYWNoZSAmIE5VRCB0bw0KPiA+Pj4gZGV0ZXJtaW5lIGlmIGEgbGluayBpcyByZWFjaGFi bGUgb3Igbm90LiBUaGUgcG9pbnQgb2YgYXNzdW1pbmcgdGhlDQo+ID4+PiBwcmVmaXggaXMgb2Zm LWxpbmsgaXMgc28geW91IGRvbid0IHNlbmQgTlMgZm9yIGFuIHVucmVhY2hhYmxlIG5vZGUsDQo+ ID4+PiBidXQgaW5zdGVhZCBzZW5kIHRvIHRoZSBkZWZhdWx0IHJvdXRlci4gQnV0IGlmIHlvdSBo YXZlIE5DIGVudHJpZXMsDQo+ID4+PiB5b3Ugc2hvdWxkIGNvbnNpZGVyIHRoZSBub2RlcyBvbi1s aW5rLiBTZWUgc2VjdGlvbiA2LjUuNCBvZiA2bG93cGFuLW5kLQ0KPiAxNC4NCj4gPj4+DQo+ID4+ PiBBbm90aGVyIG1ldGhvZCBpcyBqdXN0IHRvIGFsd2F5cyBhc3N1bWUgYSBub2RlIHdoaWNoIHlv dSBoYXZlDQo+ID4+PiByZWNlaXZlZCBhIGRvd253YXJkIHNvdXJjZSByb3V0ZSB0byBpcyByZWFj aGFibGUuIFByZXN1bWFibHkgUlBMIGlzDQo+ID4+PiB0YWtpbmcgY2FyZSBvZiBlbnN1cmluZyB0 aGF0IG5vZGUgaXMgYWN0dWFsbHkgcmVnaXN0ZXJlZCB0aHJvdWdoDQo+ID4+PiB5b3UsIHNvIGlm IHlvdSBnb3QgYSBtZXNzYWdlIHdoaWNoIGluZGljYXRlcyB0aGUgbmV4dC1ob3AgaXMgdGhhdCBu b2RlLCBpdA0KPiBzaG91bGQgYmUgcmVhY2hhYmxlLg0KPiA+Pj4NCj4gPj4+IEhUSCwNCj4gPj4+ DQo+ID4+PiDCoC1Db2xpbiBPJ0ZseW5uDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiByb2xsLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiA+Pj4gT2YgU3RlcGhlbiBEYXdz b24tSGFnZ2VydHkNCj4gPj4+IFNlbnQ6IE5vdmVtYmVyIDExLCAyMDEwIDU6MTIgUE0NCj4gPj4+ IFRvOiBST0xMIFdHDQo+ID4+PiBTdWJqZWN0OiBbUm9sbF0gTm9uLXN0b3JpbmcgbW9kZSBhZGRy ZXNzIHR5cGVzDQo+ID4+Pg0KPiA+Pj4gSGkgLS0gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRv IGNvbnN0cnVjdCBkb3dud2FyZCBzb3VyY2Ugcm91dGVzDQo+ID4+PiB1c2luZyBEQU9zLg0KPiA+ Pj4NCj4gPj4+IFRoZSA2bG93cGFuLW5kIGRyYWZ0IHNheXMgdGhhdCAiQWxsIG90aGVyIHByZWZp eGVzIGFyZSBhc3N1bWVkIHRvIGJlDQo+ID4+PiBvZmYtbGluayAuLi4gVGhleSBhcmUgdGhlcmVm b3JlIHNlbnQgdG8gb25lIG9mIHRoZSByb3V0ZXJzIGluIHRoZQ0KPiA+Pj4gRGVmYXVsdCBSb3V0 ZXIgTGlzdC4iIMKgVGhpcyBwcmVzdW1hYmx5IG1lYW5zIHVwLCBub3QgZG93biwgc28gdGhlDQo+ ID4+PiBhZGRyZXNzZXMgaW4gdGhlIHJvdXRpbmcgaGVhZGVyIHdvbGQgbmVlZCB0byBiZSBsaW5r IGxvY2FsPyDCoEl0DQo+ID4+PiBzZWVtcyBtb3JlIGxpa2VseSB0aGF0IFJQTCB3YW50ZWQgdGhl bSB0byBiZSBnbG9iYWwsIHRob3VnaD8NCj4gPj4+DQo+ID4+PiBSZWxhdGVkLCB0aGUgdGFyZ2V0 IG9wdGlvbiBpbiB0aGUgREFPIHNwZWNpZmllcyBhIGdsb2JhbCBhZGRyZXNzLCBvZg0KPiA+Pj4g Y291cnNlOyBpdCBsb29rcyBsaWtlIHRoZSBwYXJlbnQgYWRkcmVzcyBpcyBhbHNvIGEgZ2xvYmFs IGFkZHJlc3MuDQo+ID4+PiBUaGlzIGlzIHdoYXQgbGVhZHMgdG8gbXkgY29uZnVzaW9uIGFib3V0 IHRoZSBzb3VyY2Ugcm91dGUgYmVjYXVzZQ0KPiA+Pj4gd2hpbGUgeW91IGNhbiBjb25zdHJ1Y3Qg YSBwYXRoIG9mIGdsb2JhbCBhZGRyZXNzZXMsIEkgbXVzdCBiZQ0KPiA+Pj4gbWlzc2luZyBob3cg dGhlIGludGVybWVkaWF0ZSBob3BzIGNhbiByZXNvbHZlIHRoZSBuZXh0IGhvcHMgb2YgdGhlDQo+ IGFkZHJlc3Nlcy4NCj4gPj4+DQo+ID4+PiBJZiB0aGUgcGFyZW50IGFkZHJlc3NlcyB3ZXJlIGxp bmstbG9jYWwsIEkgdGhpbmsgaXQgd291bGQgd29yaywgc28NCj4gPj4+IGxvbmcgYXMgdGhlIG9y aWdpbmF0aW5nIERBTyBhbHNvIGluY2x1ZGVkIGEgU0xMQSBvcHRpb247IHRoZW4gdGhlDQo+ID4+ PiBwYXRoIHdvdWxkIGJlIGNvbXBvc2VkIG9mIG9ubHkgbGluay1sYXllciBhZGRyZXNzZXMuIFRo aXMgc2VlbXMgYQ0KPiA+Pj4gbGl0dGxlIHN0cmFuZ2UsIHRob3VnaC4gSSBsb29rZWQgaW4gNi43 LjggwqBhbmQgOSBmb3IgZ3VpZGFuY2Ugb24NCj4gPj4+IHRoaXMsIGJ1dCBhbSBzdGlsbCBjb25m dXNlZC4uLg0KPiA+Pj4NCj4gPj4+IFRoYW5rcywNCj4gPj4+IFN0ZXZlDQo+ID4+Pg0KPiA+Pj4g LS0NCj4gPj4+IHN0ZXBoZW4gZGF3c29uLWhhZ2dlcnR5DQo+ID4+PiBodHRwOi8vY3MuYmVya2Vs ZXkuZWR1L35zdGV2ZWRoDQo+ID4+PiB1YyBiZXJrZWxleSB3aXJlbGVzcyBhbmQgZW1iZWRkZWQg c3lzdGVtcyBsYWIgYmVya2VsZXksIGNhIDk0NzIwDQo+ID4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4g Pj4+IFJvbGxAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbA0KPiA+Pj4NCj4gPj4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tDQo+ID4+ IHN0ZXBoZW4gZGF3c29uLWhhZ2dlcnR5DQo+ID4+IGh0dHA6Ly9jcy5iZXJrZWxleS5lZHUvfnN0 ZXZlZGgNCj4gPj4gdWMgYmVya2VsZXkgd2lyZWxlc3MgYW5kIGVtYmVkZGVkIHN5c3RlbXMgbGFi IGJlcmtlbGV5LCBjYSA5NDcyMA0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+PiBSb2xsIG1haWxpbmcgbGlzdA0KPiA+PiBSb2xsQGlldGYu b3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KPiA+ DQo+ID4NCj4gDQo+IA0KPiANCj4gLS0NCj4gc3RlcGhlbiBkYXdzb24taGFnZ2VydHkNCj4gaHR0 cDovL2NzLmJlcmtlbGV5LmVkdS9+c3RldmVkaA0KPiB1YyBiZXJrZWxleSB3aXJlbGVzcyBhbmQg ZW1iZWRkZWQgc3lzdGVtcyBsYWINCj4gYmVya2VsZXksIGNhIDk0NzIwDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFJvbGwgbWFpbGluZyBsaXN0 DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9yb2xsDQo= From alexandru.petrescu@gmail.com Fri Nov 12 13:45:46 2010 Return-Path: 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 046003A692C for ; Fri, 12 Nov 2010 13:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 jZpHjLylYBSA for ; Fri, 12 Nov 2010 13:45:39 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 01C733A69AA for ; Fri, 12 Nov 2010 13:45:37 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 99B859400F4 for ; Fri, 12 Nov 2010 22:46:05 +0100 (CET) Message-ID: <4CDDB595.3040002@gmail.com> Date: Fri, 12 Nov 2010 22:45:57 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: roll@ietf.org References: <484090EF-9061-4739-B222-A9130CF9E79A@cs.berkeley.edu> <79B005E5-3DA0-4556-9B9F-48A9C658C115@tzi.org> In-Reply-To: <79B005E5-3DA0-4556-9B9F-48A9C658C115@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101112-1, 12/11/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] Subnet Gateway Protocol 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: , X-List-Received-Date: Fri, 12 Nov 2010 21:45:46 -0000 Le 12/11/2010 07:52, Carsten Bormann a écrit : > On Nov 12, 2010, at 13:08, Ulrich Herberg wrote: > >> RFC4903 > > The more interesting RFC here may be RFC 5889. RFC 4903 describes why > multi-link subnets are not trivial. RFC 5889 describes a model for > multi-link subnets that is used e.g. in 6LoWPANs. > >> Why does RPL need to "route within a subnet"? > > It may have to when the subnet is built out of of multiple links. > >> In a subnet, routing is not required, TTL is not decremented. > > One a single link, routing is not required (at least not at the L3 > level of that link -- it may very well be required *within the > implementation* of that link, which may be another network, based on > its own IP addresses or something else). > > A subnet composed out of multiple links does require some > forwarding, hmm... 'some forwarding'. Forwarding is when a packet is transmitted from left to right, assuming right and left are distinct media. A packet heard on an interface and repeated on the same interface is not forwarding. Forwarding using a single interface interferes with the originator. If forwarding using two interfaces then multiple links per subnet are not needed - there are multiple subnets, and that is good. (by 'forwarding' I assume 'IP forwarding'). > which may be supported by a routing protocol such as RPL. May it be... Alex > > Gruesse, Carsten > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From ulrich@herberg.name Mon Nov 15 02:32:00 2010 Return-Path: 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 BA61C3A6A9B for ; Mon, 15 Nov 2010 02:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 c56WuFzBf9U8 for ; Mon, 15 Nov 2010 02:32:00 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id D81BD3A69C6 for ; Mon, 15 Nov 2010 02:31:59 -0800 (PST) Received: by qyk7 with SMTP id 7so2562534qyk.10 for ; Mon, 15 Nov 2010 02:32:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.201.138 with SMTP id fa10mr5396369qab.31.1289817160499; Mon, 15 Nov 2010 02:32:40 -0800 (PST) Received: by 10.220.187.140 with HTTP; Mon, 15 Nov 2010 02:32:40 -0800 (PST) In-Reply-To: <79B005E5-3DA0-4556-9B9F-48A9C658C115@tzi.org> References: <484090EF-9061-4739-B222-A9130CF9E79A@cs.berkeley.edu> <79B005E5-3DA0-4556-9B9F-48A9C658C115@tzi.org> Date: Mon, 15 Nov 2010 11:32:40 +0100 Message-ID: From: Ulrich Herberg To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Subnet Gateway Protocol 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: , X-List-Received-Date: Mon, 15 Nov 2010 10:32:00 -0000 Carsten, On Fri, Nov 12, 2010 at 7:52 AM, Carsten Bormann wrote: > > On Nov 12, 2010, at 13:08, Ulrich Herberg wrote: > > > RFC4903 > > The more interesting RFC here may be RFC 5889. I agree that RFC 5889 should apply to RPL router interfaces, but here we are talking about subnets for hosts, so I see that as a separate problem. > > RFC 4903 describes why multi-link subnets are not trivial. > RFC 5889 describes a model for multi-link subnets that is used e.g. in 6LoWPANs. > > > Why does RPL need to "route within a subnet"? > > It may have to when the subnet is built out of of multiple links. Well, I think that this is a very complicated issue (we discussed about that a lot in AUTOCONF this IETF). And moreover, it is a routing-protocol-independent issue. > > > In a subnet, routing is not required, TTL is not decremented. > > One a single link, routing is not required (at least not at the L3 level of that link -- it may very well be required *within the implementation* of that link, which may be another network, based on its own IP addresses or something else). > > A subnet composed out of multiple links does require some forwarding, which may be supported by a routing protocol such as RPL. Yes, it would require some forwarding, either on L2 or some L3 tunneling to preserve the IP header (and guarantee that TTL is not decremented, and that link-local broadcast works correctly). It is non-trivial to preserve the link-model, allow aggregation of routes and correct routing within the RPL network if hosts preserve their address and "move" to another router (handover, mobile IP?, security issues,..). I definitely think that it is out of scope of a routing protocol, and is not well described in the RPL draft (only a few sentences in section 1.1 of RPL). The flexible "message option" format of RPL would allow to allow forwarding of RIO/PIOs while specifying it outside of RPL in another spec. This would allow to 1) specify the exact behavior of splitting a subnet in another spec (if such splitting is wanted, which I am not convinced), and to 2) reduce the overhead of the RPL spec. I have already mentioned here on the list that I am convinced that the RPL draft is far too overloaded. I would much rather prefer a single framework draft and several optional or mandatory modules (such as upward routes, storing mode, non-storing, security extension,...). Splitting out the subnet issue would at least reduce the size of the draft. And I think for a "standards track" document, the subnet splitting is not well understood enough anyways. Ulrich From sakane@tanu.org Mon Nov 15 15:53:21 2010 Return-Path: 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 992CE28C13F for ; Mon, 15 Nov 2010 15:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.477 X-Spam-Level: X-Spam-Status: No, score=0.477 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuEONzwutWXm for ; Mon, 15 Nov 2010 15:53:14 -0800 (PST) Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by core3.amsl.com (Postfix) with ESMTP id 3213828C1A1 for ; Mon, 15 Nov 2010 15:53:12 -0800 (PST) Received: from dhcp-64-104-shinjuku-wlan-5-200.cisco.com (dhcp-64-104-shinjuku-wlan-5-200.cisco.com [64.104.5.200]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id EEC5716DB2 for ; Tue, 16 Nov 2010 08:53:53 +0900 (JST) Message-ID: <4CE1C813.60805@tanu.org> Date: Tue, 16 Nov 2010 08:53:55 +0900 From: Shoichi Sakane User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: roll@ietf.org References: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> In-Reply-To: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] FW: New Version Notification for draft-qiu-6lowpan-secure-router-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: , X-List-Received-Date: Mon, 15 Nov 2010 23:53:22 -0000 Carsten, JP, and All, On 10/27/10 7:22 PM, QIU Ying wrote: > http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt > > The title of the draft had been changed to "Lightweight Key Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)" instead of "Lightweight Secure Router Protocol" in order to make the work more clearly. It will be presented at ROLL WG. > > Any comments are appreciated. I talked with Ying Qiu, the author of KEMP. Here is my understanding after the discussion. He proposes a method to create a session key between the mobile node (N) and the next hop router (R). This document seems not define the concrete way to use the session key. However, this proposal would be reasonable scheme under a certain environment which is "a single trust domain" as Rene mentioned, and where B is able to verify whether a node was compromised. == Model == N moves among a wireless network. N has to be authenticated by an immediate neighbor router (R) before sending any message to another node (e.g. N2). In the network, there is an authorization server (B) which authorizes all nodes including N. It generates key materials for a session key of both N and R. When N is moving to around the next router (Rn), N has to send a request to B through R in order to get a next shared session key with Rn. ____________ / \ / _______B-----N2 Rn / / R / ... / .. / . / N ====== Rm ===: verified session ---: not concerned of this protocol, it may be secured. ...: session to be verified. == Assumption == N shares a pre-shared key with B. N shares a session key with the neighbor router (Rm) somehow before N initiates this protocol. Rm just forwards a request from N to B, and is not always needed if the request directly rearches at B. N has to know that the next neighbor router will be R. It is like a manner of the handover mechanism. N has to have more than one neighbor rouers at same time. One is Rm to send REQ, another is R to get NOTICE, which are explained below. == What is missing of this proposal == - What is the identifier of each node. - How to provision each identifier into each node. - How does N know the address of B. - How to establish the secure session between N and Rm. - Any message encoding format. - Any specific message authentication code algorithm, and encryption algorithm. == How to securely share a session key between N and R == +--------+ +------------- | R | <------------+ | +--------+ | 6)NOTICE | | 4)APPV v | +--------+ 1)REQ +--------+ +--------+ | N |---------->| Rm |--------->| B | +--------+ +--------+ +--------+ 1) N sends a request (REQ) to B through Rm. Rm just forwards REQ to B. Rm is not always needed if REQ directly reach at B. REQ = {Src=SN, Dst= BS, RT||R0||MAC(K_BN, SN||RT||R0)} SN,RT,BS: identifier of each node R0: random number generated by N MAC: a message authentication code K_BN: a shared key between B and N 2) B verifies the identifier of N (SN), and knows that the request is for R (RT). 3) B generates a session key K_NR for N and R. K_NR = H(K_BN, SN||R0||R1) R1: random number generated by B B encrypts the message contained K_NR by K_BR. 4) B sends an approval (APPV) to R. APPV = {Src=BS, Dst=RT, E(K_BR, SN||R0||R1||K_NR)} E: an encryption algorithm 5) R decrypts the payload encrypted by K_BR, and gets the identifier of N (SN) and a session key K_NR. 6) R sends a notice (NOTICE) to N. NOTICE = {Src=RT, Dst=SN, R0||R1||MAC(K_NR, RT||SN||R0||R1)} 7) N calculates a session key K_NR. K_NR = H(K_BN, SN||R0||R1) To check the MAC, N verifies NOTICE was from R wchich was authorized by B. From abr@sdesigns.dk Wed Nov 17 05:50:01 2010 Return-Path: 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 60ECD3A6903 for ; Wed, 17 Nov 2010 05:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=1.036, 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 Kt7JjG6cFrsC for ; Wed, 17 Nov 2010 05:50:00 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 55F373A6912 for ; Wed, 17 Nov 2010 05:50:00 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Nov 2010 14:50:45 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD53D@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPL P2P - Clarify that hop-by-hop is identical to RPL Storing mode Thread-Index: AcuEsHGhY/NbgJ7vRrSU0AvUM2mCPQBq6Ahw References: <484090EF-9061-4739-B222-A9130CF9E79A@cs.berkeley.edu><79B005E5-3DA0-4556-9B9F-48A9C658C115@tzi.org> From: "Anders Brandt" To: "ROLL WG" Subject: [Roll] RPL P2P - Clarify that hop-by-hop is identical to RPL Storing mode 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: , X-List-Received-Date: Wed, 17 Nov 2010 13:50:01 -0000 Dear P2P'ers=20 The current RPL P2P draft http://tools.ietf.org/html/draft-dt-roll-p2p-rpl-02 appears to be a little unclear on the terms * hop-by-hop route * source route * RPL Storing mode * RPL Non-storing mode The introduction does a nice job of explaining the difference of the two uncompatible modes but forgets to point out the detail that the RPL Non-storing mode is using source routes while RPL Storing mode implements hop-by-hop routes. Since a given implementation is going to be either non-storing or storing one may consider having dedicated sections (or documents?) explaining what is required for making a system work for non-storing or storing mode, respectively. Obviously, the frame format descriptions should=20 be common. Just my $.05 From pal@cs.stanford.edu Wed Nov 17 09:13:41 2010 Return-Path: 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 A0F2B3A6940 for ; Wed, 17 Nov 2010 09:13:41 -0800 (PST) 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 KC4ZXTu955mD for ; Wed, 17 Nov 2010 09:13:40 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 8517C3A6912 for ; Wed, 17 Nov 2010 09:13:40 -0800 (PST) Received: from [76.14.65.187] (helo=[192.168.1.106]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PIlaU-0006Xb-3y; Wed, 17 Nov 2010 09:14:26 -0800 In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD53D@zensys17.zensys.local> References: <484090EF-9061-4739-B222-A9130CF9E79A@cs.berkeley.edu><79B005E5-3DA0-4556-9B9F-48A9C658C115@tzi.org> <6D9687E95918C04A8B30A7D6DA805A3E01CCD53D@zensys17.zensys.local> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7EBEEA03-7A81-49E8-9BE3-39A523DAF080@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Wed, 17 Nov 2010 09:14:24 -0800 To: Anders Brandt X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Cc: ROLL WG Subject: Re: [Roll] RPL P2P - Clarify that hop-by-hop is identical to RPL Storing mode 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: , X-List-Received-Date: Wed, 17 Nov 2010 17:13:41 -0000 On Nov 17, 2010, at 5:50 AM, Anders Brandt wrote: > Dear P2P'ers > > > The current RPL P2P draft > http://tools.ietf.org/html/draft-dt-roll-p2p-rpl-02 > > appears to be a little unclear on the terms > > * hop-by-hop route > * source route > * RPL Storing mode > * RPL Non-storing mode > > The introduction does a nice job of explaining the > difference of the two uncompatible modes but forgets > to point out the detail that the > RPL Non-storing mode is using source routes while > RPL Storing mode implements hop-by-hop routes. > > Since a given implementation is going to be either > non-storing or storing one may consider having > dedicated sections (or documents?) explaining > what is required for making a system work for > non-storing or storing mode, respectively. > > Obviously, the frame format descriptions should > be common. > > Just my $.05 I think it make sense to keep them as separate sections of the same document. They should definitely be separate, concrete sections, though. I think there's always a push to break things up into many tiny documents because of short attention spans. But it's easier to keep them consistent in a single document, and the aggregate length is shorter. Phil From prvs=9304c16d4=mukul@uwm.edu Wed Nov 17 11:47:31 2010 Return-Path: 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 0627E3A6996 for ; Wed, 17 Nov 2010 11:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, 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 PZTN5s+4ttIv for ; Wed, 17 Nov 2010 11:47:30 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 181F63A697B for ; Wed, 17 Nov 2010 11:47:29 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.134]) by ip1mta.uwm.edu with ESMTP; 17 Nov 2010 13:48:16 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D5AF41FD03E; Wed, 17 Nov 2010 13:48:15 -0600 (CST) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQQKLwYqXfvT; Wed, 17 Nov 2010 13:48:15 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6394A1FD03C; Wed, 17 Nov 2010 13:48:15 -0600 (CST) Date: Wed, 17 Nov 2010 13:48:15 -0600 (CST) From: Mukul Goyal To: Anders Brandt Message-ID: <1010799673.1728842.1290023295331.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD53D@zensys17.zensys.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] RPL P2P - Clarify that hop-by-hop is identical to RPL Storing mode 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: , X-List-Received-Date: Wed, 17 Nov 2010 19:47:31 -0000 Hi Anders, [Anders] The current RPL P2P draft http://tools.ietf.org/html/draft-dt-roll-p2p-rpl-02 appears to be a little unclear on the terms * hop-by-hop route * source route * RPL Storing mode * RPL Non-storing mode The introduction does a nice job of explaining the difference of the two uncompatible modes but forgets to point out the detail that the RPL Non-storing mode is using source routes while RPL Storing mode implements hop-by-hop routes. [Mukul] The introduction section does say that "In non-storing mode operation, only the DAG root maintains downward routing information and hence a packet travels all the way to the DAG root, which then sends it towards its destination using a source route." Then it describes the storing mode operation "In storing mode operation, if the destination is a DAG descendant and the source maintains "downwards" routing state about this descendant, it can forward the packet along this route. Otherwise, the source sends the packet to a DAG parent, which then applies the same set of rules to forward the packet further." I guess I could modify the first sentence as follows "In storing mode operation, if the destination is a DAG descendant and the source maintains "downwards" HOP-BY-HOP routing state about this descendant, it can forward the packet along this route..." Would this change be sufficient? [Anders] Since a given implementation is going to be either non-storing or storing one may consider having dedicated sections (or documents?) explaining what is required for making a system work for non-storing or storing mode, respectively. [Mukul] Are you suggesting that hop-by-hop P2P routes can not be used in an LLN using non-storing mode RPL operation? It seems to me that both types of P2P routes (hop-by-hop; source) can be used irrespective of whether core RPL operation is storing mode or non-storing mode. Thanks Mukul _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=9304c16d4=mukul@uwm.edu Wed Nov 17 11:52:01 2010 Return-Path: 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 2349C3A69AB for ; Wed, 17 Nov 2010 11:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, 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 jr3JDd5Q2vcl for ; Wed, 17 Nov 2010 11:52:00 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 302A73A69A7 for ; Wed, 17 Nov 2010 11:52:00 -0800 (PST) Received: from mta01.pantherlink.uwm.edu ([129.89.7.132]) by ip2mta.uwm.edu with ESMTP; 17 Nov 2010 13:52:44 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 49CFDE6A7C for ; Wed, 17 Nov 2010 13:52:47 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRvdpluAvNvG for ; Wed, 17 Nov 2010 13:52:47 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 27A43E6A7A for ; Wed, 17 Nov 2010 13:52:47 -0600 (CST) Date: Wed, 17 Nov 2010 13:52:45 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <484728930.1729251.1290023565863.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Replace the term "good enough" with "usable" in P2P draft? 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: , X-List-Received-Date: Wed, 17 Nov 2010 19:52:01 -0000 Hi all There is a proposal to replace the term "good enough route" with "usable route" in the P2P draft. I was wondering if there are any objections to this change. Thanks Mukul From prvs=9304c16d4=mukul@uwm.edu Wed Nov 17 12:03:56 2010 Return-Path: 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 B54953A69AD for ; Wed, 17 Nov 2010 12:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, 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 uPyB1OoXThOo for ; Wed, 17 Nov 2010 12:03:56 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id E01733A699D for ; Wed, 17 Nov 2010 12:03:55 -0800 (PST) Received: from mta02.pantherlink.uwm.edu ([129.89.7.133]) by ip1mta.uwm.edu with ESMTP; 17 Nov 2010 14:04:42 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id D7F3412E3BC for ; Wed, 17 Nov 2010 14:04:41 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4PjVfqPCM5W for ; Wed, 17 Nov 2010 14:04:41 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id ADE8512E3BA for ; Wed, 17 Nov 2010 14:04:41 -0600 (CST) Date: Wed, 17 Nov 2010 14:04:41 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <1863272273.1729950.1290024281612.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1669634362.1729515.1290023834389.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Other proposed changes to P2P draft 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: , X-List-Received-Date: Wed, 17 Nov 2010 20:03:56 -0000 Here are some of the additional changes proposed for the P2P draft: 1. Specify minimum life time of the temporary DAG as a 4-bit exponent of 2 (in units of seconds). This will allow the minimum life time to vary between 2^0 to 2^15 seconds. 2. Associate a life time with hop-by-hop state established using P2P mechanism. Or we could let the implementation decide when to clean up the state that has not been used for a while. 3. Allow nodes to ignore routing metrics they dont understand as long as such metrics are not used in propagation constraints. Currently, the P2P draft requires a node to discard the DIO for the temporary DAG if it does not understand a metric contained in the metric container. 4. Require specification of route constraints inside Route Discovery Option. This is done to separate route constraints from propagation constraints (that would be present outside the Route Discovery Option) more cleanly. Currently, the propagation and route constraints are identified based on whether they appear before or after the Route Discovery Option. Thanks Mukul From abr@sdesigns.dk Thu Nov 18 00:00:16 2010 Return-Path: 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 F3D373A67EA for ; Thu, 18 Nov 2010 00:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.777, 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 VKJKoBgzxO0s for ; Thu, 18 Nov 2010 00:00:15 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 043433A67DB for ; Thu, 18 Nov 2010 00:00:14 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Nov 2010 09:01:01 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD543@zensys17.zensys.local> In-Reply-To: <484728930.1729251.1290023565863.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Replace the term "good enough" with "usable" in P2P draft? Thread-Index: AcuGkQTzPLGwbu9rRNi7WcN90GTVmAAYq2zA References: <484728930.1729251.1290023565863.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: "Mukul Goyal" , "roll" Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? 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: , X-List-Received-Date: Thu, 18 Nov 2010 08:00:16 -0000 hi Mukul (se inline) Cheers, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Mukul Goyal > Sent: Wednesday, November 17, 2010 20:53 > To: roll > Subject: [Roll] Replace the term "good enough" with "usable"=20 > in P2P draft? >=20 > Hi all >=20 > There is a proposal to replace the term "good enough route"=20 > with "usable route" in the P2P draft. I was wondering if=20 > there are any objections to this change. (among others) I am to blaim for the "good enough" term. I have to agree that this is not a term that one meets very often in RFCs - and thus we should try to align it with the IETF vocabulary. The meaning we are trying to convey is that both ends consider the constraints fulfilled, i.e. the path is good enough. This is slightly different from convergence-based network discovery, where routers have time to register many candidates and pick the best. In both cases we end up with "usable" routes. Thus, "usable" does really not tell me a lot. My suggestion would be that we explain in the introduction, that while reactive discovery in a non-storing environment cannot locate the best routes, the constraints allow us to identify routes that are good enough for the actual purpose. The rest of the document may then just refer to "routes". > Thanks > Mukul > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From yoav@yitran.com Thu Nov 18 00:18:58 2010 Return-Path: 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 941A13A680A for ; Thu, 18 Nov 2010 00:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 DBgR8gCSRc-t for ; Thu, 18 Nov 2010 00:18:57 -0800 (PST) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by core3.amsl.com (Postfix) with SMTP id 55A4E3A67FF for ; Thu, 18 Nov 2010 00:18:57 -0800 (PST) Received: from source ([209.85.214.45]) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTOThoMWZiGLjieKfazd6rGOmKyH9mF8G@postini.com; Thu, 18 Nov 2010 00:19:45 PST Received: by mail-bw0-f45.google.com with SMTP id 16so2656593bwz.18 for ; Thu, 18 Nov 2010 00:19:43 -0800 (PST) Received: by 10.204.62.17 with SMTP id v17mr264688bkh.67.1290068382944; Thu, 18 Nov 2010 00:19:42 -0800 (PST) From: Yoav Ben-Yehezkel References: <484728930.1729251.1290023565863.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E01CCD543@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD543@zensys17.zensys.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcuGkQTzPLGwbu9rRNi7WcN90GTVmAAYq2zAAADhpLA= Date: Thu, 18 Nov 2010 10:17:43 +0200 Message-ID: <4f34196ce4e05f5455136a235bffe43d@mail.gmail.com> To: Anders Brandt , Mukul Goyal , roll Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? 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: , X-List-Received-Date: Thu, 18 Nov 2010 08:18:58 -0000 I agree with Anders that any route is "usable". I also agree that it is important to differentiate these routes from RPL routes and that one way of doing so is explain that in the introduction as Anders has suggested. An addition to what Andres proposes would be to also find a good name for these routes. What about "sub-optimal routes"? The name coveys the message of being usable routes, but not the necessarily the best ones. It's an addition and not an alternative, because I still think the properties of "sub-optimality" needs some clarification, and the introduction seems like a good place to clarify that. I'm not an expert on IETF vocabulary though :) Regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Thursday, November 18, 2010 10:01 AM To: Mukul Goyal; roll Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? hi Mukul (se inline) Cheers, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Mukul Goyal > Sent: Wednesday, November 17, 2010 20:53 > To: roll > Subject: [Roll] Replace the term "good enough" with "usable" > in P2P draft? > > Hi all > > There is a proposal to replace the term "good enough route" > with "usable route" in the P2P draft. I was wondering if > there are any objections to this change. (among others) I am to blaim for the "good enough" term. I have to agree that this is not a term that one meets very often in RFCs - and thus we should try to align it with the IETF vocabulary. The meaning we are trying to convey is that both ends consider the constraints fulfilled, i.e. the path is good enough. This is slightly different from convergence-based network discovery, where routers have time to register many candidates and pick the best. In both cases we end up with "usable" routes. Thus, "usable" does really not tell me a lot. My suggestion would be that we explain in the introduction, that while reactive discovery in a non-storing environment cannot locate the best routes, the constraints allow us to identify routes that are good enough for the actual purpose. The rest of the document may then just refer to "routes". > Thanks > Mukul > _______________________________________________ > 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 abr@sdesigns.dk Thu Nov 18 02:41:17 2010 Return-Path: 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 76DD43A681D for ; Thu, 18 Nov 2010 02:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.622, 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 epT7ESAT1TYp for ; Thu, 18 Nov 2010 02:41:15 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 0914C28C0D0 for ; Thu, 18 Nov 2010 02:41:14 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Nov 2010 11:42:01 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD546@zensys17.zensys.local> In-Reply-To: <1010799673.1728842.1290023295331.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL P2P - Clarify that hop-by-hop is identical to RPLStoring mode Thread-Index: AcuGkGFAjcnASc/xQLSZx7Pi/ZAcPQAfBSGw References: <6D9687E95918C04A8B30A7D6DA805A3E01CCD53D@zensys17.zensys.local> <1010799673.1728842.1290023295331.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: "Mukul Goyal" Cc: ROLL WG Subject: Re: [Roll] RPL P2P - Clarify that hop-by-hop is identical to RPLStoring mode 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: , X-List-Received-Date: Thu, 18 Nov 2010 10:41:17 -0000 Hi Mukul (see inline) Cheers, Anders=20 > -----Original Message----- > From: Mukul Goyal [mailto:mukul@uwm.edu]=20 > Sent: Wednesday, November 17, 2010 20:48 > To: Anders Brandt > Cc: ROLL WG > Subject: Re: [Roll] RPL P2P - Clarify that hop-by-hop is=20 > identical to RPLStoring mode >=20 > Hi Anders, >=20 > [Anders] >=20 > The current RPL P2P draft > http://tools.ietf.org/html/draft-dt-roll-p2p-rpl-02 >=20 > appears to be a little unclear on the terms >=20 > * hop-by-hop route > * source route > * RPL Storing mode > * RPL Non-storing mode >=20 > The introduction does a nice job of explaining the difference=20 > of the two uncompatible modes but forgets to point out the=20 > detail that the RPL Non-storing mode is using source routes=20 > while RPL Storing mode implements hop-by-hop routes. >=20 > [Mukul] >=20 > The introduction section does say that >=20 > "In non-storing mode operation, only the DAG root maintains=20 > downward routing > information and hence a packet travels all the way to the DAG root, > which then sends it towards its destination using a source route." >=20 > Then it describes the storing mode operation >=20 > "In storing mode operation, if the destination is a DAG descendant and > the source maintains "downwards" routing state about this=20 > descendant, > it can forward the packet along this route. Otherwise, the source > sends the packet to a DAG parent, which then applies the=20 > same set of > rules to forward the packet further." >=20 > I guess I could modify the first sentence as follows >=20 > "In storing mode operation, if the destination is a DAG descendant and > the source maintains "downwards" HOP-BY-HOP routing state=20 > about this descendant, > it can forward the packet along this route." >=20 > Would this change be sufficient? [Anders] Yes, this definitely helps. But the last part " ...forward the packet along this route." seems to mix things up. May I suggest: " ...forward the packet to a descendant router closer to the destination..." > [Anders] > Since a given implementation is going to be either=20 > non-storing or storing one may consider having dedicated=20 > sections (or documents?) explaining what is required for=20 > making a system work for non-storing or storing mode, respectively. >=20 > [Mukul] >=20 > Are you suggesting that hop-by-hop P2P routes can not be used=20 > in an LLN using non-storing mode RPL operation? It seems to=20 > me that both types of P2P routes (hop-by-hop; source) can be=20 > used irrespective of whether core RPL operation is storing=20 > mode or non-storing mode. >=20 > Thanks > Mukul >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From Jerald.P.Martocci@jci.com Thu Nov 18 06:00:58 2010 Return-Path: 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 627043A67E7; Thu, 18 Nov 2010 06:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, 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 9CejafURt4tN; Thu, 18 Nov 2010 06:00:57 -0800 (PST) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by core3.amsl.com (Postfix) with ESMTP id 2B61A3A6802; Thu, 18 Nov 2010 06:00:56 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKTOUxyJ8WhitXMLSCEiA65LzKXnu/NjRM@postini.com; Thu, 18 Nov 2010 06:01:45 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010111808014720-25097 ; Thu, 18 Nov 2010 08:01:47 -0600 In-Reply-To: <484728930.1729251.1290023565863.JavaMail.root@mail02.pantherlink.uwm.edu> References: <484728930.1729251.1290023565863.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal MIME-Version: 1.0 X-KeepSent: 0732E065:1C840CC1-862577DF:004CC0AF; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 FP4 December 11, 2009 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 18 Nov 2010 08:01:32 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/18/2010 08:01:40 AM, Serialize complete at 11/18/2010 08:01:40 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/18/2010 08:01:47 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/18/2010 08:01:51 AM, Serialize complete at 11/18/2010 08:01:51 AM Content-Type: multipart/related; boundary="=_related 004CC6D8862577DF_=" Cc: roll , roll-bounces@ietf.org Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? 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: , X-List-Received-Date: Thu, 18 Nov 2010 14:00:58 -0000 This is a multipart message in MIME format. --=_related 004CC6D8862577DF_= Content-Type: text/html; charset="US-ASCII"
I like the change.




From: Mukul Goyal <mukul@uwm.edu>
To: roll <roll@ietf.org>
Date: 11/17/2010 01:55 PM
Subject: [Roll] Replace the term "good enough" with "usable" in P2P draft?




Hi all

There is a proposal to replace the term "good enough route" with "usable route" in the P2P draft. I was wondering if there are any objections to this change.

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

--=_related 004CC6D8862577DF_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_077701280776FE7C004CC6D8862577DF> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --=_related 004CC6D8862577DF_=-- From cabo@tzi.org Thu Nov 11 19:35:39 2010 Return-Path: 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 DCC0B3A69A9; Thu, 11 Nov 2010 19:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 csZk2FY9AeOa; Thu, 11 Nov 2010 19:35:38 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 074193A698D; Thu, 11 Nov 2010 19:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oAC3ZCge024366; Fri, 12 Nov 2010 04:35:12 +0100 (CET) Received: from dhcp-67f2.meeting.ietf.org (dhcp-67f2.meeting.ietf.org [130.129.103.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9C891EAE; Fri, 12 Nov 2010 04:35:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Fri, 12 Nov 2010 11:35:05 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <894C584D-AF6B-4B3C-801B-8C21A2219346@tzi.org> References: <003e01cb81f0$b9425f60$2bc71e20$@com> To: Stephen Dawson-Haggerty X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Thu, 18 Nov 2010 14:38:26 -0800 Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: [Roll] Router-to-router ND (was: Re: Non-storing mode address types) 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: , X-List-Received-Date: Fri, 12 Nov 2010 03:35:40 -0000 On Nov 12, 2010, at 07:58, Stephen Dawson-Haggerty wrote: > Okay, that sounds good; does that mean RPL routers might need to run > ND to solve the link-layer address of the next hop? Could I also > assume that the addresses RPL puts in the source header are derived > from link-layer addresses (maybe if we're in the same prefix) so that > I can just directly translate them? Let's face it, that's what I > really want to do :). >=20 > Steve (I can't answer the general question about RPL; the below is for 6LoWPAN = only.) There is some text on the router-to-router use of 6LoWPAN-ND in section = 6.5.5 of draft-ietf-6lowpan-nd-14.txt. The first paragraph is right to the point. The "optional" approach in the second paragraph is probably not the = right way to do things in a 6LoWPAN. I don't think there is a way for a router in 6LoWPAN to send a packet to = a neighboring router without revealing its L2 address, so I don't know = what kind of network this functionality would be used for. (But then = the same is true for most uses of SLLAO, and some people continue to = insist they should be used even in 6LoWPANs.) I don't think one should ever use an algorithmic mapping of L3 to L2 = addresses. (It is fine as an implementation optimization -- don't store both if = they match. =20 But never assume they will.) It is probably most useful to continue the ND part of discussion on the = 6LoWPAN list; therefore I put ROLL on BCC. (Context below for 6lowpan-only subscribers.) Gruesse, Carsten >=20 > On Thu, Nov 11, 2010 at 3:49 PM, Jonathan Hui = wrote: >>=20 >> Steve, >>=20 >> You can make the on-link assumption when using the RPL routing = header. Section 4.2 of draft-ietf-6man-rpl-routing-header requires = routers to ensure that the next entry is on-link. If the next entry is = not on-link, the router must drop the packet. >>=20 >> BTW, I'm not convinced that using 6lowpan-nd between RPL routers even = the right approach. The current 6lowpan-nd spec is primarily focused on = the host-router interface, which makes much more sense to me than = applying the same protocol for router-router interfaces. >>=20 >> -- >> Jonathan Hui >>=20 >> On Nov 11, 2010, at 2:46 PM, Stephen Dawson-Haggerty wrote: >>=20 >>> Ahh -- I only checked the roll mailing list archives... I don't = really >>> like the idea of keeping a neighbor cache for the downstream nodes, >>> since it seems like it partially defeats the point of being >>> "non-storing"; although you only would need one-hop neighbors that >>> could still be a large set and you don't know which ones. >>>=20 >>> I thought about just assuming it's on-link, but in that case we'll >>> need to require that there is a mapping from the global address to = the >>> LL address. I think this will be mostly true, but seems like either >>> RPL or 6lowpan should explicitly require it. It's also a little >>> strange, I think, to make an exception and say that "other addresses >>> are off link, unless they're in a routing header." >>>=20 >>> Anyways, I'll go scan those 6lowpan archives, thanks for the = clarification. >>>=20 >>> Steve >>>=20 >>> On Thu, Nov 11, 2010 at 2:35 PM, Colin O'Flynn = wrote: >>>> Hi Steve, >>>>=20 >>>> That exact problem you mention was discussed on the 6LoWPAN mailing = list. If >>>> you follow the way the standards are written, it won't work since = global >>>> addresses are 'off-link' and you can never reach them! >>>>=20 >>>> How it can be accomplished though use of the neighbor cache & NUD = to >>>> determine if a link is reachable or not. The point of assuming the = prefix is >>>> off-link is so you don't send NS for an unreachable node, but = instead send >>>> to the default router. But if you have NC entries, you should = consider the >>>> nodes on-link. See section 6.5.4 of 6lowpan-nd-14. >>>>=20 >>>> Another method is just to always assume a node which you have = received a >>>> downward source route to is reachable. Presumably RPL is taking = care of >>>> ensuring that node is actually registered through you, so if you = got a >>>> message which indicates the next-hop is that node, it should be = reachable. >>>>=20 >>>> HTH, >>>>=20 >>>> -Colin O'Flynn >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = Behalf Of >>>> Stephen Dawson-Haggerty >>>> Sent: November 11, 2010 5:12 PM >>>> To: ROLL WG >>>> Subject: [Roll] Non-storing mode address types >>>>=20 >>>> Hi -- trying to figure out how to construct downward source routes = using >>>> DAOs. >>>>=20 >>>> The 6lowpan-nd draft says that "All other prefixes are assumed to = be >>>> off-link ... They are therefore sent to one of the routers in the >>>> Default Router List." This presumably means up, not down, so the >>>> addresses in the routing header wold need to be link local? It = seems >>>> more likely that RPL wanted them to be global, though? >>>>=20 >>>> Related, the target option in the DAO specifies a global address, = of >>>> course; it looks like the parent address is also a global address. >>>> This is what leads to my confusion about the source route because >>>> while you can construct a path of global addresses, I must be = missing >>>> how the intermediate hops can resolve the next hops of the = addresses. >>>>=20 >>>> If the parent addresses were link-local, I think it would work, so >>>> long as the originating DAO also included a SLLA option; then the = path >>>> would be composed of only link-layer addresses. This seems a little >>>> strange, though. I looked in 6.7.8 and 9 for guidance on this, but = am >>>> still confused... >>>>=20 >>>> Thanks, >>>> Steve >>>>=20 >>>> -- >>>> stephen dawson-haggerty >>>> http://cs.berkeley.edu/~stevedh >>>> uc berkeley wireless and embedded systems lab >>>> berkeley, ca 94720 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> stephen dawson-haggerty >>> http://cs.berkeley.edu/~stevedh >>> uc berkeley wireless and embedded systems lab >>> berkeley, ca 94720 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >=20 >=20 >=20 > --=20 > stephen dawson-haggerty > http://cs.berkeley.edu/~stevedh > uc berkeley wireless and embedded systems lab > berkeley, ca 94720 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Thu Nov 18 14:41:02 2010 Return-Path: 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 EF0F628C0EC for ; Thu, 18 Nov 2010 14:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.916 X-Spam-Level: X-Spam-Status: No, score=-109.916 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 DhO6eWCLU1PU for ; Thu, 18 Nov 2010 14:41:02 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0AEFA3A679C for ; Thu, 18 Nov 2010 14:41:01 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0DAP865UyQ/khLgWdsb2JhbACiVxUBARYiIqNYmyaFSwSKWoMMBg X-IronPort-AV: E=Sophos;i="4.59,219,1288569600"; d="scan'208";a="13590235" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 18 Nov 2010 22:41:49 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oAIMfnbj011484 for ; Thu, 18 Nov 2010 22:41:49 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Nov 2010 23:41:48 +0100 Received: from [192.168.13.18] ([10.61.100.231]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Nov 2010 23:41:48 +0100 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Nov 2010 23:41:47 +0100 Message-Id: <922D1713-AD52-418C-A103-BD262CB0E0EE@cisco.com> To: roll WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 18 Nov 2010 22:41:48.0686 (UTC) FILETIME=[C933CAE0:01CB8771] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17776.002 X-TM-AS-Result: No--11.647600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Working Group Last Call on draft-ietf-roll-of0-03.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: , X-List-Received-Date: Thu, 18 Nov 2010 22:41:03 -0000 Dear all, draft-ietf-roll-of0-03.txt has now been stable for some time. This starts a 3-week WG Last Call on draft-ietf-roll-of0-03.txt that = will end on December 10 at noon ET. Please send your comment to the authors and copy the list. We would also appreciate (off-list if you prefer) feed-back on = implementations. Thanks. JP.= From abr@sdesigns.dk Fri Nov 19 01:28:55 2010 Return-Path: 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 7441828C103 for ; Fri, 19 Nov 2010 01:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.517, 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 6lYU9PS3zM1H for ; Fri, 19 Nov 2010 01:28:54 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id DE54D28C102 for ; Fri, 19 Nov 2010 01:28:53 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB87CC.4B96A8F9" Date: Fri, 19 Nov 2010 10:29:42 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD54A@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-brandt-roll-rpl-applicability-home-building re-submitted Thread-Index: AcuHzEq71IaFRBAdSY2lR6LYUCvqkQ== From: "Anders Brandt" To: "ROLL WG" Subject: [Roll] draft-brandt-roll-rpl-applicability-home-building re-submitted 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: , X-List-Received-Date: Fri, 19 Nov 2010 09:28:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB87CC.4B96A8F9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Applicability Statement on the use of RPL in Building and Home Environments has been re-submitted =20 http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-buil ding-01 =20 The document (still) reflects the issues which initiated the development effort on RPL P2P. =20 Best regards, Anders Brandt =20 ------_=_NextPart_001_01CB87CC.4B96A8F9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The = Applicability=20 Statement on the use of RPL in Building and Home Environments has been=20 re-submitted
 
http://tools.ietf.org/html/draft-brandt-roll-rpl-applicab= ility-home-building-01
 
The = document (still)=20 reflects the issues which initiated the development effort on RPL=20 P2P.
 
Best=20 regards,
  = Anders=20 Brandt
 
------_=_NextPart_001_01CB87CC.4B96A8F9-- From jpv@cisco.com Fri Nov 19 01:58:26 2010 Return-Path: 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 396473A67F9 for ; Fri, 19 Nov 2010 01:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 UXUMRUV1mLUv for ; Fri, 19 Nov 2010 01:58:25 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6B9883A67D3 for ; Fri, 19 Nov 2010 01:58:25 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoHAKvZ5UytJXG9/2dsb2JhbACaTwGICXGhVJswhUsEiluDDgY X-IronPort-AV: E=Sophos;i="4.59,221,1288569600"; d="scan'208,217";a="183962274" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2010 09:59:13 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id oAJ9x1Qt032331; Fri, 19 Nov 2010 09:59:11 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Nov 2010 10:58:59 +0100 Received: from [64.103.30.97] ([64.103.30.97]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Nov 2010 10:58:58 +0100 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-20-468409426 From: JP Vasseur In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD54A@zensys17.zensys.local> Date: Fri, 19 Nov 2010 10:58:58 +0100 Message-Id: <25E5B5E5-301C-4CA2-8624-25A4802FCC39@cisco.com> References: <6D9687E95918C04A8B30A7D6DA805A3E01CCD54A@zensys17.zensys.local> To: Anders Brandt X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 19 Nov 2010 09:58:58.0931 (UTC) FILETIME=[62B72C30:01CB87D0] Cc: ROLL WG Subject: Re: [Roll] draft-brandt-roll-rpl-applicability-home-building re-submitted 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: , X-List-Received-Date: Fri, 19 Nov 2010 09:58:26 -0000 --Apple-Mail-20-468409426 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Anders, So this is not an applicability statement but a problem statement - do = you need a draft for that ? Thanks. JP. On Nov 19, 2010, at 10:29 AM, Anders Brandt wrote: > The Applicability Statement on the use of RPL in Building and Home = Environments has been re-submitted > =20 > = http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-buildi= ng-01 > =20 > The document (still) reflects the issues which initiated the = development effort on RPL P2P. > =20 > Best regards, > Anders Brandt > =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-20-468409426 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Anders,

So this is not an applicability statement but a problem statement - do you need a draft for that ?

Thanks.

JP.

On Nov 19, 2010, at 10:29 AM, Anders Brandt wrote:

The Applicability Statement on the use of RPL in Building and Home Environments has been re-submitted
 
 
The document (still) reflects the issues which initiated the development effort on RPL P2P.
 
Best regards,
  Anders Brandt
 
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--Apple-Mail-20-468409426-- From abr@sdesigns.dk Fri Nov 19 02:02:58 2010 Return-Path: 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 85A293A68AF for ; Fri, 19 Nov 2010 02:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.444, 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 riWkb2DFTse2 for ; Fri, 19 Nov 2010 02:02:55 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id C1E773A68A3 for ; Fri, 19 Nov 2010 02:02:54 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB87D1.0C4E3A81" Date: Fri, 19 Nov 2010 11:03:43 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD54D@zensys17.zensys.local> In-Reply-To: <25E5B5E5-301C-4CA2-8624-25A4802FCC39@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] draft-brandt-roll-rpl-applicability-home-building re-submitted Thread-Index: AcuH0G2q1wSAbG1DSVquBGFKB7lrywAAAi2w References: <6D9687E95918C04A8B30A7D6DA805A3E01CCD54A@zensys17.zensys.local> <25E5B5E5-301C-4CA2-8624-25A4802FCC39@cisco.com> From: "Anders Brandt" To: "JP Vasseur" Cc: ROLL WG Subject: Re: [Roll] draft-brandt-roll-rpl-applicability-home-building re-submitted 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: , X-List-Received-Date: Fri, 19 Nov 2010 10:02:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB87D1.0C4E3A81 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP =20 Nothing is changed in the doc. It is the doc we agreed to make back in Anaheim. =20 I just had to make a new submission to keep it alive. It has to be alive to reflect that the current RPL spec does not fulfil the requirements of the home and building applications. =20 That's all. =20 Cheers, Anders ________________________________ From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: Friday, November 19, 2010 10:59 To: Anders Brandt Cc: ROLL WG Subject: Re: [Roll] draft-brandt-roll-rpl-applicability-home-building re-submitted =09 =09 Hi Anders,=20 =09 =09 So this is not an applicability statement but a problem statement - do you need a draft for that ? Thanks. JP. On Nov 19, 2010, at 10:29 AM, Anders Brandt wrote: The Applicability Statement on the use of RPL in Building and Home Environments has been re-submitted =20 =09 http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-buil ding-01 =20 The document (still) reflects the issues which initiated the development effort on RPL P2P. =20 Best regards, Anders Brandt =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =09 ------_=_NextPart_001_01CB87D1.0C4E3A81 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi JP
 
Nothing is changed in the doc. It is the doc we = agreed to=20 make back in Anaheim.
 
I just had to make a new submission to keep it=20 alive.
It has to be alive to reflect that the current = RPL spec=20 does not fulfil the requirements of the home and building=20 applications.
 
That's all.
 
Cheers,
  Anders

From: JP Vasseur = [mailto:jpv@cisco.com]=20
Sent: Friday, November 19, 2010 10:59
To: Anders=20 Brandt
Cc: ROLL WG
Subject: Re: [Roll]=20 draft-brandt-roll-rpl-applicability-home-building=20 re-submitted

Hi Anders,

So this is not an applicability statement but a problem statement = - do=20 you need a draft for that ?

Thanks.

JP.

On Nov 19, 2010, at 10:29 AM, Anders Brandt wrote:
The=20 Applicability Statement on the use of RPL in Building and Home = Environments=20 has been re-submitted
 
http://tools.ietf.org/html/draft-brandt-roll-rpl-applicab= ility-home-building-01
 
The document=20 (still) reflects the issues which initiated the development effort = on RPL=20 P2P.
 
Best=20 regards,
  Anders=20 Brandt
 
________________________________= _______________
Roll=20 mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

= ------_=_NextPart_001_01CB87D1.0C4E3A81-- From jpv@cisco.com Fri Nov 19 02:18:47 2010 Return-Path: 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 68C5A3A6843 for ; Fri, 19 Nov 2010 02:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 U7JMurT5GG0f for ; Fri, 19 Nov 2010 02:18:46 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id EB3553A67D3 for ; Fri, 19 Nov 2010 02:18:45 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAOPd5UyQ/khMgWdsb2JhbACUGIY3AYgJFQEBFiIioUebL4VLBIpbgw4G X-IronPort-AV: E=Sophos;i="4.59,222,1288569600"; d="scan'208,217";a="13618699" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 19 Nov 2010 10:19:34 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oAJAJYwo009749; Fri, 19 Nov 2010 10:19:34 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Nov 2010 11:19:34 +0100 Received: from [64.103.30.97] ([64.103.30.97]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Nov 2010 11:19:34 +0100 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-24-469644730 From: JP Vasseur In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD54D@zensys17.zensys.local> Date: Fri, 19 Nov 2010 11:19:33 +0100 Message-Id: <69EE0E12-F204-4EF9-8880-4A0D2B9C4CA4@cisco.com> References: <6D9687E95918C04A8B30A7D6DA805A3E01CCD54A@zensys17.zensys.local> <25E5B5E5-301C-4CA2-8624-25A4802FCC39@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD54D@zensys17.zensys.local> To: "Anders Brandt" X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 19 Nov 2010 10:19:34.0150 (UTC) FILETIME=[42F6A260:01CB87D3] Cc: ROLL WG Subject: Re: [Roll] draft-brandt-roll-rpl-applicability-home-building re-submitted 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: , X-List-Received-Date: Fri, 19 Nov 2010 10:18:47 -0000 --Apple-Mail-24-469644730 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Nov 19, 2010, at 11:03 AM, Anders Brandt wrote: > Hi JP > =20 > Nothing is changed in the doc. It is the doc we agreed to make back in = Anaheim. Yes and this was needed as a problem statement to move ahead with the = P2P enhanced solution, which is now a WG document. > =20 > I just had to make a new submission to keep it alive. > It has to be alive to reflect that the current RPL spec does not = fulfil the requirements of the home and building applications. > =20 You could move the problem statement in the solution ID if you will. Cheers. JP. > That's all. > =20 > Cheers, > Anders >=20 > From: JP Vasseur [mailto:jpv@cisco.com]=20 > Sent: Friday, November 19, 2010 10:59 > To: Anders Brandt > Cc: ROLL WG > Subject: Re: [Roll] draft-brandt-roll-rpl-applicability-home-building = re-submitted >=20 > Hi Anders, >=20 > So this is not an applicability statement but a problem statement - do = you need a draft for that ? >=20 > Thanks. >=20 > JP. >=20 > On Nov 19, 2010, at 10:29 AM, Anders Brandt wrote: >=20 >> The Applicability Statement on the use of RPL in Building and Home = Environments has been re-submitted >> =20 >> = http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-buildi= ng-01 >> =20 >> The document (still) reflects the issues which initiated the = development effort on RPL P2P. >> =20 >> Best regards, >> Anders Brandt >> =20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-24-469644730 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi,

On Nov 19, 2010, at 11:03 AM, Anders Brandt wrote:

Hi JP
 
Nothing is changed in the doc. It is the doc we agreed to make back in Anaheim.

Yes and this was needed as a problem statement to move ahead with the P2P enhanced solution,
which is now a WG document.

 
I just had to make a new submission to keep it alive.
It has to be alive to reflect that the current RPL spec does not fulfil the requirements of the home and building applications.
 

You could move the problem statement in the solution ID if you will.

Cheers.

JP.

That's all.
 
Cheers,
  Anders

From: JP Vasseur [mailto:jpv@cisco.com]
Sent: Friday, November 19, 2010 10:59
To: Anders Brandt
Cc: ROLL WG
Subject: Re: [Roll] draft-brandt-roll-rpl-applicability-home-building re-submitted

Hi Anders,

So this is not an applicability statement but a problem statement - do you need a draft for that ?

Thanks.

JP.

On Nov 19, 2010, at 10:29 AM, Anders Brandt wrote:

The Applicability Statement on the use of RPL in Building and Home Environments has been re-submitted
 
 
The document (still) reflects the issues which initiated the development effort on RPL P2P.
 
Best regards,
  Anders Brandt
 
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

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

--Apple-Mail-24-469644730-- From h.kermajani9@gmail.com Fri Nov 19 02:23:40 2010 Return-Path: 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 1DDF43A68D3 for ; Fri, 19 Nov 2010 02:23:40 -0800 (PST) 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 aNGsL+glcBOc for ; Fri, 19 Nov 2010 02:23:39 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 4BEC23A6881 for ; Fri, 19 Nov 2010 02:23:39 -0800 (PST) Received: by qyk8 with SMTP id 8so636991qyk.10 for ; Fri, 19 Nov 2010 02:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=06v8yOK6VZQhI8R0Sdy8hZ1su4V8+uAZirbaGSrs90s=; b=hEZGpzv6ZCeX5knCJstimhW9b8Ka97DRO17r+XDxFj1MQlAy9+U73Xo5t99IoDMB08 XlQtYT9i8t1eaiLmgTHx6Fxfgx0a2EM/4svMIs3/LIpwz8omSeMkqwfVWcCdR72hnkBb hMxXD17IWHV1RbW9KUIYFzAhETF9fpI1+2VRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DS/4pctFi4oE37eVwO0VI2ozo2AKUV1FCBaDFgKYbe/pSQzi+wLS6PCnFAZ4DKLMwT mnAxpqGPmQ/SO52lg+kIiz/2IOBbY3zCGLm/gj3lhMYbS42beKYnX5MzwLnmjkzHbHGf acJeiIw1OocyTjkAl4fqF5Ul1O/LM8jt8oT1M= MIME-Version: 1.0 Received: by 10.224.190.4 with SMTP id dg4mr262339qab.255.1290162268308; Fri, 19 Nov 2010 02:24:28 -0800 (PST) Received: by 10.220.200.202 with HTTP; Fri, 19 Nov 2010 02:24:28 -0800 (PST) Date: Fri, 19 Nov 2010 11:24:28 +0100 Message-ID: From: Hamidreza Kermajani To: ROLL WG Content-Type: multipart/alternative; boundary=20cf300fb01db484ca0495654fb8 Subject: [Roll] Question about updating the Neighbor Cache entries in a RPL 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: , X-List-Received-Date: Fri, 19 Nov 2010 10:23:40 -0000 --20cf300fb01db484ca0495654fb8 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Can somebody tell me that does maintaining of neighbors in RPL work based on 6LoWPAN Neighbor Discovery? I want to know how does a node update its Neighbor Cache entries in a DODAG? Regards, Hamidreza. --20cf300fb01db484ca0495654fb8 Content-Type: text/html; charset=ISO-8859-1 Hi all,

Can somebody tell me that does maintaining of neighbors in RPL work based on 6LoWPAN Neighbor Discovery?
I want to know how does a node update its Neighbor Cache entries in a DODAG?

Regards,
Hamidreza.
 --20cf300fb01db484ca0495654fb8-- From pthubert@cisco.com Fri Nov 19 03:23:47 2010 Return-Path: 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 CFAE03A6820 for ; Fri, 19 Nov 2010 03:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.105 X-Spam-Level: X-Spam-Status: No, score=-10.105 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 xKPqTAmqjLoX for ; Fri, 19 Nov 2010 03:23:42 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 17A503A6822 for ; Fri, 19 Nov 2010 03:23:39 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,222,1288569600"; d="scan'208,217";a="289285820" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 19 Nov 2010 11:24:29 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAJBOF1S021073; Fri, 19 Nov 2010 11:24:29 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Nov 2010 12:24:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB87DC.4E58F049" Date: Fri, 19 Nov 2010 12:24:16 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D033C37A9@XMB-AMS-107.cisco.com> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD54D@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] draft-brandt-roll-rpl-applicability-home-buildingre-submitted Thread-Index: AcuH0G2q1wSAbG1DSVquBGFKB7lrywAAAi2wAAJoMXA= References: <6D9687E95918C04A8B30A7D6DA805A3E01CCD54A@zensys17.zensys.local><25E5B5E5-301C-4CA2-8624-25A4802FCC39@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD54D@zensys17.zensys.local> From: "Pascal Thubert (pthubert)" To: "Anders Brandt" , "JP Vasseur" X-OriginalArrivalTime: 19 Nov 2010 11:24:19.0143 (UTC) FILETIME=[4E998570:01CB87DC] Cc: ROLL WG Subject: Re: [Roll] draft-brandt-roll-rpl-applicability-home-buildingre-submitted 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: , X-List-Received-Date: Fri, 19 Nov 2010 11:23:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB87DC.4E58F049 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Anders: =20 I tend to think of RPL as a whole. The "base" RPL spec has proactive methods, with distributed states/routing and centralized state/routing based on the RPL core tool set (DIS, DIO, DAO, metrics, OF). The P2P draft adds a (pretty cool) reactive method based on (extending) that same core tool set. There might be yet another angle in the future whereby we add distributed states and yet centralized routing (in a TSMP / ISA100.11a fashion if you will), still based in the same core tool set. And hopefully all these methods are compatible, complementary, and could run in different instances in a same RPL domain. =20 For that reason, I wish to be very cautious in terms so that people do not misread your last sentence as "RPL does not fulfil the requirements of the home and building applications".=20 Rather, I'd favor text that says that the RPL reactive method (the P2P) is more appropriate than the proactive (base) RPL method for for .=20 =20 Along that drift, I'd favor a reorganization of the P2P options so that the draft reuses the existing target option for the DIO, and then adds its own information as a new option that is really specific. I'll post on that. =20 Cheers, =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Friday, November 19, 2010 11:04 AM To: JP Vasseur Cc: ROLL WG Subject: Re: [Roll] draft-brandt-roll-rpl-applicability-home-buildingre-submitted =20 Hi JP =20 Nothing is changed in the doc. It is the doc we agreed to make back in Anaheim. =20 I just had to make a new submission to keep it alive. It has to be alive to reflect that the current RPL spec does not fulfil the requirements of the home and building applications. =20 That's all. =20 Cheers, Anders =20 ________________________________ From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: Friday, November 19, 2010 10:59 To: Anders Brandt Cc: ROLL WG Subject: Re: [Roll] draft-brandt-roll-rpl-applicability-home-building re-submitted Hi Anders,=20 =20 So this is not an applicability statement but a problem statement - do you need a draft for that ? =20 Thanks. =20 JP. =20 On Nov 19, 2010, at 10:29 AM, Anders Brandt wrote: =09 =09 =09 The Applicability Statement on the use of RPL in Building and Home Environments has been re-submitted =20 =09 http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-buil ding-01 =20 The document (still) reflects the issues which initiated the development effort on RPL P2P. =20 Best regards, Anders Brandt =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CB87DC.4E58F049 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Anders:

 

I tend to think of RPL as a whole. The “base” RPL spec = has proactive methods, with distributed states/routing and centralized = state/routing based on the RPL core tool set (DIS, DIO, DAO, metrics, = OF).

The P2P draft adds a (pretty cool) reactive method based on = (extending) that same core tool set. There might be yet another angle in = the future whereby we add distributed states and yet centralized routing = (in a TSMP / ISA100.11a fashion if you will), still based in the same = core tool set. And hopefully all these methods are compatible, = complementary, and could run in different instances in a same RPL = domain.

 

For that reason, I wish to be very cautious in terms so that people = do not misread your last sentence as “RPL does not fulfil the = requirements of the home and building applications”. =

Rather, I’d favor text that says that the RPL reactive method = (the P2P) is more appropriate than the proactive (base) RPL method for = <these usages> for <these reasons>.

 

Along that drift, I’d favor  a reorganization of the P2P = options so that the draft reuses the existing target option for the DIO, = and then adds its own information as a new option that is really = specific. I’ll post on that.

 

Cheers,

 

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Anders Brandt
Sent: Friday, November 19, 2010 11:04 = AM
To: JP Vasseur
Cc: ROLL WG
Subject: Re: = [Roll] = draft-brandt-roll-rpl-applicability-home-buildingre-submitted<= /span>

 

Hi= JP

 

No= thing is changed in the doc. It is the doc we agreed to make back in = Anaheim.

 

I = just had to make a new submission to keep it = alive.

It= has to be alive to reflect that the current RPL spec does not fulfil = the requirements of the home and building = applications.

 

Th= at's all.

 

Ch= eers,

&n= bsp; Anders

 

From:= = JP Vasseur [mailto:jpv@cisco.com]
Sent: Friday, November 19, = 2010 10:59
To: Anders Brandt
Cc: ROLL = WG
Subject: Re: [Roll] = draft-brandt-roll-rpl-applicability-home-building = re-submitted

Hi Anders, =

 

So this is not an applicability statement but a = problem statement - do you need a draft for that = ?

 

Thanks.

 

JP.

 

On = Nov 19, 2010, at 10:29 AM, Anders Brandt wrote:



The = Applicability Statement on the use of RPL in Building and Home = Environments has been re-submitted

 

 

The document = (still) reflects the issues which initiated the development effort on = RPL P2P.

 

Best = regards,

  = Anders Brandt

 

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

 

------_=_NextPart_001_01CB87DC.4E58F049-- From rdroms.ietf@gmail.com Fri Nov 19 03:33:39 2010 Return-Path: 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 071273A68FA for ; Fri, 19 Nov 2010 03:33:39 -0800 (PST) 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 zZ1A3aH0jCCo for ; Fri, 19 Nov 2010 03:33:38 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id DC8593A6820 for ; Fri, 19 Nov 2010 03:33:38 -0800 (PST) Received: by pwj2 with SMTP id 2so1194495pwj.31 for ; Fri, 19 Nov 2010 03:34:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=K48w6LXALHtl8TOwdMRlyt6TlImO5+7G1jHmXHU78T0=; b=tvKO6HUdx0H7WV6xmAOOjvFSR43Ws2Opxp4EiM8ctW9LdjqwROqnr7s+SngTF+xF/B AAg9z8A8azwjwDWpW+XSbhelmpcsM31mdE8C6oPYsgG8g5nN0g6IOT2JipruhhRfAaf6 wbleXlb21KfnhJmnGXsY1S8/7i8/ORPOJCnaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=Xd+tw5Ez5UnilDYfFEZGdzab45BiKjXYkeTflv4bTTatey4Ra28nSB7vJTSAnruddP 4WGp54HjS8pL2XQZuZTwjD6L1m1LDsT3W9x3+g/0HlYfjQfgpZdeg7OU19i+8NDtVAhP L6sQ3I293Tm4Z614PBPHGRA60APPCzjdhoT1E= Received: by 10.142.210.9 with SMTP id i9mr1616696wfg.25.1290166468394; Fri, 19 Nov 2010 03:34:28 -0800 (PST) Received: from [10.21.108.198] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id w22sm1769404wfd.19.2010.11.19.03.34.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 03:34:26 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Nov 2010 11:34:21 +0000 Message-Id: <4478C36E-968D-4E02-90C2-1B6471974622@gmail.com> To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Roll] Implicit default routes in RPL 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: , X-List-Received-Date: Fri, 19 Nov 2010 11:33:39 -0000 Is a DODAG root required to include an RIO with prefix length 0 to = indicate that it can act as a default router to any destination outside = the RPL Instance, or is that capability implicit? - Ralph From prvs=932801f61=mukul@uwm.edu Fri Nov 19 06:02:37 2010 Return-Path: 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 0F76C3A67DB for ; Fri, 19 Nov 2010 06:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, 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 EV4zcNab0+7U for ; Fri, 19 Nov 2010 06:02:34 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 265F53A677D for ; Fri, 19 Nov 2010 06:02:33 -0800 (PST) Received: from mta01.pantherlink.uwm.edu ([129.89.7.132]) by ip1mta.uwm.edu with ESMTP; 19 Nov 2010 08:03:24 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id B0411E6A7C; Fri, 19 Nov 2010 08:03:23 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2bupmgqXqQo; Fri, 19 Nov 2010 08:03:23 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 4435FE6A7B; Fri, 19 Nov 2010 08:03:23 -0600 (CST) Date: Fri, 19 Nov 2010 08:03:22 -0600 (CST) From: Mukul Goyal To: Anders Brandt Message-ID: <883066000.1823239.1290175402715.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD546@zensys17.zensys.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] RPL P2P - Clarify that hop-by-hop is identical to RPLStoring mode 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: , X-List-Received-Date: Fri, 19 Nov 2010 14:02:37 -0000 Hi Anders I will include the change in the next version. Thanks Mukul ----- Original Message ----- From: "Anders Brandt" To: "Mukul Goyal" Cc: "ROLL WG" Sent: Thursday, November 18, 2010 4:42:01 AM Subject: RE: [Roll] RPL P2P - Clarify that hop-by-hop is identical to RPLStoring mode Hi Mukul (see inline) Cheers, Anders > -----Original Message----- > From: Mukul Goyal [mailto:mukul@uwm.edu] > Sent: Wednesday, November 17, 2010 20:48 > To: Anders Brandt > Cc: ROLL WG > Subject: Re: [Roll] RPL P2P - Clarify that hop-by-hop is > identical to RPLStoring mode > > Hi Anders, > > [Anders] > > The current RPL P2P draft > http://tools.ietf.org/html/draft-dt-roll-p2p-rpl-02 > > appears to be a little unclear on the terms > > * hop-by-hop route > * source route > * RPL Storing mode > * RPL Non-storing mode > > The introduction does a nice job of explaining the difference > of the two uncompatible modes but forgets to point out the > detail that the RPL Non-storing mode is using source routes > while RPL Storing mode implements hop-by-hop routes. > > [Mukul] > > The introduction section does say that > > "In non-storing mode operation, only the DAG root maintains > downward routing > information and hence a packet travels all the way to the DAG root, > which then sends it towards its destination using a source route." > > Then it describes the storing mode operation > > "In storing mode operation, if the destination is a DAG descendant and > the source maintains "downwards" routing state about this > descendant, > it can forward the packet along this route. Otherwise, the source > sends the packet to a DAG parent, which then applies the > same set of > rules to forward the packet further." > > I guess I could modify the first sentence as follows > > "In storing mode operation, if the destination is a DAG descendant and > the source maintains "downwards" HOP-BY-HOP routing state > about this descendant, > it can forward the packet along this route." > > Would this change be sufficient? [Anders] Yes, this definitely helps. But the last part " ...forward the packet along this route." seems to mix things up. May I suggest: " ...forward the packet to a descendant router closer to the destination..." > [Anders] > Since a given implementation is going to be either > non-storing or storing one may consider having dedicated > sections (or documents?) explaining what is required for > making a system work for non-storing or storing mode, respectively. > > [Mukul] > > Are you suggesting that hop-by-hop P2P routes can not be used > in an LLN using non-storing mode RPL operation? It seems to > me that both types of P2P routes (hop-by-hop; source) can be > used irrespective of whether core RPL operation is storing > mode or non-storing mode. > > Thanks > Mukul > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From prvs=932801f61=mukul@uwm.edu Fri Nov 19 06:05:20 2010 Return-Path: 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 804CD3A6778 for ; Fri, 19 Nov 2010 06:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, 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 UQeQX+7VG76j for ; Fri, 19 Nov 2010 06:05:19 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 4681728C0FB for ; Fri, 19 Nov 2010 06:05:19 -0800 (PST) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 19 Nov 2010 08:06:09 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id E38C12B3F0B; Fri, 19 Nov 2010 08:04:41 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViFaMPs5smpS; Fri, 19 Nov 2010 08:04:40 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 7720D2B3F10; Fri, 19 Nov 2010 08:04:40 -0600 (CST) Date: Fri, 19 Nov 2010 08:06:07 -0600 (CST) From: Mukul Goyal To: Yoav Ben-Yehezkel Message-ID: <1275875391.1823379.1290175567062.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <4f34196ce4e05f5455136a235bffe43d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? 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: , X-List-Received-Date: Fri, 19 Nov 2010 14:05:20 -0000 Hi Yoav I know that P2P extension may not be discovering the "optimal" routes. But, you dont have to rub it in by making us call them "suboptimal". :) Thanks Mukul ----- Original Message ----- From: "Yoav Ben-Yehezkel" To: "Anders Brandt" , "Mukul Goyal" , "roll" Sent: Thursday, November 18, 2010 2:17:43 AM Subject: RE: [Roll] Replace the term "good enough" with "usable" in P2P draft? I agree with Anders that any route is "usable". I also agree that it is important to differentiate these routes from RPL routes and that one way of doing so is explain that in the introduction as Anders has suggested. An addition to what Andres proposes would be to also find a good name for these routes. What about "sub-optimal routes"? The name coveys the message of being usable routes, but not the necessarily the best ones. It's an addition and not an alternative, because I still think the properties of "sub-optimality" needs some clarification, and the introduction seems like a good place to clarify that. I'm not an expert on IETF vocabulary though :) Regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Thursday, November 18, 2010 10:01 AM To: Mukul Goyal; roll Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? hi Mukul (se inline) Cheers, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Mukul Goyal > Sent: Wednesday, November 17, 2010 20:53 > To: roll > Subject: [Roll] Replace the term "good enough" with "usable" > in P2P draft? > > Hi all > > There is a proposal to replace the term "good enough route" > with "usable route" in the P2P draft. I was wondering if > there are any objections to this change. (among others) I am to blaim for the "good enough" term. I have to agree that this is not a term that one meets very often in RFCs - and thus we should try to align it with the IETF vocabulary. The meaning we are trying to convey is that both ends consider the constraints fulfilled, i.e. the path is good enough. This is slightly different from convergence-based network discovery, where routers have time to register many candidates and pick the best. In both cases we end up with "usable" routes. Thus, "usable" does really not tell me a lot. My suggestion would be that we explain in the introduction, that while reactive discovery in a non-storing environment cannot locate the best routes, the constraints allow us to identify routes that are good enough for the actual purpose. The rest of the document may then just refer to "routes". > Thanks > Mukul > _______________________________________________ > 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 prvs=932801f61=mukul@uwm.edu Fri Nov 19 06:06:51 2010 Return-Path: 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 607CF3A67D7 for ; Fri, 19 Nov 2010 06:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, 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 h3yuZ60INr39 for ; Fri, 19 Nov 2010 06:06:49 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id B780C3A6778 for ; Fri, 19 Nov 2010 06:06:49 -0800 (PST) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 19 Nov 2010 08:07:35 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 043642B3F05; Fri, 19 Nov 2010 08:06:08 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9e73RzlIcqM; Fri, 19 Nov 2010 08:06:07 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 98AD22B3F03; Fri, 19 Nov 2010 08:06:07 -0600 (CST) Date: Fri, 19 Nov 2010 08:07:34 -0600 (CST) From: Mukul Goyal To: Anders Brandt Message-ID: <1552099610.1823418.1290175654195.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD543@zensys17.zensys.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Cc: "Charles E. Perkins" , roll Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? 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: , X-List-Received-Date: Fri, 19 Nov 2010 14:06:51 -0000 Hi Anders I like your suggestion. Just want to make sure that this is OK with every body. Thanks Mukul ----- Original Message ----- From: "Anders Brandt" To: "Mukul Goyal" , "roll" Sent: Thursday, November 18, 2010 2:01:01 AM Subject: RE: [Roll] Replace the term "good enough" with "usable" in P2P draft? hi Mukul (se inline) Cheers, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Mukul Goyal > Sent: Wednesday, November 17, 2010 20:53 > To: roll > Subject: [Roll] Replace the term "good enough" with "usable" > in P2P draft? > > Hi all > > There is a proposal to replace the term "good enough route" > with "usable route" in the P2P draft. I was wondering if > there are any objections to this change. (among others) I am to blaim for the "good enough" term. I have to agree that this is not a term that one meets very often in RFCs - and thus we should try to align it with the IETF vocabulary. The meaning we are trying to convey is that both ends consider the constraints fulfilled, i.e. the path is good enough. This is slightly different from convergence-based network discovery, where routers have time to register many candidates and pick the best. In both cases we end up with "usable" routes. Thus, "usable" does really not tell me a lot. My suggestion would be that we explain in the introduction, that while reactive discovery in a non-storing environment cannot locate the best routes, the constraints allow us to identify routes that are good enough for the actual purpose. The rest of the document may then just refer to "routes". > Thanks > Mukul > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From mcr@sandelman.ca Fri Nov 19 06:46:22 2010 Return-Path: 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 ADC893A6800 for ; Fri, 19 Nov 2010 06:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.455 X-Spam-Level: X-Spam-Status: No, score=0.455 tagged_above=-999 required=5 tests=[AWL=2.409, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, 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 VW6xlpI+u8bP for ; Fri, 19 Nov 2010 06:46:21 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id C4BEA3A6783 for ; Fri, 19 Nov 2010 06:46:21 -0800 (PST) Received: from marajade.sandelman.ca (cmr-208-124-129-34.cr.net.cable.rogers.com [208.124.129.34]) by relay.sandelman.ca (Postfix) with ESMTPS id D50E53450F; Fri, 19 Nov 2010 09:52:14 -0500 (EST) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 22B7498B1C; Fri, 19 Nov 2010 09:47:11 -0500 (EST) From: Michael Richardson To: Ralph Droms In-Reply-To: <4478C36E-968D-4E02-90C2-1B6471974622@gmail.com> References: <4478C36E-968D-4E02-90C2-1B6471974622@gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 19 Nov 2010 09:47:11 -0500 Message-ID: <28506.1290178031@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] Implicit default routes in RPL 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: , X-List-Received-Date: Fri, 19 Nov 2010 14:46:22 -0000 >>>>> "Ralph" == Ralph Droms writes: Ralph> Is a DODAG root required to include an RIO with prefix length Ralph> 0 to indicate that it can act as a default router to any Ralph> destination outside the RPL Instance, or is that capability Ralph> implicit? My understanding is that it is not implicit, it must be explicit. Not all DODAG root's are GROUNDED, and even if they are, they might not provide reachability to the "world". -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From pthubert@cisco.com Fri Nov 19 08:11:10 2010 Return-Path: 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 A632928C129 for ; Fri, 19 Nov 2010 08:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.15 X-Spam-Level: X-Spam-Status: No, score=-10.15 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 SWy4g6PW8TvC for ; Fri, 19 Nov 2010 08:11:03 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 7005D28C0E0 for ; Fri, 19 Nov 2010 08:11:00 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkDABYx5kyQ/khLgWdsb2JhbACUG45BFQEBFiIioW6Neo1NhUsEjW+CaQ X-IronPort-AV: E=Sophos;i="4.59,223,1288569600"; d="scan'208";a="13645285" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 19 Nov 2010 16:11:44 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oAJGBiq6020961; Fri, 19 Nov 2010 16:11:44 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Nov 2010 17:11:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Nov 2010 17:11:38 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D033C3954@XMB-AMS-107.cisco.com> In-Reply-To: <28506.1290178031@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Implicit default routes in RPL Thread-Index: AcuH+OqDptdBj7G6QGq4nC+NB1natgACosdA References: <4478C36E-968D-4E02-90C2-1B6471974622@gmail.com> <28506.1290178031@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Michael Richardson" , "Ralph Droms" X-OriginalArrivalTime: 19 Nov 2010 16:11:43.0378 (UTC) FILETIME=[74F6F720:01CB8804] Cc: roll@ietf.org Subject: Re: [Roll] Implicit default routes in RPL 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: , X-List-Received-Date: Fri, 19 Nov 2010 16:11:10 -0000 Hi Ralph and Michael: It is explicit in the text that the parents are used as default routers. The default route is required to go up the DAG till you hit a common ancestor. This comes with the fact that RPL maintains a minimum set of states and resort to the default route for whatever is not attached in a anode's subdag. The default route does not mean that the parents can reach the whole internet. A RIO might tell you that, or the G bit if the goal is to reach the internet. Rather, this means that whatever you want to reach that is not in your subdag can only be reached via the parents. See section 8 of RPL 15, in particular: As mentioned in Section 3.2.8, nodes that decide to join a DODAG MUST provision at least one DODAG parent as a default route for the associated instance. This default route enables a packet to be forwarded upwards until it eventually hits a common ancestor from which it will be routed downwards to the destination. If the destination is not in the DODAG, then the DODAG root may be able to forward the packet using connectivity to the outside of the DODAG; if it cannot forward the packet outside then the DODAG root has to drop it. But also the text on RIO. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: Friday, November 19, 2010 3:47 PM > To: Ralph Droms > Cc: roll@ietf.org > Subject: Re: [Roll] Implicit default routes in RPL >=20 >=20 > >>>>> "Ralph" =3D=3D Ralph Droms writes: > Ralph> Is a DODAG root required to include an RIO with prefix length > Ralph> 0 to indicate that it can act as a default router to any > Ralph> destination outside the RPL Instance, or is that capability > Ralph> implicit? >=20 > My understanding is that it is not implicit, it must be explicit. > Not all DODAG root's are GROUNDED, and even if they are, they might not > provide reachability to the "world". >=20 > -- > ] He who is tired of Weird Al is tired of life! | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ > |device driver[ > Kyoto Plus: watch the video > > then sign the petition. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Fri Nov 19 08:53:44 2010 Return-Path: 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 32A7C3A6869 for ; Fri, 19 Nov 2010 08:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 2IbhXq35El2X for ; Fri, 19 Nov 2010 08:53:43 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 007DD3A684F for ; Fri, 19 Nov 2010 08:53:42 -0800 (PST) Received: from source ([209.85.214.48]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTOaryESPjH6coOVR28wsz7dTUVcYG4Ov@postini.com; Fri, 19 Nov 2010 08:54:33 PST Received: by mail-bw0-f48.google.com with SMTP id 9so4599680bwz.35 for ; Fri, 19 Nov 2010 08:54:32 -0800 (PST) Received: by 10.204.118.7 with SMTP id t7mr2295133bkq.148.1290185670958; Fri, 19 Nov 2010 08:54:30 -0800 (PST) From: Yoav Ben-Yehezkel References: <4f34196ce4e05f5455136a235bffe43d@mail.gmail.com> <1275875391.1823379.1290175567062.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1275875391.1823379.1290175567062.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuH8uvpSUbNFTxGRg6CbS4sgy/hOAAFvOAw Date: Fri, 19 Nov 2010 18:52:06 +0200 Message-ID: To: Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? 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: , X-List-Received-Date: Fri, 19 Nov 2010 16:53:44 -0000 Right... Sorry about that. Still I think it is valuable to differentiate these routes from the ones RPL obtains by name. Maybe call them "P2P routes"? Thanks, Yoav -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu] Sent: Friday, November 19, 2010 4:06 PM To: Yoav Ben-Yehezkel Cc: Anders Brandt; roll Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? Hi Yoav I know that P2P extension may not be discovering the "optimal" routes. But, you dont have to rub it in by making us call them "suboptimal". :) Thanks Mukul ----- Original Message ----- From: "Yoav Ben-Yehezkel" To: "Anders Brandt" , "Mukul Goyal" , "roll" Sent: Thursday, November 18, 2010 2:17:43 AM Subject: RE: [Roll] Replace the term "good enough" with "usable" in P2P draft? I agree with Anders that any route is "usable". I also agree that it is important to differentiate these routes from RPL routes and that one way of doing so is explain that in the introduction as Anders has suggested. An addition to what Andres proposes would be to also find a good name for these routes. What about "sub-optimal routes"? The name coveys the message of being usable routes, but not the necessarily the best ones. It's an addition and not an alternative, because I still think the properties of "sub-optimality" needs some clarification, and the introduction seems like a good place to clarify that. I'm not an expert on IETF vocabulary though :) Regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Thursday, November 18, 2010 10:01 AM To: Mukul Goyal; roll Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? hi Mukul (se inline) Cheers, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Mukul Goyal > Sent: Wednesday, November 17, 2010 20:53 > To: roll > Subject: [Roll] Replace the term "good enough" with "usable" > in P2P draft? > > Hi all > > There is a proposal to replace the term "good enough route" > with "usable route" in the P2P draft. I was wondering if > there are any objections to this change. (among others) I am to blaim for the "good enough" term. I have to agree that this is not a term that one meets very often in RFCs - and thus we should try to align it with the IETF vocabulary. The meaning we are trying to convey is that both ends consider the constraints fulfilled, i.e. the path is good enough. This is slightly different from convergence-based network discovery, where routers have time to register many candidates and pick the best. In both cases we end up with "usable" routes. Thus, "usable" does really not tell me a lot. My suggestion would be that we explain in the introduction, that while reactive discovery in a non-storing environment cannot locate the best routes, the constraints allow us to identify routes that are good enough for the actual purpose. The rest of the document may then just refer to "routes". > Thanks > Mukul > _______________________________________________ > 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 prvs=932801f61=mukul@uwm.edu Fri Nov 19 11:02:50 2010 Return-Path: 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 A5A593A6876 for ; Fri, 19 Nov 2010 11:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, 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 r9mmuzaefeBM for ; Fri, 19 Nov 2010 11:02:49 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 5DB563A67D7 for ; Fri, 19 Nov 2010 11:02:49 -0800 (PST) Received: from mta02.pantherlink.uwm.edu ([129.89.7.133]) by ip2mta.uwm.edu with ESMTP; 19 Nov 2010 13:03:39 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id A18AD12E3BA; Fri, 19 Nov 2010 13:03:36 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngu-rImLb8Xe; Fri, 19 Nov 2010 13:03:36 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 33D8412E3BB; Fri, 19 Nov 2010 13:03:36 -0600 (CST) Date: Fri, 19 Nov 2010 13:03:36 -0600 (CST) From: Mukul Goyal To: Yoav Ben-Yehezkel Message-ID: <1934622853.1843786.1290193416042.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? 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: , X-List-Received-Date: Fri, 19 Nov 2010 19:02:50 -0000 Yoav I am not sure what useful purpose would be served by giving these routes a special name. I agree with Anders's suggestion to clarify the good-enough nature of these routes in the introduction and simply refer to them as routes in the subsequent discussion. Thanks Mukul ----- Original Message ----- From: "Yoav Ben-Yehezkel" To: "Mukul Goyal" Cc: "Anders Brandt" , "roll" Sent: Friday, November 19, 2010 10:52:06 AM Subject: RE: [Roll] Replace the term "good enough" with "usable" in P2P draft? Right... Sorry about that. Still I think it is valuable to differentiate these routes from the ones RPL obtains by name. Maybe call them "P2P routes"? Thanks, Yoav -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu] Sent: Friday, November 19, 2010 4:06 PM To: Yoav Ben-Yehezkel Cc: Anders Brandt; roll Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? Hi Yoav I know that P2P extension may not be discovering the "optimal" routes. But, you dont have to rub it in by making us call them "suboptimal". :) Thanks Mukul ----- Original Message ----- From: "Yoav Ben-Yehezkel" To: "Anders Brandt" , "Mukul Goyal" , "roll" Sent: Thursday, November 18, 2010 2:17:43 AM Subject: RE: [Roll] Replace the term "good enough" with "usable" in P2P draft? I agree with Anders that any route is "usable". I also agree that it is important to differentiate these routes from RPL routes and that one way of doing so is explain that in the introduction as Anders has suggested. An addition to what Andres proposes would be to also find a good name for these routes. What about "sub-optimal routes"? The name coveys the message of being usable routes, but not the necessarily the best ones. It's an addition and not an alternative, because I still think the properties of "sub-optimality" needs some clarification, and the introduction seems like a good place to clarify that. I'm not an expert on IETF vocabulary though :) Regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Thursday, November 18, 2010 10:01 AM To: Mukul Goyal; roll Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? hi Mukul (se inline) Cheers, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf Of Mukul Goyal > Sent: Wednesday, November 17, 2010 20:53 > To: roll > Subject: [Roll] Replace the term "good enough" with "usable" > in P2P draft? > > Hi all > > There is a proposal to replace the term "good enough route" > with "usable route" in the P2P draft. I was wondering if > there are any objections to this change. (among others) I am to blaim for the "good enough" term. I have to agree that this is not a term that one meets very often in RFCs - and thus we should try to align it with the IETF vocabulary. The meaning we are trying to convey is that both ends consider the constraints fulfilled, i.e. the path is good enough. This is slightly different from convergence-based network discovery, where routers have time to register many candidates and pick the best. In both cases we end up with "usable" routes. Thus, "usable" does really not tell me a lot. My suggestion would be that we explain in the introduction, that while reactive discovery in a non-storing environment cannot locate the best routes, the constraints allow us to identify routes that are good enough for the actual purpose. The rest of the document may then just refer to "routes". > Thanks > Mukul > _______________________________________________ > 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 mcr@sandelman.ca Fri Nov 19 11:14:02 2010 Return-Path: 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 111E13A689C for ; Fri, 19 Nov 2010 11:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, 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 vp3vPuqDC-F8 for ; Fri, 19 Nov 2010 11:14:01 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 00F3228C128 for ; Fri, 19 Nov 2010 11:14:00 -0800 (PST) Received: from marajade.sandelman.ca (cmr-208-124-129-34.cr.net.cable.rogers.com [208.124.129.34]) by relay.sandelman.ca (Postfix) with ESMTPS id 406E33493F; Fri, 19 Nov 2010 14:19:55 -0500 (EST) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id BD73398B1C; Fri, 19 Nov 2010 14:14:49 -0500 (EST) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D033C3954@XMB-AMS-107.cisco.com> References: <4478C36E-968D-4E02-90C2-1B6471974622@gmail.com> <28506.1290178031@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D033C3954@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 19 Nov 2010 14:14:49 -0500 Message-ID: <4627.1290194089@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] Implicit default routes in RPL 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: , X-List-Received-Date: Fri, 19 Nov 2010 19:14:02 -0000 thank you for the reply, I think we are in violent agreement? see inline. >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> Hi Ralph and Michael: Pascal> It is explicit in the text that the parents are used as Pascal> default routers. The default route is required to go up the Pascal> DAG till you hit a common ancestor. This comes with the fact Pascal> that RPL maintains a minimum set of states and resort to the Pascal> default route for whatever is not attached in a anode's Pascal> subdag. The default route does not mean that the parents can Pascal> reach the whole internet. A RIO might tell you that, or the Pascal> G bit if the goal is to reach the internet. Rather, this Pascal> means that whatever you want to reach that is not in your Pascal> subdag can only be reached via the parents. Pascal> See section 8 of RPL 15, in particular: Pascal> As mentioned in Section 3.2.8, nodes that decide to join Pascal> a DODAG MUST provision at least one DODAG parent as a Pascal> default route for the associated instance. This default yes. I don't associate the words "default route" with a route to ::/0. It's the default for the "associated instance", which exists to fullful a particular set of constraints, etc. Do we agree here? So it might be the "default" for getting to 2001:PASC:ALSH::OUSE::/64, but it's not ::/0. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From alexandru.petrescu@gmail.com Fri Nov 19 12:19:39 2010 Return-Path: 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 3424A3A68D0 for ; Fri, 19 Nov 2010 12:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, 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 lCCsYUSzGQo0 for ; Fri, 19 Nov 2010 12:19:38 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 268723A6862 for ; Fri, 19 Nov 2010 12:19:36 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id A1E87940111 for ; Fri, 19 Nov 2010 21:20:21 +0100 (CET) Message-ID: <4CE6DBFD.5020608@gmail.com> Date: Fri, 19 Nov 2010 21:20:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: roll@ietf.org References: <4478C36E-968D-4E02-90C2-1B6471974622@gmail.com> <28506.1290178031@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D033C3954@XMB-AMS-107.cisco.com> <4627.1290194089@marajade.sandelman.ca> In-Reply-To: <4627.1290194089@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101119-0, 19/11/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] Implicit default routes in RPL 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: , X-List-Received-Date: Fri, 19 Nov 2010 20:19:39 -0000 Le 19/11/2010 20:14, Michael Richardson a écrit : > > thank you for the reply, I think we are in violent agreement? see > inline. > >>>>>> "Pascal" == Pascal >>>>>> Thubert<(pthubert)"> writes: > Pascal> Hi Ralph and Michael: > > Pascal> It is explicit in the text that the parents are used as > Pascal> default routers. The default route is required to go up the > Pascal> DAG till you hit a common ancestor. This comes with the fact > Pascal> that RPL maintains a minimum set of states and resort to the > Pascal> default route for whatever is not attached in a anode's > Pascal> subdag. The default route does not mean that the parents can > Pascal> reach the whole internet. A RIO might tell you that, or the > Pascal> G bit if the goal is to reach the internet. Rather, this > Pascal> means that whatever you want to reach that is not in your > Pascal> subdag can only be reached via the parents. > > > Pascal> See section 8 of RPL 15, in particular: > > Pascal> As mentioned in Section 3.2.8, nodes that decide to join > Pascal> a DODAG MUST provision at least one DODAG parent as a > Pascal> default route for the associated instance. This default > > yes. I don't associate the words "default route" with a route to > ::/0. That is conversationally wrong. In conversation (and in implemementation) one _should_ understand a default route as a ::/0 route, as a certain RFC points out, and as very long discussions and implementations agreed to. I am not the kind of person to correct others whatsoever, it is just that when we discuss and we try to understand one another we should use similar terminology. The use of the word "default" shoudl have a common meaning here with respect to routes, otherwise we risk talking for the pleasure of talking, an endeavour I do appreciate as well. In the RPL spec the words default route should mean ::/0 and nothing else, no more, no less. IMHO, Alex > It's the default for the "associated instance", which exists to > fullful a particular set of constraints, etc. Do we agree here? > > So it might be the "default" for getting to > 2001:PASC:ALSH::OUSE::/64, but it's not ::/0. > From rdroms.ietf@gmail.com Sat Nov 20 14:50:37 2010 Return-Path: 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 16E1F28C12B for ; Sat, 20 Nov 2010 14:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.762 X-Spam-Level: X-Spam-Status: No, score=-101.762 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] 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 9PgVisbKL9mw for ; Sat, 20 Nov 2010 14:50:36 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D7B8B28C12A for ; Sat, 20 Nov 2010 14:50:35 -0800 (PST) Received: by gwj23 with SMTP id 23so550964gwj.31 for ; Sat, 20 Nov 2010 14:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received :x-apple-mail-remote-attachments:in-reply-to:x-apple-mail-signature :subject:x-uniform-type-identifier:cc:mime-version:x-apple-base-url :date:message-id:to:content-transfer-encoding:x-apple-auto-saved :from:references:x-apple-mail-plain-text-draft:content-type :x-apple-windows-friendly:x-mailer; bh=QaelAcNqXbhsLkjhLwGMo4Hzms+j5Kikkvcb0SSs1Fk=; b=KJrDnBRuf+kCBNnPeIVYjLAfMgHyycT3MFLhEVdwnJrViFrYOsEGgQFkFpvhqyIKZh 6UAtLdRXhRzUdSMnX4MJZFVLsjzqGCFDTZJwodoHWILrFUyl9NSBFn0PPWIsBDFS3Iv7 NuXfclgC/OQ3S8j0KMUNA/dHC1MdzpsqKfQW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-apple-mail-remote-attachments:in-reply-to:x-apple-mail-signature :subject:x-uniform-type-identifier:cc:mime-version:x-apple-base-url :date:message-id:to:content-transfer-encoding:x-apple-auto-saved :from:references:x-apple-mail-plain-text-draft:content-type :x-apple-windows-friendly:x-mailer; b=DcAZYLUcRyBVgk4rX4CBrWQHgdWiFhaB2eFHYAlfs3LAaMJqQMyV1uF2yoH8okB4bN 2qOqmc/W/IT7+bWnxovSpskgpdyA+wQuzJr3WU4h4UDsvbCES7mBils29vsNEli6I7t9 plUb2xA3qT6YqN2oX1QBdpkwyNgN3khdpyARQ= Received: by 10.151.83.17 with SMTP id k17mr6208514ybl.311.1290293487272; Sat, 20 Nov 2010 14:51:27 -0800 (PST) Received: from [10.21.108.178] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id p20sm843121ybe.17.2010.11.20.14.51.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Nov 2010 14:51:26 -0800 (PST) X-Apple-Mail-Remote-Attachments: YES In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D033C3954@XMB-AMS-107.cisco.com> X-Apple-Mail-Signature: SKIP_SIGNATURE X-Uniform-Type-Identifier: com.apple.mail-draft Mime-Version: 1.0 (Apple Message framework v1081) X-Apple-Base-Url: x-msg://286/ Date: Sat, 20 Nov 2010 17:42:57 -0500 Message-Id: To: Pascal Thubert (pthubert) Content-Transfer-Encoding: quoted-printable X-Apple-Auto-Saved: 1 From: Ralph Droms References: <4478C36E-968D-4E02-90C2-1B6471974622@gmail.com> <28506.1290178031@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D033C3954@XMB-AMS-107.cisco.com> X-Apple-Mail-Plain-Text-Draft: yes Content-Type: text/html; charset=us-ascii X-Apple-Windows-Friendly: 1 X-Mailer: Apple Mail (2.1081) Cc: roll@ietf.org Subject: Re: [Roll] Implicit default routes in RPL 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: , X-List-Received-Date: Sat, 20 Nov 2010 22:50:37 -0000 Hi Ralph and = Michael:

It is explicit = in the text that the parents are used as default = routers.
The default route is = required to go up the DAG till you hit a = common
ancestor. This comes = with the fact that RPL maintains a minimum set = of
states and resort to the = default route for whatever is not attached in = a
anode's = subdag.

Right.  I understand about the routing = infrastructure and the setting of default routes for forwarding = "up" traffic.

The default route does = not mean that the parents can
reach the whole internet. A RIO might tell you that, or = the G bit if the
goal is to = reach the internet. Rather, this means that whatever you = want
to reach that is not in = your subdag can only be reached via the parents.

OK, = so a grounded DAG meets its goal and there is no implicit routing to = the Internet if the goal is not explicitly "route traffic to the = Internet".  If a grounded DAG, in addition to meeting its = goal, can route to the Internet, it would include an RIO with = prefix length =3D=3D 0, right?

How does a RPL mesh node determine = the goal for a specific grounded DAG?  I can imagine a RPL = mesh node would want to know the goal to choose among DAGs it might = join, or to select among DAGs for forwarding specific = traffic.

See section 8 of RPL 15, in = particular:

 As = mentioned in Section 3.2.8, nodes that decide to join a DODAG = MUST
 provision at least = one DODAG parent as a default route for the
 associated instance.  This default route = enables a packet to be
 forwarded upwards until it eventually hits a common = ancestor from
 which it = will be routed downwards to the destination.  If = the
 destination is not = in the DODAG, then the DODAG root may be able = to
 forward the packet = using connectivity to the outside of the DODAG; = if
 it cannot forward the = packet outside then the DODAG root has to = drop
 it.

But also the = text on RIO.

Cheers,

Pascal
http://www.xtranormal.com/watch/7011357/
- Ralph


-----Original = Message-----
From: roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] On = Behalf
Of
Michael = Richardson
Sent: Friday, November 19, 2010 = 3:47 PM
To: Ralph Droms
Cc: = roll@ietf.org
Subject: Re: [Roll] Implicit = default routes in RPL


"Ralph" = =3D=3D Ralph Droms <rdroms.ietf@gmail.com> = writes:
  Ralph> Is a DODAG root required to include = an RIO with prefix
length
  Ralph> 0 to indicate that it can act as a = default router to any
  Ralph> = destination outside the RPL Instance, or is that = capability
  Ralph> = implicit?

My understanding is that it is = not implicit, it must be = explicit.
Not all DODAG root's are = GROUNDED, and even if they are, they = might
not
provide reachability to the = "world".

--
]       He who is = tired of Weird Al is tired of life!           = |
firewalls =  [
]   Michael Richardson, Sandelman Software Works, = Ottawa, ON    |net
architect[
] mcr@sandelman.ottawa.on.ca = http://www.sandelman.ottawa.on.ca/
|device = driver[
 Kyoto Plus: watch the = video
<http://www.youtube.com/watch?v=3Dkzx1ycLXQSE>
=                then sign = the petition.
_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
<= /blockquote>
= From rdroms.ietf@gmail.com Sat Nov 20 14:50:43 2010 Return-Path: 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 78B7428C133 for ; Sat, 20 Nov 2010 14:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.737 X-Spam-Level: X-Spam-Status: No, score=-101.737 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] 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 OXSqpz9RCNp0 for ; Sat, 20 Nov 2010 14:50:42 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 6B9B028C134 for ; Sat, 20 Nov 2010 14:50:42 -0800 (PST) Received: by mail-gy0-f172.google.com with SMTP id 13so751180gyb.31 for ; Sat, 20 Nov 2010 14:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:x-apple-base-url:x-apple-mail-plain-text-draft:from :x-apple-mail-remote-attachments:in-reply-to :x-apple-windows-friendly:date:cc:content-transfer-encoding :message-id:references:x-uniform-type-identifier:to:x-mailer; bh=pOPJ+GmEaVvJksAAiXfiPfUp3VvmJhVH6PaVqkfiUWY=; b=Yn9/JDSdlEEglwrA/6Z2Kxki6ySYs3fxjCKSqvgy530/fhhg0a7iEgdqzi6hp7nt33 Ah3yl+lHdGgHQz3deSMMUaLP7v83QKA2ykOObq5gmW84QjEgJxxwm4tgo/fIx7i459yz TFqySB2iPGejm/GdItXRVk6dVe5OqY3mpssWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:x-apple-base-url :x-apple-mail-plain-text-draft:from:x-apple-mail-remote-attachments :in-reply-to:x-apple-windows-friendly:date:cc :content-transfer-encoding:message-id:references :x-uniform-type-identifier:to:x-mailer; b=XzzJh3J7e8j2sa3WwJX4f37t/AviuE9WdUFwk116be8vxkIf5jwKD6z9S/HluowQJ9 gzqUDfWrmvbE7r4Hmo78XPb7ltTemUxzjdRVL1SI59gn5ZqzAW+TfGh8wcQAOkqBiHIw xINH46fQmeiS0jYZ96/UYNIEo3I12CwgRLAsY= Received: by 10.150.191.16 with SMTP id o16mr6313966ybf.356.1290293494458; Sat, 20 Nov 2010 14:51:34 -0800 (PST) Received: from [10.21.108.178] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id p20sm843121ybe.17.2010.11.20.14.51.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Nov 2010 14:51:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/html; charset=iso-8859-1 X-Apple-Base-Url: x-msg://306/ X-Apple-Mail-Plain-Text-Draft: yes From: Ralph Droms X-Apple-Mail-Remote-Attachments: YES In-Reply-To: <4CE6DBFD.5020608@gmail.com> X-Apple-Windows-Friendly: 1 Date: Sat, 20 Nov 2010 17:46:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4478C36E-968D-4E02-90C2-1B6471974622@gmail.com> <28506.1290178031@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D033C3954@XMB-AMS-107.cisco.com> <4627.1290194089@marajade.sandelman.ca> <4CE6DBFD.5020608@gmail.com> X-Uniform-Type-Identifier: com.apple.mail-draft To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: roll@ietf.org Subject: Re: [Roll] Implicit default routes in RPL 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: , X-List-Received-Date: Sat, 20 Nov 2010 22:50:43 -0000 Alex = - can you give a specific pointer to text in an RFC that defines = "default route" as "::/0"?

- Ralph

On Nov 19, 2010, = at 3:20 PM 11/19/10, Alexandru Petrescu wrote:

Le 19/11/2010 20:14, Michael Richardson a =E9crit = :

thank you for the reply, I think = we are in violent agreement? = see
inline.

"Pascal"= =3D=3D = Pascal
Thubert<(pthubert)"<pthubert@cisco.com>> = writes:
Pascal>  Hi Ralph and = Michael:

Pascal>  It is explicit = in the text that the parents are used = as
Pascal>  default routers.  The default route = is required to go up the
Pascal>  DAG till you = hit a common ancestor. This comes with the = fact
Pascal>  that RPL maintains a minimum set of = states and resort to the
Pascal>  default route = for whatever is not attached in a = anode's
Pascal>  subdag. The default route does not mean = that the parents can
Pascal>  reach the whole = internet. A RIO might tell you that, or = the
Pascal>  G bit if the goal is to reach the = internet. Rather, this
Pascal>  means that = whatever you want to reach that is not in = your
Pascal>  subdag can only be reached via the = parents.


Pascal>  See section 8 = of RPL 15, in particular:

Pascal>     As = mentioned in Section 3.2.8, nodes that decide to = join
Pascal>  a DODAG MUST provision at least one DODAG = parent as a
Pascal>  default route = for the associated instance.  This = default

yes. I don't associate the words = "default route" with a route to
::/0.

That is = conversationally wrong.  In conversation (and = in
implemementation) one = _should_ understand a default route as a = ::/0
route, as a certain RFC = points out, and as very long discussions and
implementations agreed to.

I am not the = kind of person to correct others whatsoever, it is = just
that when we discuss and = we try to understand one another we should = use
similar = terminology.

The use of the = word "default" shoudl have a common meaning here = with
respect to routes, = otherwise we risk talking for the pleasure = of
talking, an endeavour I do = appreciate as well.

In the RPL spec = the words default route should mean ::/0 and = nothing
else, no more, no = less.

IMHO,

Alex

It's the default for the "associated instance", which = exists to
fullful a particular set of = constraints, etc. Do we agree = here?

So it might be the "default" for = getting to
2001:PASC:ALSH::OUSE::/64, but = it's not ::/0.


_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
<= br>= From alexandru.petrescu@gmail.com Sun Nov 21 12:09:50 2010 Return-Path: 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 100DE28C0CE for ; Sun, 21 Nov 2010 12:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, 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 LZUymcegqIFd for ; Sun, 21 Nov 2010 12:09:49 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 8341E3A690F for ; Sun, 21 Nov 2010 12:09:46 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 636B894016D; Sun, 21 Nov 2010 21:10:35 +0100 (CET) Message-ID: <4CE97CB9.1080505@gmail.com> Date: Sun, 21 Nov 2010 21:10:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ralph Droms References: <4478C36E-968D-4E02-90C2-1B6471974622@gmail.com> <28506.1290178031@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D033C3954@XMB-AMS-107.cisco.com> <4627.1290194089@marajade.sandelman.ca> <4CE6DBFD.5020608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101121-0, 21/11/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Implicit default routes in RPL 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: , X-List-Received-Date: Sun, 21 Nov 2010 20:09:50 -0000 Le 20/11/2010 23:46, Ralph Droms a écrit : > Alex - can you give a specific pointer to text in an RFC that defines > "default route" as "::/0"? Sure, RFC5156 "Special-Use IPv6 Addresses" (Informational) says: " 2.11. Default Route ::/0 is the default unicast route address." (a while ago there was discussion and implementations diverging between 2000::/3 and ::/0 as the default route, but now that RFC clarifies; it is for that reason I think it is good to stick to it; on another hand it may be that here the talk seems to be more generic about "default" routes as something different, not necessarily the IETF default route, not necessarily the widely implemented default route, which is something difficult to understand). Alex > > - Ralph > > On Nov 19, 2010, at 3:20 PM 11/19/10, Alexandru Petrescu wrote: > >> Le 19/11/2010 20:14, Michael Richardson a écrit : >>> >>> thank you for the reply, I think we are in violent agreement? >>> see inline. >>> >>>>>>>> "Pascal" == Pascal >>>>>>>> Thubert<(pthubert)"> writes: >>> Pascal> Hi Ralph and Michael: >>> >>> Pascal> It is explicit in the text that the parents are used as >>> Pascal> default routers. The default route is required to go up >>> the Pascal> DAG till you hit a common ancestor. This comes with >>> the fact Pascal> that RPL maintains a minimum set of states and >>> resort to the Pascal> default route for whatever is not attached >>> in a anode's Pascal> subdag. The default route does not mean >>> that the parents can Pascal> reach the whole internet. A RIO >>> might tell you that, or the Pascal> G bit if the goal is to >>> reach the internet. Rather, this Pascal> means that whatever you >>> want to reach that is not in your Pascal> subdag can only be >>> reached via the parents. >>> >>> >>> Pascal> See section 8 of RPL 15, in particular: >>> >>> Pascal> As mentioned in Section 3.2.8, nodes that decide to join >>> Pascal> a DODAG MUST provision at least one DODAG parent as a >>> Pascal> default route for the associated instance. This default >>> >>> yes. I don't associate the words "default route" with a route to >>> ::/0. >> >> That is conversationally wrong. In conversation (and in >> implemementation) one _should_ understand a default route as a >> ::/0 route, as a certain RFC points out, and as very long >> discussions and implementations agreed to. >> >> I am not the kind of person to correct others whatsoever, it is >> just that when we discuss and we try to understand one another we >> should use similar terminology. >> >> The use of the word "default" shoudl have a common meaning here >> with respect to routes, otherwise we risk talking for the pleasure >> of talking, an endeavour I do appreciate as well. >> >> In the RPL spec the words default route should mean ::/0 and >> nothing else, no more, no less. >> >> IMHO, >> >> Alex >> >>> It's the default for the "associated instance", which exists to >>> fullful a particular set of constraints, etc. Do we agree here? >>> >>> So it might be the "default" for getting to >>> 2001:PASC:ALSH::OUSE::/64, but it's not ::/0. >>> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From gnawali@cs.stanford.edu Sun Nov 21 17:58:20 2010 Return-Path: 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 39B823A6936 for ; Sun, 21 Nov 2010 17:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Ks09GXo5zIJr for ; Sun, 21 Nov 2010 17:58:19 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 651913A6933 for ; Sun, 21 Nov 2010 17:58:19 -0800 (PST) Received: from mail-iw0-f174.google.com ([209.85.214.174]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1PKLgX-0006to-EV for roll@ietf.org; Sun, 21 Nov 2010 17:59:14 -0800 Received: by iwn34 with SMTP id 34so2259085iwn.19 for ; Sun, 21 Nov 2010 17:59:12 -0800 (PST) Received: by 10.231.39.198 with SMTP id h6mr6230713ibe.21.1290391151801; Sun, 21 Nov 2010 17:59:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.143.131 with HTTP; Sun, 21 Nov 2010 17:58:51 -0800 (PST) From: Omprakash Gnawali Date: Sun, 21 Nov 2010 17:58:51 -0800 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 34530ccd932157cd24ba9d2c27818ca4 Cc: roll WG Subject: [Roll] Questions/comments on draft-ietf-roll-of0-03.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: , X-List-Received-Date: Mon, 22 Nov 2010 01:58:20 -0000 Thanks for the new version of OF0 draft. My biggest concern with OF0 is it would compute min-hop routes. There are many research results and deployment experiences suggesting that min-hop routing is not a good idea in wireless routing. The draft notes: "Using a metric that in essence is similar to hop count implies that the quality of the connectivity should be asserted so that only neighbors with a good enough connectivity are presented to the OF. How that connectivity is asserted and maintained is out of scope." and: " Hop count used in wireless networks will tend to favor paths with long distance links and non optimal connectivity properties. As a result, the link selection must be very conservative, and the available link set is thus constrained. In some situations, this might end up partitioning the network. For those reasons, the use of hop count only is generally not recommended in wireless networks." I appreciate mentioning these dangers of OF0 and suggesting that white-listed links (white-listing is claimed to be out of scope of this draft and not sure where I can go read how white-listing is done) might be able to address some of these dangers. It is unclear how helpful white-listing is. Right now there is no evidence that OF0-based routing will actually work. It will be great to look at some arguments or evidence that this is a reasonable way to do routing for RPL. "The metric used in OF0 is the RPL Rank, as defined in [I-D.ietf-roll-rpl]." I am not sure if Rank is defined as a metric. It might be good to be precise here. Some comment on how these values are determined would be helpful: MinHopRankIncrease: 256 DEFAULT_RANK_INCREMENT: 4 * MinHopRankIncrease MINIMUM_RANK_INCREMENT: 1 * MinHopRankIncrease MAXIMUM_RANK_INCREMENT: 16 * MinHopRankIncrease MAXIMUM_RANK_STRETCH: 4 * MinHopRankIncrease - om_p On Thu, Nov 18, 2010 at 2:41 PM, JP Vasseur wrote: > Dear all, > > draft-ietf-roll-of0-03.txt has now been stable for some time. > > This starts a 3-week WG Last Call on draft-ietf-roll-of0-03.txt that will end on December 10 at noon ET. > > Please send your comment to the authors and copy the list. > > We would also appreciate (off-list if you prefer) feed-back on implementations. > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Mon Nov 22 01:52:39 2010 Return-Path: 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 ED3703A6A84 for ; Mon, 22 Nov 2010 01:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.188 X-Spam-Level: X-Spam-Status: No, score=-10.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 YXNKwBYU37YJ for ; Mon, 22 Nov 2010 01:52:38 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D0F773A6A81 for ; Mon, 22 Nov 2010 01:52:38 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAIbM6UyrR7Hu/2dsb2JhbACUET+OBXGgLI1+jFGFSwSNcg X-IronPort-AV: E=Sophos;i="4.59,235,1288569600"; d="scan'208";a="290288412" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2010 09:53:34 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oAM9rFMe023375; Mon, 22 Nov 2010 09:53:33 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Nov 2010 10:53:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Nov 2010 10:53:28 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D033C3C51@XMB-AMS-107.cisco.com> In-Reply-To: <4627.1290194089@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Implicit default routes in RPL Thread-Index: AcuIHhKwCpWpbEXhRD6czoyL+goiigCClk3g References: <4478C36E-968D-4E02-90C2-1B6471974622@gmail.com> <28506.1290178031@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D033C3954@XMB-AMS-107.cisco.com> <4627.1290194089@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 22 Nov 2010 09:53:33.0244 (UTC) FILETIME=[1FD487C0:01CB8A2B] Cc: roll@ietf.org Subject: Re: [Roll] Implicit default routes in RPL 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: , X-List-Received-Date: Mon, 22 Nov 2010 09:52:40 -0000 > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] > Sent: Friday, November 19, 2010 8:15 PM > To: Pascal Thubert (pthubert) > Cc: Ralph Droms; roll@ietf.org > Subject: Re: [Roll] Implicit default routes in RPL >=20 >=20 > thank you for the reply, I think we are in violent agreement? > see inline. [Pascal] Yes, I think we are : ) =20 > >>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" = > > writes: > Pascal> Hi Ralph and Michael: >=20 > Pascal> It is explicit in the text that the parents are used as > Pascal> default routers. The default route is required to go up the > Pascal> DAG till you hit a common ancestor. This comes with the fact > Pascal> that RPL maintains a minimum set of states and resort to the > Pascal> default route for whatever is not attached in a anode's > Pascal> subdag. The default route does not mean that the parents can > Pascal> reach the whole internet. A RIO might tell you that, or the > Pascal> G bit if the goal is to reach the internet. Rather, this > Pascal> means that whatever you want to reach that is not in your > Pascal> subdag can only be reached via the parents. >=20 >=20 > Pascal> See section 8 of RPL 15, in particular: >=20 > Pascal> As mentioned in Section 3.2.8, nodes that decide to join > Pascal> a DODAG MUST provision at least one DODAG parent as a > Pascal> default route for the associated instance. This default >=20 > yes. I don't associate the words "default route" with a route > to ::/0. It's the default for the "associated instance", which exists > to fullful a particular set of constraints, etc. > Do we agree here? >=20 > So it might be the "default" for getting to 2001:PASC:ALSH::OUSE::/64, but it's > not ::/0. [Pascal] This certainly makes sense to me. What the default route really does is act as a default in a switch/case statement when no longer match is found, and does not provide a guarantee that the whole internet is reachable. For the time being, the RPL base spec does not specify a way to control the "default" in a RPL instance, but it does not bar that from being done either. The default "default" is ::/0, so for the rime being you will probably install ::/0 in the routing table. Further specs can be expected to come in like an OF with a scoped behavior that overloads "default" with a lower scope, a ULA domain, or an ISP aggregation, as you propose above. This can help sorting out instances when multiple are available for an incoming packet. =20 Best, Pascal > -- > ] He who is tired of Weird Al is tired of life! | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ > |device driver[ > Kyoto Plus: watch the video > > then sign the petition. From jpv@cisco.com Mon Nov 22 01:58:35 2010 Return-Path: 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 195693A6A81 for ; Mon, 22 Nov 2010 01:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 C8aH-5gr64+6 for ; Mon, 22 Nov 2010 01:58:33 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 94CBE3A6A63 for ; Mon, 22 Nov 2010 01:58:33 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHnN6UyrRN+K/2dsb2JhbACiVXGIK5gDmk+CfBAGgjkEil6DDgaHeQ X-IronPort-AV: E=Sophos;i="4.59,235,1288569600"; d="scan'208,217";a="623932358" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 22 Nov 2010 09:59:28 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id oAM9x2L8029543 for ; Mon, 22 Nov 2010 09:59:28 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Nov 2010 10:58:56 +0100 Received: from [64.103.30.193] ([64.103.30.193]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Nov 2010 10:58:56 +0100 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-45-719701791 Date: Mon, 22 Nov 2010 08:47:10 +0100 X-Priority: 3 References: <226723849.1290165458629.JavaMail.nobody@jsj6wl006.webex.com> To: ROLL WG Message-Id: <4E84436B-E5E0-4BF6-BFB1-A5874D473F74@cisco.com> X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 22 Nov 2010 09:58:56.0160 (UTC) FILETIME=[E04D9A00:01CB8A2B] Subject: [Roll] Details (webex) for the Interim ROLL Working Group Meeting - Dec 20 at 8:00am PST - 11:00am ET - 5pm CET 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: , X-List-Received-Date: Mon, 22 Nov 2010 09:58:35 -0000 --Apple-Mail-45-719701791 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, This is to announce a (virtual) ROLL Working Group meeting that will = take place on Dec 20 - details below. There will also be an official announcement. The objective is to continue our discussion on the re-chartering process = according to the timeframe that we discussed during the ROLL WG meeting = in Beijing. Date: December 20 Time: 8:00am PST =3D Noon ET =3D 6pm CET Duration =3D 90mn Agenda: Discussion on ROLL WG re-chartering process Location: This will be a Webex to be announced on the ROLL Mailing List = (let me know if you need the details). If you have an item that you would like to discuss, feel free to send = slide(s) to the chairs and we will put them together. If you do not mind, please send a short unicast ACK to chairs if you = plan to attend. Thanks JP. > Hello ,=20 >=20 > Jean Philippe Vasseur invites you to attend this online meeting.=20 >=20 > Topic: Meeting Center MPV=20 > Date: Monday, December 20, 2010=20 > Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)=20 > Meeting Number: 205 313 548=20 > Meeting Password: ROLLWG=20 >=20 >=20 > -------------------------------------------------------=20 > To join the online meeting (Now from the Apple iPhone (R) and other = smartphones!)=20 > -------------------------------------------------------=20 > 1. Go to = https://ciscosales.webex.com/ciscosales/j.php?ED=3D153700042&UID=3D0&PW=3D= NM2E1NmQ0YWNj&RT=3DMiM0=20 > 2. Enter your name and email address.=20 > 3. Enter the meeting password: ROLLWG=20 > 4. Click "Join Now".=20 >=20 > To view in other time zones or languages, please click the link:=20 > = https://ciscosales.webex.com/ciscosales/j.php?ED=3D153700042&UID=3D0&PW=3D= NM2E1NmQ0YWNj&ORT=3DMiM0=20 >=20 > ----------------------------------------------------------------=20 > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=20 > ----------------------------------------------------------------=20 >=20 > The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.=20 >=20 > Please dial the local access number for your area from the list below:=20= > - San Jose/Milpitas (408) area: 525-6800=20 > - RTP (919) area: 392-3330=20 >=20 > -------------------------------------------------------=20 > To join the teleconference only=20 > -------------------------------------------------------=20 > 1. Dial into Cisco WebEx (view all Global Access Numbers at=20 > http://cisco.com/en/US/about/doing_business/conferencing/index.html=20 > 2. Follow the prompts to enter the Meeting Number (listed above) or = Access Code followed by the # sign.=20 >=20 > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 >=20 > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 >=20 > India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 >=20 > Japan: +81.3.5763.9394 China: +86.10.8515.5666=20 >=20 > -------------------------------------------------------=20 > For assistance=20 > -------------------------------------------------------=20 > 1. Go to https://ciscosales.webex.com/ciscosales/mc=20 > 2. On the left navigation bar, click "Support".=20 >=20 > You can contact me at:=20 > jvasseur@cisco.com=20 > 33-15-804 3494=20 >=20 > To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 > = https://ciscosales.webex.com/ciscosales/j.php?ED=3D153700042&UID=3D0&ICS=3D= MI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DWDmY5mD1qAFnuRHqjuIpR7j3ficN0ePHEYGsuaNy1ac= =3D&RT=3DMiM0=20 >=20 > The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to = https://ciscosales.webex.com/ciscosales/systemdiagnosis.php=20 >=20 > Sign up for a free trial of WebEx=20 > http://www.webex.com/go/mcemfreetrial=20 >=20 > http://www.webex.com=20 >=20 > CCP:+14085256800x205313548#=20 >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation.=20 --Apple-Mail-45-719701791 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

This is to announce a (virtual) ROLL Working = Group meeting that will take place on Dec 20 - details = below.

There will also be an official = announcement.

The objective is to continue our = discussion on the re-chartering process according to the timeframe that = we discussed during the ROLL WG meeting in = Beijing.

Date: December = 20
Time: 8:00am PST =3D Noon ET =3D 6pm = CET
Duration =3D 90mn
Agenda: = Discussion on ROLL WG re-chartering process
Location: = This will be a Webex to be announced on the ROLL Mailing List (let me = know if you need the details).

If you have an item that = you would like to discuss, feel free to send slide(s) to the chairs and = we will put them together.

If you do not mind, = please send a short unicast ACK to chairs if you plan to = attend.

Thanks

JP.<= /div>

Hello ,

Jean = Philippe Vasseur invites you to attend this online meeting.

= Topic: Meeting Center MPV
Date: Monday, December 20, 2010
= Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
= Meeting Number: 205 313 548
Meeting Password: ROLLWG


= -------------------------------------------------------
To join the = online meeting (Now from the Apple iPhone (R) and other smartphones!) =
-------------------------------------------------------
1. Go = to https://ciscosales.webex.com/ciscosales/j.php?ED=3D15370= 0042&UID=3D0&PW=3DNM2E1NmQ0YWNj&RT=3DMiM0
2. Enter = your name and email address.
3. Enter the meeting password: ROLLWG =
4. Click "Join Now".

To view in other time zones or = languages, please click the link:
https://ciscosales.webex.com/ciscosales/j.php?ED=3D15370= 0042&UID=3D0&PW=3DNM2E1NmQ0YWNj&ORT=3DMiM0

= ----------------------------------------------------------------
= ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
= ----------------------------------------------------------------
=
The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please = dial the local access number for your area from the list below:
- = San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330 =

-------------------------------------------------------
= To join the teleconference only
= -------------------------------------------------------
1. Dial = into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing= /index.html
2. Follow the prompts to enter the Meeting Number = (listed above) or Access Code followed by the # sign.

San = Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: = +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: = +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: = +81.3.5763.9394 China: +86.10.8515.5666

= -------------------------------------------------------
For = assistance
------------------------------------------------------- =
1. Go to https://ciscosales.webex.com/ciscosales/mc
2. = On the left navigation bar, click "Support".

You can contact = me at:
jvasseur@cisco.com =
33-15-804 3494

To add this meeting to your calendar = program (for example Microsoft Outlook), click this link:
https://ciscosales.webex.com/ciscosales/j.php?ED=3D15370= 0042&UID=3D0&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3D= WDmY5mD1qAFnuRHqjuIpR7j3ficN0ePHEYGsuaNy1ac=3D&RT=3DMiM0
=
The playback of UCF (Universal Communications Format) rich media = files requires appropriate players. To view this type of rich media = files in the meeting, please check whether you have the players = installed on your computer by going to https://ciscosales.webex.com/ciscosales/systemdiagnosis.= php

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com =

CCP:+14085256800x205313548#

IMPORTANT NOTICE: This = WebEx service includes a feature that allows audio and any documents and = other materials exchanged or viewed during the session to be recorded. = By joining this session, you automatically consent to such recordings. = If you do not consent to the recording, discuss your concerns with the = meeting host prior to the start of the recording or do not join the = session. Please note that any such recordings may be subject to = discovery in the event of litigation.
=

= --Apple-Mail-45-719701791-- From qiuying@i2r.a-star.edu.sg Mon Nov 22 03:04:21 2010 Return-Path: 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 0C8DD3A6A87 for ; Mon, 22 Nov 2010 03:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stFbtj2E-FcF for ; Mon, 22 Nov 2010 03:04:18 -0800 (PST) Received: from gw3.scei.a-star.edu.sg (gw3.scei.a-star.edu.sg [192.122.140.12]) by core3.amsl.com (Postfix) with ESMTP id D03233A699E for ; Mon, 22 Nov 2010 03:04:13 -0800 (PST) Received: from mailfe01.teak.local.net ([10.217.253.173]) by gw3.scei.a-star.edu.sg (8.14.3/8.14.3) with ESMTP id oAMB56Uh008503; Mon, 22 Nov 2010 19:05:06 +0800 Received: from Win7PC ([10.217.141.124]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Nov 2010 19:04:35 +0800 From: "QIU Ying" To: "'Shoichi Sakane'" , References: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> <4CE1C813.60805@tanu.org> In-Reply-To: <4CE1C813.60805@tanu.org> Date: Mon, 22 Nov 2010 19:08:42 +0800 Message-ID: <024601cb8a35$9f851570$de8f4050$@a-star.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuFIFYXzGboQaiyRxe0QV5M8alGjgFCrkyg Content-Language: en-sg X-OriginalArrivalTime: 22 Nov 2010 11:04:35.0771 (UTC) FILETIME=[0C7E88B0:01CB8A35] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-11-22_05:2010-11-22, 2010-11-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1010190000 definitions=main-1011220039 Subject: Re: [Roll] FW: New Version Notification for draft-qiu-6lowpan-secure-router-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: , X-List-Received-Date: Mon, 22 Nov 2010 11:04:21 -0000 Thank Shoichi for clarifying and summarising this protocol. Shoichi pointed out a very important issue how to establish the secure session between N and Rm when the node bootstraps. The issue could be solved by using Rm instead of RT in REQ message. After bootstrapping, the sensor node N sends its first request to Base station as below: REQ = {Src=SN, Dst= BS, Rm||R0||MAC(K_BN, SN||RT||R0)} Hence, the BS will return APPV message to Rm. Upon receiving the notice from Rm, the sensor node could establish the secure session with Rm by normal processing. The responses for other issues mentioned in previous email: - What is the identifier of each node. A: For simple, the ID could the node's address. - How to provision each identifier into each node. A: the IDs of nodes should be assigned (auto/manual) before deployment. I am not sure if DHCP is suitable for WSN since it requires more cost in term of communication and computing. - How does N know the address of B. A: N should carry one or more addresses of the trust base stations before deployment. - Any message encoding format. A: to be fed in future version. - Any specific message authentication code algorithm and encryption algorithm. A: to be fed in future version. - under a certain environment which is "a single trust domain" A: I cannot understand very well why must be "a single trust domain"? In multiple domain networks, each node address should include the prefix of the domain. With the prefix, a base station or key centre could distinguish each node and avoid any confliction. Maybe I missed something. Regards and Thanks Qiu Ying > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Shoichi Sakane > Sent: Tuesday, November 16, 2010 7:54 AM > To: roll@ietf.org > Subject: Re: [Roll] FW: New Version Notification for draft-qiu-6lowpan- > secure-router-01 > > Carsten, JP, and All, > > On 10/27/10 7:22 PM, QIU Ying wrote: > > http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt > > > > The title of the draft had been changed to "Lightweight Key > Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)" > instead of "Lightweight Secure Router Protocol" in order to make the work > more clearly. It will be presented at ROLL WG. > > > > > Any comments are appreciated. > > I talked with Ying Qiu, the author of KEMP. > > Here is my understanding after the discussion. He proposes a > method to create a session key between the mobile node (N) and > the next hop router (R). This document seems not define the > concrete way to use the session key. However, this proposal > would be reasonable scheme under a certain environment which is > "a single trust domain" as Rene mentioned, and where B is able > to verify whether a node was compromised. > > == Model == > > N moves among a wireless network. N has to be authenticated > by an immediate neighbor router (R) before sending any > message to another node (e.g. N2). In the network, there is an > authorization server (B) which authorizes all nodes including > N. It generates key materials for a session key of both N and R. > When N is moving to around the next router (Rn), N has to send > a request to B through R in order to get a next shared session > key with Rn. > > ____________ > / \ > / _______B-----N2 > Rn / / > R / > ... / > .. / > . / > N ====== Rm > > ===: verified session > ---: not concerned of this protocol, it may be secured. > ...: session to be verified. > > > == Assumption == > > N shares a pre-shared key with B. N shares a session key with > the neighbor router (Rm) somehow before N initiates this protocol. > Rm just forwards a request from N to B, and is not always needed > if the request directly rearches at B. > N has to know that the next neighbor router will be R. > It is like a manner of the handover mechanism. > N has to have more than one neighbor rouers at same time. > One is Rm to send REQ, another is R to get NOTICE, which are > explained below. > > == What is missing of this proposal == > > - What is the identifier of each node. > - How to provision each identifier into each node. > - How does N know the address of B. > - How to establish the secure session between N and Rm. > - Any message encoding format. > - Any specific message authentication code algorithm, and > encryption algorithm. > > == How to securely share a session key between N and R == > > +--------+ > +------------- | R | <------------+ > | +--------+ | > 6)NOTICE | | 4)APPV > v | > +--------+ 1)REQ +--------+ +--------+ > | N |---------->| Rm |--------->| B | > +--------+ +--------+ +--------+ > > 1) N sends a request (REQ) to B through Rm. Rm just forwards REQ > to B. Rm is not always needed if REQ directly reach at B. > > REQ = {Src=SN, Dst= BS, RT||R0||MAC(K_BN, SN||RT||R0)} > > SN,RT,BS: identifier of each node > R0: random number generated by N > MAC: a message authentication code > K_BN: a shared key between B and N > > 2) B verifies the identifier of N (SN), and knows that the request > is for R (RT). > > 3) B generates a session key K_NR for N and R. > > K_NR = H(K_BN, SN||R0||R1) > > R1: random number generated by B > > B encrypts the message contained K_NR by K_BR. > > 4) B sends an approval (APPV) to R. > > APPV = {Src=BS, Dst=RT, E(K_BR, SN||R0||R1||K_NR)} > > E: an encryption algorithm > > 5) R decrypts the payload encrypted by K_BR, and gets > the identifier of N (SN) and a session key K_NR. > > 6) R sends a notice (NOTICE) to N. > > NOTICE = {Src=RT, Dst=SN, R0||R1||MAC(K_NR, RT||SN||R0||R1)} > > 7) N calculates a session key K_NR. > > K_NR = H(K_BN, SN||R0||R1) > > To check the MAC, N verifies NOTICE was from R wchich was > authorized by B. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From pthubert@cisco.com Mon Nov 22 03:59:55 2010 Return-Path: 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 B5C803A6AD7 for ; Mon, 22 Nov 2010 03:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 b499Fb6rlkmF for ; Mon, 22 Nov 2010 03:59:50 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4300B3A6AD5 for ; Mon, 22 Nov 2010 03:59:50 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAErq6UxAaMHG/2dsb2JhbACiVXGgaZpzhUsEjXKIBg X-IronPort-AV: E=Sophos;i="4.59,235,1288569600"; d="scan'208";a="383469699" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 22 Nov 2010 12:00:45 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAMC0Vcv023491; Mon, 22 Nov 2010 12:00:40 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Nov 2010 13:00:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Nov 2010 13:00:30 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D033C3D3F@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions/comments on draft-ietf-roll-of0-03.txt Thread-Index: AcuJ6N6q3BANRoAnQtmr9p27wCF9twAQkfzA References: From: "Pascal Thubert (pthubert)" To: "Omprakash Gnawali" X-OriginalArrivalTime: 22 Nov 2010 12:00:34.0529 (UTC) FILETIME=[DE785510:01CB8A3C] Cc: roll WG Subject: Re: [Roll] Questions/comments on draft-ietf-roll-of0-03.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: , X-List-Received-Date: Mon, 22 Nov 2010 11:59:55 -0000 Hi Om: Thanks a lot for your review; please see inline. > My biggest concern with OF0 is it would compute min-hop routes. There are > many research results and deployment experiences suggesting that min-hop > routing is not a good idea in wireless routing. [Pascal] Yes, quite explicitly.=20 But please remember that RPL is not designed only for a certain radio. RPL is L2-agnostic, and is supposed to also operate on wires and wire emulations. > The draft notes: >=20 > "Using a metric that in essence is similar to > hop count implies that the quality of the connectivity should be > asserted so that only neighbors with a good enough connectivity are > presented to the OF. How that connectivity is asserted and > maintained is out of scope." >=20 > and: >=20 > " Hop count used in wireless networks will tend to favor paths with > long distance links and non optimal connectivity properties. As a > result, the link selection must be very conservative, and the > available link set is thus constrained. In some situations, this > might end up partitioning the network. For those reasons, the use of > hop count only is generally not recommended in wireless networks." >=20 >=20 > I appreciate mentioning these dangers of OF0 and suggesting that white- > listed links (white-listing is claimed to be out of scope of this draft and not > sure where I can go read how white-listing is > done) might be able to address some of these dangers. It is unclear how > helpful white-listing is. [Pascal] The 802.11 association is an example of white listing. The real world suggests that it is quite useful.=20 > Right now there is no evidence that OF0-based routing will actually work. It > will be great to look at some arguments or evidence that this is a reasonable > way to do routing for RPL. [Pascal] Isn't there? On the contrary, I'd assert that there are (tens of) years of experience in Distance Vector that indicate that a weighted hop count can be very useful. The weighted hop count is the dominant metric in the world today, and OF0 enables to use RPL as an alternate protocol in networks where other IGPs operate yet are not optimum. A typical example would be a (recursively) hub and spoke network. There are also years of practical experience on something very similar to RPL/OF0 applied to wired links and more controlled radios, such as WIFI infrastructure mode. You might want to look up work on Layer 3 meshes and MANEMO for instance. Experience strongly suggest not to use hop count in 802.15.4 or any other "adhoc" radios. If the text in OF0 is not clear enough on that, then suggestions are welcome : ) > "The metric used in OF0 is the RPL Rank, as defined in > [I-D.ietf-roll-rpl]." >=20 > I am not sure if Rank is defined as a metric. It might be good to be precise > here. >=20 [Pascal] Agreed. The Rank is simply analogous to the metric but conceptually they are different beasts.=20 What do you think of : " The metric used in OF0 is an administratively defined scalar cost that is trivially added up along a path to compute the RPL Rank, as defined in [I-D.ietf-roll-rpl]. As a result, the Rank if a node is analogous to a weighted hop count of the path to the root. "=20 ? > Some comment on how these values are determined would be helpful: >=20 > MinHopRankIncrease: 256 > DEFAULT_RANK_INCREMENT: 4 * MinHopRankIncrease > MINIMUM_RANK_INCREMENT: 1 * MinHopRankIncrease > MAXIMUM_RANK_INCREMENT: 16 * MinHopRankIncrease > MAXIMUM_RANK_STRETCH: 4 * MinHopRankIncrease [Pascal] Those numbers come from the classical experience for hop count used in DV.=20 RPL is designed to control count to infinity so we do allow more than RIP's 16 hops.=20 Yet, 16 hops max stays the default behavior, and 256 ops is the max OF0 can allow. This enables compression of the Rank Floor() in one octet which is a desirable goal. - Anything wrong with those values? - Do you think we should add text like the above in the spec ? Cheers, Pascal >=20 > - om_p >=20 > On Thu, Nov 18, 2010 at 2:41 PM, JP Vasseur wrote: > > Dear all, > > > > draft-ietf-roll-of0-03.txt has now been stable for some time. > > > > This starts a 3-week WG Last Call on draft-ietf-roll-of0-03.txt that will end > on December 10 at noon ET. > > > > Please send your comment to the authors and copy the list. > > > > We would also appreciate (off-list if you prefer) feed-back on > implementations. > > > > Thanks. > > > > JP. > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > From pthubert@cisco.com Mon Nov 22 04:27:10 2010 Return-Path: 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 D686C3A6A4A for ; Mon, 22 Nov 2010 04:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.246 X-Spam-Level: X-Spam-Status: No, score=-10.246 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 7O-DjmKEdNka for ; Mon, 22 Nov 2010 04:27:06 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C06A53A69B1 for ; Mon, 22 Nov 2010 04:27:01 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFANvw6UyrR7Ht/2dsb2JhbACCAKBVcaBnmnWFSwSNcg X-IronPort-AV: E=Sophos;i="4.59,235,1288569600"; d="scan'208,217";a="290329914" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2010 12:27:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAMCRdgc023927; Mon, 22 Nov 2010 12:27:57 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Nov 2010 13:27:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8A40.AF183029" Date: Mon, 22 Nov 2010 13:27:48 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D033C3D73@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Implicit default routes in RPL Thread-Index: AcuJBXlL6GxvCNvbRcu7XOC2K20QyABOLg8g References: <4478C36E-968D-4E02-90C2-1B6471974622@gmail.com> <28506.1290178031@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D033C3954@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Ralph Droms" X-OriginalArrivalTime: 22 Nov 2010 12:27:53.0431 (UTC) FILETIME=[AF54EE70:01CB8A40] Cc: roll@ietf.org Subject: Re: [Roll] Implicit default routes in RPL 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: , X-List-Received-Date: Mon, 22 Nov 2010 12:27:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB8A40.AF183029 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ralph: =20 =20 The default route does not mean that the parents can reach the whole internet. A RIO might tell you that, or the G bit if the goal is to reach the internet. Rather, this means that whatever you want to reach that is not in your subdag can only be reached via the parents. OK, so a grounded DAG meets its goal and there is no implicit routing to the Internet if the goal is not explicitly "route traffic to the Internet". If a grounded DAG, in addition to meeting its goal, can route to the Internet, it would include an RIO with prefix length =3D=3D = 0, right? [Pascal] Right. With RPL, a node multiple hops away can select a root just like with RFC 4191, it would select a default gateway over a transit network. The preference bits can be used to indicate the preferred exit for a destination, which for RPL becomes the preferred DODAG. How does a RPL mesh node determine the goal for a specific grounded DAG? I can imagine a RPL mesh node would want to know the goal to choose among DAGs it might join, or to select among DAGs for forwarding specific traffic. [Pascal] RPL base spec is a generic protocol that is really instantiated when coupled with an Objective Function and metrics. RPL base does not use the G bit, but transports it as a generically useful tool for the OF. As you figured, the idea is that there can an abstract goal, or objective, that the OF needs to fulfill, and that only a subset of the nodes acting as root may do so. An example can be connecting to some uplink either to the Internet, to a given service provider, etc... A goal can also be a collection point like an intermediate server in a Pub/Sub deployment. So, even if it is abstract to RPL base, the meaning of Grounded must be very explicit in the Objective Function. =20 Pascal =20 ------_=_NextPart_001_01CB8A40.AF183029 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ralph:

 

 

The default route does not mean that the parents = can

reach the whole internet. A RIO might tell you that, = or the G bit if the

goal = is to reach the internet. Rather, this means that whatever you = want

to = reach that is not in your subdag can only be reached via the = parents.


OK, so a = grounded DAG meets its goal and there is no implicit routing to = the Internet if the goal is not explicitly "route traffic to = the Internet".  If a grounded DAG, in addition to meeting = its goal, can route to the Internet, it would include an RIO with = prefix length =3D=3D 0, right?

[Pascal] Right. With RPL, a node multiple hops away can select a root = just like with RFC 4191, it would select a default gateway over a = transit network. The preference bits can be used to indicate the = preferred exit for a destination, which for RPL becomes the preferred = DODAG.


How does a = RPL mesh node determine the goal for a specific grounded DAG?  I = can imagine a RPL mesh node would want to know the goal to choose = among DAGs it might join, or to select among DAGs for forwarding = specific traffic.

[Pascal]  RPL base spec is a generic protocol that is really = instantiated when coupled with an Objective Function and metrics. RPL = base does not use the G bit, but transports it as a generically useful = tool for the OF.

As you figured, the idea is that there can an abstract goal, or = objective, that the OF needs to fulfill, and that only a subset of the = nodes acting as root may do so. An example can be connecting to some = uplink either to the Internet, to a given service provider, etc… A = goal can also be a collection point like an intermediate server in a = Pub/Sub deployment. So, even if it is abstract to RPL base, the meaning = of Grounded must be very explicit in the Objective = Function.

 


Pascal

 

------_=_NextPart_001_01CB8A40.AF183029-- From iesg-secretary@ietf.org Mon Nov 22 08:35:13 2010 Return-Path: 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 ED01628C116; Mon, 22 Nov 2010 08:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 RtJ6sQv5nLf0; Mon, 22 Nov 2010 08:35:12 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F913A6A3E; Mon, 22 Nov 2010 08:35:12 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101122163512.4979.96571.idtracker@localhost> Date: Mon, 22 Nov 2010 08:35:12 -0800 Cc: roll@ietf.org Subject: [Roll] Last Call: (The Trickle Algorithm) to Proposed Standard 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: , X-List-Received-Date: Mon, 22 Nov 2010 16:35:13 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'The Trickle Algorithm' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-12-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-trickle/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-trickle/ No IPR declarations have been submitted directly on this I-D. From pal@cs.stanford.edu Mon Nov 22 11:13:39 2010 Return-Path: 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 C065828C13E for ; Mon, 22 Nov 2010 11:13:39 -0800 (PST) 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 vgN4Pgs0l87Y for ; Mon, 22 Nov 2010 11:13:38 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id AADBB3A69C2 for ; Mon, 22 Nov 2010 11:13:38 -0800 (PST) Received: from [76.14.65.187] (helo=[192.168.1.106]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PKbqU-0006Qc-Ge; Mon, 22 Nov 2010 11:14:35 -0800 In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D033C3D3F@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5D033C3D3F@XMB-AMS-107.cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61ABA820-3372-48CF-8774-7A0FC59A05F8@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Mon, 22 Nov 2010 11:14:33 -0800 To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: be0aabe7ab5d744b5094b96e60b5df0f Cc: roll WG Subject: Re: [Roll] Questions/comments on draft-ietf-roll-of0-03.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: , X-List-Received-Date: Mon, 22 Nov 2010 19:13:39 -0000 On Nov 22, 2010, at 4:00 AM, Pascal Thubert (pthubert) wrote: > Hi Om: > > Thanks a lot for your review; please see inline. > >> My biggest concern with OF0 is it would compute min-hop routes. There > are >> many research results and deployment experiences suggesting that > min-hop >> routing is not a good idea in wireless routing. > > [Pascal] Yes, quite explicitly. > But please remember that RPL is not designed only for a certain radio. > RPL is L2-agnostic, and is supposed to also operate on wires and wire > emulations. Sure -- but I think the issues hopcount runs into are predominantly due to the lossy nature of communication: RPL is for LLNs. Is there experience on using hopcount (in an interoperable way) in LLNs? > >> The draft notes: >> >> "Using a metric that in essence is similar to >> hop count implies that the quality of the connectivity should be >> asserted so that only neighbors with a good enough connectivity >> are >> presented to the OF. How that connectivity is asserted and >> maintained is out of scope." >> >> and: >> >> " Hop count used in wireless networks will tend to favor paths with >> long distance links and non optimal connectivity properties. As a >> result, the link selection must be very conservative, and the >> available link set is thus constrained. In some situations, this >> might end up partitioning the network. For those reasons, the use > of >> hop count only is generally not recommended in wireless networks." >> >> >> I appreciate mentioning these dangers of OF0 and suggesting that > white- >> listed links (white-listing is claimed to be out of scope of this > draft and not >> sure where I can go read how white-listing is >> done) might be able to address some of these dangers. It is unclear > how >> helpful white-listing is. > > [Pascal] The 802.11 association is an example of white listing. The > real > world suggests that it is quite useful. > Can you give some data? What "real world" are you referring to? There are plenty of times when association != good connectivity. >> Right now there is no evidence that OF0-based routing will actually > work. It >> will be great to look at some arguments or evidence that this is a > reasonable >> way to do routing for RPL. > > [Pascal] Isn't there? > > On the contrary, I'd assert that there are (tens of) years of > experience > in Distance Vector that indicate that a weighted hop count can be very > useful. The weighted hop count is the dominant metric in the world > today, and OF0 enables to use RPL as an alternate protocol in networks > where other IGPs operate yet are not optimum. A typical example > would be > a (recursively) hub and spoke network. Sure -- but this experience is not in LLNs. > > There are also years of practical experience on something very similar > to RPL/OF0 applied to wired links and more controlled radios, such as > WIFI infrastructure mode. You might want to look up work on Layer 3 > meshes and MANEMO for instance. Do drafts constitute experience in effective deployments? The major work I know about layer 3 meshes is Roofnet and Meraki. Practical experience is one thing: practical experience that concluded hopcount is a good idea. E.g., there were many years of practical experience with OLSR that led its current implementation to discard hopcount. > > Experience strongly suggest not to use hop count in 802.15.4 or any > other "adhoc" radios. If the text in OF0 is not clear enough on that, > then suggestions are welcome : ) What do you mean by "adhoc?" 802.11 can use the same ISM band and has similar modulation: its link layer behavior (in the 2.4GHz band) is pretty much the same as 802.15.4. Why do you think it is different? > >> "The metric used in OF0 is the RPL Rank, as defined in >> [I-D.ietf-roll-rpl]." >> >> I am not sure if Rank is defined as a metric. It might be good to be > precise >> here. >> > [Pascal] Agreed. The Rank is simply analogous to the metric but > conceptually they are different beasts. > > What do you think of : > " > The metric used in OF0 is an administratively defined scalar cost > that is trivially added up along a path to compute the RPL Rank, as > defined in [I-D.ietf-roll-rpl]. As a result, the Rank if a node is > analogous to a weighted hop count of the path to the root. " > > ? My major concern with OF0 is actually quite different: it does not say how to compute Rank from metrics. Back in the discussions on MRHOF, this emerged as a requirement for an OF, when we separated OFs from metrics. Right now, it seems like I could have an OF0 that computes Rank from latency, or throughput. Since the computation of Rank is very poorly defined, it seems very easy to have two incompatible OF0 implementations that work at cross purposes. For OF0 to be ready to be an RFC, it must actually provide some details on how metrics are converted to Rank. Take a look at the April discussion entitled "Decoupling Metrics and OF." Phil From alexandru.petrescu@gmail.com Tue Nov 23 01:00:43 2010 Return-Path: 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 C333F3A6807 for ; Tue, 23 Nov 2010 01:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 93Ur9YgiBCzB for ; Tue, 23 Nov 2010 01:00:42 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 366163A67FF for ; Tue, 23 Nov 2010 01:00:42 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id oAN91cin003510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 23 Nov 2010 10:01:38 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id oAN91cHO029250 for ; Tue, 23 Nov 2010 10:01:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.173] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id oAN91cPe031425 for ; Tue, 23 Nov 2010 10:01:38 +0100 Message-ID: <4CEB82F2.6000808@gmail.com> Date: Tue, 23 Nov 2010 10:01:38 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: roll@ietf.org References: <4478C36E-968D-4E02-90C2-1B6471974622@gmail.com> <28506.1290178031@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D033C3954@XMB-AMS-107.cisco.com> <4627.1290194089@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D033C3C51@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D033C3C51@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Implicit default routes in RPL 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: , X-List-Received-Date: Tue, 23 Nov 2010 09:00:43 -0000 Le 22/11/2010 10:53, Pascal Thubert (pthubert) a écrit : >> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] Sent: Friday, >> November 19, 2010 8:15 PM To: Pascal Thubert (pthubert) Cc: Ralph >> Droms; roll@ietf.org Subject: Re: [Roll] Implicit default routes >> in RPL >> >> >> thank you for the reply, I think we are in violent agreement? see >> inline. > > [Pascal] Yes, I think we are : ) > > >>>>>>> "Pascal" == Pascal >>>>>>> Thubert<(pthubert)"> >> writes: Pascal> Hi Ralph and Michael: >> >> Pascal> It is explicit in the text that the parents are used as >> Pascal> default routers. The default route is required to go up > the >> Pascal> DAG till you hit a common ancestor. This comes with the > fact >> Pascal> that RPL maintains a minimum set of states and resort to > the >> Pascal> default route for whatever is not attached in a anode's >> Pascal> subdag. The default route does not mean that the parents > can >> Pascal> reach the whole internet. A RIO might tell you that, or > the >> Pascal> G bit if the goal is to reach the internet. Rather, this >> Pascal> means that whatever you want to reach that is not in your >> Pascal> subdag can only be reached via the parents. >> >> >> Pascal> See section 8 of RPL 15, in particular: >> >> Pascal> As mentioned in Section 3.2.8, nodes that decide to > join >> Pascal> a DODAG MUST provision at least one DODAG parent as a >> Pascal> default route for the associated instance. This default >> >> yes. I don't associate the words "default route" with a route to >> ::/0. It's the default for the "associated instance", which > exists >> to fullful a particular set of constraints, etc. Do we agree here? >> >> So it might be the "default" for getting to >> 2001:PASC:ALSH::OUSE::/64, > but it's >> not ::/0. > > [Pascal] This certainly makes sense to me. What the default route > really does is act as a default in a switch/case statement when no > longer match is found, and does not provide a guarantee that the > whole internet is reachable. The use of a default route should be guaranteed to reach the Internet. > For the time being, the RPL base spec does not specify a way to > control the "default" in a RPL instance, but it does not bar that > from being done either. The default "default" is ::/0, so for the > rime being you will probably install ::/0 in the routing table. > Further specs can be expected to come in like an OF with a scoped > behavior that overloads "default" with a lower scope, a ULA domain, > or an ISP aggregation, as you propose above. I can't imagine specs telling that a default route is something else than ::/0. One could invent new terms like 'default default route' or a 'more particular default route' but I doubt how it could be implemented. I disagree one could have a default route to ULA domains (not ::/0) or ISP aggregations (not ::/0), or to 2001:PASC:ALSH::OUSE::/64 (not ::/0); or I don't understand what you mean. Alex > This can help sorting out instances when multiple are available for > an incoming packet. > > Best, > > Pascal >> -- ] He who is tired of Weird Al is tired of life! | > firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net >> architect[ ] mcr@sandelman.ottawa.on.ca >> http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: >> watch the video then >> sign the petition. > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From ulrich@herberg.name Tue Nov 23 02:04:47 2010 Return-Path: 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 1D64A3A68BF for ; Tue, 23 Nov 2010 02:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] 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 BSBot7HPo9+b for ; Tue, 23 Nov 2010 02:04:46 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 2AEFE3A68C3 for ; Tue, 23 Nov 2010 02:04:46 -0800 (PST) Received: by qyk11 with SMTP id 11so1202684qyk.10 for ; Tue, 23 Nov 2010 02:05:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.179.131 with SMTP id bq3mr6351925qab.81.1290506743052; Tue, 23 Nov 2010 02:05:43 -0800 (PST) Received: by 10.220.187.140 with HTTP; Tue, 23 Nov 2010 02:05:43 -0800 (PST) In-Reply-To: <20101122163512.4979.96571.idtracker@localhost> References: <20101122163512.4979.96571.idtracker@localhost> Date: Tue, 23 Nov 2010 11:05:43 +0100 Message-ID: From: Ulrich Herberg To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] Last Call: (The Trickle Algorithm) to Proposed Standard 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: , X-List-Received-Date: Tue, 23 Nov 2010 10:04:47 -0000 Hi, I have reviewed the document and think that it is in a good shape to be published. Just some nits that I found: - headers of section 6.1 to 6.7.: Should be in capital letters, similar to sections 4.1/4.2 and 10.1./10.2 - introduction: "current implementations use 4-11 bytes...". I wonder whether that is wise to put into the draft, since it once it will be published, "current" implementations may need more or less (at that future time) - introduction, 2nd paragraph: "Section Section 6.8" (remove one "Section") - section 6: "It is RECOMMENDED that a protocol [...] include mechanisms" (s/include/includes/) - Acknowledgments: thanks for having included me in that list; my first name is written Ulrich, not Urlich :-) - References: There is an informative ref to an individual draft by J. Hui. Is that a problem in a std. tracks document to cite an individual draft? Couldn't that delay the publication process? Regards Ulrich On Mon, Nov 22, 2010 at 5:35 PM, The IESG wrote: > > The IESG has received a request from the Routing Over Low power and Lossy > networks WG (roll) to consider the following document: > - 'The Trickle Algorithm' > =A0 as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2010-12-06. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-roll-trickle/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-roll-trickle/ > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From coflynn@newae.com Tue Nov 23 02:15:54 2010 Return-Path: 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 AB83A3A68E7 for ; Tue, 23 Nov 2010 02:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] 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 N3nX2Qgk8ZUl for ; Tue, 23 Nov 2010 02:15:53 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 7B9213A68E3 for ; Tue, 23 Nov 2010 02:15:53 -0800 (PST) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1PKpvd-0003lz-FI; Tue, 23 Nov 2010 05:16:49 -0500 From: "Colin O'Flynn" To: "'Ulrich Herberg'" , References: <20101122163512.4979.96571.idtracker@localhost> In-Reply-To: Date: Tue, 23 Nov 2010 10:16:24 -0000 Message-ID: <002001cb8af7$7e254cc0$7a6fe640$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuK9f+YstLGbTslSXuQfWs8Eh1HjQAABC3w Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Roll] Last Call: (The Trickle Algorithm) to Proposed Standard 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: , X-List-Received-Date: Tue, 23 Nov 2010 10:15:54 -0000 Hi Ulrich, > - introduction: "current implementations use 4-11 bytes...". I wonder > whether that is wise to put into the draft, since it once it will be > published, "current" implementations may need more or less (at that > future time) I think it is reasonable to keep such a statement. It could be = simplified to just explain what those bytes are, but I think the point is if you pick = up the draft you know right away what sort of resource requirements the = draft carries. So something saying "Trickle requires at minimum three variables". The = size of the variables would depend on your network & processor architecture. = Such a statement would remain valid even when we move to 128-bit processors & = a single variable is typically 16 bytes ;-) Regards, -Colin -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Ulrich Herberg Sent: November 23, 2010 10:06 AM To: roll@ietf.org Subject: Re: [Roll] Last Call: (The = Trickle Algorithm) to Proposed Standard Hi, I have reviewed the document and think that it is in a good shape to be published. Just some nits that I found: - headers of section 6.1 to 6.7.: Should be in capital letters, similar to sections 4.1/4.2 and 10.1./10.2 - introduction: "current implementations use 4-11 bytes...". I wonder whether that is wise to put into the draft, since it once it will be published, "current" implementations may need more or less (at that future time) - introduction, 2nd paragraph: "Section Section 6.8" (remove one = "Section") - section 6: "It is RECOMMENDED that a protocol [...] include mechanisms" (s/include/includes/) - Acknowledgments: thanks for having included me in that list; my first name is written Ulrich, not Urlich :-) - References: There is an informative ref to an individual draft by J. Hui. Is that a problem in a std. tracks document to cite an individual draft? Couldn't that delay the publication process? Regards Ulrich On Mon, Nov 22, 2010 at 5:35 PM, The IESG = wrote: > > The IESG has received a request from the Routing Over Low power and = Lossy > networks WG (roll) to consider the following document: > - 'The Trickle Algorithm' > =A0 as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2010-12-06. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-roll-trickle/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-roll-trickle/ > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > 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 ulrich@herberg.name Tue Nov 23 02:26:10 2010 Return-Path: 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 4A7753A68C5 for ; Tue, 23 Nov 2010 02:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.177 X-Spam-Level: X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] 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 R-bHHdOUrunX for ; Tue, 23 Nov 2010 02:26:05 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 0F13E3A6868 for ; Tue, 23 Nov 2010 02:26:04 -0800 (PST) Received: by qyk34 with SMTP id 34so2661039qyk.10 for ; Tue, 23 Nov 2010 02:27:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.201.138 with SMTP id fa10mr6338276qab.31.1290508020298; Tue, 23 Nov 2010 02:27:00 -0800 (PST) Received: by 10.220.187.140 with HTTP; Tue, 23 Nov 2010 02:27:00 -0800 (PST) In-Reply-To: <002001cb8af7$7e254cc0$7a6fe640$@com> References: <20101122163512.4979.96571.idtracker@localhost> <002001cb8af7$7e254cc0$7a6fe640$@com> Date: Tue, 23 Nov 2010 11:27:00 +0100 Message-ID: From: Ulrich Herberg To: "Colin O'Flynn" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Last Call: (The Trickle Algorithm) to Proposed Standard 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: , X-List-Received-Date: Tue, 23 Nov 2010 10:26:10 -0000 Colin, On Tue, Nov 23, 2010 at 11:16 AM, Colin O'Flynn wrote: >> - introduction: "current implementations use 4-11 bytes...". I wonder >> whether that is wise to put into the draft, since it once it will be >> published, "current" implementations may need more or less (at that >> future time) > > I think it is reasonable to keep such a statement. It could be simplified= to > just explain what those bytes are, but I think the point is if you pick u= p > the draft you know right away what sort of resource requirements the draf= t > carries. > > So something saying "Trickle requires at minimum three variables". The si= ze > of the variables would depend on your network & processor architecture. S= uch > a statement would remain valid even when we move to 128-bit processors & = a > single variable is typically 16 bytes ;-) Yes, I can agree to that. Ulrich > > Regards, > > =A0-Colin > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Ulrich Herberg > Sent: November 23, 2010 10:06 AM > To: roll@ietf.org > Subject: Re: [Roll] Last Call: (The Tric= kle > Algorithm) to Proposed Standard > > Hi, > > I have reviewed the document and think that it is in a good shape to > be published. Just some nits that I found: > > - headers of section 6.1 to 6.7.: Should be in capital letters, > similar to sections 4.1/4.2 and 10.1./10.2 > - introduction: "current implementations use 4-11 bytes...". I wonder > whether that is wise to put into the draft, since it once it will be > published, "current" implementations may need more or less (at that > future time) > - introduction, 2nd paragraph: "Section Section 6.8" (remove one "Section= ") > - section 6: "It is RECOMMENDED that a protocol [...] include > mechanisms" (s/include/includes/) > - Acknowledgments: thanks for having included me in that list; my > first name is written Ulrich, not Urlich :-) > - References: There is an informative ref to an individual draft by J. > Hui. Is that a problem in a std. tracks document to cite an individual > draft? Couldn't that delay the publication process? > > Regards > Ulrich > > On Mon, Nov 22, 2010 at 5:35 PM, The IESG wrote= : >> >> The IESG has received a request from the Routing Over Low power and Loss= y >> networks WG (roll) to consider the following document: >> - 'The Trickle Algorithm' >> =A0 as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2010-12-06. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-roll-trickle/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-roll-trickle/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> 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 Adrian.Farrel@huawei.com Tue Nov 23 02:37:44 2010 Return-Path: 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 F302C3A68FB for ; Tue, 23 Nov 2010 02:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.323 X-Spam-Level: X-Spam-Status: No, score=-103.323 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 RgLAW7zgmSgr for ; Tue, 23 Nov 2010 02:37:38 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 41FAA3A68EC for ; Tue, 23 Nov 2010 02:37:35 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCC00EZD2VUNW@usaga01-in.huawei.com> for roll@ietf.org; Tue, 23 Nov 2010 02:38:18 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCC00BZE2VSC1@usaga01-in.huawei.com> for roll@ietf.org; Tue, 23 Nov 2010 02:38:18 -0800 (PST) Date: Tue, 23 Nov 2010 10:38:16 +0000 From: Adrian Farrel To: draft-ietf-roll-security-framework@tools.ietf.org Message-id: <0b9f01cb8afa$8a73c0d0$9f5b4270$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcuK+eHOEv2t2978RrKkYTgEyUv14g== Cc: roll@ietf.org Subject: [Roll] AD review of draft-ietf-roll-security-framework X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 10:37:44 -0000 Hi, I have performed an AD review of your draft. Don't panic! I review all drafts that I am responsible for before putting them forward for IETF last call. The main objective is to catch nits and minor issues that would show up during the last call or in IESG review. The intention is to help polish your document and make sure it is clean and shiny so that other reviewers will stick to the technical details. Thanks for a very thorough survey of the landscape, and a well written document. Most of my comments are pretty trivial, but a couple have more meat on them and I'd like to see a quick respin of the document before I issue the IETF last call. As soon as I see a new revision posted, I'll set the ball in motion. Of course, all of my issues are up for discussion. Thanks for the work, Adrian --- idnits gives two warnings about references: == Unused Reference: 'I-D.ietf-6man-rpl-option' is defined on lines 1786, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-roll-rpl-11 --- I think that Section 1 uses [I-D.ietf-roll-terminology] as a normative reference. You may want to look at this to decide whether you can avoid or dilute the reference so that you are not blocked in the RFC Editor Queue. --- The RFC Editor usually likes the first section in the document to be the Introduction. I think you can safely swap the Terminology section with the Introduction. --- Section 3.2 Because LLNs are most commonly found on publicly accessible shared medium, e.g., air or wiring in a building, and sometimes s/on/on a/ --- Section 3.2 Integrity Integrity, as a security principle, entails the protection of routing information and routing neighbor maintenance exchanges, as well as derived information maintained in the database, from misuse or unauthorized and improper modification. I'm not comfortable with "misuse" in the context of integrity. The term suggests to me that the information might be used for illicit purposes which I would think ties in with "confidentiality" not "integrity". Am I missing something? --- Section 3.2 In addition, integrity also requires the authenticity of claimed identity in the origin and destination of a message, access and removal of data, execution of the routing process, and use of computing and energy resources. I'm curious that you tie authenticity to the *message* source and destination rather than to the *information*. This has been a debate in routing security for some time. Consider an IGP where one could authenticate the message exchanges between protocol peers, or one could authenticate the link state information that is being distributed. Clearly there are implications for the solution, and the chain-of-trust model of the former may achieve the latter. However, I think that the asset is the information not the message, and it is the asset that must be authenticated. --- Section 3.2 It is noted that, besides those captured in the CIA model, assurance "those" what? Suggest... It is noted that, besides those security issues captured in the CIA model, assurance --- Section 3.2 Non-repudiation Reading this section, it seems to me that you have identified non- repudiation as a viable threat to ROLL. You have also recognised that the traditional mechanisms for discovering it are hard or impossible to apply in a LLN. That analysis is fine. But then you go on to say "it is hard, so we won't talk about it"! This doesn't seem to be right. At the very least you should provide an analysis of the risks and impact of non-repudiation in ROLL. You can then also quantify the issues with applying traditional techniques, and this might motivate people to derive new techniques (or to determine that it is not a significant problem in ROLL). --- Section 3.3 As a consequence of these constraints, there is an even more critical need than usual for a careful trade study on which and "trade study"? Do you mean "study of trade-offs"? Or just "study"? --- Section 3.3 Highly directional traffic Some types of LLNs see a high percentage of their total traffic traverse between the nodes and the Lln Border Routers (LBRs) s/Lln/LLN/ --- Section 3.3 I'm not sure, but I think you should add some emphasis on the ease with which nodes can attach to some LLNs (especially wireless ones). To some extent this might be covered by the "ad hoc" elements in Autonomous operations and by the bullet item Unattended locations and limited physical security but I think you should draw this out specifically as it is one of the greater security issues that I have heard voiced. --- I think that the discussion of key management is a bit weak. The issue is identified in Sections 3.3 and 3,4 as something that can be made more complicated in the LLN environment, but then very little is made of the topic in the document. I think you should have a look at RFC 4107, which should probably one of your references, and then see whether there is anything you can add, possibly to Sections 6 and 7. From jpv@cisco.com Tue Nov 23 13:04:46 2010 Return-Path: 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 095463A69BD for ; Tue, 23 Nov 2010 13:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.052 X-Spam-Level: X-Spam-Status: No, score=-110.052 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 fgy1HzsnrzU7 for ; Tue, 23 Nov 2010 13:04:44 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4A4D83A695C for ; Tue, 23 Nov 2010 13:04:44 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,244,1288569600"; d="scan'208,217";a="293289657" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 23 Nov 2010 21:05:42 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oANL5fNZ003992; Tue, 23 Nov 2010 21:05:42 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Nov 2010 22:05:41 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Nov 2010 22:05:40 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-7-853164197 From: JP Vasseur X-Priority: 3 In-Reply-To: <4E84436B-E5E0-4BF6-BFB1-A5874D473F74@cisco.com> Date: Tue, 23 Nov 2010 21:51:33 +0100 Message-Id: <00F1D3BD-C0A6-4BD8-B533-2653B78AA726@cisco.com> References: <226723849.1290165458629.JavaMail.nobody@jsj6wl006.webex.com> <4E84436B-E5E0-4BF6-BFB1-A5874D473F74@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 23 Nov 2010 21:05:40.0522 (UTC) FILETIME=[2F2C90A0:01CB8B52] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17786.002 X-TM-AS-Result: No--58.054300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Details (webex) for the Interim ROLL Working Group Meeting - Dec 20 at 8:00am PST - 11:00am ET - 5pm CET 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: , X-List-Received-Date: Tue, 23 Nov 2010 21:04:46 -0000 --Apple-Mail-7-853164197 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 22, 2010, at 8:47 AM, JP Vasseur wrote: > Dear all, >=20 > This is to announce a (virtual) ROLL Working Group meeting that will = take place on Dec 20 - details below. >=20 > There will also be an official announcement. >=20 > The objective is to continue our discussion on the re-chartering = process according to the timeframe that we discussed during the ROLL WG = meeting in Beijing. >=20 > Date: December 20 > Time: 8:00am PST =3D Noon ET =3D 6pm CET =3D> 8:00 AM PST / 11:00 AM EST / 5:00 PM CET=20 > Duration =3D 90mn > Agenda: Discussion on ROLL WG re-chartering process > Location: This will be a Webex to be announced on the ROLL Mailing = List (let me know if you need the details). >=20 > If you have an item that you would like to discuss, feel free to send = slide(s) to the chairs and we will put them together. >=20 > If you do not mind, please send a short unicast ACK to chairs if you = plan to attend. >=20 > Thanks >=20 > JP. >=20 >> Hello ,=20 >>=20 >> Jean Philippe Vasseur invites you to attend this online meeting.=20 >>=20 >> Topic: Meeting Center MPV=20 >> Date: Monday, December 20, 2010=20 >> Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)=20 >> Meeting Number: 205 313 548=20 >> Meeting Password: ROLLWG=20 >>=20 >>=20 >> -------------------------------------------------------=20 >> To join the online meeting (Now from the Apple iPhone (R) and other = smartphones!)=20 >> -------------------------------------------------------=20 >> 1. Go to = https://ciscosales.webex.com/ciscosales/j.php?ED=3D153700042&UID=3D0&PW=3D= NM2E1NmQ0YWNj&RT=3DMiM0=20 >> 2. Enter your name and email address.=20 >> 3. Enter the meeting password: ROLLWG=20 >> 4. Click "Join Now".=20 >>=20 >> To view in other time zones or languages, please click the link:=20 >> = https://ciscosales.webex.com/ciscosales/j.php?ED=3D153700042&UID=3D0&PW=3D= NM2E1NmQ0YWNj&ORT=3DMiM0=20 >>=20 >> ----------------------------------------------------------------=20 >> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=20 >> ----------------------------------------------------------------=20 >>=20 >> The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.=20 >>=20 >> Please dial the local access number for your area from the list = below:=20 >> - San Jose/Milpitas (408) area: 525-6800=20 >> - RTP (919) area: 392-3330=20 >>=20 >> -------------------------------------------------------=20 >> To join the teleconference only=20 >> -------------------------------------------------------=20 >> 1. Dial into Cisco WebEx (view all Global Access Numbers at=20 >> http://cisco.com/en/US/about/doing_business/conferencing/index.html=20= >> 2. Follow the prompts to enter the Meeting Number (listed above) or = Access Code followed by the # sign.=20 >>=20 >> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 >>=20 >> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 >>=20 >> India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 >>=20 >> Japan: +81.3.5763.9394 China: +86.10.8515.5666=20 >>=20 >> -------------------------------------------------------=20 >> For assistance=20 >> -------------------------------------------------------=20 >> 1. Go to https://ciscosales.webex.com/ciscosales/mc=20 >> 2. On the left navigation bar, click "Support".=20 >>=20 >> You can contact me at:=20 >> jvasseur@cisco.com=20 >> 33-15-804 3494=20 >>=20 >> To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 >> = https://ciscosales.webex.com/ciscosales/j.php?ED=3D153700042&UID=3D0&ICS=3D= MI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DWDmY5mD1qAFnuRHqjuIpR7j3ficN0ePHEYGsuaNy1ac= =3D&RT=3DMiM0=20 >>=20 >> The playback of UCF (Universal Communications Format) rich media = files requires appropriate players. To view this type of rich media = files in the meeting, please check whether you have the players = installed on your computer by going to = https://ciscosales.webex.com/ciscosales/systemdiagnosis.php=20 >>=20 >> Sign up for a free trial of WebEx=20 >> http://www.webex.com/go/mcemfreetrial=20 >>=20 >> http://www.webex.com=20 >>=20 >> CCP:+14085256800x205313548#=20 >>=20 >> IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation.=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-7-853164197 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear = all,

This is to announce a (virtual) ROLL Working = Group meeting that will take place on Dec 20 - details = below.

There will also be an official = announcement.

The objective is to continue our = discussion on the re-chartering process according to the timeframe that = we discussed during the ROLL WG meeting in = Beijing.

Date: December = 20
Time: 8:00am PST =3D Noon ET =3D 6pm = CET

=3D> 8:00 = AM PST / 11:00 AM EST / 5:00 PM CET 

If you have an item that = you would like to discuss, feel free to send slide(s) to the chairs and = we will put them together.

If you do not mind, = please send a short unicast ACK to chairs if you plan to = attend.

Thanks

JP.<= /div>

Hello ,

Jean = Philippe Vasseur invites you to attend this online meeting.

= Topic: Meeting Center MPV
Date: Monday, December 20, 2010
= Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
= Meeting Number: 205 313 548
Meeting Password: ROLLWG


= -------------------------------------------------------
To join the = online meeting (Now from the Apple iPhone (R) and other smartphones!) =
-------------------------------------------------------
1. Go = to https://ciscosales.webex.com/ciscosales/j.php?ED=3D15370= 0042&UID=3D0&PW=3DNM2E1NmQ0YWNj&RT=3DMiM0
2. Enter = your name and email address.
3. Enter the meeting password: ROLLWG =
4. Click "Join Now".

To view in other time zones or = languages, please click the link:
https://ciscosales.webex.com/ciscosales/j.php?ED=3D15370= 0042&UID=3D0&PW=3DNM2E1NmQ0YWNj&ORT=3DMiM0

= ----------------------------------------------------------------
= ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
= ----------------------------------------------------------------
=
The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please = dial the local access number for your area from the list below:
- = San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330 =

-------------------------------------------------------
= To join the teleconference only
= -------------------------------------------------------
1. Dial = into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing= /index.html
2. Follow the prompts to enter the Meeting Number = (listed above) or Access Code followed by the # sign.

San = Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: = +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: = +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: = +81.3.5763.9394 China: +86.10.8515.5666

= -------------------------------------------------------
For = assistance
------------------------------------------------------- =
1. Go to https://ciscosales.webex.com/ciscosales/mc
2. = On the left navigation bar, click "Support".

You can contact = me at:
jvasseur@cisco.com =
33-15-804 3494

To add this meeting to your calendar = program (for example Microsoft Outlook), click this link:
https://ciscosales.webex.com/ciscosales/j.php?ED=3D15370= 0042&UID=3D0&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3D= WDmY5mD1qAFnuRHqjuIpR7j3ficN0ePHEYGsuaNy1ac=3D&RT=3DMiM0
=
The playback of UCF (Universal Communications Format) rich media = files requires appropriate players. To view this type of rich media = files in the meeting, please check whether you have the players = installed on your computer by going to https://ciscosales.webex.com/ciscosales/systemdiagnosis.= php

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com =

CCP:+14085256800x205313548#

IMPORTANT NOTICE: This = WebEx service includes a feature that allows audio and any documents and = other materials exchanged or viewed during the session to be recorded. = By joining this session, you automatically consent to such recordings. = If you do not consent to the recording, discuss your concerns with the = meeting host prior to the start of the recording or do not join the = session. Please note that any such recordings may be subject to = discovery in the event of litigation.
=

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

= --Apple-Mail-7-853164197-- From wwwrun@core3.amsl.com Tue Nov 23 13:44:10 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 90DDF3A6987; Tue, 23 Nov 2010 13:44:10 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20101123214410.90DDF3A6987@core3.amsl.com> Date: Tue, 23 Nov 2010 13:44:10 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] ROLL WG Virtual Interim Meeting, December 20, 2010 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: , X-List-Received-Date: Tue, 23 Nov 2010 21:44:10 -0000 The ROLL working group will hold a virtual interim meeting on Monday, December 20, 2010 at 8:00 AM PST (11:00 AM EST, 5:00 PM CET) for 90 minutes. WebEx details for this meeting were announced on the ROLL Mailing List (http://www.ietf.org/mail-archive/web/roll/current/msg05712.html). From prvs=93784eff5=mukul@uwm.edu Tue Nov 23 18:55:22 2010 Return-Path: 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 4AEC83A69EB for ; Tue, 23 Nov 2010 18:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=-1.911, BAYES_00=-2.599, FRT_STOCK2=3.988, 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 mIYkLshXtZWN for ; Tue, 23 Nov 2010 18:55:21 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 4CC203A69EC for ; Tue, 23 Nov 2010 18:55:21 -0800 (PST) Received: from mta01.pantherlink.uwm.edu ([129.89.7.132]) by ip2mta.uwm.edu with ESMTP; 23 Nov 2010 20:56:20 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 6CF42E6A7B; Tue, 23 Nov 2010 20:56:20 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf8AzyJ9t4eX; Tue, 23 Nov 2010 20:56:20 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 0E2D3E6A7A; Tue, 23 Nov 2010 20:56:20 -0600 (CST) Date: Tue, 23 Nov 2010 20:56:18 -0600 (CST) From: Mukul Goyal To: charliep@computer.org Message-ID: <1975740596.1993400.1290567378418.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <4CEBFFCA.9070208@computer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? 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: , X-List-Received-Date: Wed, 24 Nov 2010 02:55:22 -0000 Here is a bit of context behind this comment from Charlie. While commenting on the applicability section of the P2P draft, Charlie suggested that, in general, the application layer would/should decide the exact RPL constraints comprising the good enough criteria for P2P route discovery. In contrast, I was of the opinion that, in general, the application layer would not want to deal with the nitty-gritty details of RPL routing metrics and hence would just want to complain to the routing layer if the current route is not good enough (or usable). Then the routing layer should figure out the exact constraints to be used for P2P route discovery. I guess I could modify the text so that a particular implementation may decide for itself whether the application layer would specify the good enough constraints or the routing layer. Thanks Mukul ----- Original Message ----- From: "Charles E. Perkins" To: "Anders Brandt" Cc: "Mukul Goyal" , "roll" Sent: Tuesday, November 23, 2010 11:54:18 AM Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? >And I still believe that the application is best suited to provide the information determining whether or not a route could be used. For instance, it could setsockopt(QOS) some specific class of service . Regards, Charlie P. From Gerald.Paprocki@us.elster.com Wed Nov 24 12:06:29 2010 Return-Path: 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 956D128C148 for ; Wed, 24 Nov 2010 12:06:29 -0800 (PST) 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 tzigkQvRVesp for ; Wed, 24 Nov 2010 12:06:28 -0800 (PST) Received: from mail198.messagelabs.com (mail198.messagelabs.com [216.82.254.163]) by core3.amsl.com (Postfix) with SMTP id 5F7F228C11E for ; Wed, 24 Nov 2010 12:06:28 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Gerald.Paprocki@us.elster.com X-Msg-Ref: server-15.tower-198.messagelabs.com!1290629247!53019766!3 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 31903 invoked from network); 24 Nov 2010 20:07:28 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-15.tower-198.messagelabs.com with SMTP; 24 Nov 2010 20:07:28 -0000 Auto-Submitted: auto-generated From: Gerald.Paprocki@us.elster.com To: roll@ietf.org Message-ID: Date: Wed, 24 Nov 2010 15:07:44 -0500 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 11/24/2010 03:01:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Roll] AUTO: Gerald Paprocki is out of the office (returning 11/29/2010) 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: , X-List-Received-Date: Wed, 24 Nov 2010 20:06:29 -0000 I am out of the office until 11/29/2010. I will be out of the office starting Wednesday 11/24 and returning to the office Monday 11/29. While I am away I will have limited access to my email and phone messages. Note: This is an automated response to your message "Roll Digest, Vol 34, Issue 26" sent on 11/24/2010 3:00:12 PM. This is the only notification you will receive while this person is away. From rmarchap@cisco.com Wed Nov 24 18:11:58 2010 Return-Path: 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 6783D3A6A6B for ; Wed, 24 Nov 2010 18:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 oHzv6uRtqEfY for ; Wed, 24 Nov 2010 18:11:52 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 771DB28C1EF for ; Wed, 24 Nov 2010 18:11:48 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMFAHNV7UyrR7H+/2dsb2JhbACCApMAjghxoiubI4VHBIRbiRo X-IronPort-AV: E=Sophos;i="4.59,251,1288569600"; d="scan'208,217";a="292229057" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 25 Nov 2010 02:12:49 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAP2CnET000466 for ; Thu, 25 Nov 2010 02:12:49 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Nov 2010 18:12:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {48C4A8B5-4846-4C7B-93BC-51311B01618D} MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8C46.41892C80" x-cr-hashedpuzzle: g+Y= Az9+ A6Vl A6hE B4Zk DWem DqM2 DuZg D3CR E2yw Fd0b GhWw G0V2 HHnP KvWd LNSH; 1; cgBvAGwAbABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {48C4A8B5-4846-4C7B-93BC-51311B01618D}; cgBtAGEAcgBjAGgAYQBwAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Thu, 25 Nov 2010 02:12:44 GMT; TQBhAGsAZQAgAE8AQwBQACAAcABhAHIAdAAgAG8AZgAgAEQASQBPACAAYgBhAHMAZQAgAG8AYgBqAGUAYwB0ACAAbwByACAAbQBhAGsAZQAgAEQATwBEAEEARwAgAGMAbwBuAGYAaQBnAHUAcgBhAHQAaQBvAG4AIABtAGEAbgBkAGEAdABvAHIAeQAgAGYAbwByACAAYQBsAGwAIABEAEkATwBzAA== Content-class: urn:content-classes:message Date: Wed, 24 Nov 2010 18:12:44 -0800 Message-ID: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Make OCP part of DIO base object or make DODAG configuration mandatory for all DIOs Thread-Index: AcuMRj9OZtLG/ihlRamPngj5Zm2Ykw== From: "Rajesh Marchappanavar (rmarchap)" To: X-OriginalArrivalTime: 25 Nov 2010 02:12:48.0599 (UTC) FILETIME=[4193B670:01CB8C46] Subject: [Roll] Make OCP part of DIO base object or make DODAG configuration mandatory for all DIOs 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: , X-List-Received-Date: Thu, 25 Nov 2010 02:11:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB8C46.41892C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 Consider a setup with 2 LBRs or DAG roots configured with same instance-id and dag-id but different ocp-type. =20 LBR1---------Node-------------LBR2 =20 Say LBR1 is configured with OCP0 and LBR2 with OCP1 and Node is configured to join OCP0. LBR1 starts up first, Node hears DIO from LBR1 and joins OCP0 dag. LBR2 sends DIO with configuration option, Node fails to match OCP and rejects DIO. All fine. LBR2 sends DIO with only Base option, Node would select LBR2 as alternate parent assuming rank and version number are same as LBR1's. A node now has a OCP0 preferred parent and a OCP1 alternate parent. Based on network situation, Node could be flapping between a OCP0 dag and a OCP1 dag. =20 This seems to be a major issue unless somebody can help explain RPL behavior is such cases. You could say this is a misconfiguration, true, but how would a Node detect and reject this misconfig? =20 IMO, we should either make OCP part of DIO base object or make DODAG configuration option mandatory for DIOs. Please share your thoughts. =20 Cheers, Rajesh =20 ------_=_NextPart_001_01CB8C46.41892C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

Consider a setup with 2 LBRs or DAG roots = configured with same instance-id and dag-id but different ocp-type.

 

LBR1---------Node-------------LBR2

 

Say LBR1 is configured with OCP0 and LBR2 with OCP1 = and Node is configured to join OCP0.

LBR1 starts up first, Node hears DIO from LBR1 and = joins OCP0 dag.

LBR2 sends DIO with configuration option, Node = fails to match OCP and rejects DIO. All fine.

LBR2 sends DIO with only Base option, Node would = select LBR2 as alternate parent assuming rank and version number are same as = LBR1’s.

A node now has a OCP0 preferred parent and a OCP1 = alternate parent. Based on network situation, Node could be flapping between = a

OCP0 dag and a OCP1 dag.

 

This seems to be a major issue unless somebody can = help explain RPL behavior is such cases.

You could say this is a misconfiguration, true, but = how would a Node detect and reject this misconfig?

 

IMO, we should either make OCP part of DIO base = object or make DODAG configuration option mandatory for DIOs.

Please share your thoughts.

 

Cheers,

Rajesh

 

------_=_NextPart_001_01CB8C46.41892C80-- From pal@cs.stanford.edu Wed Nov 24 18:22:47 2010 Return-Path: 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 60C2A3A6A6B for ; Wed, 24 Nov 2010 18:22:47 -0800 (PST) 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 zyLphpGYO7lE for ; Wed, 24 Nov 2010 18:22:35 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 00A8C3A6A60 for ; Wed, 24 Nov 2010 18:22:34 -0800 (PST) Received: from [76.14.65.187] (helo=[192.168.1.133]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PLRUl-000177-Gi; Wed, 24 Nov 2010 18:23:35 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com> Date: Wed, 24 Nov 2010 18:23:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com> To: Rajesh Marchappanavar (rmarchap) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAG configuration mandatory for all DIOs 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: , X-List-Received-Date: Thu, 25 Nov 2010 02:22:47 -0000 On Nov 24, 2010, at 6:12 PM, Rajesh Marchappanavar (rmarchap) wrote: > =20 > Hi, > =20 > Consider a setup with 2 LBRs or DAG roots configured with same = instance-id and dag-id but different ocp-type. > =20 > LBR1---------Node-------------LBR2 > =20 > Say LBR1 is configured with OCP0 and LBR2 with OCP1 and Node is = configured to join OCP0. > LBR1 starts up first, Node hears DIO from LBR1 and joins OCP0 dag. > LBR2 sends DIO with configuration option, Node fails to match OCP and = rejects DIO. All fine. > LBR2 sends DIO with only Base option, Node would select LBR2 as = alternate parent assuming rank and version number are same as LBR1=92s. > A node now has a OCP0 preferred parent and a OCP1 alternate parent. = Based on network situation, Node could be flapping between a > OCP0 dag and a OCP1 dag. > =20 > This seems to be a major issue unless somebody can help explain RPL = behavior is such cases. > You could say this is a misconfiguration, true, but how would a Node = detect and reject this misconfig? > =20 > IMO, we should either make OCP part of DIO base object or make DODAG = configuration option mandatory for DIOs. > Please share your thoughts. > =20 LBR1 and LBR2 use different OCPs if and only if they are part of = different DODAGs. Node needs to keep track of the DODAG -> OCP mapping = and act accordingly. Phil= From rmarchap@cisco.com Wed Nov 24 18:32:39 2010 Return-Path: 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 9186428C0ED for ; Wed, 24 Nov 2010 18:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 L1I87TGOm4Dq for ; Wed, 24 Nov 2010 18:32:27 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E3B0828C222 for ; Wed, 24 Nov 2010 18:32:26 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIDALJZ7UyrR7Ht/2dsb2JhbACUQ45HcaIimyOFRwSEW4kaiAQ X-IronPort-AV: E=Sophos;i="4.59,251,1288569600"; d="scan'208";a="249070687" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 25 Nov 2010 02:33:27 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAP2XRqV010668; Thu, 25 Nov 2010 02:33:27 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Nov 2010 18:33:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Nov 2010 18:33:23 -0800 Message-ID: <7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Make OCP part of DIO base object or make DODAG configuration mandatory for all DIOs Thread-Index: AcuMR8P5cIluJ+2HRSOr22a+RHfzwwAAJLRg References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com> From: "Rajesh Marchappanavar (rmarchap)" To: "Philip Levis" X-OriginalArrivalTime: 25 Nov 2010 02:33:26.0449 (UTC) FILETIME=[2364A210:01CB8C49] Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAG configuration mandatory for all DIOs 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: , X-List-Received-Date: Thu, 25 Nov 2010 02:32:39 -0000 > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Thursday, November 25, 2010 7:54 AM > To: Rajesh Marchappanavar (rmarchap) > Cc: roll@ietf.org > Subject: Re: [Roll] Make OCP part of DIO base object or make DODAG > configuration mandatory for all DIOs >=20 >=20 > On Nov 24, 2010, at 6:12 PM, Rajesh Marchappanavar (rmarchap) wrote: >=20 > > > > Hi, > > > > Consider a setup with 2 LBRs or DAG roots configured with same > instance-id and dag-id but different ocp-type. > > > > LBR1---------Node-------------LBR2 > > > > Say LBR1 is configured with OCP0 and LBR2 with OCP1 and Node is > configured to join OCP0. > > LBR1 starts up first, Node hears DIO from LBR1 and joins OCP0 dag. > > LBR2 sends DIO with configuration option, Node fails to match OCP and > rejects DIO. All fine. > > LBR2 sends DIO with only Base option, Node would select LBR2 as > alternate parent assuming rank and version number are same as LBR1's. > > A node now has a OCP0 preferred parent and a OCP1 alternate parent. > Based on network situation, Node could be flapping between a > > OCP0 dag and a OCP1 dag. > > > > This seems to be a major issue unless somebody can help explain RPL > behavior is such cases. > > You could say this is a misconfiguration, true, but how would a Node > detect and reject this misconfig? > > > > IMO, we should either make OCP part of DIO base object or make DODAG > configuration option mandatory for DIOs. > > Please share your thoughts. > > >=20 > LBR1 and LBR2 use different OCPs if and only if they are part of > different DODAGs. Node needs to keep track of the DODAG -> OCP mapping > and act accordingly. [RM:] Instance-id, DODAG-id and OCP are configurable parameters on root/LBR, if network administrator configures same instance-id, DODAG-id and different OCPs on LBR1 and LBR2, are LBR1 and LBR2 part of same DODAG or different DODAG? Cheers, Rajesh >=20 > Phil From pal@cs.stanford.edu Wed Nov 24 18:56:48 2010 Return-Path: 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 7B9853A69E7 for ; Wed, 24 Nov 2010 18:56:48 -0800 (PST) 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 WL-T8U3ONsia for ; Wed, 24 Nov 2010 18:56:47 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id D02A03A69DD for ; Wed, 24 Nov 2010 18:56:47 -0800 (PST) Received: from [76.14.65.187] (helo=[192.168.1.133]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PLS1q-0002HT-1n; Wed, 24 Nov 2010 18:57:48 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com> Date: Wed, 24 Nov 2010 18:57:45 -0800 Content-Transfer-Encoding: 7bit Message-Id: <9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu> References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com> <7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com> To: "Rajesh Marchappanavar (rmarchap)" X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 4c7a780eb20f40a19c8376fd8d8b00d5 Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAG configuration mandatory for all DIOs 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: , X-List-Received-Date: Thu, 25 Nov 2010 02:56:48 -0000 On Nov 24, 2010, at 6:33 PM, Rajesh Marchappanavar (rmarchap) wrote: >>> >> and act accordingly. > > [RM:] Instance-id, DODAG-id and OCP are configurable parameters on > root/LBR, if network administrator configures same instance-id, DODAG-id > and different OCPs on LBR1 and LBR2, are LBR1 and LBR2 part of same > DODAG or different DODAG? This would be a configuration error that violates the specification. Phil From rmarchap@cisco.com Wed Nov 24 19:11:51 2010 Return-Path: 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 02BE23A69DD for ; Wed, 24 Nov 2010 19:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 vEV76tZ2GGfW for ; Wed, 24 Nov 2010 19:11:41 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 610383A6984 for ; Wed, 24 Nov 2010 19:11:37 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIDAAtj7UyrRN+J/2dsb2JhbACUQ45HcaIimyGFRwSEW4kaiAQ X-IronPort-AV: E=Sophos;i="4.59,251,1288569600"; d="scan'208";a="625665582" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 25 Nov 2010 03:12:38 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oAP3CcBj006107; Thu, 25 Nov 2010 03:12:38 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Nov 2010 19:12:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Nov 2010 19:12:36 -0800 Message-ID: <7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> In-Reply-To: <9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Make OCP part of DIO base object or make DODAG configuration mandatory for all DIOs Thread-Index: AcuMTItkD27XqK/ZT9CzVccgbTTaEgAAdOWQ References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com> <7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com> <9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu> From: "Rajesh Marchappanavar (rmarchap)" To: "Philip Levis" X-OriginalArrivalTime: 25 Nov 2010 03:12:38.0086 (UTC) FILETIME=[9D13F660:01CB8C4E] Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAG configuration mandatory for all DIOs 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: , X-List-Received-Date: Thu, 25 Nov 2010 03:11:55 -0000 > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Thursday, November 25, 2010 8:28 AM > To: Rajesh Marchappanavar (rmarchap) > Cc: roll@ietf.org > Subject: Re: [Roll] Make OCP part of DIO base object or make DODAG > configuration mandatory for all DIOs >=20 >=20 > On Nov 24, 2010, at 6:33 PM, Rajesh Marchappanavar (rmarchap) wrote: >=20 > >>> > >> and act accordingly. > > > > [RM:] Instance-id, DODAG-id and OCP are configurable parameters on > > root/LBR, if network administrator configures same instance-id, > DODAG-id > > and different OCPs on LBR1 and LBR2, are LBR1 and LBR2 part of same > > DODAG or different DODAG? >=20 > This would be a configuration error that violates the specification. [RM:] True and I already said that. How does a node handle this configuration error? Putting ocp in DIO base object would help handle various such issues. Cheers, Rajesh >=20 > Phil From m.pouillot@watteco.com Thu Nov 25 00:03:56 2010 Return-Path: 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 37AEC28C0DC for ; Thu, 25 Nov 2010 00:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 REbtBM4+4IMz for ; Thu, 25 Nov 2010 00:03:55 -0800 (PST) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 4213028C0DD for ; Thu, 25 Nov 2010 00:03:53 -0800 (PST) Received: from [192.168.4.247] ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id HTD57852 for ; Thu, 25 Nov 2010 09:04:52 +0100 Message-ID: <4CEE18A1.8080009@watteco.com> Date: Thu, 25 Nov 2010 09:04:49 +0100 From: Mathieu Pouillot User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [Roll] DIO loop X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: m.pouillot@watteco.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 08:03:56 -0000 Hi all, I have a problem with a DIO loop in a specific topology.: A---B---C , A is the root of the DAG and the parent of B, B the parent of C. B resets for any reason (watchdog, power failure,...), then it receives first the DIO from C . Therefore there is a loop because B is the child and the parent of C. On each sending of DIO from B and C, the rank will be incremented by the other one and so on… Two possibilities to avoid this loop, saved all the configuration of B in memory and so after a reset load the information saved (can ask a lot of memory). Second solution is to send a DIS (not mandatory by the specification) and wait to receive all DIO before joining the DAG. Is there another solution? best regards, Mathieu -- Mathieu Pouillot R&D Engineer m.pouillot@watteco.com Tel : +33(0)4 98 01 60 05 (Poste 43) Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE - France www.watteco.com From prvs=938804a3d=mukul@uwm.edu Thu Nov 25 06:53:12 2010 Return-Path: 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 1DEC828C116 for ; Thu, 25 Nov 2010 06:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, 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 CNuEg7B-wKWH for ; Thu, 25 Nov 2010 06:53:11 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 2D95D28C0D7 for ; Thu, 25 Nov 2010 06:53:10 -0800 (PST) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 25 Nov 2010 08:54:13 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id DA28E2B3F05; Thu, 25 Nov 2010 08:52:41 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q64ZODNSsV-E; Thu, 25 Nov 2010 08:52:41 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 784E72B3F03; Thu, 25 Nov 2010 08:52:41 -0600 (CST) Date: Thu, 25 Nov 2010 08:54:11 -0600 (CST) From: Mukul Goyal To: Philip Levis Message-ID: <1390944047.2024771.1290696851780.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAG configuration mandatory for all DIOs 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: , X-List-Received-Date: Thu, 25 Nov 2010 14:53:12 -0000 >LBR1 and LBR2 use different OCPs if and only if they are part of different= DODAGs. Just a little correction: LBR1 and LBR2 can use different OCPs if and only if they are part of differ= ent RPL Instances. Here is the relevant quote from Section 3.1.2 of RPL-15: "A RPLInstanceID identifies a set of one or more Destination Oriented DAGs (DODAGs). A network may have multiple RPLInstanceIDs, each of which defines an independent set of DODAGs, which may be optimized for different Objective Functions (OFs) and/or applications. The set of DODAGs identified by a RPLInstanceID is called a RPL Instance. All DODAGs in the same RPL Instance use the same OF." Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "Rajesh Marchappanavar (rmarchap)" Cc: roll@ietf.org Sent: Wednesday, November 24, 2010 8:23:35 PM Subject: Re: [Roll] Make OCP part of DIO base object or make DODAG=09config= uration mandatory for all DIOs On Nov 24, 2010, at 6:12 PM, Rajesh Marchappanavar (rmarchap) wrote: > =20 > Hi, > =20 > Consider a setup with 2 LBRs or DAG roots configured with same instance-i= d and dag-id but different ocp-type. > =20 > LBR1---------Node-------------LBR2 > =20 > Say LBR1 is configured with OCP0 and LBR2 with OCP1 and Node is configure= d to join OCP0. > LBR1 starts up first, Node hears DIO from LBR1 and joins OCP0 dag. > LBR2 sends DIO with configuration option, Node fails to match OCP and rej= ects DIO. All fine. > LBR2 sends DIO with only Base option, Node would select LBR2 as alternate= parent assuming rank and version number are same as LBR1=E2=80=99s. > A node now has a OCP0 preferred parent and a OCP1 alternate parent. Based= on network situation, Node could be flapping between a > OCP0 dag and a OCP1 dag. > =20 > This seems to be a major issue unless somebody can help explain RPL behav= ior is such cases. > You could say this is a misconfiguration, true, but how would a Node dete= ct and reject this misconfig? > =20 > IMO, we should either make OCP part of DIO base object or make DODAG conf= iguration option mandatory for DIOs. > Please share your thoughts. > =20 LBR1 and LBR2 use different OCPs if and only if they are part of different = DODAGs. Node needs to keep track of the DODAG -> OCP mapping and act accord= ingly. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Thu Nov 25 07:26:18 2010 Return-Path: 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 617F228C124 for ; Thu, 25 Nov 2010 07:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.27 X-Spam-Level: X-Spam-Status: No, score=-10.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 dXGQLeElB-xx for ; Thu, 25 Nov 2010 07:26:16 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 83B6B28C139 for ; Thu, 25 Nov 2010 07:26:16 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEDAFYP7kyrR7H+/2dsb2JhbACUR45GcaQfmyKFRwSNdg X-IronPort-AV: E=Sophos;i="4.59,255,1288569600"; d="scan'208";a="625938982" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 25 Nov 2010 15:27:18 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAPFR2hw019451; Thu, 25 Nov 2010 15:27:17 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Nov 2010 16:27:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Nov 2010 16:27:06 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03448396@XMB-AMS-107.cisco.com> In-Reply-To: <4CEE18A1.8080009@watteco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DIO loop Thread-Index: AcuMd3o98WpUtctARce4loWQ2159EAAOOM9Q References: <4CEE18A1.8080009@watteco.com> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 25 Nov 2010 15:27:10.0153 (UTC) FILETIME=[3A13B390:01CB8CB5] Subject: Re: [Roll] DIO loop 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: , X-List-Received-Date: Thu, 25 Nov 2010 15:26:18 -0000 Hi Mathieu We understand that the data path loop is detected. So, what we are discussing here is the question of whether a child can immediately follow the last parent as that parent moves deeper in the same DODAG. Historically, the spec has disallowed such a behavior. A node could not increase its Rank immediately. Instead, the node would poison, wait, and then reattach. So in your case: - B resets - B attaches to C - C sees B moves deeper than self - C detaches < a) advertises INFINITE_RANK OR b) forms its own grounded DAG > and waits for the poisoning to take effect (time for the bad news has spread a few hops) before it reattaches without constraint. - If a) B has to detach from C and stay there till it finds another parent.=20 - If b), B stays attached to C has long as C is the best thing that it sees. - If B misses the news from C then, after the delay, B discovers that C is now deeper. There is a statistical chance that this happens. If that chance is 20% then the chance that it happens twice is 4%, 3 time it becomes .8 % etc... We see that things would settle rapidly. =20 Since the spec has allowed a limited elasticity to the poisoning rule, so the child could follow the parent down as long as (8.2.2.4. item 3.) it does not go deeper down than DAGMaxRankIncrease from its original position. If you set DAGMaxRankIncrease to 0, you are back to the historic behavior. Alternatively, you may set DAGMaxRankIncrease to a few MinHopRankIncrease. In your case, that will cause a few iteration of the loop you describe. In a dense environment, there is a chance that the node that loses its last parent can reparent to someone lower that is not in its subdag, in which case the new rule has allowed the DAG to recover faster.=20 I'm afraid that you have to make your own mind on whether a non-zero DAGMaxRankIncrease is a good thing for your application... : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Mathieu Pouillot > Sent: Thursday, November 25, 2010 9:05 AM > To: roll@ietf.org > Subject: [Roll] DIO loop >=20 > Hi all, >=20 > I have a problem with a DIO loop in a specific topology.: A---B---C , A is the > root of the DAG and the parent of B, B the parent of C. >=20 > B resets for any reason (watchdog, power failure,...), then it receives first the > DIO from C . Therefore there is a loop because B is the child and the parent of > C. On each sending of DIO from B and C, the rank will be incremented by the > other one and so on... >=20 > Two possibilities to avoid this loop, saved all the configuration of B in memory > and so after a reset load the information saved (can ask a lot of memory). > Second solution is to send a DIS (not mandatory by the > specification) and wait to receive all DIO before joining the DAG. >=20 > Is there another solution? >=20 > best regards, >=20 > Mathieu >=20 >=20 >=20 > -- > Mathieu Pouillot > R&D Engineer > m.pouillot@watteco.com >=20 > Tel : +33(0)4 98 01 60 05 (Poste 43) > Fax : +33(0)4 94 14 10 80 > 1766 Chemin de la Planquette > 83130 LA GARDE - France > www.watteco.com >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From rmarchap@cisco.com Thu Nov 25 10:15:02 2010 Return-Path: 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 0FE8428C0F7 for ; Thu, 25 Nov 2010 10:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 tstKQJ5Kal0D for ; Thu, 25 Nov 2010 10:15:00 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B952528C0E6 for ; Thu, 25 Nov 2010 10:15:00 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIDAPs17kyrRN+J/2dsb2JhbACDT5B5jWVhcaQ5ijuQUYEhgzNzBIRciRqIBQ X-IronPort-AV: E=Sophos;i="4.59,256,1288569600"; d="scan'208";a="249164438" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 25 Nov 2010 18:16:02 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oAPIG2D5019515; Thu, 25 Nov 2010 18:16:02 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Nov 2010 10:16:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 25 Nov 2010 10:15:59 -0800 Message-ID: <7B822F730F822147977ED5B684ACE4900BFE8F8A@xmb-sjc-21b.amer.cisco.com> In-Reply-To: <1390944047.2024771.1290696851780.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs Thread-Index: AcuMsKcXSQymmkBjTsKsi2l7+sgEfAAG8y6g References: <1390944047.2024771.1290696851780.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Rajesh Marchappanavar (rmarchap)" To: "Mukul Goyal" , "Philip Levis" X-OriginalArrivalTime: 25 Nov 2010 18:16:02.0583 (UTC) FILETIME=[D179D270:01CB8CCC] Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Thu, 25 Nov 2010 18:15:02 -0000 DQpUaGUga2V5d29yZCBoZXJlIGlzICJtaXNjb25maWd1cmF0aW9uIi4gQXJlIHlvdSBhbGwgc3Vn Z2VzdGluZyBSUEwgbm9kZXMgZG8gbm90L3dpbGwgbm90IGhhdmUgY2FwYWJpbGl0eSB0byBkZXRl Y3QvaGFuZGxlIG1pc2NvbmZpZ3M/DQoNCkNoZWVycywNClJhamVzaA0KDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTXVrdWwgR295YWwgW21haWx0bzptdWt1bEB1d20u ZWR1XQ0KPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjUsIDIwMTAgODoyNCBQTQ0KPiBUbzog UGhpbGlwIExldmlzDQo+IENjOiByb2xsQGlldGYub3JnOyBSYWplc2ggTWFyY2hhcHBhbmF2YXIg KHJtYXJjaGFwKQ0KPiBTdWJqZWN0OiBSZTogW1JvbGxdIE1ha2UgT0NQIHBhcnQgb2YgRElPIGJh c2Ugb2JqZWN0IG9yIG1ha2UNCj4gRE9EQUdjb25maWd1cmF0aW9uIG1hbmRhdG9yeSBmb3IgYWxs IERJT3MNCj4gDQo+ID5MQlIxIGFuZCBMQlIyIHVzZSBkaWZmZXJlbnQgT0NQcyBpZiBhbmQgb25s eSBpZiB0aGV5IGFyZSBwYXJ0IG9mDQo+IGRpZmZlcmVudCBET0RBR3MuDQo+IA0KPiBKdXN0IGEg bGl0dGxlIGNvcnJlY3Rpb246DQo+IA0KPiBMQlIxIGFuZCBMQlIyIGNhbiB1c2UgZGlmZmVyZW50 IE9DUHMgaWYgYW5kIG9ubHkgaWYgdGhleSBhcmUgcGFydCBvZg0KPiBkaWZmZXJlbnQgUlBMIElu c3RhbmNlcy4NCj4gDQo+IEhlcmUgaXMgdGhlIHJlbGV2YW50IHF1b3RlIGZyb20gU2VjdGlvbiAz LjEuMiBvZiBSUEwtMTU6DQo+IA0KPiAiQSBSUExJbnN0YW5jZUlEIGlkZW50aWZpZXMgYSBzZXQg b2YNCj4gICAgICAgb25lIG9yIG1vcmUgRGVzdGluYXRpb24gT3JpZW50ZWQgREFHcyAoRE9EQUdz KS4gIEEgbmV0d29yayBtYXkNCj4gICAgICAgaGF2ZSBtdWx0aXBsZSBSUExJbnN0YW5jZUlEcywg ZWFjaCBvZiB3aGljaCBkZWZpbmVzIGFuDQo+IGluZGVwZW5kZW50DQo+ICAgICAgIHNldCBvZiBE T0RBR3MsIHdoaWNoIG1heSBiZSBvcHRpbWl6ZWQgZm9yIGRpZmZlcmVudCBPYmplY3RpdmUNCj4g ICAgICAgRnVuY3Rpb25zIChPRnMpIGFuZC9vciBhcHBsaWNhdGlvbnMuICBUaGUgc2V0IG9mIERP REFHcw0KPiBpZGVudGlmaWVkDQo+ICAgICAgIGJ5IGEgUlBMSW5zdGFuY2VJRCBpcyBjYWxsZWQg YSBSUEwgSW5zdGFuY2UuICBBbGwgRE9EQUdzIGluIHRoZQ0KPiAgICAgICBzYW1lIFJQTCBJbnN0 YW5jZSB1c2UgdGhlIHNhbWUgT0YuIg0KPiANCj4gVGhhbmtzDQo+IE11a3VsDQo+IA0KPiAtLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJQaGlsaXAgTGV2aXMiIDxwYWxAY3Mu c3RhbmZvcmQuZWR1Pg0KPiBUbzogIlJhamVzaCBNYXJjaGFwcGFuYXZhciAocm1hcmNoYXApIiA8 cm1hcmNoYXBAY2lzY28uY29tPg0KPiBDYzogcm9sbEBpZXRmLm9yZw0KPiBTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDI0LCAyMDEwIDg6MjM6MzUgUE0NCj4gU3ViamVjdDogUmU6IFtSb2xsXSBN YWtlIE9DUCBwYXJ0IG9mIERJTyBiYXNlIG9iamVjdCBvciBtYWtlIERPREFHDQo+IAljb25maWd1 cmF0aW9uIG1hbmRhdG9yeSBmb3IgYWxsIERJT3MNCj4gDQo+IA0KPiBPbiBOb3YgMjQsIDIwMTAs IGF0IDY6MTIgUE0sIFJhamVzaCBNYXJjaGFwcGFuYXZhciAocm1hcmNoYXApIHdyb3RlOg0KPiAN Cj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gQ29uc2lkZXIgYSBzZXR1cCB3aXRoIDIgTEJScyBvciBE QUcgcm9vdHMgY29uZmlndXJlZCB3aXRoIHNhbWUNCj4gaW5zdGFuY2UtaWQgYW5kIGRhZy1pZCBi dXQgZGlmZmVyZW50IG9jcC10eXBlLg0KPiA+DQo+ID4gTEJSMS0tLS0tLS0tLU5vZGUtLS0tLS0t LS0tLS0tTEJSMg0KPiA+DQo+ID4gU2F5IExCUjEgaXMgY29uZmlndXJlZCB3aXRoIE9DUDAgYW5k IExCUjIgd2l0aCBPQ1AxIGFuZCBOb2RlIGlzDQo+IGNvbmZpZ3VyZWQgdG8gam9pbiBPQ1AwLg0K PiA+IExCUjEgc3RhcnRzIHVwIGZpcnN0LCBOb2RlIGhlYXJzIERJTyBmcm9tIExCUjEgYW5kIGpv aW5zIE9DUDAgZGFnLg0KPiA+IExCUjIgc2VuZHMgRElPIHdpdGggY29uZmlndXJhdGlvbiBvcHRp b24sIE5vZGUgZmFpbHMgdG8gbWF0Y2ggT0NQIGFuZA0KPiByZWplY3RzIERJTy4gQWxsIGZpbmUu DQo+ID4gTEJSMiBzZW5kcyBESU8gd2l0aCBvbmx5IEJhc2Ugb3B0aW9uLCBOb2RlIHdvdWxkIHNl bGVjdCBMQlIyIGFzDQo+IGFsdGVybmF0ZSBwYXJlbnQgYXNzdW1pbmcgcmFuayBhbmQgdmVyc2lv biBudW1iZXIgYXJlIHNhbWUgYXMgTEJSMeKAmXMuDQo+ID4gQSBub2RlIG5vdyBoYXMgYSBPQ1Aw IHByZWZlcnJlZCBwYXJlbnQgYW5kIGEgT0NQMSBhbHRlcm5hdGUgcGFyZW50Lg0KPiBCYXNlZCBv biBuZXR3b3JrIHNpdHVhdGlvbiwgTm9kZSBjb3VsZCBiZSBmbGFwcGluZyBiZXR3ZWVuIGENCj4g PiBPQ1AwIGRhZyBhbmQgYSBPQ1AxIGRhZy4NCj4gPg0KPiA+IFRoaXMgc2VlbXMgdG8gYmUgYSBt YWpvciBpc3N1ZSB1bmxlc3Mgc29tZWJvZHkgY2FuIGhlbHAgZXhwbGFpbiBSUEwNCj4gYmVoYXZp b3IgaXMgc3VjaCBjYXNlcy4NCj4gPiBZb3UgY291bGQgc2F5IHRoaXMgaXMgYSBtaXNjb25maWd1 cmF0aW9uLCB0cnVlLCBidXQgaG93IHdvdWxkIGEgTm9kZQ0KPiBkZXRlY3QgYW5kIHJlamVjdCB0 aGlzIG1pc2NvbmZpZz8NCj4gPg0KPiA+IElNTywgd2Ugc2hvdWxkIGVpdGhlciBtYWtlIE9DUCBw YXJ0IG9mIERJTyBiYXNlIG9iamVjdCBvciBtYWtlIERPREFHDQo+IGNvbmZpZ3VyYXRpb24gb3B0 aW9uIG1hbmRhdG9yeSBmb3IgRElPcy4NCj4gPiBQbGVhc2Ugc2hhcmUgeW91ciB0aG91Z2h0cy4N Cj4gPg0KPiANCj4gTEJSMSBhbmQgTEJSMiB1c2UgZGlmZmVyZW50IE9DUHMgaWYgYW5kIG9ubHkg aWYgdGhleSBhcmUgcGFydCBvZg0KPiBkaWZmZXJlbnQgRE9EQUdzLiBOb2RlIG5lZWRzIHRvIGtl ZXAgdHJhY2sgb2YgdGhlIERPREFHIC0+IE9DUCBtYXBwaW5nDQo+IGFuZCBhY3QgYWNjb3JkaW5n bHkuDQo+IA0KPiBQaGlsDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IFJvbGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From pthubert@cisco.com Thu Nov 25 23:24:56 2010 Return-Path: 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 2B7203A6A12 for ; Thu, 25 Nov 2010 23:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.291 X-Spam-Level: X-Spam-Status: No, score=-10.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Qjb-enKiFnl1 for ; Thu, 25 Nov 2010 23:24:54 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B88373A69DD for ; Thu, 25 Nov 2010 23:24:54 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0DAE/w7kyrRN+K/2dsb2JhbACUSI5HcaRXmmeFRwSNdg X-IronPort-AV: E=Sophos;i="4.59,260,1288569600"; d="scan'208";a="626196192" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 26 Nov 2010 07:25:42 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id oAQ7PesP025230; Fri, 26 Nov 2010 07:25:41 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Nov 2010 08:25:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Nov 2010 08:25:38 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D034484A4@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03448396@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DIO loop Thread-Index: AcuMd3o98WpUtctARce4loWQ2159EAAOOM9QACKlObA= References: <4CEE18A1.8080009@watteco.com> <6A2A459175DABE4BB11DE2026AA50A5D03448396@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 26 Nov 2010 07:25:41.0269 (UTC) FILETIME=[215F9450:01CB8D3B] Subject: Re: [Roll] DIO loop 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: , X-List-Received-Date: Fri, 26 Nov 2010 07:24:56 -0000 Hello again Mathieu.=20 Typo: C detaches < a) advertises INFINITE_RANK OR b) forms its own grounded DAG > -> C detaches < a) advertises INFINITE_RANK OR b) forms its own floating (G bit reset) DAG > Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Pascal Thubert (pthubert) > Sent: Thursday, November 25, 2010 4:27 PM > To: m.pouillot@watteco.com; roll@ietf.org > Subject: Re: [Roll] DIO loop >=20 > Hi Mathieu >=20 > We understand that the data path loop is detected. So, what we are > discussing here is the question of whether a child can immediately follow the > last parent as that parent moves deeper in the same DODAG. >=20 > Historically, the spec has disallowed such a behavior. A node could not > increase its Rank immediately. Instead, the node would poison, wait, and > then reattach. So in your case: >=20 > - B resets > - B attaches to C > - C sees B moves deeper than self > - C detaches < a) advertises INFINITE_RANK OR b) forms its own grounded > DAG > and waits for the poisoning to take effect (time for the bad news has > spread a few hops) before it reattaches without constraint. > - If a) B has to detach from C and stay there till it finds another > parent. > - If b), B stays attached to C has long as C is the best thing that > it sees. > - If B misses the news from C then, after the delay, B discovers that C is now > deeper. There is a statistical chance that this happens. If that chance is 20% > then the chance that it happens twice is 4%, 3 time it becomes .8 % etc... We > see that things would settle rapidly. >=20 > Since the spec has allowed a limited elasticity to the poisoning rule, so the > child could follow the parent down as long as (8.2.2.4. item 3.) it does not go > deeper down than DAGMaxRankIncrease from its original position. >=20 > If you set DAGMaxRankIncrease to 0, you are back to the historic behavior. > Alternatively, you may set DAGMaxRankIncrease to a few > MinHopRankIncrease. In your case, that will cause a few iteration of the loop > you describe. In a dense environment, there is a chance that the node that > loses its last parent can reparent to someone lower that is not in its subdag, > in which case the new rule has allowed the DAG to recover faster. >=20 > I'm afraid that you have to make your own mind on whether a non-zero > DAGMaxRankIncrease is a good thing for your application... >=20 > : ) >=20 > Pascal > http://www.xtranormal.com/watch/7011357/ >=20 >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > > Mathieu Pouillot > > Sent: Thursday, November 25, 2010 9:05 AM > > To: roll@ietf.org > > Subject: [Roll] DIO loop > > > > Hi all, > > > > I have a problem with a DIO loop in a specific topology.: A---B---C , > A is the > > root of the DAG and the parent of B, B the parent of C. > > > > B resets for any reason (watchdog, power failure,...), then it > receives first the > > DIO from C . Therefore there is a loop because B is the child and the > parent of > > C. On each sending of DIO from B and C, the rank will be incremented > by the > > other one and so on... > > > > Two possibilities to avoid this loop, saved all the configuration of B > in memory > > and so after a reset load the information saved (can ask a lot of > memory). > > Second solution is to send a DIS (not mandatory by the > > specification) and wait to receive all DIO before joining the DAG. > > > > Is there another solution? > > > > best regards, > > > > Mathieu > > > > > > > > -- > > Mathieu Pouillot > > R&D Engineer > > m.pouillot@watteco.com > > > > Tel : +33(0)4 98 01 60 05 (Poste 43) > > Fax : +33(0)4 94 14 10 80 > > 1766 Chemin de la Planquette > > 83130 LA GARDE - France > > www.watteco.com > > > > _______________________________________________ > > 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 m.pouillot@watteco.com Thu Nov 25 23:46:45 2010 Return-Path: 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 0C6943A69CC for ; Thu, 25 Nov 2010 23:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 rzxdk1H6SZ3s for ; Thu, 25 Nov 2010 23:46:43 -0800 (PST) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 85EA83A69A6 for ; Thu, 25 Nov 2010 23:46:43 -0800 (PST) Received: from [192.168.4.247] ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id ISV95344; Fri, 26 Nov 2010 08:47:44 +0100 Message-ID: <4CEF662D.5000802@watteco.com> Date: Fri, 26 Nov 2010 08:47:57 +0100 From: Mathieu Pouillot User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4CEE18A1.8080009@watteco.com> <6A2A459175DABE4BB11DE2026AA50A5D03448396@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D034484A4@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D034484A4@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] DIO loop X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: m.pouillot@watteco.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 07:46:45 -0000 Hi Pascal, Thank you for this terrific explication. Now, it is more clear for me and I need to choose the best solution for my application and plc medium. best regards, Mathieu Le 26/11/2010 08:25, Pascal Thubert (pthubert) a écrit : > Hello again Mathieu. > > Typo: > C detaches< a) advertises INFINITE_RANK OR b) forms its own grounded > DAG> > -> > C detaches< a) advertises INFINITE_RANK OR b) forms its own floating > (G bit reset) DAG> > > Cheers, > > Pascal > http://www.xtranormal.com/watch/7011357/ > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Pascal Thubert (pthubert) >> Sent: Thursday, November 25, 2010 4:27 PM >> To: m.pouillot@watteco.com; roll@ietf.org >> Subject: Re: [Roll] DIO loop >> >> Hi Mathieu >> >> We understand that the data path loop is detected. So, what we are >> discussing here is the question of whether a child can immediately > follow the >> last parent as that parent moves deeper in the same DODAG. >> >> Historically, the spec has disallowed such a behavior. A node could > not >> increase its Rank immediately. Instead, the node would poison, wait, > and >> then reattach. So in your case: >> >> - B resets >> - B attaches to C >> - C sees B moves deeper than self >> - C detaches< a) advertises INFINITE_RANK OR b) forms its own > grounded >> DAG> and waits for the poisoning to take effect (time for the bad > news has >> spread a few hops) before it reattaches without constraint. >> - If a) B has to detach from C and stay there till it finds another >> parent. >> - If b), B stays attached to C has long as C is the best thing that >> it sees. >> - If B misses the news from C then, after the delay, B discovers that > C is now >> deeper. There is a statistical chance that this happens. If that > chance is 20% >> then the chance that it happens twice is 4%, 3 time it becomes .8 % > etc... We >> see that things would settle rapidly. >> >> Since the spec has allowed a limited elasticity to the poisoning rule, > so the >> child could follow the parent down as long as (8.2.2.4. item 3.) it > does not go >> deeper down than DAGMaxRankIncrease from its original position. >> >> If you set DAGMaxRankIncrease to 0, you are back to the historic > behavior. >> Alternatively, you may set DAGMaxRankIncrease to a few >> MinHopRankIncrease. In your case, that will cause a few iteration of > the loop >> you describe. In a dense environment, there is a chance that the node > that >> loses its last parent can reparent to someone lower that is not in its > subdag, >> in which case the new rule has allowed the DAG to recover faster. >> >> I'm afraid that you have to make your own mind on whether a non-zero >> DAGMaxRankIncrease is a good thing for your application... >> >> : ) >> >> Pascal >> http://www.xtranormal.com/watch/7011357/ >> >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of >>> Mathieu Pouillot >>> Sent: Thursday, November 25, 2010 9:05 AM >>> To: roll@ietf.org >>> Subject: [Roll] DIO loop >>> >>> Hi all, >>> >>> I have a problem with a DIO loop in a specific topology.: A---B---C > , >> A is the >>> root of the DAG and the parent of B, B the parent of C. >>> >>> B resets for any reason (watchdog, power failure,...), then it >> receives first the >>> DIO from C . Therefore there is a loop because B is the child and > the >> parent of >>> C. On each sending of DIO from B and C, the rank will be incremented >> by the >>> other one and so on... >>> >>> Two possibilities to avoid this loop, saved all the configuration of > B >> in memory >>> and so after a reset load the information saved (can ask a lot of >> memory). >>> Second solution is to send a DIS (not mandatory by the >>> specification) and wait to receive all DIO before joining the DAG. >>> >>> Is there another solution? >>> >>> best regards, >>> >>> Mathieu >>> >>> >>> >>> -- >>> Mathieu Pouillot >>> R&D Engineer >>> m.pouillot@watteco.com >>> >>> Tel : +33(0)4 98 01 60 05 (Poste 43) >>> Fax : +33(0)4 94 14 10 80 >>> 1766 Chemin de la Planquette >>> 83130 LA GARDE - France >>> www.watteco.com >>> >>> _______________________________________________ >>> 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 -- Mathieu Pouillot R&D Engineer m.pouillot@watteco.com Tel : +33(0)4 98 01 60 05 (Poste 43) Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE - France www.watteco.com From Adrian.Farrel@huawei.com Fri Nov 26 00:28:56 2010 Return-Path: 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 DEF613A6A0B for ; Fri, 26 Nov 2010 00:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.839 X-Spam-Level: X-Spam-Status: No, score=-100.839 tagged_above=-999 required=5 tests=[AWL=-3.240, BAYES_00=-2.599, GB_SUMOF=5, USER_IN_WHITELIST=-100] 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 9F4flG5o4ter for ; Fri, 26 Nov 2010 00:28:55 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 2C9043A69A3 for ; Fri, 26 Nov 2010 00:28:55 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCH00I76GXX1R@usaga01-in.huawei.com> for roll@ietf.org; Fri, 26 Nov 2010 00:29:57 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCH00HKTGXUAT@usaga01-in.huawei.com> for roll@ietf.org; Fri, 26 Nov 2010 00:29:57 -0800 (PST) Date: Fri, 26 Nov 2010 08:29:54 +0000 From: Adrian Farrel To: draft-ietf-roll-routing-metric@tools.ietf.org Message-id: <021e01cb8d44$1b6d1fa0$52475ee0$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcuNQ8FeTw/5B5cWTume3sDwRRRxKA== Cc: roll@ietf.org Subject: [Roll] AD review of draft-ietf-roll-routing-metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 08:28:57 -0000 Hi, I have performed an AD review of your draft. Don't panic! I review all drafts that I am responsible for before putting them forward for IETF last call. The main objective is to catch nits and minor issues that would show up during the last call or in IESG review. The intention is to help polish your document and make sure it is clean and shiny so that other reviewers will stick to the technical details. Thanks for an important component of the RPL family. Most of my comments are pretty trivial, but a couple have more meat on them and I'd like to see a quick respin of the document before I issue the IETF last call. As soon as I see a new revision posted, I'll set the ball in motion. Of course, all of my issues are up for discussion. Thanks for the work, Adrian --- I am slightly worried about the complexity inherent in this spec. Although individual implementations and deployments might choose to use a very limited subset of the available (and flexible) options, it seems that an implementation must support a much wider subset of options, metrics, and constraints in order to be deployable into a wide range of networks. Does this flexibility impact simplicity of implementation? --- I think [I-D.ietf-roll-rpl] should be a normative reference. --- Section 1 One of the prime objectives of this document is to propose a flexible s/propose/define/ --- DODAG is used without expansion On the other hand, DAG is expanded more than once. --- Section 1 The best path is the path with the lowest cost with respect to some metrics that satisfies all constraints (if any). Slightly ambiguous. What satisfies the constraints: the path, the cost, the metrics? Suggest... The best path is the path that satisfies all supplied constraints and that has the lowest cost with respect to some specified metrics. --- Section 1 OLD Routing metrics falls into the following sets of characteristics: NEW Routing metrics may be categorized according to the following characteristics: END (English) --- Section 1 OLD Some link or node characteristics (e.g. link reliability flag, NEW Some link or node characteristics (e.g. link reliability, END (the flag is not a characteristic) --- Section 1 OLD remaining energy on the node) may either be used by RPL either as routing constraints or metrics. NEW remaining energy on the node) may be used by RPL either as routing constraints or as metrics. OLD (English) --- Section 1 OLD exclusive (e.g. it is for example possible to advertise a "hop count" NEW exclusive (e.g. it is possible to advertise a "hop count" END (English) --- Section 1 s/dynimicity/dynamicity/ --- Section 1 It must be noted that the use of dynamic metrics is not new and has been experimented in ARPANET 2. The use of dynamic metrics is not trivial and great care must be given to the use of dynamic metrics since it may lead to potential routing instabilities. That being said, lots of experience has been gained over the years on the use of dynamic routing metrics, which have been deployed in a number of (non IP) networks. Can you add a couple of references? One for ARPANET 2 experimentation, and one for the "lots of experience gained". --- Use of RFC 2119 language. The first use (SHOULD) shows up late in Section 1 after a number of lower case "must". I think that the best way to smooth this out is to not use any 2119 language in the Introduction. --- Section 1 OLD nodes in LLN, it is particularly critical to ensure the use of NEW nodes in LLN, it is critical to ensure the use of END (critical is a superlative) --- Please capitalise all section headers --- Figure 1 This is a copy of figure 22 in draft-ietf-roll-rpl. I strongly recommend that you do not duplicate protocol bit/byte definitions as this can lead to accidental discrepancies. Why not replace this figure with a reference? --- Bit numberings in fields. Please align the numbers so that we count bits in base 10. --- Section 2.1 Routing Metric/Constraint object field descriptions. Convention is to list these under the figure in the same order as they appear in the figure. The most disruptive, in this case, is the dislocation of the P field (which should probably also be called the P flag). --- Section 2.1 I think the A flag needs a little more constraint. Not only is it only valid when C=1 (as stated), but it is only valid when R=0. Also OLD and MUST be written to 0x00. NEW and MUST be set to 0x00 and MUST be ignored on receipt. END --- Section 2.1 Unrecognized TLVs MUST be ignored. Do you want to clarify that "ignoring" includes leaving the TLVs in place in the object when it is forwarded along the DAG? --- Section 2.2 Have you considered the case that the recording of metrics causes the Routing Metric/Constraint object to overflow? --- Section 3.1 The Node State and Attribute (NSA) object is used to provide information on node's characteristics. s/node's/node/ --- Section 3.1 The NSA object MAY be present in the DAG Metric Container. There MUST be no more than one NSA object as a constraint per DAG Metric Container, and no more than one NSA object as a metric per DAG Metric Container. This is fine, but you will need to define somewhere what happens when a formatting error is detected. This can either be done on a case-by- case basis, or can be a general statement in Section 3. See also, Section 3.2 The NE object MAY be present in the DAG Metric Container. There MUST be no more than one NE object as a constraint per DAG Metric Container, and no more than one NE object as a metric per DAG Metric Container. etc., etc. Incidentally, it might be more graceful to use "MUST NOT" instead of "MUST". For example: OLD The HP object MAY be present in the DAG Metric Container. There MUST be no more than one HP object as a constraint per DAG Metric Container, and no more than one HP object as a metric per DAG Metric Container. NEW The HP object MAY be present in the DAG Metric Container. There MUST NOT be more one HP object as a constraint per DAG Metric Container, and there MUST NOT be more than one HP object as a metric per DAG Metric Container. END --- Section 3.1 There seems to be some duplication of the definition of the O and A flags. --- Section 3.1 Is IANA expected to track the flags in the NSA object? Are the Type values for the TLVs chosen from a common registry across all objects, or is there a separate registry for each object? --- Section 3.2 Whenever possible, a node with low residual energy should not be selected as a router Do you have a reference for this? --- Section 3.2 Given the complexity of trying to address such a broad collection of constraints, this document defines three levels of fidelity in the solution. I only find two levels defined in the section: - The simplest solution relies on a 2-bit field - The mid-complexity solution is a single parameter Did I miss one, or did you? --- Section 3.2 For scavenging nodes, the 8 bit quantity is the power provided by the scavenger divided by the power consumed by the application, H=P_in/P_out, in units of percent. and For battery powered devices, H is the current expected lifetime divided by the desired minimum lifetime. Is the second case also expressed as a percentage? --- Section 3.2 I'm slightly confused by the difference (or not) between the term 'H' and the term 'E-E'. Firstly, E-E looks like an arithmetic expression. But, more to the point, I *think* you put the value of H in the field E-E, so why have two names for the same thing? --- Objects, sub-objects, and TLVs I think you have some inconsistency in naming. At the top level we have "Routing Metric/Constraint object" The "object body" of this object is defined as: The object body carries one or more sub-objects defined later in this document. So I expect everything that follows in Sections 3 and 4 to be termed sub-objects. But you have also termed these things as "objects". Some of the objects/sub-objects in Sections 3 and 4 can, themselves have sub-objects, while others launch straight into contained TLVs. This is all a bit confusing (although there is nothing technically wrong) and it would be really nice to achieve some consistency of terminology. --- Section 3.2 The format of the NE sub-object body is as follows: And what Type value does this sub-object use? --- Section 3.2 o T (node Type): 2-bit field indicating the node type. E=0x00 designates a mains-powered node, E=0x01 a battery-powered node and E=0x02 a node powered by an energy scavenger. Do you mean T=0x00 etc.? --- Section 3.2 empty is that I bit is an inclusion. s/is that/if that/ --- Section 3.2 Future addenda to this document may include more complex solutions involving a half dozen TLV parameters representing energy storage, consumption, and generation capabilities of the node, as well as desired lifetime. Can you rephrase this to avoid mentioning "addenda" which we don't really do? How about: Future documents may define more complex solutions involving TLV parameters representing energy storage, consumption, and generation capabilities of the node, as well as desired lifetime. --- Section 3.3 No Flag is currently defined. Need the usual "set to zero, ignored on receipt" text. --- Section 3.3 The HP object may be used as a constraint or a metric. When used as a constraint, the DAG root indicates the maximum number of hops that a path may traverse. When that number is reached, no other node can join that path. When used as a metric, each visited node simply increments the Hop Count field. Are you counting nodes or hops? Does the first node send the Hop Count as one or zero? --- Section 3.3 It looks to me that if the object is used as a constraint, it MUST also be present as a metric. This seems to be different from the burble at the top of the section. (and obviously, we can think of more optimal ways of signaling this - such as decrementing the hop count at each hop). --- Section 4.1 For the deeply duty-cycled links found in many LLNs Will this term be clear to the reader? --- Section 4.1 OLD There are several MAC layer protocols which allow for the effective bit rate and power consumption of a link to vary over more than three orders of magnitude, with a corresponding change in power consumption. NEW There are several MAC layer protocols which allow for the effective bit rate of a link to vary over more than three orders of magnitude with a corresponding change in power consumption. END --- Section 4.1 With special reference to my comment (above) about objects, sub-objects, and TLVs, it is really not helpful to have an object (which is actually a sub-object) and a sub-object of that object both called Throughput! --- Section 4.1 Figure 9: Throughput sub-object format And what Type value does this sub-object use? But, I might ask why you need sub-objects when the content is well-known to be 32-bit values, and the parent object has a length field. --- Section 4.1 Throughput: 32 bits. The Throughput is encoded in 32 bits in unsigned integer format, expressed in bytes per second. Are you sure this is enough? Yes, it seems like it today. How future- proof is this? --- Section 4.2 Similarly to throughput, the latency of many LLN MAC sub-layers can vary over many orders of magnitude, again with a corresponding change in current consumption. s/current/power/? --- Section 4.2 Ditto object and sub-object names. Ditto sub-object Type value. --- Section 4.2 Again, it looks like the use of this object as a constraint is only possible if it is also used as a metric. So (again) it looks like the rules for object presence are broken. But that depends how it is used as a constraint! It might be used to mean that no link with unsatisfactory latency may be added to the DAG, or it might mean that the cumulative latency must not grow beyond the the constrained limit. You need to clarify meaning and usage. --- Section 4.3 Note that an RPL implementation MAY either use the LQL, the ETX or both. This immediately makes me worry about interoperability. --- Section 4.3.1 By contrast, the LQL link metric may be aggregated, in which case the sum of all LQLs may be reported (additive metric) How can this possibly be useful? Unless you know how many hops are traversed, the aggregate is meaningless! --- Section 4.3.1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | LQL sub-object +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... The Res field does not appear to be described. --- Section 4.3.1 It seems to me that a type 0x02 aggregation is not very helpful because "unknown" will hide the otherwise 'best' link quality. But maybe this doesn't matter because 'worst' link quality is more interesting. --- Section 4.4.1 Ditto Res field --- Section 4.4.1 How come the LC field in the two sub-objects have different sizes? --- Section 4.4.1 The use of the LC object is outside the scope of this document. It seems to me you have gone off half cocked :-( There is some description at the top of the section that implies a little about how LC is used. It seems closer to a color (a la ToS) than to a bit array (a la resource affinities). If you are determined that this is out of scope for your document, I wonder why the object is defined, and I wonder why the section has preamble on the use of the meaning of LC. And I really wonder about the presence of section 4.4.2. --- Section 6 There doesn't seem to be any tracking of sub-object Type values. --- Section 7 You really need a reference to draft-ietf-roll-security-framework. I think that you made a key security comment in a previous section where you said that it is recommended that the algorithms used do not cause excess information flapping. A significant security attack might be mounted by periodically attacking the quality of a link resulting in the routing protocol flapping. This would cause wider damage than simply the disruption to the local link. From jpv@cisco.com Fri Nov 26 07:31:42 2010 Return-Path: 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 AED013A6B13 for ; Fri, 26 Nov 2010 07:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.644 X-Spam-Level: X-Spam-Status: No, score=-107.644 tagged_above=-999 required=5 tests=[AWL=-2.045, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 r-2sueaBnsIQ for ; Fri, 26 Nov 2010 07:31:39 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3C3703A6A47 for ; Fri, 26 Nov 2010 07:31:38 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAINh70yQ/khMgWdsb2JhbACjDxUBARYiIqVimm2FRwSKYYMV X-IronPort-AV: E=Sophos;i="4.59,261,1288569600"; d="scan'208";a="70213635" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2010 15:32:41 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oAQFWfvU029353; Fri, 26 Nov 2010 15:32:41 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Nov 2010 16:32:41 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Nov 2010 16:32:40 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <021e01cb8d44$1b6d1fa0$52475ee0$@huawei.com> Date: Fri, 26 Nov 2010 16:32:39 +0100 Content-Transfer-Encoding: 7bit Message-Id: <74430CDC-EF18-4AFA-8614-43F463A7E34B@cisco.com> References: <021e01cb8d44$1b6d1fa0$52475ee0$@huawei.com> To: Adrian.Farrel@huawei.com X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 26 Nov 2010 15:32:40.0665 (UTC) FILETIME=[297D9490:01CB8D7F] Cc: roll@ietf.org, draft-ietf-roll-routing-metric@tools.ietf.org Subject: Re: [Roll] AD review of draft-ietf-roll-routing-metric 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: , X-List-Received-Date: Fri, 26 Nov 2010 15:31:42 -0000 Thanks for the very useful review. Expect a new revision next week ! Thanks. JP. On Nov 26, 2010, at 9:29 AM, Adrian Farrel wrote: > Hi, > > I have performed an AD review of your draft. > > Don't panic! > > I review all drafts that I am responsible for before putting them > forward for IETF last call. The main objective is to catch nits and > minor issues that would show up during the last call or in IESG > review. The intention is to help polish your document and make sure > it is clean and shiny so that other reviewers will stick to the > technical details. > > Thanks for an important component of the RPL family. > > Most of my comments are pretty trivial, but a couple have more meat > on them and I'd like to see a quick respin of the document before I > issue the IETF last call. As soon as I see a new revision posted, > I'll set the ball in motion. > > Of course, all of my issues are up for discussion. > > Thanks for the work, > Adrian > > --- > > I am slightly worried about the complexity inherent in this spec. > Although individual implementations and deployments might choose to use > a very limited subset of the available (and flexible) options, it seems > that an implementation must support a much wider subset of options, > metrics, and constraints in order to be deployable into a wide range of > networks. > > Does this flexibility impact simplicity of implementation? > > --- > > I think [I-D.ietf-roll-rpl] should be a normative reference. > > --- > > Section 1 > > One of the prime objectives of this document is to propose a flexible > > s/propose/define/ > > --- > > DODAG is used without expansion > On the other hand, DAG is expanded more than once. > > --- > > Section 1 > > The best path is the path with the lowest cost with respect to some > metrics that satisfies all constraints (if any). > > Slightly ambiguous. What satisfies the constraints: the path, the cost, > the metrics? > > Suggest... > > The best path is the path that satisfies all supplied constraints and > that has the lowest cost with respect to some specified metrics. > > --- > > Section 1 > > OLD > Routing metrics falls into the following sets of characteristics: > NEW > Routing metrics may be categorized according to the following > characteristics: > END > > (English) > > --- > > Section 1 > > OLD > Some link or node characteristics (e.g. link reliability flag, > NEW > Some link or node characteristics (e.g. link reliability, > END > > (the flag is not a characteristic) > > --- > > Section 1 > > OLD > remaining energy on the node) may either be used by RPL either as > routing constraints or metrics. > NEW > remaining energy on the node) may be used by RPL either as routing > constraints or as metrics. > OLD > > (English) > > --- > > Section 1 > > OLD > exclusive (e.g. it is for example possible to advertise a "hop count" > NEW > exclusive (e.g. it is possible to advertise a "hop count" > END > > (English) > > --- > > Section 1 > > s/dynimicity/dynamicity/ > > --- > > Section 1 > > It must be noted that the use of dynamic metrics is not new and has > been experimented in ARPANET 2. The use of dynamic metrics is not > trivial and great care must be given to the use of dynamic metrics > since it may lead to potential routing instabilities. That being > said, lots of experience has been gained over the years on the use of > dynamic routing metrics, which have been deployed in a number of (non > IP) networks. > > Can you add a couple of references? One for ARPANET 2 experimentation, > and one for the "lots of experience gained". > > --- > > Use of RFC 2119 language. > > The first use (SHOULD) shows up late in Section 1 after a number of > lower case "must". I think that the best way to smooth this out is to > not use any 2119 language in the Introduction. > > --- > > Section 1 > > OLD > nodes in LLN, it is particularly critical to ensure the use of > NEW > nodes in LLN, it is critical to ensure the use of > END > > (critical is a superlative) > > --- > > Please capitalise all section headers > > --- > > Figure 1 > > This is a copy of figure 22 in draft-ietf-roll-rpl. > I strongly recommend that you do not duplicate protocol bit/byte > definitions as this can lead to accidental discrepancies. Why not > replace this figure with a reference? > > --- > > Bit numberings in fields. Please align the numbers so that we > count bits in base 10. > > --- > > Section 2.1 > > Routing Metric/Constraint object field descriptions. > > Convention is to list these under the figure in the same order as they > appear in the figure. The most disruptive, in this case, is the > dislocation of the P field (which should probably also be called the P > flag). > > --- > > Section 2.1 > > I think the A flag needs a little more constraint. Not only is it only > valid when C=1 (as stated), but it is only valid when R=0. > > Also > OLD > and MUST be written to 0x00. > NEW > and MUST be set to 0x00 and MUST be ignored on receipt. > END > > --- > > Section 2.1 > > Unrecognized TLVs MUST be ignored. > > Do you want to clarify that "ignoring" includes leaving the TLVs in > place in the object when it is forwarded along the DAG? > > --- > > Section 2.2 > > Have you considered the case that the recording of metrics causes the > Routing Metric/Constraint object to overflow? > > --- > > Section 3.1 > > The Node State and Attribute (NSA) object is used to provide > information on node's characteristics. > > s/node's/node/ > > --- > > Section 3.1 > > The NSA object MAY be present in the DAG Metric Container. There > MUST be no more than one NSA object as a constraint per DAG Metric > Container, and no more than one NSA object as a metric per DAG Metric > Container. > > This is fine, but you will need to define somewhere what happens when > a formatting error is detected. This can either be done on a case-by- > case basis, or can be a general statement in Section 3. > > See also, Section 3.2 > > The NE object MAY be present in the DAG Metric Container. There MUST > be no more than one NE object as a constraint per DAG Metric > Container, and no more than one NE object as a metric per DAG Metric > Container. > > etc., etc. > > Incidentally, it might be more graceful to use "MUST NOT" instead of > "MUST". For example: > > OLD > The HP object MAY be present in the DAG Metric Container. There MUST > be no more than one HP object as a constraint per DAG Metric > Container, and no more than one HP object as a metric per DAG Metric > Container. > NEW > The HP object MAY be present in the DAG Metric Container. There MUST > NOT be more one HP object as a constraint per DAG Metric Container, > and there MUST NOT be more than one HP object as a metric per DAG > Metric Container. > END > > --- > > Section 3.1 > > There seems to be some duplication of the definition of the O and A > flags. > > --- > > Section 3.1 > > Is IANA expected to track the flags in the NSA object? > > Are the Type values for the TLVs chosen from a common registry across > all objects, or is there a separate registry for each object? > > --- > > Section 3.2 > > Whenever possible, a node with low residual energy should not be > selected as a router > > Do you have a reference for this? > > --- > > Section 3.2 > > Given the complexity of trying to address such a broad collection of > constraints, this document defines three levels of fidelity in the > solution. > > I only find two levels defined in the section: > - The simplest solution relies on a 2-bit field > - The mid-complexity solution is a single parameter > > Did I miss one, or did you? > > --- > > Section 3.2 > > For scavenging nodes, the 8 bit quantity is the power > provided by the scavenger divided by the power consumed by the > application, H=P_in/P_out, in units of percent. > > and > > For > battery powered devices, H is the current expected lifetime divided > by the desired minimum lifetime. > > Is the second case also expressed as a percentage? > > --- > > Section 3.2 > > I'm slightly confused by the difference (or not) between the term 'H' > and the term 'E-E'. Firstly, E-E looks like an arithmetic expression. > But, more to the point, I *think* you put the value of H in the field > E-E, so why have two names for the same thing? > > --- > > Objects, sub-objects, and TLVs > > I think you have some inconsistency in naming. > > At the top level we have "Routing Metric/Constraint object" > The "object body" of this object is defined as: > The object body carries one or more sub-objects defined later in this > document. > So I expect everything that follows in Sections 3 and 4 to be termed > sub-objects. But you have also termed these things as "objects". > > Some of the objects/sub-objects in Sections 3 and 4 can, themselves have > sub-objects, while others launch straight into contained TLVs. > > This is all a bit confusing (although there is nothing technically > wrong) and it would be really nice to achieve some consistency of > terminology. > > --- > > Section 3.2 > > The format of the NE sub-object body is as follows: > > And what Type value does this sub-object use? > > --- > > Section 3.2 > > o T (node Type): 2-bit field indicating the node type. E=0x00 > designates a mains-powered node, E=0x01 a battery-powered node and > E=0x02 a node powered by an energy scavenger. > > Do you mean T=0x00 etc.? > > --- > > Section 3.2 > > empty is that I bit is an inclusion. > > s/is that/if that/ > > --- > > Section 3.2 > > Future addenda to this document may include more complex solutions > involving a half dozen TLV parameters representing energy storage, > consumption, and generation capabilities of the node, as well as > desired lifetime. > > Can you rephrase this to avoid mentioning "addenda" which we don't > really do? How about: > > Future documents may define more complex solutions involving TLV > parameters representing energy storage, consumption, and generation > capabilities of the node, as well as desired lifetime. > > --- > > Section 3.3 > > No Flag is currently defined. > > Need the usual "set to zero, ignored on receipt" text. > > --- > > Section 3.3 > > The HP object may be used as a constraint or a metric. When used as > a constraint, the DAG root indicates the maximum number of hops that > a path may traverse. When that number is reached, no other node can > join that path. When used as a metric, each visited node simply > increments the Hop Count field. > > Are you counting nodes or hops? > Does the first node send the Hop Count as one or zero? > > --- > > Section 3.3 > > It looks to me that if the object is used as a constraint, it MUST also > be present as a metric. This seems to be different from the burble at > the top of the section. (and obviously, we can think of more optimal > ways of signaling this - such as decrementing the hop count at each > hop). > > --- > > Section 4.1 > > For the deeply duty-cycled links > found in many LLNs > > Will this term be clear to the reader? > > --- > > Section 4.1 > > OLD > There are several MAC layer > protocols which allow for the effective bit rate and power > consumption of a link to vary over more than three orders of > magnitude, with a corresponding change in power consumption. > NEW > There are several MAC layer > protocols which allow for the effective bit rate of a link to vary > over more than three orders of magnitude with a corresponding change > in power consumption. > END > > --- > > Section 4.1 > > With special reference to my comment (above) about objects, sub-objects, > and TLVs, it is really not helpful to have an object (which is actually > a sub-object) and a sub-object of that object both called Throughput! > > --- > > Section 4.1 > > Figure 9: Throughput sub-object format > > And what Type value does this sub-object use? > But, I might ask why you need sub-objects when the content is well-known > to be 32-bit values, and the parent object has a length field. > > --- > > Section 4.1 > > Throughput: 32 bits. The Throughput is encoded in 32 bits in > unsigned integer format, expressed in bytes per second. > > Are you sure this is enough? Yes, it seems like it today. How future- > proof is this? > > --- > > Section 4.2 > > Similarly to throughput, the latency of many LLN MAC sub-layers can > vary over many orders of magnitude, again with a corresponding change > in current consumption. > > s/current/power/? > > --- > > Section 4.2 > > Ditto object and sub-object names. > Ditto sub-object Type value. > > --- > > Section 4.2 > > Again, it looks like the use of this object as a constraint is only > possible if it is also used as a metric. So (again) it looks like the > rules for object presence are broken. > > But that depends how it is used as a constraint! It might be used to > mean that no link with unsatisfactory latency may be added to the DAG, > or it might mean that the cumulative latency must not grow beyond the > the constrained limit. > > You need to clarify meaning and usage. > > --- > > Section 4.3 > > Note that an RPL implementation MAY either use the LQL, the ETX or > both. > > This immediately makes me worry about interoperability. > > --- > > Section 4.3.1 > > By contrast, the LQL link metric may be > aggregated, in which case the sum of all LQLs may be reported > (additive metric) > > How can this possibly be useful? Unless you know how many hops are > traversed, the aggregate is meaningless! > > --- > > Section 4.3.1 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... > | Res | LQL sub-object > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... > > The Res field does not appear to be described. > > --- > > Section 4.3.1 > > It seems to me that a type 0x02 aggregation is not very helpful because > "unknown" will hide the otherwise 'best' link quality. > > But maybe this doesn't matter because 'worst' link quality is more > interesting. > > --- > > Section 4.4.1 > > Ditto Res field > > --- > > Section 4.4.1 > > How come the LC field in the two sub-objects have different sizes? > > --- > > Section 4.4.1 > > The use of the LC object is outside the scope of this document. > > It seems to me you have gone off half cocked :-( > > There is some description at the top of the section that implies a > little about how LC is used. It seems closer to a color (a la ToS) than > to a bit array (a la resource affinities). > > If you are determined that this is out of scope for your document, I > wonder why the object is defined, and I wonder why the section has > preamble on the use of the meaning of LC. And I really wonder about the > presence of section 4.4.2. > > --- > > Section 6 > > There doesn't seem to be any tracking of sub-object Type values. > > --- > > Section 7 > > You really need a reference to draft-ietf-roll-security-framework. > > I think that you made a key security comment in a previous section where > you said that it is recommended that the algorithms used do not cause > excess information flapping. A significant security attack might be > mounted by periodically attacking the quality of a link resulting in the > routing protocol flapping. This would cause wider damage than simply > the disruption to the local link. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From charliep@computer.org Tue Nov 23 09:53:26 2010 Return-Path: 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 6AA3E3A699D for ; Tue, 23 Nov 2010 09:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] 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 GxrAvF0RZb6u for ; Tue, 23 Nov 2010 09:53:25 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 8070C3A693E for ; Tue, 23 Nov 2010 09:53:25 -0800 (PST) Received: from [138.111.58.2] (helo=[172.17.96.169]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PKx4O-0003qK-F4; Tue, 23 Nov 2010 12:54:20 -0500 Message-ID: <4CEBFFCA.9070208@computer.org> Date: Tue, 23 Nov 2010 09:54:18 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Anders Brandt References: <1552099610.1823418.1290175654195.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1552099610.1823418.1290175654195.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52cc81979f564fcf311a7230df150bfd2a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 X-Mailman-Approved-At: Fri, 26 Nov 2010 23:59:25 -0800 Cc: roll Subject: Re: [Roll] Replace the term "good enough" with "usable" in P2P draft? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 17:53:26 -0000 Hello folks, Comments below : ----- Original Message ----- > From: "Anders Brandt" > To: "Mukul Goyal", "roll" > Sent: Thursday, November 18, 2010 2:01:01 AM > Subject: RE: [Roll] Replace the term "good enough" with "usable" in P2P draft? > > My suggestion would be that we explain in the introduction, that while > reactive discovery in a non-storing environment cannot locate the best > routes, the constraints allow us to identify routes that are good enough > for the actual purpose. > The rest of the document may then just refer to "routes". I am O.K. with this. > I have to agree that this is not a term that one meets very often > in RFCs - and thus we should try to align it with the IETF vocabulary. I'm not aware of a particular "IETF vocabulary" on this, but there might be a conventional term in use somewhere. If so, we should consider adopting it. > The meaning we are trying to convey is that both ends consider the > constraints fulfilled, i.e. the path is good enough. Check. > This is slightly different from convergence-based network discovery, > where routers have time to register many candidates and pick the best. Here, I am not sure. Do you have an example? What about when a router picks a route worth advertising, but is allowed to make local updates based on newer information and not advertise it? And besides, is there any example of network discovery that is not "convergence-based"? > In both cases we end up with "usable" routes. Thus, "usable" does really > not tell me a lot. I don't understand this. Either a route is usable or it isn't usable. The criteria for acceptance should be unambiguous. What more should be disclosed in order to improve the process of route discovery? Anyway, I am still O.K. with the Anders' suggestion above. I don't think that such terms as "usable" are ambiguous as was claimed. In some publications, the word "feasible" has been used successfully for this concept. And I still believe that the application is best suited to provide the information determining whether or not a route could be used. For instance, it could setsockopt(QOS) some specific class of service . Regards, Charlie P. From mcr@sandelman.ca Mon Nov 29 06:33:36 2010 Return-Path: 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 B740328C126 for ; Mon, 29 Nov 2010 06:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_DUL=0.877] 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 o0aiBHbD9evQ for ; Mon, 29 Nov 2010 06:33:35 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id B4EC328C129 for ; Mon, 29 Nov 2010 06:33:35 -0800 (PST) Received: from marajade.sandelman.ca (cmr-208-124-129-34.cr.net.cable.rogers.com [208.124.129.34]) by relay.sandelman.ca (Postfix) with ESMTPS id C29ED3471E for ; Mon, 29 Nov 2010 09:40:31 -0500 (EST) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 60B3B98B1D for ; Mon, 29 Nov 2010 09:34:43 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com> <7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com> <9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu> <7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 29 Nov 2010 09:34:43 -0500 Message-ID: <31691.1291041283@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Make OCP part of DIO base object or make DODAG configuration mandatory for all DIOs 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: , X-List-Received-Date: Mon, 29 Nov 2010 14:33:36 -0000 >>>>> "Rajesh" == Rajesh Marchappanavar <(rmarchap)" > writes: >> > [RM:] Instance-id, DODAG-id and OCP are configurable parameters on >> > root/LBR, if network administrator configures same instance-id, >> DODAG-id >> > and different OCPs on LBR1 and LBR2, are LBR1 and LBR2 part of same >> > DODAG or different DODAG? >> >> This would be a configuration error that violates the specification. Rajesh> [RM:] True and I already said that. How does a node handle this Rajesh> configuration error? Putting ocp in DIO base object would Rajesh> help handle various such issues. I'm not sure why moving the location of the OCP would help. Rajesh asks a legitimate question: protocols must specify responses to external actions, with some transitions labelled as illegal. It's not useful to label a possible configuration as illegal: because a network node can only control it's own behaviour. Instead, we must be able to identify transitions in the state machine as being illegal. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From rmarchap@cisco.com Mon Nov 29 07:55:31 2010 Return-Path: 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 7706928C0ED for ; Mon, 29 Nov 2010 07:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 vxXY0w7egDlH for ; Mon, 29 Nov 2010 07:55:30 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5F3BB3A6AAC for ; Mon, 29 Nov 2010 07:55:30 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJJc80yrRN+J/2dsb2JhbACjA3GndI4BjQOCcYJWBIRciRo X-IronPort-AV: E=Sophos;i="4.59,276,1288569600"; d="scan'208";a="627640203" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2010 15:56:40 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oATFuebq014758; Mon, 29 Nov 2010 15:56:40 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Nov 2010 07:56:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Nov 2010 07:56:36 -0800 Message-ID: <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> In-Reply-To: <31691.1291041283@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs Thread-Index: AcuP0pcTVZ9TYlD0Tf6ir10sa6m86QABttsg References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> <31691.1291041283@marajade.sandelman.ca> From: "Rajesh Marchappanavar (rmarchap)" To: "Michael Richardson" , X-OriginalArrivalTime: 29 Nov 2010 15:56:40.0124 (UTC) FILETIME=[02B6D7C0:01CB8FDE] Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Mon, 29 Nov 2010 15:55:31 -0000 > >>>>> "Rajesh" =3D=3D Rajesh Marchappanavar <(rmarchap)" > > writes: > >> > [RM:] Instance-id, DODAG-id and OCP are configurable > parameters on > >> > root/LBR, if network administrator configures same instance- > id, > >> DODAG-id > >> > and different OCPs on LBR1 and LBR2, are LBR1 and LBR2 part of > same > >> > DODAG or different DODAG? > >> > >> This would be a configuration error that violates the > specification. >=20 >=20 > Rajesh> [RM:] True and I already said that. How does a node handle > this > Rajesh> configuration error? Putting ocp in DIO base object would > Rajesh> help handle various such issues. >=20 > I'm not sure why moving the location of the OCP would help. [RM:] Instance-id, dag-id, version number and ocp identify a dag.=20 While the first 3 parameters are in DIO base object, ocp is in optional configuration option. This creates situations like the one I mentioned earlier. Repeating the issue here - if there are 2 roots configured with same instance-id/dag-id/ver-num but different ocps, and the roots do not always send configuration option in DIO, then on receiving a DIO without config option, a node would consider both the DIOs valid and has no means of knowing the 2 roots are actually hosting dags for different ocps. This would lead the node selecting one root as preferred parent and another as alternate parent although the 2 roots dags are of different ocps. If ocp is moved to DIO base object or by making configuration option mandatory in DIO, a node would detect the misconfig and reject DIO from second root when it is already attached to the first ocp DAG. Cheers, Rajesh >=20 > Rajesh asks a legitimate question: protocols must specify responses to > external actions, with some transitions labelled as illegal. It's not > useful to label a possible configuration as illegal: because a network > node can only control it's own behaviour. Instead, we must be able to > identify transitions in the state machine as being illegal. >=20 > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video > > then sign the petition. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Mon Nov 29 09:19:29 2010 Return-Path: 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 B65BA28C144 for ; Mon, 29 Nov 2010 09:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_DUL=0.877] 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 0ybuDKEALTRf for ; Mon, 29 Nov 2010 09:19:24 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 40C9E28C0DC for ; Mon, 29 Nov 2010 09:19:23 -0800 (PST) Received: from marajade.sandelman.ca (cmr-208-124-129-34.cr.net.cable.rogers.com [208.124.129.34]) by relay.sandelman.ca (Postfix) with ESMTPS id 119CE34718; Mon, 29 Nov 2010 12:26:21 -0500 (EST) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id C593A98B1D; Mon, 29 Nov 2010 12:20:23 -0500 (EST) From: Michael Richardson To: "Rajesh Marchappanavar (rmarchap)" In-Reply-To: <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> <31691.1291041283@marajade.sandelman.ca> <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 29 Nov 2010 12:20:23 -0500 Message-ID: <5717.1291051223@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Mon, 29 Nov 2010 17:19:29 -0000 >>>>> "Rajesh" == Rajesh Marchappanavar <(rmarchap)" > writes: Rajesh> [RM:] Instance-id, dag-id, version number and ocp identify a dag. Rajesh> While the first 3 parameters are in DIO base object, ocp is Rajesh> in optional Rajesh> configuration option. Rajesh> This creates situations like the one I mentioned Rajesh> earlier. Repeating the Rajesh> issue here - if there Rajesh> are 2 roots configured with same instance-id/dag-id/ver-num but Rajesh> different ocps, and the roots Rajesh> do not always send configuration option in DIO, then on Rajesh> receiving a DIO So the real bug is that the receiving node, which wants a specific DAG, taking into account the non-default OCF, is making a mistake and matching against a DIO which does not have that OCF payload. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From pal@cs.stanford.edu Mon Nov 29 09:38:46 2010 Return-Path: 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 C0FEE28C1A4 for ; Mon, 29 Nov 2010 09:38:45 -0800 (PST) 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 ospF9MdwuYob for ; Mon, 29 Nov 2010 09:38:43 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 23ECF28C155 for ; Mon, 29 Nov 2010 09:38:43 -0800 (PST) Received: from dn0a2103a2.sunet ([10.33.3.162]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PN7hg-0002Qr-RO; Mon, 29 Nov 2010 09:39:53 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> Date: Mon, 29 Nov 2010 09:39:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> <31691.1291041283@marajade.sandelman.ca> <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> To: Rajesh Marchappanavar (rmarchap) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: f824399eb00b5943f8bdbe5dd24fccda Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Mon, 29 Nov 2010 17:38:46 -0000 On Nov 29, 2010, at 7:56 AM, Rajesh Marchappanavar (rmarchap) wrote: >=20 >=20 >=20 >>>>>>> "Rajesh" =3D=3D Rajesh Marchappanavar <(rmarchap)" >> > writes: >>>>> [RM:] Instance-id, DODAG-id and OCP are configurable >> parameters on >>>>> root/LBR, if network administrator configures same instance- >> id, >>>> DODAG-id >>>>> and different OCPs on LBR1 and LBR2, are LBR1 and LBR2 part > of >> same >>>>> DODAG or different DODAG? >>>>=20 >>>> This would be a configuration error that violates the >> specification. >>=20 >>=20 >> Rajesh> [RM:] True and I already said that. How does a node handle >> this >> Rajesh> configuration error? Putting ocp in DIO base object would >> Rajesh> help handle various such issues. >>=20 >> I'm not sure why moving the location of the OCP would help. >=20 > [RM:] Instance-id, dag-id, version number and ocp identify a dag.=20 > While the first 3 parameters are in DIO base object, ocp is in = optional > configuration option. > This creates situations like the one I mentioned earlier. Repeating = the > issue here - if there > are 2 roots configured with same instance-id/dag-id/ver-num but > different ocps, and the roots > do not always send configuration option in DIO, then on receiving a = DIO > without config option, a node > would consider both the DIOs valid and has no means of knowing the 2 > roots are actually hosting dags > for different ocps. This would lead the node selecting one root as > preferred parent and another as > alternate parent although the 2 roots dags are of different ocps. >=20 > If ocp is moved to DIO base object or by making configuration option > mandatory in DIO, a node would > detect the misconfig and reject DIO from second root when it is = already > attached to the first ocp DAG. >=20 > Cheers, > Rajesh The trivial answer is that a node can request a configuration object = from another node (e.g., via a unicast DIS) before adding that node to = its neighbor set.=20 Phil= From rmarchap@cisco.com Mon Nov 29 09:54:42 2010 Return-Path: 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 B699228C142 for ; Mon, 29 Nov 2010 09:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 iK4+RY4zT9Pr for ; Mon, 29 Nov 2010 09:54:41 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DFEE528C11B for ; Mon, 29 Nov 2010 09:54:41 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0DADp480yrR7Ht/2dsb2JhbACUQI5GcagHmx6CcYJWBIRciRqIBQ X-IronPort-AV: E=Sophos;i="4.59,276,1288569600"; d="scan'208";a="385617200" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 29 Nov 2010 17:55:51 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oATHtppG019462; Mon, 29 Nov 2010 17:55:51 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Nov 2010 09:55:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Nov 2010 09:55:48 -0800 Message-ID: <7B822F730F822147977ED5B684ACE4900BFE92B1@xmb-sjc-21b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs Thread-Index: AcuP7G7ndrLESUoPQTK2/iuVA2yiAAAAVz7g References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> <31691.1291041283@marajade.sandelman.ca> <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> From: "Rajesh Marchappanavar (rmarchap)" To: "Philip Levis" X-OriginalArrivalTime: 29 Nov 2010 17:55:51.0254 (UTC) FILETIME=[A91EAF60:01CB8FEE] Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Mon, 29 Nov 2010 17:54:42 -0000 > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Monday, November 29, 2010 11:10 PM > To: Rajesh Marchappanavar (rmarchap) > Cc: Michael Richardson; roll@ietf.org > Subject: Re: [Roll] Make OCP part of DIO base object or make > DODAGconfiguration mandatory for all DIOs >=20 >=20 > On Nov 29, 2010, at 7:56 AM, Rajesh Marchappanavar (rmarchap) wrote: >=20 > > > > > > > >>>>>>> "Rajesh" =3D=3D Rajesh Marchappanavar <(rmarchap)" > >> > writes: > >>>>> [RM:] Instance-id, DODAG-id and OCP are configurable > >> parameters on > >>>>> root/LBR, if network administrator configures same instance- > >> id, > >>>> DODAG-id > >>>>> and different OCPs on LBR1 and LBR2, are LBR1 and LBR2 part > > of > >> same > >>>>> DODAG or different DODAG? > >>>> > >>>> This would be a configuration error that violates the > >> specification. > >> > >> > >> Rajesh> [RM:] True and I already said that. How does a node > handle > >> this > >> Rajesh> configuration error? Putting ocp in DIO base object would > >> Rajesh> help handle various such issues. > >> > >> I'm not sure why moving the location of the OCP would help. > > > > [RM:] Instance-id, dag-id, version number and ocp identify a dag. > > While the first 3 parameters are in DIO base object, ocp is in > optional > > configuration option. > > This creates situations like the one I mentioned earlier. Repeating > the > > issue here - if there > > are 2 roots configured with same instance-id/dag-id/ver-num but > > different ocps, and the roots > > do not always send configuration option in DIO, then on receiving a > DIO > > without config option, a node > > would consider both the DIOs valid and has no means of knowing the 2 > > roots are actually hosting dags > > for different ocps. This would lead the node selecting one root as > > preferred parent and another as > > alternate parent although the 2 roots dags are of different ocps. > > > > If ocp is moved to DIO base object or by making configuration option > > mandatory in DIO, a node would > > detect the misconfig and reject DIO from second root when it is > already > > attached to the first ocp DAG. > > > > Cheers, > > Rajesh >=20 >=20 > The trivial answer is that a node can request a configuration object > from another node (e.g., via a unicast DIS) before adding that node to > its neighbor set. [RM:] Yes that was considered but the issue with that is, every time a node receives a DIO without config option it would send out DIS, get a DIO with config option and drop it because the OCP does not match. The process would repeat every time root sends a DIO without config option. Battery powered nodes would drain out. Instead, IMO ocp can be added to DIO base object. Cheers, Rajesh >=20 > Phil From pal@cs.stanford.edu Mon Nov 29 10:19:23 2010 Return-Path: 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 DB0E73A6B44 for ; Mon, 29 Nov 2010 10:19:23 -0800 (PST) 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 NzgUzjVY-RpK for ; Mon, 29 Nov 2010 10:19:23 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 26C153A6B3D for ; Mon, 29 Nov 2010 10:19:23 -0800 (PST) Received: from dn0a2103a2.sunet ([10.33.3.162]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PN8L3-000521-0m; Mon, 29 Nov 2010 10:20:33 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <7B822F730F822147977ED5B684ACE4900BFE92B1@xmb-sjc-21b.amer.cisco.com> Date: Mon, 29 Nov 2010 10:20:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <80EFACEA-1CA0-4C18-9E15-1276DCB6EC73@cs.stanford.edu> References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> <31691.1291041283@marajade.sandelman.ca> <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> <7B822F730F822147977ED5B684ACE4900BFE92B1@xmb-sjc-21b.amer.cisco.com> To: Rajesh Marchappanavar (rmarchap) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Mon, 29 Nov 2010 18:19:24 -0000 On Nov 29, 2010, at 9:55 AM, Rajesh Marchappanavar (rmarchap) wrote: >>=20 > [RM:] Yes that was considered but the issue with that is, every time a > node receives a DIO without config option it would send out DIS, get a > DIO with config option and drop it because the OCP does not match. The > process would repeat every time root sends a DIO without config = option. > Battery powered nodes would drain out. Instead, IMO ocp can be added = to > DIO base object. I don't think I understand the exact problem you're describing. You seem = to have an idea for a feature or protocol change, then are arguing for = it from many directions, any one of which can be solved through other = means. If two nodes are advertising the same DODAGID, RPLInstance, and = InstanceID, yet have different OCPs, that is a configuration error or = bug (e.g., an implementation might have a memory bug that overwrote one = of the above fields to create the conflict). It is actually a = configuration error if *any* of the configuration option values are = different, even across InstanceIDs. But we seem to be fixating on the = OCP. The question was "how do you detect this configuration error?" I = presented the simple way in which a node can detect it: it validates the = configuration of another node before adding it to its neighbor set. By = definition, there is another node in the neighbor set. The node = detecting the configuration mismatch can use this "correct" node (it = might be the one with the error) to route some kind of configuration = error report as part of a management layer. Phil= From rmarchap@cisco.com Mon Nov 29 10:50:43 2010 Return-Path: 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 75A2F3A6C2A for ; Mon, 29 Nov 2010 10:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2rlPrFylOssl for ; Mon, 29 Nov 2010 10:50:42 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 185833A6BD7 for ; Mon, 29 Nov 2010 10:50:42 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0DAKeE80yrRN+J/2dsb2JhbACUQI5JcadtmySFRwSEXIkaiAU X-IronPort-AV: E=Sophos;i="4.59,276,1288569600"; d="scan'208";a="225106213" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 29 Nov 2010 18:51:52 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oATIpqA6000056; Mon, 29 Nov 2010 18:51:52 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Nov 2010 10:51:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Nov 2010 10:51:49 -0800 Message-ID: <7B822F730F822147977ED5B684ACE4900BFE9357@xmb-sjc-21b.amer.cisco.com> In-Reply-To: <80EFACEA-1CA0-4C18-9E15-1276DCB6EC73@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs Thread-Index: AcuP8h4xR1krIDEXSKC2qsdzQXHZhAAAFJ7g References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> <31691.1291041283@marajade.sandelman.ca> <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> <7B822F730F822147977ED5B684ACE4900BFE92B1@xmb-sjc-21b.amer.cisco.com> <80EFACEA-1CA0-4C18-9E15-1276DCB6EC73@cs.stanford.edu> From: "Rajesh Marchappanavar (rmarchap)" To: "Philip Levis" X-OriginalArrivalTime: 29 Nov 2010 18:51:52.0052 (UTC) FILETIME=[7C4FC340:01CB8FF6] Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Mon, 29 Nov 2010 18:50:43 -0000 > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Monday, November 29, 2010 11:51 PM > To: Rajesh Marchappanavar (rmarchap) > Cc: Michael Richardson; roll@ietf.org > Subject: Re: [Roll] Make OCP part of DIO base object or make > DODAGconfiguration mandatory for all DIOs >=20 >=20 > On Nov 29, 2010, at 9:55 AM, Rajesh Marchappanavar (rmarchap) wrote: >=20 > >> > > [RM:] Yes that was considered but the issue with that is, every time > a > > node receives a DIO without config option it would send out DIS, get > a > > DIO with config option and drop it because the OCP does not match. > The > > process would repeat every time root sends a DIO without config > option. > > Battery powered nodes would drain out. Instead, IMO ocp can be added > to > > DIO base object. >=20 > I don't think I understand the exact problem you're describing. You [RM:] Please read my first email, I will rewrite it below in this email. > seem to have an idea for a feature or protocol change, then are arguing > for it from many directions, any one of which can be solved through > other means. [RM:] No there aren't many directions, just one. The solution you described was tried out and I just presented the issues with that solution, not another direction for the problem. If you can provide a solution I will be the happiest person to use it instead of a protocol change. Protocol change is the only solution I could think of and I am not saying that is the only solution, I would listen to alternates happily. >=20 > If two nodes are advertising the same DODAGID, RPLInstance, and > InstanceID, yet have different OCPs, that is a configuration error or [RM:] Yes I have repeated that in every email I have sent out. This is a configuration error. Nodes needs to deal with it. If we can say in the draft that such configuration errors could occur and exist in the lifetime of a dag and will not be dealt with by the protocol, I am fine with that too. But that statement has to be made in the draft. > bug (e.g., an implementation might have a memory bug that overwrote one > of the above fields to create the conflict). It is actually a > configuration error if *any* of the configuration option values are > different, even across InstanceIDs. But we seem to be fixating on the > OCP. [RM:] That is because OCP differentiates dags, it's not just a 'configuration option'. A node can join 2 dags of different OCP, instance-id, and dag-id. Which means OCP is a dag characteristic and not just one of the configuration option. The fact that two nodes advertise same instance-id, dag-id, and different OCP is a mis-configuration. They should be advertising different instance-id, dag-id, and ocp. That said, nodes need to deal with such configuration errors. >=20 > The question was "how do you detect this configuration error?" I > presented the simple way in which a node can detect it: it validates > the configuration of another node before adding it to its neighbor set. > By definition, there is another node in the neighbor set. The node > detecting the configuration mismatch can use this "correct" node (it > might be the one with the error) to route some kind of configuration > error report as part of a management layer. [RM:] Below is the problem repeated from first mail along with the issue with your solution: Consider a setup with 2 LBRs or DAG roots configured with same instance-id and dag-id but different ocp-type. LBR1---------Node-------------LBR2 Say LBR1 is configured with OCP0 and LBR2 with OCP1 and Node is configured to join OCP0. LBR1 starts up first, Node hears DIO from LBR1 and joins OCP0 dag. LBR2 sends DIO with configuration option, Node fails to match OCP and rejects DIO. All fine. LBR2 sends DIO with only Base option, Node would select LBR2 as alternate parent assuming rank and version number are same as LBR1's. A node now has a OCP0 preferred parent and a OCP1 alternate parent. Based on network situation, Node could be flapping between a OCP0 dag and a OCP1 dag. Your solution: Send a unicast DIS and get config option. Issue with that - LBR2 sends DIO with only base option Node sends unicast DIS LBR2 sends DIO with config option, Node fails to match OCP and rejects DIO LBR2 sends DIO with only base option Node sends unicast DIS LBR2 sends DIO with config option, Node fails to match OCP and rejects DIO This process could keep repeating, which is fine. But since RPL network would have constraint nodes, if the node in this example happens to be a battery powered node, its battery would drain. Is this process worth when the simpler solution is to put ocp in DIO base object? Cheers, Rajesh >=20 > Phil From pal@cs.stanford.edu Mon Nov 29 11:04:50 2010 Return-Path: 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 AF83D3A6BE2 for ; Mon, 29 Nov 2010 11:04:50 -0800 (PST) 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 jjxM-VCDNDlN for ; Mon, 29 Nov 2010 11:04:49 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id A257A3A6BE1 for ; Mon, 29 Nov 2010 11:04:49 -0800 (PST) Received: from dn0a2103a2.sunet ([10.33.3.162]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PN931-0001rY-Bh; Mon, 29 Nov 2010 11:05:59 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <7B822F730F822147977ED5B684ACE4900BFE9357@xmb-sjc-21b.amer.cisco.com> Date: Mon, 29 Nov 2010 11:05:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1C508DE6-CE08-4A7E-B95C-4CF58C136BF1@cs.stanford.edu> References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> <31691.1291041283@marajade.sandelman.ca> <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> <7B822F730F822147977ED5B684ACE4900BFE92B1@xmb-sjc-21b.amer.cisco.com> <80EFACEA-1CA0-4C18-9E15-1276DCB6EC73@cs.stanford.edu> <7B822F730F822147977ED5B684ACE4900BFE9357@xmb-sjc-21b.amer.cisco.com> To: Rajesh Marchappanavar (rmarchap) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: bd77090d0b101435ee34dbdc8f90621c Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Mon, 29 Nov 2010 19:04:50 -0000 On Nov 29, 2010, at 10:51 AM, Rajesh Marchappanavar (rmarchap) wrote: >=20 >=20 >> -----Original Message----- >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> Sent: Monday, November 29, 2010 11:51 PM >> To: Rajesh Marchappanavar (rmarchap) >> Cc: Michael Richardson; roll@ietf.org >> Subject: Re: [Roll] Make OCP part of DIO base object or make >> DODAGconfiguration mandatory for all DIOs >>=20 >>=20 >> On Nov 29, 2010, at 9:55 AM, Rajesh Marchappanavar (rmarchap) wrote: >>=20 >>>>=20 >>> [RM:] Yes that was considered but the issue with that is, every time >> a >>> node receives a DIO without config option it would send out DIS, get >> a >>> DIO with config option and drop it because the OCP does not match. >> The >>> process would repeat every time root sends a DIO without config >> option. >>> Battery powered nodes would drain out. Instead, IMO ocp can be added >> to >>> DIO base object. >>=20 >> I don't think I understand the exact problem you're describing. You >=20 > [RM:] Please read my first email, I will rewrite it below in this = email. >=20 >> seem to have an idea for a feature or protocol change, then are > arguing >> for it from many directions, any one of which can be solved through >> other means. >=20 > [RM:] No there aren't many directions, just one. The solution you > described was tried out and I just presented the issues with that > solution, not another direction for the problem. If you can provide a > solution I will be the happiest person to use it instead of a protocol > change. Protocol change is the only solution I could think of and I am > not saying that is the only solution, I would listen to alternates > happily. >=20 >>=20 >> If two nodes are advertising the same DODAGID, RPLInstance, and >> InstanceID, yet have different OCPs, that is a configuration error or >=20 > [RM:] Yes I have repeated that in every email I have sent out. This is = a > configuration error. Nodes needs to deal with it. If we can say in the > draft that such configuration errors could occur and exist in the > lifetime of a dag and will not be dealt with by the protocol, I am = fine > with that too. But that statement has to be made in the draft. >=20 >> bug (e.g., an implementation might have a memory bug that overwrote > one >> of the above fields to create the conflict). It is actually a >> configuration error if *any* of the configuration option values are >> different, even across InstanceIDs. But we seem to be fixating on the >> OCP. >=20 > [RM:] That is because OCP differentiates dags, it's not just a > 'configuration option'. A node can join 2 dags of different OCP, > instance-id, and dag-id. Which means OCP is a dag characteristic and = not > just one of the configuration option. The fact that two nodes = advertise > same instance-id, dag-id, and different OCP is a mis-configuration. = They > should be advertising different instance-id, dag-id, and ocp. That = said, > nodes need to deal with such configuration errors. >=20 >>=20 >> The question was "how do you detect this configuration error?" I >> presented the simple way in which a node can detect it: it validates >> the configuration of another node before adding it to its neighbor > set. >> By definition, there is another node in the neighbor set. The node >> detecting the configuration mismatch can use this "correct" node (it >> might be the one with the error) to route some kind of configuration >> error report as part of a management layer. >=20 > [RM:] Below is the problem repeated from first mail along with the = issue > with your solution: >=20 > Consider a setup with 2 LBRs or DAG roots configured with same > instance-id and dag-id but different ocp-type. >=20 > LBR1---------Node-------------LBR2 >=20 > Say LBR1 is configured with OCP0 and LBR2 with OCP1 and Node is > configured to join OCP0. > LBR1 starts up first, Node hears DIO from LBR1 and joins OCP0 dag. > LBR2 sends DIO with configuration option, Node fails to match OCP and > rejects DIO. All fine. > LBR2 sends DIO with only Base option, Node would select LBR2 as > alternate parent assuming rank and version number are same as LBR1's. > A node now has a OCP0 preferred parent and a OCP1 alternate parent. > Based on network situation, Node could be flapping between a > OCP0 dag and a OCP1 dag. >=20 > Your solution: Send a unicast DIS and get config option. Issue with = that > - > LBR2 sends DIO with only base option > Node sends unicast DIS > LBR2 sends DIO with config option, Node fails to match OCP and rejects > DIO > LBR2 sends DIO with only base option > Node sends unicast DIS > LBR2 sends DIO with config option, Node fails to match OCP and rejects > DIO >=20 > This process could keep repeating, which is fine. But since RPL = network > would have constraint nodes, if the node in this example happens to be = a > battery powered node, its battery would drain. Is this process worth > when the simpler solution is to put ocp in DIO base object? Is this an accurate summary: the problem is that a misconfiguration can = lead to energy-inefficient behavior? Phil= From rmarchap@cisco.com Mon Nov 29 11:11:32 2010 Return-Path: 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 6B9DC3A6C23 for ; Mon, 29 Nov 2010 11:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 hDJNH44TmrWP for ; Mon, 29 Nov 2010 11:11:29 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9E0413A6C14 for ; Mon, 29 Nov 2010 11:11:29 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0DAEeK80yrR7Ht/2dsb2JhbACUQI5JcadymyKFRwSEXIkaiAU X-IronPort-AV: E=Sophos;i="4.59,276,1288569600"; d="scan'208";a="627751821" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2010 19:11:50 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oATJBoCp015932; Mon, 29 Nov 2010 19:11:50 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Nov 2010 11:11:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Nov 2010 11:11:46 -0800 Message-ID: <7B822F730F822147977ED5B684ACE4900BFE938E@xmb-sjc-21b.amer.cisco.com> In-Reply-To: <1C508DE6-CE08-4A7E-B95C-4CF58C136BF1@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs Thread-Index: AcuP+HrkQm6hlP6fSg2eo38xd6KyYQAACEAQ References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> <31691.1291041283@marajade.sandelman.ca> <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> <7B822F730F822147977ED5B684ACE4900BFE92B1@xmb-sjc-21b.amer.cisco.com> <80EFACEA-1CA0-4C18-9E15-1276DCB6EC73@cs.stanford.edu> <7B822F730F822147977ED5B684ACE4900BFE9357@xmb-sjc-21b.amer.cisco.com> <1C508DE6-CE08-4A7E-B95C-4CF58C136BF1@cs.stanford.edu> From: "Rajesh Marchappanavar (rmarchap)" To: "Philip Levis" X-OriginalArrivalTime: 29 Nov 2010 19:11:49.0385 (UTC) FILETIME=[45FA4790:01CB8FF9] Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Mon, 29 Nov 2010 19:11:33 -0000 > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, November 30, 2010 12:36 AM > To: Rajesh Marchappanavar (rmarchap) > Cc: Michael Richardson; roll@ietf.org > Subject: Re: [Roll] Make OCP part of DIO base object or make > DODAGconfiguration mandatory for all DIOs >=20 >=20 > On Nov 29, 2010, at 10:51 AM, Rajesh Marchappanavar (rmarchap) wrote: >=20 > > > > > >> -----Original Message----- > >> From: Philip Levis [mailto:pal@cs.stanford.edu] > >> Sent: Monday, November 29, 2010 11:51 PM > >> To: Rajesh Marchappanavar (rmarchap) > >> Cc: Michael Richardson; roll@ietf.org > >> Subject: Re: [Roll] Make OCP part of DIO base object or make > >> DODAGconfiguration mandatory for all DIOs > >> > >> > >> On Nov 29, 2010, at 9:55 AM, Rajesh Marchappanavar (rmarchap) wrote: > >> > >>>> > >>> [RM:] Yes that was considered but the issue with that is, every > time > >> a > >>> node receives a DIO without config option it would send out DIS, > get > >> a > >>> DIO with config option and drop it because the OCP does not match. > >> The > >>> process would repeat every time root sends a DIO without config > >> option. > >>> Battery powered nodes would drain out. Instead, IMO ocp can be > added > >> to > >>> DIO base object. > >> > >> I don't think I understand the exact problem you're describing. You > > > > [RM:] Please read my first email, I will rewrite it below in this > email. > > > >> seem to have an idea for a feature or protocol change, then are > > arguing > >> for it from many directions, any one of which can be solved through > >> other means. > > > > [RM:] No there aren't many directions, just one. The solution you > > described was tried out and I just presented the issues with that > > solution, not another direction for the problem. If you can provide a > > solution I will be the happiest person to use it instead of a > protocol > > change. Protocol change is the only solution I could think of and I > am > > not saying that is the only solution, I would listen to alternates > > happily. > > > >> > >> If two nodes are advertising the same DODAGID, RPLInstance, and > >> InstanceID, yet have different OCPs, that is a configuration error > or > > > > [RM:] Yes I have repeated that in every email I have sent out. This > is a > > configuration error. Nodes needs to deal with it. If we can say in > the > > draft that such configuration errors could occur and exist in the > > lifetime of a dag and will not be dealt with by the protocol, I am > fine > > with that too. But that statement has to be made in the draft. > > > >> bug (e.g., an implementation might have a memory bug that overwrote > > one > >> of the above fields to create the conflict). It is actually a > >> configuration error if *any* of the configuration option values are > >> different, even across InstanceIDs. But we seem to be fixating on > the > >> OCP. > > > > [RM:] That is because OCP differentiates dags, it's not just a > > 'configuration option'. A node can join 2 dags of different OCP, > > instance-id, and dag-id. Which means OCP is a dag characteristic and > not > > just one of the configuration option. The fact that two nodes > advertise > > same instance-id, dag-id, and different OCP is a mis-configuration. > They > > should be advertising different instance-id, dag-id, and ocp. That > said, > > nodes need to deal with such configuration errors. > > > >> > >> The question was "how do you detect this configuration error?" I > >> presented the simple way in which a node can detect it: it validates > >> the configuration of another node before adding it to its neighbor > > set. > >> By definition, there is another node in the neighbor set. The node > >> detecting the configuration mismatch can use this "correct" node (it > >> might be the one with the error) to route some kind of configuration > >> error report as part of a management layer. > > > > [RM:] Below is the problem repeated from first mail along with the > issue > > with your solution: > > > > Consider a setup with 2 LBRs or DAG roots configured with same > > instance-id and dag-id but different ocp-type. > > > > LBR1---------Node-------------LBR2 > > > > Say LBR1 is configured with OCP0 and LBR2 with OCP1 and Node is > > configured to join OCP0. > > LBR1 starts up first, Node hears DIO from LBR1 and joins OCP0 dag. > > LBR2 sends DIO with configuration option, Node fails to match OCP and > > rejects DIO. All fine. > > LBR2 sends DIO with only Base option, Node would select LBR2 as > > alternate parent assuming rank and version number are same as LBR1's. > > A node now has a OCP0 preferred parent and a OCP1 alternate parent. > > Based on network situation, Node could be flapping between a > > OCP0 dag and a OCP1 dag. > > > > Your solution: Send a unicast DIS and get config option. Issue with > that > > - > > LBR2 sends DIO with only base option > > Node sends unicast DIS > > LBR2 sends DIO with config option, Node fails to match OCP and > rejects > > DIO > > LBR2 sends DIO with only base option > > Node sends unicast DIS > > LBR2 sends DIO with config option, Node fails to match OCP and > rejects > > DIO > > > > This process could keep repeating, which is fine. But since RPL > network > > would have constraint nodes, if the node in this example happens to > be a > > battery powered node, its battery would drain. Is this process worth > > when the simpler solution is to put ocp in DIO base object? >=20 > Is this an accurate summary: the problem is that a misconfiguration can > lead to energy-inefficient behavior? [RM:] Yes that is accurate with the solution you provided. Without that solution, the problem is a node would have a preferred parent of one OCP and a alternate parent of another OCP, basically a node joins 2 dags (with configuration error) for same instance. Cheers, Rajesh >=20 > Phil From pal@cs.stanford.edu Mon Nov 29 16:35:45 2010 Return-Path: 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 251803A6C47 for ; Mon, 29 Nov 2010 16:35:45 -0800 (PST) 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 pmUqDgRWcEgO for ; Mon, 29 Nov 2010 16:35:43 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 468A43A6C3F for ; Mon, 29 Nov 2010 16:35:43 -0800 (PST) Received: from dn0a21027e.sunet ([10.33.2.126]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PNEDF-00072Q-Ju; Mon, 29 Nov 2010 16:36:53 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <7B822F730F822147977ED5B684ACE4900BFE938E@xmb-sjc-21b.amer.cisco.com> Date: Mon, 29 Nov 2010 16:36:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0A8BEF33-1150-437A-8308-5A7081741683@cs.stanford.edu> References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> <31691.1291041283@marajade.sandelman.ca> <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> <7B822F730F822147977ED5B684ACE4900BFE92B1@xmb-sjc-21b.amer.cisco.com> <80EFACEA-1CA0-4C18-9E15-1276DCB6EC73@cs.stanford.edu> <7B822F730F822147977ED5B684ACE4900BFE9357@xmb-sjc-21b.amer.cisco.com> <1C508DE6-CE08-4A7E-B95C-4CF58C136BF1@cs.stanford.edu> <7B822F730F822147977ED5B684ACE4900BFE938E@xmb-sjc-21b.amer.cisco.com> To: Rajesh Marchappanavar (rmarchap) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5 Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Tue, 30 Nov 2010 00:35:45 -0000 On Nov 29, 2010, at 11:11 AM, Rajesh Marchappanavar (rmarchap) wrote: >>=20 >> Is this an accurate summary: the problem is that a misconfiguration = can >> lead to energy-inefficient behavior? >=20 > [RM:] Yes that is accurate with the solution you provided. Without = that > solution, the problem is a node would have a preferred parent of one = OCP > and a alternate parent of another OCP, basically a node joins 2 dags > (with configuration error) for same instance. The same is true if there's a misconfiguration that sets DIOIntDoubl. to = 0: this would lead to energy-inefficient behavior. Should the protocol = protect against this case too? There's a configuration error if *any* of = the configuration values differ between the two nodes. Should all of = them be in the DIO? Your logic seems to assume particular processing on a node. E.g., that=20= "LBR2 sends DIO with config option, Node fails to match OCP and rejects = DIO" Where in the specification does it say that a node rejects the DIO in = this case and discards it? Another option is to keep state on that node = around: there's no question that a seriously misconfigured network is = going to work suboptimally. E.g., misconfigured routing tables can lead = to loops...=20 Phil From prvs=9435895e4=mukul@uwm.edu Mon Nov 29 21:22:33 2010 Return-Path: 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 3B0F328C16D for ; Mon, 29 Nov 2010 21:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, 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 MeWyVFa0AoE5 for ; Mon, 29 Nov 2010 21:22:26 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 7A70028C152 for ; Mon, 29 Nov 2010 21:22:20 -0800 (PST) Received: from mta01.pantherlink.uwm.edu ([129.89.7.132]) by ip1mta.uwm.edu with ESMTP; 29 Nov 2010 23:23:29 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id A137BE6A71; Mon, 29 Nov 2010 23:23:31 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HeeZJ-VHeSQ; Mon, 29 Nov 2010 23:23:30 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id A691BE6A6F; Mon, 29 Nov 2010 23:23:30 -0600 (CST) Date: Mon, 29 Nov 2010 23:23:29 -0600 (CST) From: Mukul Goyal To: "Rajesh Marchappanavar (rmarchap)" Message-ID: <1708544239.78429.1291094609909.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <7B822F730F822147977ED5B684ACE4900BFE9357@xmb-sjc-21b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Tue, 30 Nov 2010 05:22:33 -0000 Rajesh, [RM:] That is because OCP differentiates dags, it's not just a 'configuration option'. A node can join 2 dags of different OCP, instance-id, and dag-id. Which means OCP is a dag characteristic and not just one of the configuration option. The fact that two nodes advertise same instance-id, dag-id, and different OCP is a mis-configuration. They should be advertising different instance-id, dag-id, and ocp. That said, nodes need to deal with such configuration errors. The same can be said about the routing metrics in the Metric Container. What if the two roots in your example include different routing metrics in the Metric Container? I guess the metrics in use also characterize the dag just like OCP. Perhaps, one can identify other parameters that characterize a dag but are not there in the DIO base object. It seems to me that dealing with configuration errors does not belong to the core spec. Thanks Mukul ----- Original Message ----- From: "Rajesh Marchappanavar (rmarchap)" To: "Philip Levis" Cc: roll@ietf.org Sent: Monday, November 29, 2010 12:51:49 PM Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Monday, November 29, 2010 11:51 PM > To: Rajesh Marchappanavar (rmarchap) > Cc: Michael Richardson; roll@ietf.org > Subject: Re: [Roll] Make OCP part of DIO base object or make > DODAGconfiguration mandatory for all DIOs > > > On Nov 29, 2010, at 9:55 AM, Rajesh Marchappanavar (rmarchap) wrote: > > >> > > [RM:] Yes that was considered but the issue with that is, every time > a > > node receives a DIO without config option it would send out DIS, get > a > > DIO with config option and drop it because the OCP does not match. > The > > process would repeat every time root sends a DIO without config > option. > > Battery powered nodes would drain out. Instead, IMO ocp can be added > to > > DIO base object. > > I don't think I understand the exact problem you're describing. You [RM:] Please read my first email, I will rewrite it below in this email. > seem to have an idea for a feature or protocol change, then are arguing > for it from many directions, any one of which can be solved through > other means. [RM:] No there aren't many directions, just one. The solution you described was tried out and I just presented the issues with that solution, not another direction for the problem. If you can provide a solution I will be the happiest person to use it instead of a protocol change. Protocol change is the only solution I could think of and I am not saying that is the only solution, I would listen to alternates happily. > > If two nodes are advertising the same DODAGID, RPLInstance, and > InstanceID, yet have different OCPs, that is a configuration error or [RM:] Yes I have repeated that in every email I have sent out. This is a configuration error. Nodes needs to deal with it. If we can say in the draft that such configuration errors could occur and exist in the lifetime of a dag and will not be dealt with by the protocol, I am fine with that too. But that statement has to be made in the draft. > bug (e.g., an implementation might have a memory bug that overwrote one > of the above fields to create the conflict). It is actually a > configuration error if *any* of the configuration option values are > different, even across InstanceIDs. But we seem to be fixating on the > OCP. [RM:] That is because OCP differentiates dags, it's not just a 'configuration option'. A node can join 2 dags of different OCP, instance-id, and dag-id. Which means OCP is a dag characteristic and not just one of the configuration option. The fact that two nodes advertise same instance-id, dag-id, and different OCP is a mis-configuration. They should be advertising different instance-id, dag-id, and ocp. That said, nodes need to deal with such configuration errors. > > The question was "how do you detect this configuration error?" I > presented the simple way in which a node can detect it: it validates > the configuration of another node before adding it to its neighbor set. > By definition, there is another node in the neighbor set. The node > detecting the configuration mismatch can use this "correct" node (it > might be the one with the error) to route some kind of configuration > error report as part of a management layer. [RM:] Below is the problem repeated from first mail along with the issue with your solution: Consider a setup with 2 LBRs or DAG roots configured with same instance-id and dag-id but different ocp-type. LBR1---------Node-------------LBR2 Say LBR1 is configured with OCP0 and LBR2 with OCP1 and Node is configured to join OCP0. LBR1 starts up first, Node hears DIO from LBR1 and joins OCP0 dag. LBR2 sends DIO with configuration option, Node fails to match OCP and rejects DIO. All fine. LBR2 sends DIO with only Base option, Node would select LBR2 as alternate parent assuming rank and version number are same as LBR1's. A node now has a OCP0 preferred parent and a OCP1 alternate parent. Based on network situation, Node could be flapping between a OCP0 dag and a OCP1 dag. Your solution: Send a unicast DIS and get config option. Issue with that - LBR2 sends DIO with only base option Node sends unicast DIS LBR2 sends DIO with config option, Node fails to match OCP and rejects DIO LBR2 sends DIO with only base option Node sends unicast DIS LBR2 sends DIO with config option, Node fails to match OCP and rejects DIO This process could keep repeating, which is fine. But since RPL network would have constraint nodes, if the node in this example happens to be a battery powered node, its battery would drain. Is this process worth when the simpler solution is to put ocp in DIO base object? Cheers, Rajesh > > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Mon Nov 29 22:46:28 2010 Return-Path: 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 7FDDE3A6C58 for ; Mon, 29 Nov 2010 22:46:28 -0800 (PST) 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 BZCPxW0yxFQh for ; Mon, 29 Nov 2010 22:46:27 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id C5EB13A6B39 for ; Mon, 29 Nov 2010 22:46:27 -0800 (PST) Received: from [76.14.65.187] (helo=[192.168.1.133]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PNK02-00063D-HZ; Mon, 29 Nov 2010 22:47:38 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <7B822F730F822147977ED5B684ACE4900BFE9357@xmb-sjc-21b.amer.cisco.com> Date: Mon, 29 Nov 2010 22:47:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com> <31691.1291041283@marajade.sandelman.ca> <7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com> <7B822F730F822147977ED5B684ACE4900BFE92B1@xmb-sjc-21b.amer.cisco.com> <80EFACEA-1CA0-4C18-9E15-1276DCB6EC73@cs.stanford.edu> <7B822F730F822147977ED5B684ACE4900BFE9357@xmb-sjc-21b.amer.cisco.com> To: Rajesh Marchappanavar (rmarchap) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Tue, 30 Nov 2010 06:46:28 -0000 On Nov 29, 2010, at 10:51 AM, Rajesh Marchappanavar (rmarchap) wrote: >>=20 >=20 > [RM:] That is because OCP differentiates dags, it's not just a > 'configuration option'. A node can join 2 dags of different OCP, > instance-id, and dag-id. Which means OCP is a dag characteristic and = not > just one of the configuration option. The fact that two nodes = advertise > same instance-id, dag-id, and different OCP is a mis-configuration. = They > should be advertising different instance-id, dag-id, and ocp. That = said, > nodes need to deal with such configuration errors. This statement is technically incorrect. An OCP does not differentiate = DAGs. An OCP is associated with a DAG. There is a one-to-one mapping = between OCPs and DAGs. The draft is quite clear on this. Different OCPs = on the same DAG is a (serious) configuration error: while it's important = that RPL can detect this, I'd argue it's outside the scope of the = protocol (or any routing protocol) to proactively deal with such = problems. The resulting complexity of dealing with all of the possible = configuration errors is just too great. Phil= From pthubert@cisco.com Tue Nov 30 06:42:45 2010 Return-Path: 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 5EE3D28C19F for ; Tue, 30 Nov 2010 06:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.309 X-Spam-Level: X-Spam-Status: No, score=-10.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TVi1+Uxfcch6 for ; Tue, 30 Nov 2010 06:42:42 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7413228C187 for ; Tue, 30 Nov 2010 06:42:42 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8DAImc9EyrR7Ht/2dsb2JhbACUR45Lcagvm2GFRwSNd4gG X-IronPort-AV: E=Sophos;i="4.59,280,1288569600"; d="scan'208";a="628230320" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 30 Nov 2010 14:43:54 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAUEhZCr011873; Tue, 30 Nov 2010 14:43:53 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Nov 2010 15:43:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Nov 2010 15:43:34 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D034C8951@XMB-AMS-107.cisco.com> In-Reply-To: <7B822F730F822147977ED5B684ACE4900BFE938E@xmb-sjc-21b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Make OCP part of DIO base object or makeDODAGconfiguration mandatory for all DIOs Thread-Index: AcuP+HrkQm6hlP6fSg2eo38xd6KyYQAACEAQACiwc2A= References: <7B822F730F822147977ED5B684ACE4900BFE8F2C@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE8F2F@xmb-sjc-21b.amer.cisco.com><9D713E84-DA43-49CE-BFC6-4A56502D92E2@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE8F37@xmb-sjc-21b.amer.cisco.com><31691.1291041283@marajade.sandelman.ca><7B822F730F822147977ED5B684ACE4900BFE91E9@xmb-sjc-21b.amer.cisco.com><7B822F730F822147977ED5B684ACE4900BFE92B1@xmb-sjc-21b.amer.cisco.com><80EFACEA-1CA0-4C18-9E15-1276DCB6EC73@cs.stanford.edu><7B822F730F822147977ED5B684ACE4900BFE9357@xmb-sjc-21b.amer.cisco.com><1C508DE6-CE08-4A7E-B95C-4CF58C136BF1@cs.stanford.edu> <7B822F730F822147977ED5B684ACE4900BFE938E@xmb-sjc-21b.amer.cisco.com> From: "Pascal Thubert (pthubert)" To: "Rajesh Marchappanavar (rmarchap)" , "Philip Levis" X-OriginalArrivalTime: 30 Nov 2010 14:43:38.0199 (UTC) FILETIME=[F94BE670:01CB909C] Cc: roll@ietf.org Subject: Re: [Roll] Make OCP part of DIO base object or makeDODAGconfiguration mandatory for all DIOs 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: , X-List-Received-Date: Tue, 30 Nov 2010 14:42:45 -0000 Hi Rajesh > [RM:] Yes that is accurate with the solution you provided. Without that > solution, the problem is a node would have a preferred parent of one OCP > and a alternate parent of another OCP, basically a node joins 2 dags (with > configuration error) for same instance. For this specific sentence above, no a node cannot join 2 DODAGs for the same instance, even when there is the OCP misconfig that you are talking about I think everything was said about the misconfiguration. There can be only one OCP in an instance, and yes, global instances require a minimum administration so that all roots are configured the same. Bandwidth is often scarce on LLNs so we have to avoid repeating a number of things in all messages. Thus we made the instance ID an index to everything that comes configured with the DAG, including the OCP.=20 Like Phil said, is a node does not have that info, it can always DIS it. In case of misconfig, nodes will probably join the wrong DODAG. There can be many sorts of misconfigs, including what's in the OCP. How could the node decide? Rich nodes can always be equipped with some checks to validate consistency and raise alerts. Other nodes will simply have to live with it, and though the operation will not be as expected, DODAGs will still form. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Rajesh Marchappanavar (rmarchap) > Sent: Monday, November 29, 2010 8:12 PM > To: Philip Levis > Cc: roll@ietf.org > Subject: Re: [Roll] Make OCP part of DIO base object or > makeDODAGconfiguration mandatory for all DIOs >=20 >=20 >=20 > > -----Original Message----- > > From: Philip Levis [mailto:pal@cs.stanford.edu] > > Sent: Tuesday, November 30, 2010 12:36 AM > > To: Rajesh Marchappanavar (rmarchap) > > Cc: Michael Richardson; roll@ietf.org > > Subject: Re: [Roll] Make OCP part of DIO base object or make > > DODAGconfiguration mandatory for all DIOs > > > > > > On Nov 29, 2010, at 10:51 AM, Rajesh Marchappanavar (rmarchap) wrote: > > > > > > > > > > >> -----Original Message----- > > >> From: Philip Levis [mailto:pal@cs.stanford.edu] > > >> Sent: Monday, November 29, 2010 11:51 PM > > >> To: Rajesh Marchappanavar (rmarchap) > > >> Cc: Michael Richardson; roll@ietf.org > > >> Subject: Re: [Roll] Make OCP part of DIO base object or make > > >> DODAGconfiguration mandatory for all DIOs > > >> > > >> > > >> On Nov 29, 2010, at 9:55 AM, Rajesh Marchappanavar (rmarchap) > wrote: > > >> > > >>>> > > >>> [RM:] Yes that was considered but the issue with that is, every > > time > > >> a > > >>> node receives a DIO without config option it would send out DIS, > > get > > >> a > > >>> DIO with config option and drop it because the OCP does not match. > > >> The > > >>> process would repeat every time root sends a DIO without config > > >> option. > > >>> Battery powered nodes would drain out. Instead, IMO ocp can be > > added > > >> to > > >>> DIO base object. > > >> > > >> I don't think I understand the exact problem you're describing. You > > > > > > [RM:] Please read my first email, I will rewrite it below in this > > email. > > > > > >> seem to have an idea for a feature or protocol change, then are > > > arguing > > >> for it from many directions, any one of which can be solved through > > >> other means. > > > > > > [RM:] No there aren't many directions, just one. The solution you > > > described was tried out and I just presented the issues with that > > > solution, not another direction for the problem. If you can provide > a > > > solution I will be the happiest person to use it instead of a > > protocol > > > change. Protocol change is the only solution I could think of and I > > am > > > not saying that is the only solution, I would listen to alternates > > > happily. > > > > > >> > > >> If two nodes are advertising the same DODAGID, RPLInstance, and > > >> InstanceID, yet have different OCPs, that is a configuration error > > or > > > > > > [RM:] Yes I have repeated that in every email I have sent out. This > > is a > > > configuration error. Nodes needs to deal with it. If we can say in > > the > > > draft that such configuration errors could occur and exist in the > > > lifetime of a dag and will not be dealt with by the protocol, I am > > fine > > > with that too. But that statement has to be made in the draft. > > > > > >> bug (e.g., an implementation might have a memory bug that overwrote > > > one > > >> of the above fields to create the conflict). It is actually a > > >> configuration error if *any* of the configuration option values are > > >> different, even across InstanceIDs. But we seem to be fixating on > > the > > >> OCP. > > > > > > [RM:] That is because OCP differentiates dags, it's not just a > > > 'configuration option'. A node can join 2 dags of different OCP, > > > instance-id, and dag-id. Which means OCP is a dag characteristic and > > not > > > just one of the configuration option. The fact that two nodes > > advertise > > > same instance-id, dag-id, and different OCP is a mis-configuration. > > They > > > should be advertising different instance-id, dag-id, and ocp. That > > said, > > > nodes need to deal with such configuration errors. > > > > > >> > > >> The question was "how do you detect this configuration error?" I > > >> presented the simple way in which a node can detect it: it > validates > > >> the configuration of another node before adding it to its neighbor > > > set. > > >> By definition, there is another node in the neighbor set. The node > > >> detecting the configuration mismatch can use this "correct" node > (it > > >> might be the one with the error) to route some kind of > configuration > > >> error report as part of a management layer. > > > > > > [RM:] Below is the problem repeated from first mail along with the > > issue > > > with your solution: > > > > > > Consider a setup with 2 LBRs or DAG roots configured with same > > > instance-id and dag-id but different ocp-type. > > > > > > LBR1---------Node-------------LBR2 > > > > > > Say LBR1 is configured with OCP0 and LBR2 with OCP1 and Node is > > > configured to join OCP0. > > > LBR1 starts up first, Node hears DIO from LBR1 and joins OCP0 dag. > > > LBR2 sends DIO with configuration option, Node fails to match OCP > and > > > rejects DIO. All fine. > > > LBR2 sends DIO with only Base option, Node would select LBR2 as > > > alternate parent assuming rank and version number are same as > LBR1's. > > > A node now has a OCP0 preferred parent and a OCP1 alternate parent. > > > Based on network situation, Node could be flapping between a > > > OCP0 dag and a OCP1 dag. > > > > > > Your solution: Send a unicast DIS and get config option. Issue with > > that > > > - > > > LBR2 sends DIO with only base option Node sends unicast DIS > > > LBR2 sends DIO with config option, Node fails to match OCP and > > rejects > > > DIO > > > LBR2 sends DIO with only base option Node sends unicast DIS > > > LBR2 sends DIO with config option, Node fails to match OCP and > > rejects > > > DIO > > > > > > This process could keep repeating, which is fine. But since RPL > > network > > > would have constraint nodes, if the node in this example happens to > > be a > > > battery powered node, its battery would drain. Is this process worth > > > when the simpler solution is to put ocp in DIO base object? > > > > Is this an accurate summary: the problem is that a misconfiguration > can > > lead to energy-inefficient behavior? >=20 > [RM:] Yes that is accurate with the solution you provided. Without that > solution, the problem is a node would have a preferred parent of one OCP > and a alternate parent of another OCP, basically a node joins 2 dags (with > configuration error) for same instance. >=20 > Cheers, > Rajesh >=20 > > > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Tue Nov 30 11:08:44 2010 Return-Path: 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 1C79928C13C for ; Tue, 30 Nov 2010 11:08:44 -0800 (PST) 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=[AWL=0.000, 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 lnzekIhuqRNX for ; Tue, 30 Nov 2010 11:08:43 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 4552528C130 for ; Tue, 30 Nov 2010 11:08:43 -0800 (PST) Received: from dn0a210036.sunet ([10.33.0.54]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PNVaM-0007o4-QD; Tue, 30 Nov 2010 11:09:55 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 30 Nov 2010 11:09:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <88B51503-1B15-4F5A-8139-2BBA6B81A4AD@cs.stanford.edu> References: <20101122163512.4979.96571.idtracker@localhost> <002001cb8af7$7e254cc0$7a6fe640$@com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1082) X-Scan-Signature: f69c4e6b4bf914f22ae37cd490358bf0 Cc: roll@ietf.org Subject: Re: [Roll] Last Call: (The Trickle Algorithm) to Proposed Standard 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: , X-List-Received-Date: Tue, 30 Nov 2010 19:08:44 -0000 On Nov 23, 2010, at 2:27 AM, Ulrich Herberg wrote: > Colin, >=20 > On Tue, Nov 23, 2010 at 11:16 AM, Colin O'Flynn = wrote: >>> - introduction: "current implementations use 4-11 bytes...". I = wonder >>> whether that is wise to put into the draft, since it once it will be >>> published, "current" implementations may need more or less (at that >>> future time) >>=20 >> I think it is reasonable to keep such a statement. It could be = simplified to >> just explain what those bytes are, but I think the point is if you = pick up >> the draft you know right away what sort of resource requirements the = draft >> carries. >>=20 >> So something saying "Trickle requires at minimum three variables". = The size >> of the variables would depend on your network & processor = architecture. Such >> a statement would remain valid even when we move to 128-bit = processors & a >> single variable is typically 16 bytes ;-) >=20 > Yes, I can agree to that. Hm -- let me explain the reasoning for why the text says "4-11 bytes" = rather than "x variables." Basically, bytes is more precise. Even if an = architecture has 16-byte words (I guess by "typical variable" you mean = "C int type"), there are still one-byte and two-byte variables. If you = care about data size, you can use these smaller types, and that's what = leads to having 4-11 bytes. Saying "three variables" could mean "3 large arrays" or "3 bytes." It = doesn't provide a lot of insight. I could implement Trickle with a = single long long, where I pack things like c, t, and the current = interval size into those 8 bytes. "Variables" isn't really a statement = of the resource requirements, while the number of bytes can be.=20 Does that make sense? Phil=