From adrian@olddog.co.uk Mon Sep 2 03:32:37 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8210411E82F0 for ; Mon, 2 Sep 2013 03:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK6ovhIDzzap for ; Mon, 2 Sep 2013 03:32:32 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 111F811E81D5 for ; Mon, 2 Sep 2013 03:31:38 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r82AVbhw001221 for ; Mon, 2 Sep 2013 11:31:37 +0100 Received: from 950129200 ([203.118.14.76]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r82AVXG2001174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 2 Sep 2013 11:31:36 +0100 From: "Adrian Farrel" To: "'Routing Over Low power and Lossy networks'" References: <23397.1377885103@sandelman.ca> In-Reply-To: <23397.1377885103@sandelman.ca> Date: Mon, 2 Sep 2013 11:31:34 +0100 Message-ID: <0b7a01cea7c7$9b1b2120$d1516360$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF/uVVVEt7Kf+yx5uXlk7YHQAo+fgF/t/WkmkQdv5A= Content-Language: en-gb Subject: Re: [Roll] RPL MIB X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 10:32:37 -0000 Hi, In this context it might make a lot of sense for some work to be done on a "management framework for RPL devices". What needs to be configurable? What protocol needs to be visible? What information is needed for diagnostics? What alarms/alerts are needed? What are the implications of storing logs? What are the implications of sending unsolicited notifications and/or of responding to status queries? What protocols are appropriate? This would lead to an Information model, which might in time lead to a data model. It is definitely also worth coordinating with CORE to see what they think about higher layer protocols to constrained devices. Cheers, Adrian > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Michael > Richardson > Sent: 30 August 2013 18:52 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] RPL MIB > > > Turner, Randy wrote: > > On the IETF ROLL WG page, I was looking for a current (not expired) > > version of the RPL MIB draft, but there doesn?t appear to be one. > > It likely expired. > > http://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib/ > > > Can someone let me know what the status of this work is ? > > The WG has discussed this question a few times and has not reached any > consensus. > > Here is the summary: > > 1) many feel that an **SNMP** Agent is not going to fit into constrained devices. > 2) Jurgen has demonstrated it does fit into a class 2 device on using > Contiki. > 3) others have pointed out that SNMP is not the only way to deal with a MIB, > and the important things in a MIB is the set of statistics which one might > collect, and transmit in *some* way. > 4) opinions have ranged from HTTP / CoAP to NetCONF/YANG as other transport > alternatives to SNMP. > > I think that it is simply early for many people to talk about having > consistent sets of statistics... BUT. PLEASE FEEL FREE TO PROVE ME WRONG. > > In particular, I think that *some* standard way to get the network adjacency > matrix (as well as the DODAG) out of motes would be very useful for network > operators. > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From jvasseur@cisco.com Mon Sep 2 23:20:16 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6827321E8089 for ; Mon, 2 Sep 2013 23:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaXpOTnFVIld for ; Mon, 2 Sep 2013 23:20:11 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBA511E8188 for ; Mon, 2 Sep 2013 23:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3207; q=dns/txt; s=iport; t=1378189211; x=1379398811; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LxSUJWfrzcXJlqgTQtc73OL0bFbMg9quqktA+geEuFA=; b=W2W50Jok25jE6hBOyXpu0GOBH5AK4kpBQtwGKHoO5zqNWuVnZBNUboj+ OSrPFdOeVpfYobTyv7qSFc8eS1hktf1SvmPbDNQVZ1SN04xpJXrme+Ayr P9VBlEXWGifsT+eu6Ole3YuL2QO8eU9qhqJjEF29yf/UeWbBDeylHDayh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAHp+JVKtJXG9/2dsb2JhbABagwc1UcB8gS4WdIIkAQEBAwEBAQE3NBAHBAIBCBEEAQEBChQJBycLFAkIAgQTCId0Bgy5KI4+gQUCBjICBIMXgQADmSSQN4Mggio X-IronPort-AV: E=Sophos;i="4.89,1012,1367971200"; d="scan'208";a="251805515" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 03 Sep 2013 06:20:11 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r836KA74023418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Sep 2013 06:20:10 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.92]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 01:20:10 -0500 From: "JP Vasseur (jvasseur)" To: "" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] RPL MIB Thread-Index: AQHOqG2joek26JQpbUCKooxjozXY/A== Date: Tue, 3 Sep 2013 06:20:09 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77237657C9@xmb-rcd-x02.cisco.com> References: <23397.1377885103@sandelman.ca> <0b7a01cea7c7$9b1b2120$d1516360$@olddog.co.uk> In-Reply-To: <0b7a01cea7c7$9b1b2120$d1516360$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.3] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] RPL MIB X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 06:20:16 -0000 Hi, I cannot agree, adding some thoughts: of course, we would need to think ver= y careful on where such a management MIB would be run and the framework should cover some of t= he required=20 workflow. Indeed, running a RPL MIB on a router would make total sense, but= may be simply=20 not possible on a low-end node (due to memory but also bandwidth constraint= ), and this is where we would need to sync up with CORE. Cheers. JP. On Sep 2, 2013, at 12:31 PM, Adrian Farrel wrote: > Hi, >=20 > In this context it might make a lot of sense for some work to be done on = a > "management framework for RPL devices". >=20 > What needs to be configurable? What protocol needs to be visible? What > information is needed for diagnostics? What alarms/alerts are needed? Wha= t are > the implications of storing logs? What are the implications of sending > unsolicited notifications and/or of responding to status queries? What pr= otocols > are appropriate? >=20 > This would lead to an Information model, which might in time lead to a da= ta > model. >=20 > It is definitely also worth coordinating with CORE to see what they think= about > higher layer protocols to constrained devices. >=20 > Cheers, > Adrian >=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Michael >> Richardson >> Sent: 30 August 2013 18:52 >> To: Routing Over Low power and Lossy networks >> Subject: Re: [Roll] RPL MIB >>=20 >>=20 >> Turner, Randy wrote: >>> On the IETF ROLL WG page, I was looking for a current (not expired) >>> version of the RPL MIB draft, but there doesn?t appear to be one. >>=20 >> It likely expired. >>=20 >> http://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib/ >>=20 >>> Can someone let me know what the status of this work is ? >>=20 >> The WG has discussed this question a few times and has not reached any >> consensus. >>=20 >> Here is the summary: >>=20 >> 1) many feel that an **SNMP** Agent is not going to fit into constrained > devices. >> 2) Jurgen has demonstrated it does fit into a class 2 device on using >> Contiki. >> 3) others have pointed out that SNMP is not the only way to deal with a = MIB, >> and the important things in a MIB is the set of statistics which one m= ight >> collect, and transmit in *some* way. >> 4) opinions have ranged from HTTP / CoAP to NetCONF/YANG as other transp= ort >> alternatives to SNMP. >>=20 >> I think that it is simply early for many people to talk about having >> consistent sets of statistics... BUT. PLEASE FEEL FREE TO PROVE ME WRONG= . >>=20 >> In particular, I think that *some* standard way to get the network adjac= ency >> matrix (as well as the DODAG) out of motes would be very useful for netw= ork >> operators. >>=20 >> -- >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Sep 3 00:44:53 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B3711E81AF for ; Tue, 3 Sep 2013 00:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGORgu8ODdg4 for ; Tue, 3 Sep 2013 00:44:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E6D5711E81A6 for ; Tue, 3 Sep 2013 00:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3573; q=dns/txt; s=iport; t=1378194287; x=1379403887; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=itO2AhuKDBmvuIA4LHny3CWl6Z6Ho4sPYuVYUy0W9DA=; b=M52O9ECryH5kONmreKWH3XcJSWwZAd8GJVQAdhaM1Z/X4kxsHL7wC77q IZiewHQboqiu+KdX+IXBq7NqY1bDvZbe/6VtVUcu3aNY8bP72WyoEB2ZR nk/bbJDSsh6TzzH4eS5WTGACgavLvZb8Pmi8GZFI+ApY2/38nVxwUOgyO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAOaRJVKtJXG//2dsb2JhbABagwc1UcB2gSsWdIIkAQEBAwEBAQE3NBAHBAIBCBEEAQEBChQJBycLFAkIAgQTCId0Bgy5JI4+gQUCBjICBIMXgQADmSSQN4Mggio X-IronPort-AV: E=Sophos;i="4.89,1012,1367971200"; d="scan'208";a="254852234" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 03 Sep 2013 07:44:44 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r837ihGY012271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Sep 2013 07:44:43 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.92]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 02:44:43 -0500 From: "JP Vasseur (jvasseur)" To: Adrian Farrel , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] RPL MIB Thread-Index: AQHOqG2joek26JQpbUCKooxjozXY/Jmz9d0A Date: Tue, 3 Sep 2013 07:44:42 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77237682C3@xmb-rcd-x02.cisco.com> References: <23397.1377885103@sandelman.ca> <0b7a01cea7c7$9b1b2120$d1516360$@olddog.co.uk> <03B78081B371D44390ED6E7BADBB4A77237657C9@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77237657C9@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.3] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] RPL MIB X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 07:44:54 -0000 Typo "I cannot agree MORE" ;-) On Sep 3, 2013, at 8:20 AM, JP Vasseur (jvasseur) wrot= e: > Hi, >=20 > I cannot agree, adding some thoughts: of course, we would need to think v= ery careful on where > such a management MIB would be run and the framework should cover some of= the required=20 > workflow. Indeed, running a RPL MIB on a router would make total sense, b= ut may be simply=20 > not possible on a low-end node (due to memory but also bandwidth constrai= nt), and this is where > we would need to sync up with CORE. >=20 > Cheers. >=20 > JP. >=20 > On Sep 2, 2013, at 12:31 PM, Adrian Farrel wrote: >=20 >> Hi, >>=20 >> In this context it might make a lot of sense for some work to be done on= a >> "management framework for RPL devices". >>=20 >> What needs to be configurable? What protocol needs to be visible? What >> information is needed for diagnostics? What alarms/alerts are needed? Wh= at are >> the implications of storing logs? What are the implications of sending >> unsolicited notifications and/or of responding to status queries? What p= rotocols >> are appropriate? >>=20 >> This would lead to an Information model, which might in time lead to a d= ata >> model. >>=20 >> It is definitely also worth coordinating with CORE to see what they thin= k about >> higher layer protocols to constrained devices. >>=20 >> Cheers, >> Adrian >>=20 >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >> Michael >>> Richardson >>> Sent: 30 August 2013 18:52 >>> To: Routing Over Low power and Lossy networks >>> Subject: Re: [Roll] RPL MIB >>>=20 >>>=20 >>> Turner, Randy wrote: >>>> On the IETF ROLL WG page, I was looking for a current (not expired) >>>> version of the RPL MIB draft, but there doesn?t appear to be one. >>>=20 >>> It likely expired. >>>=20 >>> http://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib/ >>>=20 >>>> Can someone let me know what the status of this work is ? >>>=20 >>> The WG has discussed this question a few times and has not reached any >>> consensus. >>>=20 >>> Here is the summary: >>>=20 >>> 1) many feel that an **SNMP** Agent is not going to fit into constraine= d >> devices. >>> 2) Jurgen has demonstrated it does fit into a class 2 device on using >>> Contiki. >>> 3) others have pointed out that SNMP is not the only way to deal with a= MIB, >>> and the important things in a MIB is the set of statistics which one m= ight >>> collect, and transmit in *some* way. >>> 4) opinions have ranged from HTTP / CoAP to NetCONF/YANG as other trans= port >>> alternatives to SNMP. >>>=20 >>> I think that it is simply early for many people to talk about having >>> consistent sets of statistics... BUT. PLEASE FEEL FREE TO PROVE ME WRON= G. >>>=20 >>> In particular, I think that *some* standard way to get the network adja= cency >>> matrix (as well as the DODAG) out of motes would be very useful for net= work >>> operators. >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Randy.Turner@landisgyr.com Tue Sep 3 06:34:24 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FB611E81DD for ; Tue, 3 Sep 2013 06:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIrUG8xuZz1y for ; Tue, 3 Sep 2013 06:34:20 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0076.outbound.protection.outlook.com [213.199.154.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7981911E81D3 for ; Tue, 3 Sep 2013 06:34:19 -0700 (PDT) Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com (10.255.176.37) by DBXPR01MB014.eurprd01.prod.exchangelabs.com (10.255.176.36) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 13:34:17 +0000 Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.179]) by DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.179]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 13:34:17 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] RPL MIB Thread-Index: Ac6logq3/vh0oGNlTpWt+jWe8hDnVgAB4uWAAIeAkAAAKYLDgAAC8/AAAAwTpDA= Date: Tue, 3 Sep 2013 13:34:16 +0000 Message-ID: <866c54ef240c43f296e2f066b85134bf@DBXPR01MB015.eurprd01.prod.exchangelabs.com> References: <23397.1377885103@sandelman.ca> <0b7a01cea7c7$9b1b2120$d1516360$@olddog.co.uk> <03B78081B371D44390ED6E7BADBB4A77237657C9@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77237682C3@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77237682C3@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [148.80.255.144] x-forefront-prvs: 09583628E0 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(51704005)(24454002)(13464003)(52044002)(51444003)(377454003)(81542001)(50986001)(15975445006)(47976001)(81816001)(74316001)(74366001)(74502001)(47446002)(76796001)(49866001)(4396001)(15202345003)(47736001)(77096001)(79102001)(83072001)(33646001)(74706001)(51856001)(46102001)(74876001)(19580405001)(66066001)(19580395003)(69226001)(80022001)(65816001)(81342001)(83322001)(80976001)(81686001)(31966008)(74662001)(53806001)(63696002)(76786001)(56816003)(59766001)(77982001)(54356001)(76482001)(56776001)(54316002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR01MB014; H:DBXPR01MB015.eurprd01.prod.exchangelabs.com; CLIP:148.80.255.144; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Subject: Re: [Roll] RPL MIB X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 13:34:24 -0000 There is an expired draft for an RPL MIB that I think is a good start...th= at doesn't seem to violate the spirit of what is being proposed below. So it doesn't appear that this would be a "from scratch" effort. The data model suggested by the expired draft offers some good ideas, much = of it I think is quite usable and valuable. There remains a "non-data-related" aspect of management in an LLN, which mi= ght suggest that there are some endpoint devices that are too constrained t= o support something like an SNMP agent. While that maybe true, I believe = the more constrained a device is in functionality and capability, the less = likely I may want to actively (pro-actively) manage such an endpoint. Randy -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur (jvasseur) Sent: Tuesday, September 03, 2013 3:45 AM To: Adrian Farrel; Routing Over Low power and Lossy networks Subject: Re: [Roll] RPL MIB Typo "I cannot agree MORE" ;-) On Sep 3, 2013, at 8:20 AM, JP Vasseur (jvasseur) wrot= e: > Hi, > > I cannot agree, adding some thoughts: of course, we would need to > think very careful on where such a management MIB would be run and the > framework should cover some of the required workflow. Indeed, running > a RPL MIB on a router would make total sense, but may be simply not > possible on a low-end node (due to memory but also bandwidth constraint),= and this is where we would need to sync up with CORE. > > Cheers. > > JP. > > On Sep 2, 2013, at 12:31 PM, Adrian Farrel wrote: > >> Hi, >> >> In this context it might make a lot of sense for some work to be done >> on a "management framework for RPL devices". >> >> What needs to be configurable? What protocol needs to be visible? >> What information is needed for diagnostics? What alarms/alerts are >> needed? What are the implications of storing logs? What are the >> implications of sending unsolicited notifications and/or of >> responding to status queries? What protocols are appropriate? >> >> This would lead to an Information model, which might in time lead to >> a data model. >> >> It is definitely also worth coordinating with CORE to see what they >> think about higher layer protocols to constrained devices. >> >> Cheers, >> Adrian >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>> Of >> Michael >>> Richardson >>> Sent: 30 August 2013 18:52 >>> To: Routing Over Low power and Lossy networks >>> Subject: Re: [Roll] RPL MIB >>> >>> >>> Turner, Randy wrote: >>>> On the IETF ROLL WG page, I was looking for a current (not expired) >>>> version of the RPL MIB draft, but there doesn?t appear to be one. >>> >>> It likely expired. >>> >>> http://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib/ >>> >>>> Can someone let me know what the status of this work is ? >>> >>> The WG has discussed this question a few times and has not reached >>> any consensus. >>> >>> Here is the summary: >>> >>> 1) many feel that an **SNMP** Agent is not going to fit into >>> constrained >> devices. >>> 2) Jurgen has demonstrated it does fit into a class 2 device on >>> using Contiki. >>> 3) others have pointed out that SNMP is not the only way to deal >>> with a MIB, and the important things in a MIB is the set of >>> statistics which one might collect, and transmit in *some* way. >>> 4) opinions have ranged from HTTP / CoAP to NetCONF/YANG as other >>> transport alternatives to SNMP. >>> >>> I think that it is simply early for many people to talk about having >>> consistent sets of statistics... BUT. PLEASE FEEL FREE TO PROVE ME WRON= G. >>> >>> In particular, I think that *some* standard way to get the network >>> adjacency matrix (as well as the DODAG) out of motes would be very >>> useful for network operators. >>> >>> -- >>> Michael Richardson , Sandelman Software Works >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. From j.schoenwaelder@jacobs-university.de Tue Sep 3 06:46:12 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1155611E81E9 for ; Tue, 3 Sep 2013 06:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGBEYnBIB2NM for ; Tue, 3 Sep 2013 06:46:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8DB11E81EB for ; Tue, 3 Sep 2013 06:45:59 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C04A20C5A; Tue, 3 Sep 2013 15:45:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id j-FPWwJS16Z1; Tue, 3 Sep 2013 15:45:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80DAF2062F; Tue, 3 Sep 2013 15:45:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4C28728322CE; Tue, 3 Sep 2013 15:45:51 +0200 (CEST) Date: Tue, 3 Sep 2013 15:45:51 +0200 From: Juergen Schoenwaelder To: Routing Over Low power and Lossy networks Message-ID: <20130903134551.GD48413@elstar.local> Mail-Followup-To: Routing Over Low power and Lossy networks References: <23397.1377885103@sandelman.ca> <0b7a01cea7c7$9b1b2120$d1516360$@olddog.co.uk> <03B78081B371D44390ED6E7BADBB4A77237657C9@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77237682C3@xmb-rcd-x02.cisco.com> <866c54ef240c43f296e2f066b85134bf@DBXPR01MB015.eurprd01.prod.exchangelabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <866c54ef240c43f296e2f066b85134bf@DBXPR01MB015.eurprd01.prod.exchangelabs.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Roll] RPL MIB X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder , Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 13:46:12 -0000 Hi, the key is to find agreement which counters etc. are relevant to instrument in the RPL code. Whether one provides access to these counters via SNMP or some other means may depends on the specific constraints of the device and the deployment target. A MIB module is a way to define what needs to be instrumented and, as a side effect, it of course works well with SNMP as an access mechanism. But this does not exclude other access mechanism from being used instead. /js On Tue, Sep 03, 2013 at 01:34:16PM +0000, Turner, Randy wrote: > > There is an expired draft for an RPL MIB that I think is a good start...that doesn't seem to violate the spirit of what is being proposed below. > > So it doesn't appear that this would be a "from scratch" effort. > > The data model suggested by the expired draft offers some good ideas, much of it I think is quite usable and valuable. > > There remains a "non-data-related" aspect of management in an LLN, which might suggest that there are some endpoint devices that are too constrained to support something like an SNMP agent. While that maybe true, I believe the more constrained a device is in functionality and capability, the less likely I may want to actively (pro-actively) manage such an endpoint. > > Randy > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) > Sent: Tuesday, September 03, 2013 3:45 AM > To: Adrian Farrel; Routing Over Low power and Lossy networks > Subject: Re: [Roll] RPL MIB > > Typo "I cannot agree MORE" ;-) > > On Sep 3, 2013, at 8:20 AM, JP Vasseur (jvasseur) wrote: > > > Hi, > > > > I cannot agree, adding some thoughts: of course, we would need to > > think very careful on where such a management MIB would be run and the > > framework should cover some of the required workflow. Indeed, running > > a RPL MIB on a router would make total sense, but may be simply not > > possible on a low-end node (due to memory but also bandwidth constraint), and this is where we would need to sync up with CORE. > > > > Cheers. > > > > JP. > > > > On Sep 2, 2013, at 12:31 PM, Adrian Farrel wrote: > > > >> Hi, > >> > >> In this context it might make a lot of sense for some work to be done > >> on a "management framework for RPL devices". > >> > >> What needs to be configurable? What protocol needs to be visible? > >> What information is needed for diagnostics? What alarms/alerts are > >> needed? What are the implications of storing logs? What are the > >> implications of sending unsolicited notifications and/or of > >> responding to status queries? What protocols are appropriate? > >> > >> This would lead to an Information model, which might in time lead to > >> a data model. > >> > >> It is definitely also worth coordinating with CORE to see what they > >> think about higher layer protocols to constrained devices. > >> > >> Cheers, > >> Adrian > >> > >>> -----Original Message----- > >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > >>> Of > >> Michael > >>> Richardson > >>> Sent: 30 August 2013 18:52 > >>> To: Routing Over Low power and Lossy networks > >>> Subject: Re: [Roll] RPL MIB > >>> > >>> > >>> Turner, Randy wrote: > >>>> On the IETF ROLL WG page, I was looking for a current (not expired) > >>>> version of the RPL MIB draft, but there doesn?t appear to be one. > >>> > >>> It likely expired. > >>> > >>> http://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib/ > >>> > >>>> Can someone let me know what the status of this work is ? > >>> > >>> The WG has discussed this question a few times and has not reached > >>> any consensus. > >>> > >>> Here is the summary: > >>> > >>> 1) many feel that an **SNMP** Agent is not going to fit into > >>> constrained > >> devices. > >>> 2) Jurgen has demonstrated it does fit into a class 2 device on > >>> using Contiki. > >>> 3) others have pointed out that SNMP is not the only way to deal > >>> with a MIB, and the important things in a MIB is the set of > >>> statistics which one might collect, and transmit in *some* way. > >>> 4) opinions have ranged from HTTP / CoAP to NetCONF/YANG as other > >>> transport alternatives to SNMP. > >>> > >>> I think that it is simply early for many people to talk about having > >>> consistent sets of statistics... BUT. PLEASE FEEL FREE TO PROVE ME WRONG. > >>> > >>> In particular, I think that *some* standard way to get the network > >>> adjacency matrix (as well as the DODAG) out of motes would be very > >>> useful for network operators. > >>> > >>> -- > >>> Michael Richardson , Sandelman Software Works > >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > >> > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mounir.kellil@cea.fr Tue Sep 3 07:10:32 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C44321E812C for ; Tue, 3 Sep 2013 07:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prt+AbP20+gw for ; Tue, 3 Sep 2013 07:10:25 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 18AB021E80B6 for ; Tue, 3 Sep 2013 07:10:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r83EAKGB000757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Sep 2013 16:10:20 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r83EAKNm004056; Tue, 3 Sep 2013 16:10:20 +0200 (envelope-from mounir.kellil@cea.fr) Received: from EXCAH-B2.intra.cea.fr (excah-b2.intra.cea.fr [132.166.88.87]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r83EAKwc019200; Tue, 3 Sep 2013 16:10:20 +0200 Received: from EXDAG0-B2.intra.cea.fr ([fe80::d079:8496:6c6c:9b1f]) by EXCAH-B2.intra.cea.fr ([fe80::6d9a:7f48:7b8f:6abc%11]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 16:10:19 +0200 From: KELLIL Mounir To: "roll@ietf.org" , "johui@cisco.com" Thread-Topic: [Roll] [roll] #129: draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwarding should be mutually exclusive within the same MPL Domain? Thread-Index: AQHOpRB9U1J2Gyk69EeLptKoHav1q5m0D5qw Date: Tue, 3 Sep 2013 14:10:19 +0000 Message-ID: <7708224CCA85B641A12F88B1F5A47A431B1C0A48@EXDAG0-B2.intra.cea.fr> References: <067.eb8cd06a193daa93167f1567d59337cc@trac.tools.ietf.org> <082.c53b887921203ff02b64d18ef29ca24a@trac.tools.ietf.org> In-Reply-To: <082.c53b887921203ff02b64d18ef29ca24a@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.105] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-20124.007 x-tm-as-result: No--58.156300-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Roll] [roll] #129: draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwarding should be mutually exclusive within the same MPL Domain? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 14:10:32 -0000 RGVhciBKb25hdGhhbiwgYWxsLA0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiByZWdhcmRp bmcgdGhlIHByb2FjdGl2ZSBhbmQgUmVhY3RpdmUgRm9yd2FyZGluZyBwcm9jZWR1cmVzLCB5ZXQg aXQgaXMgc3RpbGwgbm90IGNsZWFyIGZvciBtZSB3aGF0IGhhcHBlbnMgaWYgYSBmb3J3YXJkaW5n IG5vZGUgaW4gYSAncmVhY3RpdmUgZm9yd2FyZGluZyBvbmx5JyBtb2RlIHJlY2VpdmVzIGEgbmV3 IE1QTCBtZXNzYWdlID8gRG9lcyBpdCBmb3J3YXJkIHRoZSBtZXNzYWdlIHN5c3RlbWF0aWNhbGx5 IChpLmUuLCB3aXRob3V0IHJlY2VpdmluZyBhbnkgYXNzb2NpYXRlZCBjb250cm9sIG1lc3NhZ2Up PyBJZiB0aGUgYW5zd2VyIGlzIE5vLCBpbiB0aGlzIGNhc2UgaXQgbWF5IGhhcHBlbiB0aGF0IGZv ciBMTE5zIHdpdGggc3BlY2lmaWMgdG9wb2xvZ2llcyAoZS5nLiwgc3BhcnNlIG5ldHdvcmtzKSBz b21lIG5vZGVzIG1pZ2h0IG5vdCByZWNlaXZlIChhbGwpIHRoZSBNUEwgbWVzc2FnZXMuIE1heWJl IHlvdSBoYXZlIGFscmVhZHkgY29uc2lkZXJlZCB0aGlzIHByb2JsZW0gc29tZWhvdz8NCg0KUmVn YXJkcw0KDQpNb3VuaXINCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiByb2xs LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBh cnQgZGUgcm9sbCBpc3N1ZSB0cmFja2VyDQpFbnZvecOpwqA6IHZlbmRyZWRpIDMwIGFvw7t0IDIw MTMgMDE6MzUNCsOAwqA6IGpvaHVpQGNpc2NvLmNvbTsgcmRyb21zQGNpc2NvLmNvbTsgbWFyaWFp bmVzcm9ibGVzQGdtYWlsLmNvbQ0KQ2PCoDogcm9sbEBpZXRmLm9yZw0KT2JqZXTCoDogUmU6IFtS b2xsXSBbcm9sbF0gIzEyOTogZHJhZnQtaWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3QtMDQgLSBQcm9h Y3RpdmUgYW5kIFJlYWN0aXZlIEZvcndhcmRpbmcgc2hvdWxkIGJlIG11dHVhbGx5IGV4Y2x1c2l2 ZSB3aXRoaW4gdGhlIHNhbWUgTVBMIERvbWFpbj8NCg0KIzEyOTogZHJhZnQtaWV0Zi1yb2xsLXRy aWNrbGUtbWNhc3QtMDQgLSBQcm9hY3RpdmUgYW5kIFJlYWN0aXZlIEZvcndhcmRpbmcgc2hvdWxk IGJlIG11dHVhbGx5IGV4Y2x1c2l2ZSB3aXRoaW4gdGhlIHNhbWUgTVBMIERvbWFpbj8NCg0KDQpD b21tZW50IChieSBtYXJpYWluZXNyb2JsZXNAZ21haWwuY29tKToNCg0KIERhdGU6IFRodSwgMjkg QXVnIDIwMTMgMTQ6MzQ6MzggKzAwMDANCg0KIEZyb206ICJKb25hdGhhbiBIdWkgKGpvaHVpKSIg PGpvaHVpQGNpc2NvLmNvbT4NCg0KIFN1YmplY3Q6IFJlOiBbUm9sbF0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3QtDQoNCiAwNS50eHQNCg0KIOKAnFRoaXMgdXBkYXRl IGF0dGVtcHRzIHRvIGFkZHJlc3MgYWxsIG9mIHRoZSBvcGVuIHRpY2tldHMuICBBIHN1bW1hcnkg b2YgIGNoYW5nZXMgaXMgYmVsb3cuICBQbGVhc2UgcHJvdmlkZSBmZWVkYmFjayBvbiB0aGVzZSBj aGFuZ2VzLiAgVGhhbmtzLg0KDQogLi4uDQoNCiAxMjk6DQogLSBVcGRhdGVkIFNlY3Rpb24gNC4y IHRvIGV4cGxpY2l0bHkgaW5kaWNhdGUgdGhhdCBwcm9hY3RpdmUgYW5kIHJlYWN0aXZlICBhcmUg bm90IG11dHVhbGx5IGV4Y2x1c2l2ZS4gIFByb2FjdGl2ZSBhbmQgcmVhY3RpdmUgdGVjaG5pcXVl cyBtYXkgYmUgdXNlZCAgc2ltdWx0YW5lb3VzbHkgd2l0aGluIGFuIE1QTCBEb21haW4uICBGb3Ig ZXhhbXBsZSwgdXBvbiByZWNlaXZpbmcgYSBuZXcgIE1QTCBEYXRhIG1lc3NhZ2VzIHdoZW4gYm90 aCBwcm9hY3RpdmUgYW5kIHJlYWN0aXZlIGZvcndhcmRpbmcgdGVjaG5pcXVlcyAgYXJlIGVuYWJs ZWQsIGFuIE1QTCBGb3J3YXJkZXIgd2lsbCBwcm9hY3RpdmVseSByZXRyYW5zbWl0IHRoZSBNUEwg RGF0YSAgTWVzc2FnZSBhIGxpbWl0ZWQgbnVtYmVyIG9mIHRpbWVzIGFuZCBzY2hlZHVsZSBmdXJ0 aGVyIHRyYW5zbWlzc2lvbnMgdXBvbiAgcmVjZWl2aW5nIE1QTCBDb250cm9sIE1lc3NhZ2VzLuKA nQ0KDQogVGhyZWFkOiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcm9sbC9j dXJyZW50L21zZzA4MTAzLmh0bWwNCiBUaHJlYWQ6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9yb2xsL2N1cnJlbnQvbXNnMDc5NDcuaHRtbA0KDQotLSANCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCiBSZXBvcnRlcjogIG1hcmlhaW5lc3JvYmxlc0BnbWFpbC5jb20gIHwgICAgICAgT3duZXI6 ICBqb2h1aUBjaXNjby5jb20NCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAgICAgICAgICAg IHwgICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1pbm9yICAgICAgICAgICAgICAgICAg ICAgIHwgICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICB0cmlja2xlLW1jYXN0ICAgICAgICAgICAg ICB8ICAgICBWZXJzaW9uOg0KIFNldmVyaXR5OiAgSW4gV0cgTGFzdCBDYWxsICAgICAgICAgICAg fCAgUmVzb2x1dGlvbjoNCiBLZXl3b3JkczogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHBzOi8vc3ZuLnRvb2xzLmlldGYub3Jn L3dnL3JvbGwvdHJhYy90aWNrZXQvMTI5I2NvbW1lbnQ6Mj4NCnJvbGwgPGh0dHA6Ly90b29scy5p ZXRmLm9yZy93Zy9yb2xsLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From Randy.Turner@landisgyr.com Tue Sep 3 07:13:03 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFA921F9FED for ; Tue, 3 Sep 2013 07:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaeBNsC7hGnD for ; Tue, 3 Sep 2013 07:12:58 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0081.outbound.protection.outlook.com [213.199.154.81]) by ietfa.amsl.com (Postfix) with ESMTP id 00A5521F942D for ; Tue, 3 Sep 2013 07:12:57 -0700 (PDT) Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com (10.255.176.37) by DBXPR01MB014.eurprd01.prod.exchangelabs.com (10.255.176.36) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 14:12:55 +0000 Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.179]) by DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.179]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 14:12:55 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] RPL MIB Thread-Index: Ac6logq3/vh0oGNlTpWt+jWe8hDnVgAB4uWAAIeAkAAAKYLDgAAC8/AAAAwTpDAAAIlLgAAA4Lzw Date: Tue, 3 Sep 2013 14:12:55 +0000 Message-ID: References: <23397.1377885103@sandelman.ca> <0b7a01cea7c7$9b1b2120$d1516360$@olddog.co.uk> <03B78081B371D44390ED6E7BADBB4A77237657C9@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77237682C3@xmb-rcd-x02.cisco.com> <866c54ef240c43f296e2f066b85134bf@DBXPR01MB015.eurprd01.prod.exchangelabs.com> <20130903134551.GD48413@elstar.local> In-Reply-To: <20130903134551.GD48413@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [148.80.255.144] x-forefront-prvs: 09583628E0 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(13464003)(377454003)(51444003)(52044002)(51704005)(189002)(199002)(81686001)(80976001)(59766001)(77982001)(56776001)(76482001)(54316002)(54356001)(53806001)(31966008)(74662001)(56816003)(63696002)(76786001)(76796001)(47446002)(74502001)(79102001)(77096001)(49866001)(15202345003)(47736001)(4396001)(47976001)(50986001)(81542001)(15975445006)(81816001)(74316001)(74366001)(19580395003)(66066001)(69226001)(19580405001)(83322001)(81342001)(80022001)(65816001)(83072001)(74876001)(46102001)(33646001)(51856001)(74706001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR01MB014; H:DBXPR01MB015.eurprd01.prod.exchangelabs.com; CLIP:148.80.255.144; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Subject: Re: [Roll] RPL MIB X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 14:13:03 -0000 Yes, you can separate the usage of the MIB data model within a device from = the SNMP protocol used to transport it -- however, there should be a very g= ood reason for doing this. I think it might be possible to "profile" SNMPv= 3 in such a way as to make it more attractive to constrained devices. Randy -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jue= rgen Schoenwaelder Sent: Tuesday, September 03, 2013 9:46 AM To: Routing Over Low power and Lossy networks Subject: Re: [Roll] RPL MIB Hi, the key is to find agreement which counters etc. are relevant to instrument= in the RPL code. Whether one provides access to these counters via SNMP or= some other means may depends on the specific constraints of the device and= the deployment target. A MIB module is a way to define what needs to be instrumented and, as a sid= e effect, it of course works well with SNMP as an access mechanism. But thi= s does not exclude other access mechanism from being used instead. /js On Tue, Sep 03, 2013 at 01:34:16PM +0000, Turner, Randy wrote: >=20 > There is an expired draft for an RPL MIB that I think is a good start...= that doesn't seem to violate the spirit of what is being proposed below. >=20 > So it doesn't appear that this would be a "from scratch" effort. >=20 > The data model suggested by the expired draft offers some good ideas, muc= h of it I think is quite usable and valuable. >=20 > There remains a "non-data-related" aspect of management in an LLN, which = might suggest that there are some endpoint devices that are too constrained= to support something like an SNMP agent. While that maybe true, I believ= e the more constrained a device is in functionality and capability, the les= s likely I may want to actively (pro-actively) manage such an endpoint. >=20 > Randy >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of JP Vasseur (jvasseur) > Sent: Tuesday, September 03, 2013 3:45 AM > To: Adrian Farrel; Routing Over Low power and Lossy networks > Subject: Re: [Roll] RPL MIB >=20 > Typo "I cannot agree MORE" ;-) >=20 > On Sep 3, 2013, at 8:20 AM, JP Vasseur (jvasseur) wr= ote: >=20 > > Hi, > > > > I cannot agree, adding some thoughts: of course, we would need to=20 > > think very careful on where such a management MIB would be run and=20 > > the framework should cover some of the required workflow. Indeed,=20 > > running a RPL MIB on a router would make total sense, but may be=20 > > simply not possible on a low-end node (due to memory but also bandwidth= constraint), and this is where we would need to sync up with CORE. > > > > Cheers. > > > > JP. > > > > On Sep 2, 2013, at 12:31 PM, Adrian Farrel wrote: > > > >> Hi, > >> > >> In this context it might make a lot of sense for some work to be=20 > >> done on a "management framework for RPL devices". > >> > >> What needs to be configurable? What protocol needs to be visible? > >> What information is needed for diagnostics? What alarms/alerts are=20 > >> needed? What are the implications of storing logs? What are the=20 > >> implications of sending unsolicited notifications and/or of=20 > >> responding to status queries? What protocols are appropriate? > >> > >> This would lead to an Information model, which might in time lead=20 > >> to a data model. > >> > >> It is definitely also worth coordinating with CORE to see what they=20 > >> think about higher layer protocols to constrained devices. > >> > >> Cheers, > >> Adrian > >> > >>> -----Original Message----- > >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > >>> Behalf Of > >> Michael > >>> Richardson > >>> Sent: 30 August 2013 18:52 > >>> To: Routing Over Low power and Lossy networks > >>> Subject: Re: [Roll] RPL MIB > >>> > >>> > >>> Turner, Randy wrote: > >>>> On the IETF ROLL WG page, I was looking for a current (not=20 > >>>> expired) version of the RPL MIB draft, but there doesn?t appear to b= e one. > >>> > >>> It likely expired. > >>> > >>> http://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib/ > >>> > >>>> Can someone let me know what the status of this work is ? > >>> > >>> The WG has discussed this question a few times and has not reached=20 > >>> any consensus. > >>> > >>> Here is the summary: > >>> > >>> 1) many feel that an **SNMP** Agent is not going to fit into=20 > >>> constrained > >> devices. > >>> 2) Jurgen has demonstrated it does fit into a class 2 device on=20 > >>> using Contiki. > >>> 3) others have pointed out that SNMP is not the only way to deal=20 > >>> with a MIB, and the important things in a MIB is the set of=20 > >>> statistics which one might collect, and transmit in *some* way. > >>> 4) opinions have ranged from HTTP / CoAP to NetCONF/YANG as other=20 > >>> transport alternatives to SNMP. > >>> > >>> I think that it is simply early for many people to talk about=20 > >>> having consistent sets of statistics... BUT. PLEASE FEEL FREE TO PROV= E ME WRONG. > >>> > >>> In particular, I think that *some* standard way to get the network=20 > >>> adjacency matrix (as well as the DODAG) out of motes would be very=20 > >>> useful for network operators. > >>> > >>> -- > >>> Michael Richardson , Sandelman Software Works > >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter= / > >> > >> > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. >=20 > This e-mail (including any attachments) is confidential and may be legall= y privileged. If you are not an intended recipient or an authorized represe= ntative of an intended recipient, you are prohibited from using, copying or= distributing the information in this e-mail or its attachments. If you hav= e received this e-mail in error, please notify the sender immediately by re= turn e-mail and delete all copies of this message and any attachments. Than= k you. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From johui@cisco.com Tue Sep 3 07:24:02 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB6521E8152 for ; Tue, 3 Sep 2013 07:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klqMRsnYhCnk for ; Tue, 3 Sep 2013 07:23:56 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 95B6511E80ED for ; Tue, 3 Sep 2013 07:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3624; q=dns/txt; s=iport; t=1378218234; x=1379427834; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CnC7njReRYGbtY74NaLMw4mS9lTkCSK5sGpZJ5VNJXM=; b=VOYDWePhotEHLu9CF3MhHn+ZSyz6VmdsIyq7CXvMQnpuAW6X7iB/6mwz wpiQIp3597oKc28BYHQhKwaT+NeIR4e2b8UEwrVVa749F0YI+lXh5qofP hP/0gTH/DX7CeYe9KSLuGJIscHfqCNiQ6inB+9XDF4xr9dldTpjWnJbXQ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAB3wJVKtJXG8/2dsb2JhbABbgwc1UcB1gSoWdIIkAQEBAwEBAQFrCwULAgEIEQMBAgsZBAchBgsUCQgCBA4FCAGHZwMJBgywIg2IUY0JgS4GCnwCMQIFBoMXgQADlgyDGIsIhS+BY4E9gWgJFyI X-IronPort-AV: E=Sophos;i="4.89,1014,1367971200"; d="scan'208";a="254990348" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 03 Sep 2013 14:23:54 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r83ENrHn023645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Sep 2013 14:23:53 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.145]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 09:23:53 -0500 From: "Jonathan Hui (johui)" To: KELLIL Mounir Thread-Topic: [Roll] [roll] #129: draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwarding should be mutually exclusive within the same MPL Domain? Thread-Index: AQHOqLE3evN5HS86kU2B4gsdzFYmVA== Date: Tue, 3 Sep 2013 14:23:52 +0000 Message-ID: References: <067.eb8cd06a193daa93167f1567d59337cc@trac.tools.ietf.org> <082.c53b887921203ff02b64d18ef29ca24a@trac.tools.ietf.org> <7708224CCA85B641A12F88B1F5A47A431B1C0A48@EXDAG0-B2.intra.cea.fr> In-Reply-To: <7708224CCA85B641A12F88B1F5A47A431B1C0A48@EXDAG0-B2.intra.cea.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.29] Content-Type: text/plain; charset="Windows-1252" Content-ID: <323695441BA3BC45B9272A9CC765CA10@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] [roll] #129: draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwarding should be mutually exclusive within the same MPL Domain? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 14:24:02 -0000 Hi Mounir, MPL's reactive mode relies on MPL Control Messages to provide eventual cons= istency. Using the Trickle algorithm, a device resets its MPL Control Mess= age Trickle timer whenever it determines that a neighboring node has newer = or older information. When determining that a neighboring device has not r= eceived an MPL Data Message, a device will reset/start the Trickle timer to= transmit the MPL Data Message. Hope that helps. -- Jonathan Hui On Sep 3, 2013, at 7:10 AM, KELLIL Mounir wrote: > Dear Jonathan, all, > Thanks for the clarification regarding the proactive and Reactive Forward= ing procedures, yet it is still not clear for me what happens if a forwardi= ng node in a 'reactive forwarding only' mode receives a new MPL message ? D= oes it forward the message systematically (i.e., without receiving any asso= ciated control message)? If the answer is No, in this case it may happen th= at for LLNs with specific topologies (e.g., sparse networks) some nodes mig= ht not receive (all) the MPL messages. Maybe you have already considered th= is problem somehow? >=20 > Regards >=20 > Mounir >=20 > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de r= oll issue tracker > Envoy=E9 : vendredi 30 ao=FBt 2013 01:35 > =C0 : johui@cisco.com; rdroms@cisco.com; mariainesrobles@gmail.com > Cc : roll@ietf.org > Objet : Re: [Roll] [roll] #129: draft-ietf-roll-trickle-mcast-04 - Proact= ive and Reactive Forwarding should be mutually exclusive within the same MP= L Domain? >=20 > #129: draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwardin= g should be mutually exclusive within the same MPL Domain? >=20 >=20 > Comment (by mariainesrobles@gmail.com): >=20 > Date: Thu, 29 Aug 2013 14:34:38 +0000 >=20 > From: "Jonathan Hui (johui)" >=20 > Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast- >=20 > 05.txt >=20 > =93This update attempts to address all of the open tickets. A summary of= changes is below. Please provide feedback on these changes. Thanks. >=20 > ... >=20 > 129: > - Updated Section 4.2 to explicitly indicate that proactive and reactive = are not mutually exclusive. Proactive and reactive techniques may be used= simultaneously within an MPL Domain. For example, upon receiving a new = MPL Data messages when both proactive and reactive forwarding techniques a= re enabled, an MPL Forwarder will proactively retransmit the MPL Data Mess= age a limited number of times and schedule further transmissions upon rece= iving MPL Control Messages.=94 >=20 > Thread: http://www.ietf.org/mail-archive/web/roll/current/msg08103.html > Thread: http://www.ietf.org/mail-archive/web/roll/current/msg07947.html >=20 > --=20 > ---------------------------------------+------------------------------ > Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com > Type: defect | Status: new > Priority: minor | Milestone: > Component: trickle-mcast | Version: > Severity: In WG Last Call | Resolution: > Keywords: | > ---------------------------------------+------------------------------ >=20 > Ticket URL: > roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mounir.kellil@cea.fr Tue Sep 3 07:52:22 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8762121E8154 for ; Tue, 3 Sep 2013 07:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIgJeQvUeqmC for ; Tue, 3 Sep 2013 07:52:11 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 149FF21E814C for ; Tue, 3 Sep 2013 07:52:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r83Eq4mD008058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Sep 2013 16:52:04 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r83Eq3PB025617; Tue, 3 Sep 2013 16:52:03 +0200 (envelope-from mounir.kellil@cea.fr) Received: from EXCAH-A3.intra.cea.fr (excah-a3.intra.cea.fr [132.166.88.77]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r83Eq3cs014845; Tue, 3 Sep 2013 16:52:03 +0200 Received: from EXDAG0-B2.intra.cea.fr ([fe80::d079:8496:6c6c:9b1f]) by EXCAH-A3.intra.cea.fr ([fe80::60de:a77e:427d:f7e6%10]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 16:52:03 +0200 From: KELLIL Mounir To: "Jonathan Hui (johui)" Thread-Topic: [Roll] [roll] #129: draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwarding should be mutually exclusive within the same MPL Domain? Thread-Index: AQHOpRB9U1J2Gyk69EeLptKoHav1q5m0D5qw///nKwCAACSS4A== Date: Tue, 3 Sep 2013 14:52:03 +0000 Message-ID: <7708224CCA85B641A12F88B1F5A47A431B1C0A89@EXDAG0-B2.intra.cea.fr> References: <067.eb8cd06a193daa93167f1567d59337cc@trac.tools.ietf.org> <082.c53b887921203ff02b64d18ef29ca24a@trac.tools.ietf.org> <7708224CCA85B641A12F88B1F5A47A431B1C0A48@EXDAG0-B2.intra.cea.fr> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.105] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-20124.007 x-tm-as-result: No--66.973200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] [roll] #129: draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwarding should be mutually exclusive within the same MPL Domain? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 14:52:23 -0000 Thanks Jonathan. I got it.=20 Regards Mounir -----Message d'origine----- De=A0: Jonathan Hui (johui) [mailto:johui@cisco.com]=20 Envoy=E9=A0: mardi 3 septembre 2013 16:24 =C0=A0: KELLIL Mounir Cc=A0: roll@ietf.org Objet=A0: Re: [Roll] [roll] #129: draft-ietf-roll-trickle-mcast-04 - Proact= ive and Reactive Forwarding should be mutually exclusive within the same MP= L Domain? Hi Mounir, MPL's reactive mode relies on MPL Control Messages to provide eventual cons= istency. Using the Trickle algorithm, a device resets its MPL Control Mess= age Trickle timer whenever it determines that a neighboring node has newer = or older information. When determining that a neighboring device has not r= eceived an MPL Data Message, a device will reset/start the Trickle timer to= transmit the MPL Data Message. Hope that helps. -- Jonathan Hui On Sep 3, 2013, at 7:10 AM, KELLIL Mounir wrote: > Dear Jonathan, all, > Thanks for the clarification regarding the proactive and Reactive Forward= ing procedures, yet it is still not clear for me what happens if a forwardi= ng node in a 'reactive forwarding only' mode receives a new MPL message ? D= oes it forward the message systematically (i.e., without receiving any asso= ciated control message)? If the answer is No, in this case it may happen th= at for LLNs with specific topologies (e.g., sparse networks) some nodes mig= ht not receive (all) the MPL messages. Maybe you have already considered th= is problem somehow? >=20 > Regards >=20 > Mounir >=20 > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part=20 > de roll issue tracker Envoy=E9 : vendredi 30 ao=FBt 2013 01:35 =C0 :=20 > johui@cisco.com; rdroms@cisco.com; mariainesrobles@gmail.com Cc :=20 > roll@ietf.org Objet : Re: [Roll] [roll] #129:=20 > draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwarding shou= ld be mutually exclusive within the same MPL Domain? >=20 > #129: draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwardin= g should be mutually exclusive within the same MPL Domain? >=20 >=20 > Comment (by mariainesrobles@gmail.com): >=20 > Date: Thu, 29 Aug 2013 14:34:38 +0000 >=20 > From: "Jonathan Hui (johui)" >=20 > Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast- >=20 > 05.txt >=20 > "This update attempts to address all of the open tickets. A summary of = changes is below. Please provide feedback on these changes. Thanks. >=20 > ... >=20 > 129: > - Updated Section 4.2 to explicitly indicate that proactive and reactive = are not mutually exclusive. Proactive and reactive techniques may be used= simultaneously within an MPL Domain. For example, upon receiving a new = MPL Data messages when both proactive and reactive forwarding techniques a= re enabled, an MPL Forwarder will proactively retransmit the MPL Data Mess= age a limited number of times and schedule further transmissions upon rece= iving MPL Control Messages." >=20 > Thread:=20 > http://www.ietf.org/mail-archive/web/roll/current/msg08103.html > Thread:=20 > http://www.ietf.org/mail-archive/web/roll/current/msg07947.html >=20 > -- > ---------------------------------------+------------------------------ > Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com > Type: defect | Status: new > Priority: minor | Milestone: > Component: trickle-mcast | Version: > Severity: In WG Last Call | Resolution: > Keywords: | > ---------------------------------------+------------------------------ >=20 > Ticket URL:=20 > > roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From j.schoenwaelder@jacobs-university.de Tue Sep 3 10:01:43 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061FF21F9B86 for ; Tue, 3 Sep 2013 10:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.928 X-Spam-Level: X-Spam-Status: No, score=-102.928 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUS8cgxoan0V for ; Tue, 3 Sep 2013 10:01:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D199021F9AB4 for ; Tue, 3 Sep 2013 10:01:28 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 394A220C4B; Tue, 3 Sep 2013 19:01:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5A8IVviyk92j; Tue, 3 Sep 2013 19:01:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CD6E20C42; Tue, 3 Sep 2013 19:01:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 437422832A1E; Tue, 3 Sep 2013 19:01:21 +0200 (CEST) Date: Tue, 3 Sep 2013 19:01:21 +0200 From: Juergen Schoenwaelder To: Routing Over Low power and Lossy networks Message-ID: <20130903170121.GB51228@elstar.local> Mail-Followup-To: Routing Over Low power and Lossy networks References: <23397.1377885103@sandelman.ca> <0b7a01cea7c7$9b1b2120$d1516360$@olddog.co.uk> <03B78081B371D44390ED6E7BADBB4A77237657C9@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77237682C3@xmb-rcd-x02.cisco.com> <866c54ef240c43f296e2f066b85134bf@DBXPR01MB015.eurprd01.prod.exchangelabs.com> <20130903134551.GD48413@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Roll] RPL MIB X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder , Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 17:01:43 -0000 Randy, we have done a detailed analysis of our SNMP stack implemented on Contiki. SNMP itself is not a resource hog (actually no surprise given that SNMP was designed in the 80s). If you do crypto in software, then the crypto code is the killer in size and (depending on the platform) in performance. But this applies equally well to DTLS as long as you can't exploit hardware crypto and you use off-the-shelf cryto algorithms. Anyway, having agreement which counters etc. should be in the RPL code would already be a big plus. If people can ship the data more efficiently or more comfortably over CoAP and there is no need to integrate with SNMP-based tools, fine. /js On Tue, Sep 03, 2013 at 02:12:55PM +0000, Turner, Randy wrote: > > Yes, you can separate the usage of the MIB data model within a device from the SNMP protocol used to transport it -- however, there should be a very good reason for doing this. I think it might be possible to "profile" SNMPv3 in such a way as to make it more attractive to constrained devices. > > Randy > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, September 03, 2013 9:46 AM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] RPL MIB > > Hi, > > the key is to find agreement which counters etc. are relevant to instrument in the RPL code. Whether one provides access to these counters via SNMP or some other means may depends on the specific constraints of the device and the deployment target. > > A MIB module is a way to define what needs to be instrumented and, as a side effect, it of course works well with SNMP as an access mechanism. But this does not exclude other access mechanism from being used instead. > > /js > > On Tue, Sep 03, 2013 at 01:34:16PM +0000, Turner, Randy wrote: > > > > There is an expired draft for an RPL MIB that I think is a good start...that doesn't seem to violate the spirit of what is being proposed below. > > > > So it doesn't appear that this would be a "from scratch" effort. > > > > The data model suggested by the expired draft offers some good ideas, much of it I think is quite usable and valuable. > > > > There remains a "non-data-related" aspect of management in an LLN, which might suggest that there are some endpoint devices that are too constrained to support something like an SNMP agent. While that maybe true, I believe the more constrained a device is in functionality and capability, the less likely I may want to actively (pro-actively) manage such an endpoint. > > > > Randy > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of JP Vasseur (jvasseur) > > Sent: Tuesday, September 03, 2013 3:45 AM > > To: Adrian Farrel; Routing Over Low power and Lossy networks > > Subject: Re: [Roll] RPL MIB > > > > Typo "I cannot agree MORE" ;-) > > > > On Sep 3, 2013, at 8:20 AM, JP Vasseur (jvasseur) wrote: > > > > > Hi, > > > > > > I cannot agree, adding some thoughts: of course, we would need to > > > think very careful on where such a management MIB would be run and > > > the framework should cover some of the required workflow. Indeed, > > > running a RPL MIB on a router would make total sense, but may be > > > simply not possible on a low-end node (due to memory but also bandwidth constraint), and this is where we would need to sync up with CORE. > > > > > > Cheers. > > > > > > JP. > > > > > > On Sep 2, 2013, at 12:31 PM, Adrian Farrel wrote: > > > > > >> Hi, > > >> > > >> In this context it might make a lot of sense for some work to be > > >> done on a "management framework for RPL devices". > > >> > > >> What needs to be configurable? What protocol needs to be visible? > > >> What information is needed for diagnostics? What alarms/alerts are > > >> needed? What are the implications of storing logs? What are the > > >> implications of sending unsolicited notifications and/or of > > >> responding to status queries? What protocols are appropriate? > > >> > > >> This would lead to an Information model, which might in time lead > > >> to a data model. > > >> > > >> It is definitely also worth coordinating with CORE to see what they > > >> think about higher layer protocols to constrained devices. > > >> > > >> Cheers, > > >> Adrian > > >> > > >>> -----Original Message----- > > >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > > >>> Behalf Of > > >> Michael > > >>> Richardson > > >>> Sent: 30 August 2013 18:52 > > >>> To: Routing Over Low power and Lossy networks > > >>> Subject: Re: [Roll] RPL MIB > > >>> > > >>> > > >>> Turner, Randy wrote: > > >>>> On the IETF ROLL WG page, I was looking for a current (not > > >>>> expired) version of the RPL MIB draft, but there doesn?t appear to be one. > > >>> > > >>> It likely expired. > > >>> > > >>> http://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib/ > > >>> > > >>>> Can someone let me know what the status of this work is ? > > >>> > > >>> The WG has discussed this question a few times and has not reached > > >>> any consensus. > > >>> > > >>> Here is the summary: > > >>> > > >>> 1) many feel that an **SNMP** Agent is not going to fit into > > >>> constrained > > >> devices. > > >>> 2) Jurgen has demonstrated it does fit into a class 2 device on > > >>> using Contiki. > > >>> 3) others have pointed out that SNMP is not the only way to deal > > >>> with a MIB, and the important things in a MIB is the set of > > >>> statistics which one might collect, and transmit in *some* way. > > >>> 4) opinions have ranged from HTTP / CoAP to NetCONF/YANG as other > > >>> transport alternatives to SNMP. > > >>> > > >>> I think that it is simply early for many people to talk about > > >>> having consistent sets of statistics... BUT. PLEASE FEEL FREE TO PROVE ME WRONG. > > >>> > > >>> In particular, I think that *some* standard way to get the network > > >>> adjacency matrix (as well as the DODAG) out of motes would be very > > >>> useful for network operators. > > >>> > > >>> -- > > >>> Michael Richardson , Sandelman Software Works > > >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > >> > > >> > > >> _______________________________________________ > > >> Roll mailing list > > >> Roll@ietf.org > > >> https://www.ietf.org/mailman/listinfo/roll > > > > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > > > This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you. > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Randy.Turner@landisgyr.com Tue Sep 3 10:23:29 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6C711E80E4 for ; Tue, 3 Sep 2013 10:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuOmLctgPie9 for ; Tue, 3 Sep 2013 10:23:16 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0083.outbound.protection.outlook.com [213.199.154.83]) by ietfa.amsl.com (Postfix) with ESMTP id DF02B11E8104 for ; Tue, 3 Sep 2013 10:23:05 -0700 (PDT) Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com (10.255.176.37) by DBXPR01MB016.eurprd01.prod.exchangelabs.com (10.255.176.38) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 17:23:02 +0000 Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.179]) by DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.179]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 17:23:02 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] RPL MIB Thread-Index: Ac6logq3/vh0oGNlTpWt+jWe8hDnVgAB4uWAAIeAkAAAKYLDgAAC8/AAAAwTpDAAAIlLgAAA4LzwAAXzLIAAAH2BMA== Date: Tue, 3 Sep 2013 17:23:01 +0000 Message-ID: References: <23397.1377885103@sandelman.ca> <0b7a01cea7c7$9b1b2120$d1516360$@olddog.co.uk> <03B78081B371D44390ED6E7BADBB4A77237657C9@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77237682C3@xmb-rcd-x02.cisco.com> <866c54ef240c43f296e2f066b85134bf@DBXPR01MB015.eurprd01.prod.exchangelabs.com> <20130903134551.GD48413@elstar.local> <20130903170121.GB51228@elstar.local> In-Reply-To: <20130903170121.GB51228@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [148.80.255.144] x-forefront-prvs: 09583628E0 x-forefront-antispam-report: SFV:NSPM; SFS:(52044002)(13464003)(24454002)(52314003)(51444003)(199002)(189002)(51704005)(377454003)(74706001)(66066001)(79102001)(80022001)(63696002)(81686001)(76796001)(81342001)(76786001)(69226001)(15202345003)(74876001)(56816003)(77096001)(74316001)(80976001)(81816001)(31966008)(74662001)(65816001)(77982001)(59766001)(53806001)(54356001)(74502001)(56776001)(74366001)(47446002)(54316002)(76482001)(15975445006)(51856001)(33646001)(19580395003)(83072001)(83322001)(19580405001)(46102001)(81542001)(4396001)(49866001)(50986001)(47976001)(47736001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR01MB016; H:DBXPR01MB015.eurprd01.prod.exchangelabs.com; CLIP:148.80.255.144; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Subject: Re: [Roll] RPL MIB X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 17:23:29 -0000 Agreed, if they already have COAP in the box, then there's an incentive to = reuse it as much as possible -- but if they don't, there are a multitude of= existing network management infrastructures that utilize SNMP managers -- = this infrastructure could be reused -- I'm not aware of any NMS vendors loo= king at adapting anything new on the protocol front (except possibly NETCON= F, which has its' own implications for constrained devices). I'm happy to b= e proved wrong here :) At the end of the day, I would like to reuse existing SNMP management infra= structure as much as possible, but I'm not opposed to using something else = to transport the management information, if need be. I think we're going to want to secure the network management traffic regard= less of transport, so I'm assuming crypto overhead is "sunk cost", meaning = it's going to be there. If there is consensus in the WG, I would like to "restart" the MIB and asso= ciated management effort, with of course input from other interested partie= s (CORE, etc.) R. -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jue= rgen Schoenwaelder Sent: Tuesday, September 03, 2013 1:01 PM To: Routing Over Low power and Lossy networks Subject: Re: [Roll] RPL MIB Randy, we have done a detailed analysis of our SNMP stack implemented on Contiki. = SNMP itself is not a resource hog (actually no surprise given that SNMP was= designed in the 80s). If you do crypto in software, then the crypto code i= s the killer in size and (depending on the platform) in performance. But th= is applies equally well to DTLS as long as you can't exploit hardware crypt= o and you use off-the-shelf cryto algorithms. Anyway, having agreement which counters etc. should be in the RPL code woul= d already be a big plus. If people can ship the data more efficiently or mo= re comfortably over CoAP and there is no need to integrate with SNMP-based = tools, fine. /js On Tue, Sep 03, 2013 at 02:12:55PM +0000, Turner, Randy wrote: >=20 > Yes, you can separate the usage of the MIB data model within a device fro= m the SNMP protocol used to transport it -- however, there should be a very= good reason for doing this. I think it might be possible to "profile" SNM= Pv3 in such a way as to make it more attractive to constrained devices. >=20 > Randy >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Juergen Schoenwaelder > Sent: Tuesday, September 03, 2013 9:46 AM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] RPL MIB >=20 > Hi, >=20 > the key is to find agreement which counters etc. are relevant to instrume= nt in the RPL code. Whether one provides access to these counters via SNMP = or some other means may depends on the specific constraints of the device a= nd the deployment target. >=20 > A MIB module is a way to define what needs to be instrumented and, as a s= ide effect, it of course works well with SNMP as an access mechanism. But t= his does not exclude other access mechanism from being used instead. >=20 > /js >=20 > On Tue, Sep 03, 2013 at 01:34:16PM +0000, Turner, Randy wrote: > >=20 > > There is an expired draft for an RPL MIB that I think is a good start.= ..that doesn't seem to violate the spirit of what is being proposed below. > >=20 > > So it doesn't appear that this would be a "from scratch" effort. > >=20 > > The data model suggested by the expired draft offers some good ideas, m= uch of it I think is quite usable and valuable. > >=20 > > There remains a "non-data-related" aspect of management in an LLN, whic= h might suggest that there are some endpoint devices that are too constrain= ed to support something like an SNMP agent. While that maybe true, I beli= eve the more constrained a device is in functionality and capability, the l= ess likely I may want to actively (pro-actively) manage such an endpoint. > >=20 > > Randy > >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > > Of JP Vasseur (jvasseur) > > Sent: Tuesday, September 03, 2013 3:45 AM > > To: Adrian Farrel; Routing Over Low power and Lossy networks > > Subject: Re: [Roll] RPL MIB > >=20 > > Typo "I cannot agree MORE" ;-) > >=20 > > On Sep 3, 2013, at 8:20 AM, JP Vasseur (jvasseur) = wrote: > >=20 > > > Hi, > > > > > > I cannot agree, adding some thoughts: of course, we would need to=20 > > > think very careful on where such a management MIB would be run and=20 > > > the framework should cover some of the required workflow. Indeed,=20 > > > running a RPL MIB on a router would make total sense, but may be=20 > > > simply not possible on a low-end node (due to memory but also bandwid= th constraint), and this is where we would need to sync up with CORE. > > > > > > Cheers. > > > > > > JP. > > > > > > On Sep 2, 2013, at 12:31 PM, Adrian Farrel wrot= e: > > > > > >> Hi, > > >> > > >> In this context it might make a lot of sense for some work to be=20 > > >> done on a "management framework for RPL devices". > > >> > > >> What needs to be configurable? What protocol needs to be visible? > > >> What information is needed for diagnostics? What alarms/alerts=20 > > >> are needed? What are the implications of storing logs? What are=20 > > >> the implications of sending unsolicited notifications and/or of=20 > > >> responding to status queries? What protocols are appropriate? > > >> > > >> This would lead to an Information model, which might in time lead=20 > > >> to a data model. > > >> > > >> It is definitely also worth coordinating with CORE to see what=20 > > >> they think about higher layer protocols to constrained devices. > > >> > > >> Cheers, > > >> Adrian > > >> > > >>> -----Original Message----- > > >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > > >>> Behalf Of > > >> Michael > > >>> Richardson > > >>> Sent: 30 August 2013 18:52 > > >>> To: Routing Over Low power and Lossy networks > > >>> Subject: Re: [Roll] RPL MIB > > >>> > > >>> > > >>> Turner, Randy wrote: > > >>>> On the IETF ROLL WG page, I was looking for a current (not > > >>>> expired) version of the RPL MIB draft, but there doesn?t appear to= be one. > > >>> > > >>> It likely expired. > > >>> > > >>> http://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib/ > > >>> > > >>>> Can someone let me know what the status of this work is ? > > >>> > > >>> The WG has discussed this question a few times and has not=20 > > >>> reached any consensus. > > >>> > > >>> Here is the summary: > > >>> > > >>> 1) many feel that an **SNMP** Agent is not going to fit into=20 > > >>> constrained > > >> devices. > > >>> 2) Jurgen has demonstrated it does fit into a class 2 device on=20 > > >>> using Contiki. > > >>> 3) others have pointed out that SNMP is not the only way to deal=20 > > >>> with a MIB, and the important things in a MIB is the set of=20 > > >>> statistics which one might collect, and transmit in *some* way. > > >>> 4) opinions have ranged from HTTP / CoAP to NetCONF/YANG as=20 > > >>> other transport alternatives to SNMP. > > >>> > > >>> I think that it is simply early for many people to talk about=20 > > >>> having consistent sets of statistics... BUT. PLEASE FEEL FREE TO PR= OVE ME WRONG. > > >>> > > >>> In particular, I think that *some* standard way to get the=20 > > >>> network adjacency matrix (as well as the DODAG) out of motes=20 > > >>> would be very useful for network operators. > > >>> > > >>> -- > > >>> Michael Richardson , Sandelman Software Work= s > > >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/chart= er/ > > >> > > >> > > >> _______________________________________________ > > >> 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 > >=20 > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > >=20 > >=20 > > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > >=20 > > This e-mail (including any attachments) is confidential and may be lega= lly privileged. If you are not an intended recipient or an authorized repre= sentative of an intended recipient, you are prohibited from using, copying = or distributing the information in this e-mail or its attachments. If you h= ave received this e-mail in error, please notify the sender immediately by = return e-mail and delete all copies of this message and any attachments. Th= ank you. > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > 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 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From trac+roll@trac.tools.ietf.org Tue Sep 3 14:57:49 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE9B11E811F for ; Tue, 3 Sep 2013 14:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WrgmCqVp0qB for ; Tue, 3 Sep 2013 14:57:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 94E8A21F86BE for ; Tue, 3 Sep 2013 14:57:41 -0700 (PDT) Received: from localhost ([127.0.0.1]:35449 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGybU-0004bw-Ih; Tue, 03 Sep 2013 23:57:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mariainesrobles@gmail.com X-Trac-Project: roll Date: Tue, 03 Sep 2013 21:57:40 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/111#comment:3 Message-ID: <083.9750f81928ae57a98fbefc23220c4f6f@trac.tools.ietf.org> References: <068.d297e97474c3aa6d3b0200f33881db3c@trac.tools.ietf.org> X-Trac-Ticket-ID: 111 In-Reply-To: <068.d297e97474c3aa6d3b0200f33881db3c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #111: MPL relation with RPL is not clear X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 21:57:49 -0000 #111: MPL relation with RPL is not clear Changes (by mariainesrobles@gmail.com): * status: new => closed * resolution: => fixed -- ----------------------------------------+-------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun Type: enhancement | Status: closed Priority: major | Milestone: Component: trickle-mcast | Version: Severity: Active WG Document | Resolution: fixed Keywords: Multicast, RPL, Trickle | ----------------------------------------+-------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Tue Sep 3 14:58:45 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19E021E80D9 for ; Tue, 3 Sep 2013 14:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QT7LNowwx6X for ; Tue, 3 Sep 2013 14:58:44 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6B221E80D4 for ; Tue, 3 Sep 2013 14:58:44 -0700 (PDT) Received: from localhost ([127.0.0.1]:35525 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGycR-0001EY-Mg; Tue, 03 Sep 2013 23:58:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mariainesrobles@gmail.com X-Trac-Project: roll Date: Tue, 03 Sep 2013 21:58:39 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/113#comment:2 Message-ID: <083.c833ebe119fb8b44a6713e2ac5f94d78@trac.tools.ietf.org> References: <068.911b32936c333d1785fb02055eb8148d@trac.tools.ietf.org> X-Trac-Ticket-ID: 113 In-Reply-To: <068.911b32936c333d1785fb02055eb8148d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mariainesrobles@gmail.com, draft-ietf-roll-trickle-mcast@tools.ietf.org, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130903215844.1C6B221E80D4@ietfa.amsl.com> Resent-Date: Tue, 3 Sep 2013 14:58:44 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org, draft-ietf-roll-trickle-mcast@tools.ietf.org Subject: Re: [Roll] [roll] #113: MPL Processing Section X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 21:58:45 -0000 #113: MPL Processing Section Changes (by mariainesrobles@gmail.com): * status: new => closed * resolution: => fixed -- ----------------------------------------+-------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun Type: enhancement | Status: closed Priority: major | Milestone: milestone1 Component: trickle-mcast | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: Multicast, RPL, Trickle | ----------------------------------------+-------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Tue Sep 3 15:04:33 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0E521E8055 for ; Tue, 3 Sep 2013 15:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlcseOP39T-e for ; Tue, 3 Sep 2013 15:04:32 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 360E321E8095 for ; Tue, 3 Sep 2013 15:04:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:36321 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGyhy-0007j5-PK; Wed, 04 Sep 2013 00:04:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, mcr@sandelman.ca, rdroms@cisco.com X-Trac-Project: roll Date: Tue, 03 Sep 2013 22:04:22 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/128#comment:5 Message-ID: <082.fcc5038278155da22a1c12e9e7a11c50@trac.tools.ietf.org> References: <067.081907fd6195c3034e6e8c71a7eb4a93@trac.tools.ietf.org> X-Trac-Ticket-ID: 128 In-Reply-To: <067.081907fd6195c3034e6e8c71a7eb4a93@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, mcr@sandelman.ca, rdroms@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #128: Trickle multicast could be considered in other applications? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 22:04:33 -0000 #128: Trickle multicast could be considered in other applications? Changes (by mariainesrobles@gmail.com): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: enhancement | Status: closed Priority: minor | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From trac+roll@trac.tools.ietf.org Tue Sep 3 15:16:18 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252DD21F9655 for ; Tue, 3 Sep 2013 15:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-F8j4swMRmL for ; Tue, 3 Sep 2013 15:16:17 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6C59521F93E4 for ; Tue, 3 Sep 2013 15:16:17 -0700 (PDT) Received: from localhost ([127.0.0.1]:37001 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGytT-0007Gf-34; Wed, 04 Sep 2013 00:16:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, rdroms@cisco.com, mariainesrobles@gmail.com X-Trac-Project: roll Date: Tue, 03 Sep 2013 22:16:15 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/129#comment:3 Message-ID: <082.fbea7f85f834b7855059366c8cce574c@trac.tools.ietf.org> References: <067.eb8cd06a193daa93167f1567d59337cc@trac.tools.ietf.org> X-Trac-Ticket-ID: 129 In-Reply-To: <067.eb8cd06a193daa93167f1567d59337cc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, rdroms@cisco.com, mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #129: draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwarding should be mutually exclusive within the same MPL Domain? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 22:16:18 -0000 #129: draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwarding should be mutually exclusive within the same MPL Domain? Comment (by mariainesrobles@gmail.com): From: KELLIL Mounir [[BR]] Date: Tue, 3 Sep 2013 14:10:19 +0000 ... Dear Jonathan, all, Thanks for the clarification regarding the proactive and Reactive Forwarding procedures, yet it is still not clear for me what happens if a forwarding node in a 'reactive forwarding only' mode receives a new MPL message ? Does it forward the message systematically (i.e., without receiving any associated control message)? If the answer is No, in this case it may happen that for LLNs with specific topologies (e.g., sparse networks) some nodes might not receive (all) the MPL messages. Maybe you have already considered this problem somehow? Regards Mounir --------------------------------------------------- From: "Jonathan Hui (johui)" Hi Mounir, MPL's reactive mode relies on MPL Control Messages to provide eventual consistency. Using the Trickle algorithm, a device resets its MPL Control Message Trickle timer whenever it determines that a neighboring node has newer or older information. When determining that a neighboring device has not received an MPL Data Message, a device will reset/start the Trickle timer to transmit the MPL Data Message. Hope that helps.--Jonathan Hui -------------------------------------------------------- From: KELLIL Mounir Thanks Jonathan. I got it. Regards Mounir[[BR]] [[BR]] Thread: http://www.ietf.org/mail-archive/web/roll/current/msg08119.html -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: new Priority: minor | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From trac+roll@trac.tools.ietf.org Tue Sep 3 18:16:50 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F230321F85C3 for ; Tue, 3 Sep 2013 18:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.465 X-Spam-Level: X-Spam-Status: No, score=-101.465 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKFeunsysf5m for ; Tue, 3 Sep 2013 18:16:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5994C21E8118 for ; Tue, 3 Sep 2013 18:16:42 -0700 (PDT) Received: from localhost ([127.0.0.1]:49909 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VH1hu-00051L-Gv; Wed, 04 Sep 2013 03:16:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Wed, 04 Sep 2013 01:16:30 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/117#comment:3 Message-ID: <082.14b97f935c2b9cebdccf7dce1c3699d9@trac.tools.ietf.org> References: <067.2ab3aa03f106c42294a1c316eb2b7bc0@trac.tools.ietf.org> X-Trac-Ticket-ID: 117 In-Reply-To: <067.2ab3aa03f106c42294a1c316eb2b7bc0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #117: draft-ietf-roll-security-threats-01.txt --- Verify/include references X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 01:16:50 -0000 #117: draft-ietf-roll-security-threats-01.txt --- Verify/include references Comment (by mcr@sandelman.ca): link is: http://www.ic.unicamp.br/~leob/publications/ewsn/NanoECC.pdf -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | tzeta.tsao@cooperindustries.com Type: defect | Status: new Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From stokcons@xs4all.nl Wed Sep 4 02:37:43 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61D511E819C for ; Wed, 4 Sep 2013 02:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.146 X-Spam-Level: X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4McpGSwg7TY for ; Wed, 4 Sep 2013 02:37:37 -0700 (PDT) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3F96911E80E3 for ; Wed, 4 Sep 2013 02:37:32 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube12.xs4all.net [194.109.20.211]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id r849bRI1058063 for ; Wed, 4 Sep 2013 11:37:27 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-158-227.w90-0.abo.wanadoo.fr ([90.0.253.227]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 04 Sep 2013 11:37:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 04 Sep 2013 11:37:27 +0200 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <23397.1377885103@sandelman.ca> <0b7a01cea7c7$9b1b2120$d1516360$@olddog.co.uk> <03B78081B371D44390ED6E7BADBB4A77237657C9@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77237682C3@xmb-rcd-x02.cisco.com> <866c54ef240c43f296e2f066b85134bf@DBXPR01MB015.eurprd01.prod.exchangelabs.com> <20130903134551.GD48413@elstar.local> <20130903170121.GB51228@elstar.local> Message-ID: <32f4fd11890c1bb17078dbdede004ec3@xs4all.nl> X-Sender: stokcons@xs4all.nl (1Wjq7pu2HC3Q2HJgmBQ89Z2dZEYzTD3E) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] RPL MIB X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 09:37:43 -0000 Hi Randy, excellent idea to look at a MIB for RPL, RPL-P2P, and MPL. I hope you will also include the parameters that need initialization, like: k, c, Imin, DIOIntervalMin, DIOIntervalDoublings, etc. I agree fully with the reuse of the existing MIB base also for low resource devices. The separation between SNMP and MIB is nicely described in RFC 3410. I don't see people changing their existing SNMP installed base, but I get requests to look at a CoAP interface to the MIBs for the small devices. I have been working on a CoAP interface to the MIBs, called CoMI (CoAP Management Interface). I expect to publish a second, much improved, more focussed, draft the coming weeks. According to me the advantages are: One programming interface for management and other applications and the subsequent reduction in stack complexity, reduction of security complexity as proposed during the DICE BoF will follow automatically with CoAP updates, use of resource discovery will come for free, possible use of multicast to initialize variables to a group of devices. Disadvantages are: a different approach to the multi packet transport, and a different approach to passing through the lexicographically ordered list of data. This list of (dis)advantages still needs to be validated. Greetings, Peter van der Stok Turner, Randy schreef op 2013-09-03 19:23: > Agreed, if they already have COAP in the box, then there's an > incentive to reuse it as much as possible -- but if they don't, there > are a multitude of existing network management infrastructures that > utilize SNMP managers -- this infrastructure could be reused -- I'm > not aware of any NMS vendors looking at adapting anything new on the > protocol front (except possibly NETCONF, which has its' own > implications for constrained devices). I'm happy to be proved wrong > here :) > > At the end of the day, I would like to reuse existing SNMP management > infrastructure as much as possible, but I'm not opposed to using > something else to transport the management information, if need be. > > I think we're going to want to secure the network management traffic > regardless of transport, so I'm assuming crypto overhead is "sunk > cost", meaning it's going to be there. > > If there is consensus in the WG, I would like to "restart" the MIB and > associated management effort, with of course input from other > interested parties (CORE, etc.) > > R. > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Juergen Schoenwaelder > Sent: Tuesday, September 03, 2013 1:01 PM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] RPL MIB > > Randy, > > we have done a detailed analysis of our SNMP stack implemented on > Contiki. SNMP itself is not a resource hog (actually no surprise given > that SNMP was designed in the 80s). If you do crypto in software, then > the crypto code is the killer in size and (depending on the platform) > in performance. But this applies equally well to DTLS as long as you > can't exploit hardware crypto and you use off-the-shelf cryto > algorithms. > > Anyway, having agreement which counters etc. should be in the RPL code > would already be a big plus. If people can ship the data more > efficiently or more comfortably over CoAP and there is no need to > integrate with SNMP-based tools, fine. > > /js > > On Tue, Sep 03, 2013 at 02:12:55PM +0000, Turner, Randy wrote: > > Yes, you can separate the usage of the MIB data model within a device > from the SNMP protocol used to transport it -- however, there should be > a very good reason for doing this. I think it might be possible to > "profile" SNMPv3 in such a way as to make it more attractive to > constrained devices. > > Randy > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Juergen Schoenwaelder > Sent: Tuesday, September 03, 2013 9:46 AM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] RPL MIB > > Hi, > > the key is to find agreement which counters etc. are relevant to > instrument in the RPL code. Whether one provides access to these > counters via SNMP or some other means may depends on the specific > constraints of the device and the deployment target. > > A MIB module is a way to define what needs to be instrumented and, as a > side effect, it of course works well with SNMP as an access mechanism. > But this does not exclude other access mechanism from being used > instead. > > /js > > On Tue, Sep 03, 2013 at 01:34:16PM +0000, Turner, Randy wrote: > > > > There is an expired draft for an RPL MIB that I think is a good start...that doesn't seem to violate the spirit of what is being proposed below. > > > > So it doesn't appear that this would be a "from scratch" effort. > > > > The data model suggested by the expired draft offers some good ideas, much of it I think is quite usable and valuable. > > > > There remains a "non-data-related" aspect of management in an LLN, which might suggest that there are some endpoint devices that are too constrained to support something like an SNMP agent. While that maybe true, I believe the more constrained a device is in functionality and capability, the less likely I may want to actively (pro-actively) manage such an endpoint. > > > > Randy > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of JP Vasseur (jvasseur) > > Sent: Tuesday, September 03, 2013 3:45 AM > > To: Adrian Farrel; Routing Over Low power and Lossy networks > > Subject: Re: [Roll] RPL MIB > > > > Typo "I cannot agree MORE" ;-) > > > > On Sep 3, 2013, at 8:20 AM, JP Vasseur (jvasseur) wrote: > > > > > Hi, > > > > > > I cannot agree, adding some thoughts: of course, we would need to > > > think very careful on where such a management MIB would be run and > > > the framework should cover some of the required workflow. Indeed, > > > running a RPL MIB on a router would make total sense, but may be > > > simply not possible on a low-end node (due to memory but also bandwidth constraint), and this is where we would need to sync up with CORE. > > > > > > Cheers. > > > > > > JP. > > > > > > On Sep 2, 2013, at 12:31 PM, Adrian Farrel wrote: > > > > > >> Hi, > > >> > > >> In this context it might make a lot of sense for some work to be > > >> done on a "management framework for RPL devices". > > >> > > >> What needs to be configurable? What protocol needs to be visible? > > >> What information is needed for diagnostics? What alarms/alerts > > >> are needed? What are the implications of storing logs? What are > > >> the implications of sending unsolicited notifications and/or of > > >> responding to status queries? What protocols are appropriate? > > >> > > >> This would lead to an Information model, which might in time lead > > >> to a data model. > > >> > > >> It is definitely also worth coordinating with CORE to see what > > >> they think about higher layer protocols to constrained devices. > > >> > > >> Cheers, > > >> Adrian > > >> > > >>> -----Original Message----- > > >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > > >>> Behalf Of > > >> Michael > > >>> Richardson > > >>> Sent: 30 August 2013 18:52 > > >>> To: Routing Over Low power and Lossy networks > > >>> Subject: Re: [Roll] RPL MIB > > >>> > > >>> > > >>> Turner, Randy wrote: > > >>>> On the IETF ROLL WG page, I was looking for a current (not > > >>>> expired) version of the RPL MIB draft, but there doesn?t appear to be one. > > >>> > > >>> It likely expired. > > >>> > > >>> http://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib/ > > >>> > > >>>> Can someone let me know what the status of this work is ? > > >>> > > >>> The WG has discussed this question a few times and has not > > >>> reached any consensus. > > >>> > > >>> Here is the summary: > > >>> > > >>> 1) many feel that an **SNMP** Agent is not going to fit into > > >>> constrained > > >> devices. > > >>> 2) Jurgen has demonstrated it does fit into a class 2 device on > > >>> using Contiki. > > >>> 3) others have pointed out that SNMP is not the only way to deal > > >>> with a MIB, and the important things in a MIB is the set of > > >>> statistics which one might collect, and transmit in *some* way. > > >>> 4) opinions have ranged from HTTP / CoAP to NetCONF/YANG as > > >>> other transport alternatives to SNMP. > > >>> > > >>> I think that it is simply early for many people to talk about > > >>> having consistent sets of statistics... BUT. PLEASE FEEL FREE TO PROVE ME WRONG. > > >>> > > >>> In particular, I think that *some* standard way to get the > > >>> network adjacency matrix (as well as the DODAG) out of motes > > >>> would be very useful for network operators. > > >>> > > >>> -- > > >>> Michael Richardson , Sandelman Software Works > > >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > >> > > >> > > >> _______________________________________________ > > >> Roll mailing list > > >> Roll@ietf.org > > >> https://www.ietf.org/mailman/listinfo/roll > > > > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > > > This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you. > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > 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 Randy.Turner@landisgyr.com Wed Sep 4 07:42:11 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F71621E80B7 for ; Wed, 4 Sep 2013 07:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8c20ZSEYQGk for ; Wed, 4 Sep 2013 07:42:07 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0075.outbound.protection.outlook.com [213.199.154.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6BB21E809E for ; Wed, 4 Sep 2013 07:42:05 -0700 (PDT) Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com (10.255.176.37) by DBXPR01MB016.eurprd01.prod.exchangelabs.com (10.255.176.38) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 4 Sep 2013 14:42:02 +0000 Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.103]) by DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.103]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 14:42:02 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] RPL MIB Thread-Index: Ac6logq3/vh0oGNlTpWt+jWe8hDnVgAB4uWAAIeAkAAAKYLDgAAC8/AAAAwTpDAAAIlLgAAA4LzwAAXzLIAAAH2BMAAiTFOAAAp9VAA= Date: Wed, 4 Sep 2013 14:42:01 +0000 Message-ID: <45d66460c0004f10b6455dd372bc311e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> References: <23397.1377885103@sandelman.ca> <0b7a01cea7c7$9b1b2120$d1516360$@olddog.co.uk> <03B78081B371D44390ED6E7BADBB4A77237657C9@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77237682C3@xmb-rcd-x02.cisco.com> <866c54ef240c43f296e2f066b85134bf@DBXPR01MB015.eurprd01.prod.exchangelabs.com> <20130903134551.GD48413@elstar.local> <20130903170121.GB51228@elstar.local> <32f4fd11890c1bb17078dbdede004ec3@xs4all.nl> In-Reply-To: <32f4fd11890c1bb17078dbdede004ec3@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [148.80.255.144] x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(24454002)(13464003)(52044002)(51444003)(52314003)(189002)(199002)(51704005)(377424004)(81542001)(50986001)(49866001)(51856001)(47736001)(19580395003)(54356001)(47976001)(83322001)(19580405001)(4396001)(54316002)(56776001)(31966008)(63696002)(79102001)(77982001)(59766001)(47446002)(76482001)(74662001)(74502001)(46102001)(83072001)(80976001)(15202345003)(81342001)(53806001)(56816003)(77096001)(66066001)(80022001)(65816001)(69226001)(74316001)(74876001)(76786001)(76796001)(74706001)(74366001)(33646001)(15975445006)(81686001)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR01MB016; H:DBXPR01MB015.eurprd01.prod.exchangelabs.com; CLIP:148.80.255.144; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Subject: Re: [Roll] RPL MIB X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 14:42:11 -0000 Hi Peter, Yes, the eventual model may be that there is an SNMP proxy on a less-resou= rce-constrained DODAG root device, which proxies SNMP operations (and notif= ications) between head-end management stations and endpoint devices on the = LLN. The protocol that is proxied "to" could be CoAP, or something else, b= ut I would try to avoid creating something new. My first attempt would be = to somehow "profile" SNMPv3 "as is" (no proxy), and if that is too much for= an endpoint (or LLN), then move to other proxy methods. Randy -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of pet= er van der Stok Sent: Wednesday, September 04, 2013 5:37 AM To: roll@ietf.org Subject: Re: [Roll] RPL MIB Hi Randy, excellent idea to look at a MIB for RPL, RPL-P2P, and MPL. I hope you will = also include the parameters that need initialization, like: k, c, Imin, DIOIntervalMin, DIOIntervalDoublings, etc. I agree fully with the reuse of the existing MIB base also for low resource= devices. The separation between SNMP and MIB is nicely described in RFC 3410. I don't see people changing their existing SNMP installed base, but I get r= equests to look at a CoAP interface to the MIBs for the small devices. I have been working on a CoAP interface to the MIBs, called CoMI (CoAP Mana= gement Interface). I expect to publish a second, much improved, more focussed, draft the comin= g weeks. According to me the advantages are: One programming interface for managemen= t and other applications and the subsequent reduction in stack complexity, = reduction of security complexity as proposed during the DICE BoF will follo= w automatically with CoAP updates, use of resource discovery will come for = free, possible use of multicast to initialize variables to a group of devic= es. Disadvantages are: a different approach to the multi packet transport, and = a different approach to passing through the lexicographically ordered list = of data. This list of (dis)advantages still needs to be validated. Greetings, Peter van der Stok Turner, Randy schreef op 2013-09-03 19:23: > Agreed, if they already have COAP in the box, then there's an=20 > incentive to reuse it as much as possible -- but if they don't, there=20 > are a multitude of existing network management infrastructures that=20 > utilize SNMP managers -- this infrastructure could be reused -- I'm=20 > not aware of any NMS vendors looking at adapting anything new on the=20 > protocol front (except possibly NETCONF, which has its' own=20 > implications for constrained devices). I'm happy to be proved wrong=20 > here :) >=20 > At the end of the day, I would like to reuse existing SNMP management=20 > infrastructure as much as possible, but I'm not opposed to using=20 > something else to transport the management information, if need be. >=20 > I think we're going to want to secure the network management traffic=20 > regardless of transport, so I'm assuming crypto overhead is "sunk=20 > cost", meaning it's going to be there. >=20 > If there is consensus in the WG, I would like to "restart" the MIB and=20 > associated management effort, with of course input from other=20 > interested parties (CORE, etc.) >=20 > R. >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Juergen Schoenwaelder > Sent: Tuesday, September 03, 2013 1:01 PM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] RPL MIB >=20 > Randy, >=20 > we have done a detailed analysis of our SNMP stack implemented on=20 > Contiki. SNMP itself is not a resource hog (actually no surprise given=20 > that SNMP was designed in the 80s). If you do crypto in software, then=20 > the crypto code is the killer in size and (depending on the platform)=20 > in performance. But this applies equally well to DTLS as long as you=20 > can't exploit hardware crypto and you use off-the-shelf cryto=20 > algorithms. >=20 > Anyway, having agreement which counters etc. should be in the RPL code=20 > would already be a big plus. If people can ship the data more=20 > efficiently or more comfortably over CoAP and there is no need to=20 > integrate with SNMP-based tools, fine. >=20 > /js >=20 > On Tue, Sep 03, 2013 at 02:12:55PM +0000, Turner, Randy wrote: >=20 > Yes, you can separate the usage of the MIB data model within a device=20 > from the SNMP protocol used to transport it -- however, there should=20 > be a very good reason for doing this. I think it might be possible to=20 > "profile" SNMPv3 in such a way as to make it more attractive to=20 > constrained devices. >=20 > Randy >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Juergen Schoenwaelder > Sent: Tuesday, September 03, 2013 9:46 AM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] RPL MIB >=20 > Hi, >=20 > the key is to find agreement which counters etc. are relevant to=20 > instrument in the RPL code. Whether one provides access to these=20 > counters via SNMP or some other means may depends on the specific=20 > constraints of the device and the deployment target. >=20 > A MIB module is a way to define what needs to be instrumented and, as=20 > a side effect, it of course works well with SNMP as an access mechanism. > But this does not exclude other access mechanism from being used=20 > instead. >=20 > /js >=20 > On Tue, Sep 03, 2013 at 01:34:16PM +0000, Turner, Randy wrote: > > > > There is an expired draft for an RPL MIB that I think is a good start.= ..that doesn't seem to violate the spirit of what is being proposed below. > > > > So it doesn't appear that this would be a "from scratch" effort. > > > > The data model suggested by the expired draft offers some good ideas, m= uch of it I think is quite usable and valuable. > > > > There remains a "non-data-related" aspect of management in an LLN, whic= h might suggest that there are some endpoint devices that are too constrain= ed to support something like an SNMP agent. While that maybe true, I beli= eve the more constrained a device is in functionality and capability, the l= ess likely I may want to actively (pro-actively) manage such an endpoint. > > > > Randy > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > > Of JP Vasseur (jvasseur) > > Sent: Tuesday, September 03, 2013 3:45 AM > > To: Adrian Farrel; Routing Over Low power and Lossy networks > > Subject: Re: [Roll] RPL MIB > > > > Typo "I cannot agree MORE" ;-) > > > > On Sep 3, 2013, at 8:20 AM, JP Vasseur (jvasseur) = wrote: > > > > > Hi, > > > > > > I cannot agree, adding some thoughts: of course, we would need to=20 > > > think very careful on where such a management MIB would be run and=20 > > > the framework should cover some of the required workflow. Indeed,=20 > > > running a RPL MIB on a router would make total sense, but may be=20 > > > simply not possible on a low-end node (due to memory but also bandwid= th constraint), and this is where we would need to sync up with CORE. > > > > > > Cheers. > > > > > > JP. > > > > > > On Sep 2, 2013, at 12:31 PM, Adrian Farrel wrot= e: > > > > > >> Hi, > > >> > > >> In this context it might make a lot of sense for some work to be=20 > > >> done on a "management framework for RPL devices". > > >> > > >> What needs to be configurable? What protocol needs to be visible? > > >> What information is needed for diagnostics? What alarms/alerts=20 > > >> are needed? What are the implications of storing logs? What are=20 > > >> the implications of sending unsolicited notifications and/or of=20 > > >> responding to status queries? What protocols are appropriate? > > >> > > >> This would lead to an Information model, which might in time lead=20 > > >> to a data model. > > >> > > >> It is definitely also worth coordinating with CORE to see what=20 > > >> they think about higher layer protocols to constrained devices. > > >> > > >> Cheers, > > >> Adrian > > >> > > >>> -----Original Message----- > > >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > > >>> Behalf Of > > >> Michael > > >>> Richardson > > >>> Sent: 30 August 2013 18:52 > > >>> To: Routing Over Low power and Lossy networks > > >>> Subject: Re: [Roll] RPL MIB > > >>> > > >>> > > >>> Turner, Randy wrote: > > >>>> On the IETF ROLL WG page, I was looking for a current (not > > >>>> expired) version of the RPL MIB draft, but there doesn?t appear to= be one. > > >>> > > >>> It likely expired. > > >>> > > >>> http://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib/ > > >>> > > >>>> Can someone let me know what the status of this work is ? > > >>> > > >>> The WG has discussed this question a few times and has not=20 > > >>> reached any consensus. > > >>> > > >>> Here is the summary: > > >>> > > >>> 1) many feel that an **SNMP** Agent is not going to fit into=20 > > >>> constrained > > >> devices. > > >>> 2) Jurgen has demonstrated it does fit into a class 2 device on=20 > > >>> using Contiki. > > >>> 3) others have pointed out that SNMP is not the only way to deal=20 > > >>> with a MIB, and the important things in a MIB is the set of=20 > > >>> statistics which one might collect, and transmit in *some* way. > > >>> 4) opinions have ranged from HTTP / CoAP to NetCONF/YANG as=20 > > >>> other transport alternatives to SNMP. > > >>> > > >>> I think that it is simply early for many people to talk about=20 > > >>> having consistent sets of statistics... BUT. PLEASE FEEL FREE TO PR= OVE ME WRONG. > > >>> > > >>> In particular, I think that *some* standard way to get the=20 > > >>> network adjacency matrix (as well as the DODAG) out of motes=20 > > >>> would be very useful for network operators. > > >>> > > >>> -- > > >>> Michael Richardson , Sandelman Software Work= s > > >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/chart= er/ > > >> > > >> > > >> _______________________________________________ > > >> Roll mailing list > > >> Roll@ietf.org > > >> https://www.ietf.org/mailman/listinfo/roll > > > > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > > > This e-mail (including any attachments) is confidential and may be lega= lly privileged. If you are not an intended recipient or an authorized repre= sentative of an intended recipient, you are prohibited from using, copying = or distributing the information in this e-mail or its attachments. If you h= ave received this e-mail in error, please notify the sender immediately by = return e-mail and delete all copies of this message and any attachments. Th= ank you. > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From trac+roll@trac.tools.ietf.org Wed Sep 4 12:29:02 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2A421E80E1 for ; Wed, 4 Sep 2013 12:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y50nNy3i+Q7 for ; Wed, 4 Sep 2013 12:29:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 83EE921E80EA for ; Wed, 4 Sep 2013 12:29:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:40966 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VHIl4-0003ll-WF; Wed, 04 Sep 2013 21:28:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Wed, 04 Sep 2013 19:28:54 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/132#comment:4 Message-ID: <082.2575e3eac69ef4a48e17c74e124d5f4e@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 19:29:02 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Changes (by mcr@sandelman.ca): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: closed Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Sep 4 12:29:15 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011AF21E80FB for ; Wed, 4 Sep 2013 12:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1z6Dyk9238NB for ; Wed, 4 Sep 2013 12:29:14 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D377F21E8136 for ; Wed, 4 Sep 2013 12:29:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:40971 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VHIlJ-0003lz-DH; Wed, 04 Sep 2013 21:29:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Wed, 04 Sep 2013 19:29:09 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/131#comment:2 Message-ID: <082.18f60c37cde8e00cbc930da771eaaeed@trac.tools.ietf.org> References: <067.e4de15ce80832e02dc4336e884c41db0@trac.tools.ietf.org> X-Trac-Ticket-ID: 131 In-Reply-To: <067.e4de15ce80832e02dc4336e884c41db0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #131: draft-ietf-roll-trickle-mcast-04 - Parameter-IMAX-equal-to-IMIX X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 19:29:15 -0000 #131: draft-ietf-roll-trickle-mcast-04 - Parameter-IMAX-equal-to-IMIX Changes (by mcr@sandelman.ca): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: closed Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Sep 4 12:29:20 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B4321E8153 for ; Wed, 4 Sep 2013 12:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBaUUXYDW1K5 for ; Wed, 4 Sep 2013 12:29:19 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6691A21E8151 for ; Wed, 4 Sep 2013 12:29:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:40976 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VHIlR-0003m7-2s; Wed, 04 Sep 2013 21:29:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Wed, 04 Sep 2013 19:29:17 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/130#comment:2 Message-ID: <082.82e9fe33c7b5c1a94507d27e4f3469ae@trac.tools.ietf.org> References: <067.0d5d0fe70fe1dd4413131ee8d5d0a3ce@trac.tools.ietf.org> X-Trac-Ticket-ID: 130 In-Reply-To: <067.0d5d0fe70fe1dd4413131ee8d5d0a3ce@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #130: draft-ietf-roll-trickle-mcast-04 - meaning of DATA_MESSAGE_TIMER_EXPIRATIONS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 19:29:20 -0000 #130: draft-ietf-roll-trickle-mcast-04 - meaning of DATA_MESSAGE_TIMER_EXPIRATIONS Changes (by mcr@sandelman.ca): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: closed Priority: minor | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Sep 4 12:29:33 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6CD21E8161 for ; Wed, 4 Sep 2013 12:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QQiFz2UUVFT for ; Wed, 4 Sep 2013 12:29:32 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BAAAB21E80E1 for ; Wed, 4 Sep 2013 12:29:32 -0700 (PDT) Received: from localhost ([127.0.0.1]:40981 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VHIle-0003mF-3W; Wed, 04 Sep 2013 21:29:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, rdroms@cisco.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Wed, 04 Sep 2013 19:29:30 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/129#comment:4 Message-ID: <082.60b5cc48f04af3330a8be07fdc414919@trac.tools.ietf.org> References: <067.eb8cd06a193daa93167f1567d59337cc@trac.tools.ietf.org> X-Trac-Ticket-ID: 129 In-Reply-To: <067.eb8cd06a193daa93167f1567d59337cc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, rdroms@cisco.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #129: draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwarding should be mutually exclusive within the same MPL Domain? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 19:29:33 -0000 #129: draft-ietf-roll-trickle-mcast-04 - Proactive and Reactive Forwarding should be mutually exclusive within the same MPL Domain? Changes (by mcr@sandelman.ca): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: closed Priority: minor | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Sep 4 12:29:43 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E57721E8169 for ; Wed, 4 Sep 2013 12:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6tYCKv5MJzS for ; Wed, 4 Sep 2013 12:29:42 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE4B21E8161 for ; Wed, 4 Sep 2013 12:29:42 -0700 (PDT) Received: from localhost ([127.0.0.1]:40986 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VHIlo-0003mN-9w; Wed, 04 Sep 2013 21:29:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Wed, 04 Sep 2013 19:29:40 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/127#comment:5 Message-ID: <082.2ef3ec41320f15d2e0ba27b061c18680@trac.tools.ietf.org> References: <067.187eacba7e92c2802d1ec6182a5ccc87@trac.tools.ietf.org> X-Trac-Ticket-ID: 127 In-Reply-To: <067.187eacba7e92c2802d1ec6182a5ccc87@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #127: Editorial Comments for draft-ietf-roll-trickle-mcast-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 19:29:43 -0000 #127: Editorial Comments for draft-ietf-roll-trickle-mcast-04 Changes (by mcr@sandelman.ca): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: closed Priority: minor | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From mcr@sandelman.ca Wed Sep 4 12:45:35 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A798D11E81E9 for ; Wed, 4 Sep 2013 12:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhLyC9xLBZzv for ; Wed, 4 Sep 2013 12:45:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB3111E81E8 for ; Wed, 4 Sep 2013 12:45:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A5A9B202C5 for ; Wed, 4 Sep 2013 16:53:37 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0B72063AF0; Wed, 4 Sep 2013 15:45:30 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F09F863848 for ; Wed, 4 Sep 2013 15:45:30 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 19:45:35 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable A number of issues were raised this past spring by IESG and other reviewers on draft-ietf-roll-trickle-mcast. You can review them using the custom que= ry: http://trac.tools.ietf.org/wg/roll/trac/query?status=3Dassigned&status=3Dcl= osed&status=3Dnew&status=3Dreopened&component=3Dtrickle-mcast&group=3Dcompo= nent&col=3Did&col=3Dsummary&col=3Dcomponent&col=3Dstatus&col=3Dtype&col=3Dp= riority&col=3Dmilestone&order=3Dpriority The chairs, Document Shephard and Document Authors believe that current issues are closed in the -05 revision at: https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ A diff is available at: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-roll-trickle-mcast-04= &difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-roll-trickle-mcast-05 We are starting another WG Last Call. It will run until Friday 2013-09-13 at 9am EST. Please read the document. Do you concur that it is done?=20=20 Please post any and all comments.=20=20 If there is something you do not like, please provide a suggestion (a diff) about what to fix. Thank you. Michael and JP. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUieN2oqHRg3pndX9AQISiwP/dBx9TNG/znT7RElWWKmQi/RIHeH/VHb5 CdwqtTRBI7fnzV+oq9mp6qoRulsjjnnlN5fPJ4xnEHqwWU8tflIr0z6bKHMYNi/a n3//VR9aJGn7ZdBo0nmlcBqNQB3PEJION+Aarqnf7xUau4NnkFMoSxMi7ttM4FtA HdlJUCZ1pRs= =kr/z -----END PGP SIGNATURE----- --=-=-=-- From trac+roll@trac.tools.ietf.org Wed Sep 4 18:14:39 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B78111E8222 for ; Wed, 4 Sep 2013 18:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiuzQfAAMqRW for ; Wed, 4 Sep 2013 18:14:38 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2B04711E8150 for ; Wed, 4 Sep 2013 18:14:33 -0700 (PDT) Received: from localhost ([127.0.0.1]:37352 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VHO9Q-0007Un-I0; Thu, 05 Sep 2013 03:14:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 05 Sep 2013 01:14:24 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/117#comment:4 Message-ID: <082.ecffe9a807fbb075d085040be0873e96@trac.tools.ietf.org> References: <067.2ab3aa03f106c42294a1c316eb2b7bc0@trac.tools.ietf.org> X-Trac-Ticket-ID: 117 In-Reply-To: <067.2ab3aa03f106c42294a1c316eb2b7bc0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tzeta.tsao@cooperindustries.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #117: draft-ietf-roll-security-threats-01.txt --- Verify/include references X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 01:14:39 -0000 #117: draft-ietf-roll-security-threats-01.txt --- Verify/include references Changes (by mcr@sandelman.ca): * status: new => closed * resolution: => fixed Comment: Acted on 5.2.3 change in -04. Acted on 6.4 change in -04. Will not add reference to BGP correct operation papers: I do not think it will make the document clearer or more complete. -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | tzeta.tsao@cooperindustries.com Type: defect | Status: closed Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Sep 4 18:15:11 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA11111E822B for ; Wed, 4 Sep 2013 18:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAXUrea41bnG for ; Wed, 4 Sep 2013 18:15:10 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E1DDE11E8150 for ; Wed, 4 Sep 2013 18:15:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:37452 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VHOA6-0003bd-Gu; Thu, 05 Sep 2013 03:15:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Thu, 05 Sep 2013 01:15:06 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/115#comment:4 Message-ID: <082.6b560b2b8f9273be142ee05b47c5ac18@trac.tools.ietf.org> References: <067.b8704d3db60284c62fffde3d26abf9e1@trac.tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <067.b8704d3db60284c62fffde3d26abf9e1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #115: draft-ietf-roll-security-threats-01.txt --- Editorial Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 01:15:11 -0000 #115: draft-ietf-roll-security-threats-01.txt --- Editorial Comments Changes (by mcr@sandelman.ca): * owner: tzeta.tsao@cooperindustries.com => mcr@sandelman.ca * status: new => assigned -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: assigned Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: Editorial | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Sep 4 18:15:41 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531A811E8225 for ; Wed, 4 Sep 2013 18:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf1BMnr8XdI9 for ; Wed, 4 Sep 2013 18:15:40 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 772FD11E822F for ; Wed, 4 Sep 2013 18:15:38 -0700 (PDT) Received: from localhost ([127.0.0.1]:37479 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VHOAP-0000cc-9i; Thu, 05 Sep 2013 03:15:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Thu, 05 Sep 2013 01:15:25 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/116#comment:3 Message-ID: <082.aa48a58c4cfbb70c1d0d5350df8c9795@trac.tools.ietf.org> References: <067.d6cfe14f83c6ca306e7f0311d9ee1435@trac.tools.ietf.org> X-Trac-Ticket-ID: 116 In-Reply-To: <067.d6cfe14f83c6ca306e7f0311d9ee1435@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #116: draft-ietf-roll-security-threats-01.txt --- Include/fix/verify definitions/terms X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 01:15:41 -0000 #116: draft-ietf-roll-security-threats-01.txt --- Include/fix/verify definitions/terms Changes (by mcr@sandelman.ca): * owner: tzeta.tsao@cooperindustries.com => mcr@sandelman.ca * status: new => assigned -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: assigned Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Sep 4 18:15:55 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011BD11E8225 for ; Wed, 4 Sep 2013 18:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDrg+12V682s for ; Wed, 4 Sep 2013 18:15:53 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C9AF711E8234 for ; Wed, 4 Sep 2013 18:15:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:37495 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VHOAm-0008IU-6z; Thu, 05 Sep 2013 03:15:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Thu, 05 Sep 2013 01:15:47 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/119#comment:4 Message-ID: <082.dccb4ee5fa33c0b8e8583c63ff67c17c@trac.tools.ietf.org> References: <067.8571ad6f4d633472ef48478791cc6332@trac.tools.ietf.org> X-Trac-Ticket-ID: 119 In-Reply-To: <067.8571ad6f4d633472ef48478791cc6332@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #119: draft-ietf-roll-security-threats-01.txt --- Verify abstraction/superficial terms X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 01:15:55 -0000 #119: draft-ietf-roll-security-threats-01.txt --- Verify abstraction/superficial terms Changes (by mcr@sandelman.ca): * owner: tzeta.tsao@cooperindustries.com => mcr@sandelman.ca * status: new => assigned -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: assigned Priority: minor | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Sep 4 18:16:09 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0DA11E8232 for ; Wed, 4 Sep 2013 18:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFY4EAtxC6CY for ; Wed, 4 Sep 2013 18:16:09 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 385F611E8230 for ; Wed, 4 Sep 2013 18:16:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:37501 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VHOB4-0006JD-Ro; Thu, 05 Sep 2013 03:16:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Thu, 05 Sep 2013 01:16:06 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/121#comment:3 Message-ID: <082.16e5816b921e7a4ee4ba4f957b615596@trac.tools.ietf.org> References: <067.966e013d1f392cdfd7a3db95de968ef6@trac.tools.ietf.org> X-Trac-Ticket-ID: 121 In-Reply-To: <067.966e013d1f392cdfd7a3db95de968ef6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #121: draft-ietf-roll-security-threats-01.txt --- Provide a pointer to the concept of control plane and specify it in the figure X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 01:16:09 -0000 #121: draft-ietf-roll-security-threats-01.txt --- Provide a pointer to the concept of control plane and specify it in the figure Changes (by mcr@sandelman.ca): * owner: tzeta.tsao@cooperindustries.com => mcr@sandelman.ca * status: new => assigned -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: assigned Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Sep 4 18:16:28 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D124911E822A for ; Wed, 4 Sep 2013 18:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUz2asphr4ml for ; Wed, 4 Sep 2013 18:16:28 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4F20511E8225 for ; Wed, 4 Sep 2013 18:16:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:37518 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VHOBN-0004eO-VK; Thu, 05 Sep 2013 03:16:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mcr@sandelman.ca, mariainesrobles@gmail.com X-Trac-Project: roll Date: Thu, 05 Sep 2013 01:16:25 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/125#comment:4 Message-ID: <082.c8b0c45203b048fe5045021e876da7f3@trac.tools.ietf.org> References: <067.b8a42ee3aa07b56a25c0575de68ce20e@trac.tools.ietf.org> X-Trac-Ticket-ID: 125 In-Reply-To: <067.b8a42ee3aa07b56a25c0575de68ce20e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mcr@sandelman.ca, mariainesrobles@gmail.com, tzeta.tsao@cooperindustries.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org, tzeta.tsao@cooperindustries.com Subject: Re: [Roll] [roll] #125: draft-ietf-roll-security-threats-01.txt --- Delete section/terms X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 01:16:29 -0000 #125: draft-ietf-roll-security-threats-01.txt --- Delete section/terms Changes (by mcr@sandelman.ca): * owner: tzeta.tsao@cooperindustries.com => mcr@sandelman.ca * status: new => assigned -- ---------------------------------------+------------------------------- Reporter: mariainesrobles@gmail.com | Owner: mcr@sandelman.ca Type: defect | Status: assigned Priority: major | Milestone: Component: security-threats | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------------+------------------------------- Ticket URL: roll From esko.dijk@philips.com Thu Sep 5 03:41:37 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B572121E80ED for ; Thu, 5 Sep 2013 03:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=1.377, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NmC3ur9Cdco for ; Thu, 5 Sep 2013 03:41:31 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC3A11E80D7 for ; Thu, 5 Sep 2013 03:41:27 -0700 (PDT) Received: from mail1-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 10:41:27 +0000 Received: from mail1-co1 (localhost [127.0.0.1]) by mail1-co1-R.bigfish.com (Postfix) with ESMTP id 0A40C8E037B; Thu, 5 Sep 2013 10:41:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz217bI15d6Oc85fh9251I168aJdd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h1de097h186068h8275dhz2dh2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail1-co1 (localhost.localdomain [127.0.0.1]) by mail1-co1 (MessageSwitch) id 1378377669276710_16537; Thu, 5 Sep 2013 10:41:09 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.248]) by mail1-co1.bigfish.com (Postfix) with ESMTP id 369A67E0274; Thu, 5 Sep 2013 10:41:09 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 10:41:08 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.104]) by 011-DB3MMR1-007.MGDPHG.emi.philips.com ([10.128.28.57]) with mapi id 14.03.0146.002; Thu, 5 Sep 2013 10:40:54 +0000 From: "Dijk, Esko" To: "Routing Over Low power and Lossy networks (roll@ietf.org)" Thread-Topic: trickle-mcast-05 - Need to explain role of Hop Limit field in Data Messages? Thread-Index: Ac6qHGykYd3Nz3ozQnaPJZyYIRvOEA== Date: Thu, 5 Sep 2013 10:40:53 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618D09393@011-DB3MPN2-083.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.104] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618D09393011DB3MPN2083MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "johui@cisco.com" Subject: [Roll] trickle-mcast-05 - Need to explain role of Hop Limit field in Data Messages? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 10:41:37 -0000 --_000_031DD135F9160444ABBE3B0C36CED618D09393011DB3MPN2083MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, reviewing the new trickle-mcast-05 draft, I wondered if there is a need to = explain a little more about the role/value of the Hop Limit field to be use= d in MPL Data Messages. Section 4 states delivery to *all* interfaces: The goal of MPL is to deliver multicast messages to all interfaces that subscribe to the multicast messages' destination address within an MPL Domain. I assume this can only be achieved with Hop Limit set sufficiently high (*)= by the Seed in a newly generated Data Message. However, how to set Hop Lim= it is not mentioned for Data Messages (only for Control Messages). So do we= need mention setting Hop Limit "high enough" for the specific MPL Domain? = Also I assume that by setting Hop Limit to a low value the effect can be ac= hieved that an MPL Data Message is only disseminated to a subset of an MPL = Domain. For me the reason to bring this up is that dealing with Hop Limit seems not= a trivial matter (considering e.g. the extensive prior discussion and diag= rams http://www.ietf.org/mail-archive/web/roll/current/msg07552.html) best regards, Esko (*) assuming the Hop Limit field in the (outer, non-encapsulated) IPv6 head= er is decremented by each successive MPL Forwarder ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED618D09393011DB3MPN2083MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

reviewing the new trickle-mcast-05 draft, I wondered= if there is a need to explain a little more about the role/value of the Ho= p Limit field to be used in MPL Data Messages.

 

Section 4 states delivery to *all* interfaces= :

  The goal of MPL is to deliver multicast messa= ges to all interfaces

   that subscribe to the multicast message= s' destination address within

   an MPL Domain.

 

I assume this can only be achieved with Hop Limit se= t sufficiently high (*) by the Seed in a newly generated Data Message. Howe= ver, how to set Hop Limit is not mentioned for Data Messages (only for Cont= rol Messages). So do we need mention setting Hop Limit “high enough” for the specific MPL Domain? A= lso I assume that by setting Hop Limit to a low value the effect can be ach= ieved that an MPL Data Message is only disseminated to a subset of an MPL D= omain.

 

For me the reason to bring this up is that dealing w= ith Hop Limit seems not a trivial matter (considering e.g. the extensive pr= ior discussion and diagrams http://www.ietf.org/mail-archive/web/roll/current/msg07552.html)

 

best regards,

 

Esko

 

(*) assuming the Hop Limit field in the (outer, non-= encapsulated) IPv6 header is decremented by each successive MPL Forwarder

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED618D09393011DB3MPN2083MGDP_-- From mcr@sandelman.ca Thu Sep 5 05:49:28 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7ED211E818B for ; Thu, 5 Sep 2013 05:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTGJr0rCmugj for ; Thu, 5 Sep 2013 05:49:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 03E9C21F85B8 for ; Thu, 5 Sep 2013 05:49:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 03B5520280; Thu, 5 Sep 2013 09:57:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9C8CB63AF0; Thu, 5 Sep 2013 08:49:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8A98863848; Thu, 5 Sep 2013 08:49:16 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <031DD135F9160444ABBE3B0C36CED618D09393@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618D09393@011-DB3MPN2-083.MGDPHG.emi.philips.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] trickle-mcast-05 - Need to explain role of Hop Limit field in Data Messages? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 12:49:29 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Dijk, Esko wrote: > Section 4 states delivery to *all* interfaces: > The goal of MPL is to deliver multicast messages to all interfaces > that subscribe to the multicast messages' destination address with= in > an MPL Domain. =20 > I assume this can only be achieved with Hop Limit set sufficiently hi= gh > (*) by the Seed in a newly generated Data Message. However, how to set > Hop Limit is not mentioned for Data Messages (only for Control Given that the MPL document can not predict the maximum rank of a deployed topology, whereas the applicability statements authors *can*, would it make sense to include a "Hop Limit range" question into the applicability statement for deployments that use MPL? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUih9yoqHRg3pndX9AQKpoQP/bjPuqS0A5z+sDQc3WdoNgHoTTUtqeH31 /nL7Otti0Lp0sJGbgcevJMh95CadSdfFmO1diXarVDX0hREg7jq0uMvjXKnY8fX/ JJt9HAPy08fMAh40EDTPi2Tk92kIAUf/CdyHQ9cPZzxt3DwYT37CBamhhJfezz4n EXPIlbz7a28= =bbSf -----END PGP SIGNATURE----- --=-=-=-- From internet-drafts@ietf.org Thu Sep 5 05:55:34 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF8D21E80BD; Thu, 5 Sep 2013 05:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t83zI7I1uTlW; Thu, 5 Sep 2013 05:55:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB46121E8090; Thu, 5 Sep 2013 05:55:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130905125508.25746.24075.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2013 05:55:08 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-security-threats-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 12:55:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : A Security Threat Analysis for Routing over Low-Power an= d Lossy Networks Author(s) : Tzeta Tsao Roger K. Alexander Mischa Dohler Vanesa Daza Angel Lozano Michael Richardson Filename : draft-ietf-roll-security-threats-04.txt Pages : 45 Date : 2013-09-04 Abstract: This document presents a security threat analysis 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. Applicable countermeasures are application specific and are addressed in relevant applicability statements. These assessments provide the basis of the security recommendations for incorporation into low-power, lossy network routing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-security-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-security-threats-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-security-threats-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From esko.dijk@philips.com Thu Sep 5 06:18:52 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E00311E8140 for ; Thu, 5 Sep 2013 06:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umOsu-A0jzzR for ; Thu, 5 Sep 2013 06:18:46 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id E3FC711E80DF for ; Thu, 5 Sep 2013 06:18:45 -0700 (PDT) Received: from mail216-db9-R.bigfish.com (10.174.16.240) by DB9EHSOBE037.bigfish.com (10.174.14.100) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 13:18:43 +0000 Received: from mail216-db9 (localhost [127.0.0.1]) by mail216-db9-R.bigfish.com (Postfix) with ESMTP id 8787260156; Thu, 5 Sep 2013 13:18:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -6 X-BigFish: VPS-6(zz217bI15d6O9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2dh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail216-db9 (localhost.localdomain [127.0.0.1]) by mail216-db9 (MessageSwitch) id 1378387120862624_17010; Thu, 5 Sep 2013 13:18:40 +0000 (UTC) Received: from DB9EHSMHS008.bigfish.com (unknown [10.174.16.230]) by mail216-db9.bigfish.com (Postfix) with ESMTP id CF585480046; Thu, 5 Sep 2013 13:18:40 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB9EHSMHS008.bigfish.com (10.174.14.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 13:18:38 +0000 Received: from 011-DB3MMR1-022.MGDPHG.emi.philips.com (10.128.28.105) by 011-DB3MMR1-009.MGDPHG.emi.philips.com (10.128.28.48) with Microsoft SMTP Server (TLS) id 14.3.146.2; Thu, 5 Sep 2013 13:17:54 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.104]) by 011-DB3MMR1-022.MGDPHG.emi.philips.com ([fe80::1113:17d7:70dc:6faa%11]) with mapi id 14.03.0146.002; Thu, 5 Sep 2013 13:17:54 +0000 From: "Dijk, Esko" To: Michael Richardson , Routing Over Low power and Lossy networks Thread-Topic: [Roll] trickle-mcast-05 - Need to explain role of Hop Limit field in Data Messages? Thread-Index: Ac6qHGykYd3Nz3ozQnaPJZyYIRvOEAAGeesAAAC4MHA= Date: Thu, 5 Sep 2013 13:17:53 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618D09637@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618D09393@011-DB3MPN2-083.MGDPHG.emi.philips.com> <519.1378385356@sandelman.ca> In-Reply-To: <519.1378385356@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Roll] trickle-mcast-05 - Need to explain role of Hop Limit field in Data Messages? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 13:18:52 -0000 > Given that the MPL document can not predict the maximum rank of a deploye= d topology, whereas the applicability statements authors *can*, would it ma= ke sense to include a "Hop Limit range" > question into the applicability statement for deployments that use MPL? Yes, I think so. It can also be advised to choose Hop Limit by default as h= igh as possible (255) to ensure propagation of the message throughout the M= PL domain. Lower Hop Limit values can then still be specified, but would ne= ed good arguments in the applicability statement why that is necessary/bene= ficial. The fact that Hop Limit can be chosen/tuned should be mentioned though in t= he MPL I-D. Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From robert.cragie@gridmerge.com Thu Sep 5 09:22:13 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9EB21E8125 for ; Thu, 5 Sep 2013 09:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AX3vEpRB4R7c for ; Thu, 5 Sep 2013 09:22:07 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 135D511E80E0 for ; Thu, 5 Sep 2013 09:21:53 -0700 (PDT) Received: from [94.116.154.196] (helo=[10.38.241.156]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1VHcJZ-0007Of-09 for roll@ietf.org; Thu, 05 Sep 2013 17:21:49 +0100 Message-ID: <5228AF9B.30805@gridmerge.com> Date: Thu, 05 Sep 2013 17:21:47 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: roll@ietf.org References: <031DD135F9160444ABBE3B0C36CED618D09393@011-DB3MPN2-083.MGDPHG.emi.philips.com> <519.1378385356@sandelman.ca> <031DD135F9160444ABBE3B0C36CED618D09637@011-DB3MPN2-083.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618D09637@011-DB3MPN2-083.MGDPHG.emi.philips.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020701070801040204050707" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] trickle-mcast-05 - Need to explain role of Hop Limit field in Data Messages? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 16:22:14 -0000 This is a cryptographically signed message in MIME format. --------------ms020701070801040204050707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I would suggest what might be appropriate is to leave the draft as is=20 but to consider drafting a template or specific applicability statement=20 for MPL, which will make it clear what needs to be in an applicability=20 statement. Robert On 05/09/2013 14:17, Dijk, Esko wrote: >> Given that the MPL document can not predict the maximum rank of a depl= oyed topology, whereas the applicability statements authors *can*, would = it make sense to include a "Hop Limit range" >> question into the applicability statement for deployments that use MPL= ? > Yes, I think so. It can also be advised to choose Hop Limit by default = as high as possible (255) to ensure propagation of the message throughout= the MPL domain. Lower Hop Limit values can then still be specified, but = would need good arguments in the applicability statement why that is nece= ssary/beneficial. > > The fact that Hop Limit can be chosen/tuned should be mentioned though = in the MPL I-D. > > Esko > > ________________________________ > The information contained in this message may be confidential and legal= ly protected under applicable law. The message is intended solely for the= addressee(s). If you are not the intended recipient, you are hereby noti= fied that any use, forwarding, dissemination, or reproduction of this mes= sage is strictly prohibited and may be unlawful. If you are not the inten= ded recipient, please contact the sender by return e-mail and destroy all= copies of the original message. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------ms020701070801040204050707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA5MDUxNjIxNDdaMCMGCSqGSIb3DQEJBDEWBBTVW9YcGAomAUF7W8beqDnxBPx4ajBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBADO1Jbxav93bsZExcHx1ivh0h+XUekE0vXDMSVRJIkI35v85 IAHYOkwC8f7DKO/HVW+wVlYHoHsNpF9n90TYEzZaoCewXFQQuxTGAQaIKWCb1TJkASEDoYev 9BtVVyCy5lEMmQvSKU69kb9BFCJzUhKUASrv20anSx4TXw4tI0dZYasisxmXDrK6H1X8qsR3 oXfRCM7B+biaNAxaqJzKc45O3baMU3R9NzqroQDgnz6ozcFbALPc1E10fgt1Fmilh4IZF7YE qUI7nl9GfxbIiFROqZmLC+pkPquC/zrKJXbzDfja2Blzn+2eBewK4GSVidnZeaDgroK6/NE7 f56Gd6QAAAAAAAA= --------------ms020701070801040204050707-- From jvasseur@cisco.com Sun Sep 8 05:15:56 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C9521F9DC7 for ; Sun, 8 Sep 2013 05:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YmJ+dFO3sYy for ; Sun, 8 Sep 2013 05:15:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7E80421F9D04 for ; Sun, 8 Sep 2013 05:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1984; q=dns/txt; s=iport; t=1378642538; x=1379852138; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=iGo86TdhV+x8VPkxj9Ix7z4M/96/4uQIZgOzid8frYU=; b=GrejnxIClWl0mW00rbjR66txj2kVpPhUR6cYn9HyDbdb2RxHssss31ju 8XbhdnrBS3SU+BJeUU6EeCROYMJs1hDXyGtoeVWcLMoyszvAuLEyIkhsl SmjYQ1P9m8VIJR5etBJ/N0vnYHi4v/KTYImvstDLSSO7ISgX9fk0f0SnA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFACppLFKtJXG+/2dsb2JhbABbgwc4UcIIgSQWdIIlAQEBAwEBAQFrEAsCAQgYCiQnCyUCBBMIh3QGDMY9BI5CBYEGAjiDHYEAA4h9oF6BY4E9gWkIFyI X-IronPort-AV: E=Sophos;i="4.90,864,1371081600"; d="scan'208";a="257106395" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 08 Sep 2013 12:15:38 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r88CFbAY001997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Sep 2013 12:15:37 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.35]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Sun, 8 Sep 2013 07:15:37 -0500 From: "JP Vasseur (jvasseur)" To: "" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] trickle-mcast-05 - Need to explain role of Hop Limit field in Data Messages? Thread-Index: AQHOrI0gNGntzh5Lb022bAXglwa25g== Date: Sun, 8 Sep 2013 12:15:37 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772379CCFC@xmb-rcd-x02.cisco.com> References: <031DD135F9160444ABBE3B0C36CED618D09393@011-DB3MPN2-083.MGDPHG.emi.philips.com> <519.1378385356@sandelman.ca> <031DD135F9160444ABBE3B0C36CED618D09637@011-DB3MPN2-083.MGDPHG.emi.philips.com> <5228AF9B.30805@gridmerge.com> In-Reply-To: <5228AF9B.30805@gridmerge.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.230] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9A7A537922AE2045A5326DF36F1F2CF4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] trickle-mcast-05 - Need to explain role of Hop Limit field in Data Messages? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 12:15:56 -0000 That seems to be a perfectly fine idea indeed. On Sep 5, 2013, at 6:21 PM, Robert Cragie wro= te: > I would suggest what might be appropriate is to leave the draft as is but= to consider drafting a template or specific applicability statement for MP= L, which will make it clear what needs to be in an applicability statement. >=20 > Robert >=20 > On 05/09/2013 14:17, Dijk, Esko wrote: >>> Given that the MPL document can not predict the maximum rank of a deplo= yed topology, whereas the applicability statements authors *can*, would it = make sense to include a "Hop Limit range" >>> question into the applicability statement for deployments that use MPL? >> Yes, I think so. It can also be advised to choose Hop Limit by default a= s high as possible (255) to ensure propagation of the message throughout th= e MPL domain. Lower Hop Limit values can then still be specified, but would= need good arguments in the applicability statement why that is necessary/b= eneficial. >>=20 >> The fact that Hop Limit can be chosen/tuned should be mentioned though i= n the MPL I-D. >>=20 >> Esko >>=20 >> ________________________________ >> The information contained in this message may be confidential and legall= y protected under applicable law. The message is intended solely for the ad= dressee(s). If you are not the intended recipient, you are hereby notified = that any use, forwarding, dissemination, or reproduction of this message is= strictly prohibited and may be unlawful. If you are not the intended recip= ient, please contact the sender by return e-mail and destroy all copies of = the original message. >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From internet-drafts@ietf.org Mon Sep 9 05:53:53 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D6721F9D3B; Mon, 9 Sep 2013 05:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyk1uyIcVzQM; Mon, 9 Sep 2013 05:53:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAF811E81DB; Mon, 9 Sep 2013 05:52:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130909125211.17011.61548.idtracker@ietfa.amsl.com> Date: Mon, 09 Sep 2013 05:52:11 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-rpl-industrial-applicability-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 12:53:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : RPL applicability in industrial networks Author(s) : Tom Phinney Pascal Thubert Robert Assimiti Filename : draft-ietf-roll-rpl-industrial-applicability-01.txt Pages : 31 Date : 2013-09-09 Abstract: The wide deployment of wireless devices, with their low installed cost (compared to wired devices), will significantly improve the productivity and safety of industrial plants. It will simultaneously increase the efficiency and safety of the plant's workers, by extending and making more timely the information set available about plant operations. The new Routing Protocol for Low Power and Lossy Networks (RPL) defines a Distance Vector protocol that is designed for such networks. The aim of this document is to analyze the applicability of that routing protocol in industrial LLNs formed of field devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-rpl-industrial-applicabili= ty There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-rpl-industrial-applicabi= lity-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From esko.dijk@philips.com Tue Sep 10 04:46:43 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83A221E811D for ; Tue, 10 Sep 2013 04:46:42 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41JFHIOKGzdj for ; Tue, 10 Sep 2013 04:46:36 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id CEA0E11E818E for ; Tue, 10 Sep 2013 04:46:27 -0700 (PDT) Received: from mail51-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE035.bigfish.com (10.243.66.100) with Microsoft SMTP Server id 14.1.225.22; Tue, 10 Sep 2013 11:46:26 +0000 Received: from mail51-co1 (localhost [127.0.0.1]) by mail51-co1-R.bigfish.com (Postfix) with ESMTP id C5A441C0134; Tue, 10 Sep 2013 11:46:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zzbb2dI217bI98dI15d6O9371I542I1432I9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz31iz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2dh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail51-co1 (localhost.localdomain [127.0.0.1]) by mail51-co1 (MessageSwitch) id 1378813585674747_5983; Tue, 10 Sep 2013 11:46:25 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.242]) by mail51-co1.bigfish.com (Postfix) with ESMTP id 973DEC0049; Tue, 10 Sep 2013 11:46:25 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 10 Sep 2013 11:46:25 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.104]) by 011-DB3MMR1-006.MGDPHG.emi.philips.com ([10.128.28.56]) with mapi id 14.03.0146.002; Tue, 10 Sep 2013 11:46:23 +0000 From: "Dijk, Esko" To: Routing Over Low power and Lossy networks , "" Thread-Topic: [Roll] trickle-mcast-05 - Need to explain role of Hop Limit field in Data Messages? Thread-Index: Ac6qHGykYd3Nz3ozQnaPJZyYIRvOEAAGeesAAAC4MHAABrPcgACORumAAGMSFrA= Date: Tue, 10 Sep 2013 11:46:22 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618D09C6C@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618D09393@011-DB3MPN2-083.MGDPHG.emi.philips.com> <519.1378385356@sandelman.ca> <031DD135F9160444ABBE3B0C36CED618D09637@011-DB3MPN2-083.MGDPHG.emi.philips.com> <5228AF9B.30805@gridmerge.com> <03B78081B371D44390ED6E7BADBB4A772379CCFC@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772379CCFC@xmb-rcd-x02.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Roll] trickle-mcast-05 - Need to explain role of Hop Limit field in Data Messages? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 11:46:43 -0000 That's ok for me - MPL and P2P-RPL are currently targeted to be in the ROL= L applicability statements. (See Michael's statement http://www.ietf.org/mail-archive/web/roll/current/= msg07816.html ; and practical use example in http://tools.ietf.org/html/dra= ft-ietf-roll-applicability-home-building-01#section-4.3.3 ) The template could still be updated to reflect MPL and P2P-RPL; however the= main action is to include a hop limit consideration into draft-ietf-roll-a= pplicability-home-building, right? Esko -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur (jvasseur) Sent: Sunday, September 08, 2013 14:16 To: ; Routing Over Low power and Lossy network= s Subject: Re: [Roll] trickle-mcast-05 - Need to explain role of Hop Limit fi= eld in Data Messages? That seems to be a perfectly fine idea indeed. On Sep 5, 2013, at 6:21 PM, Robert Cragie wro= te: > I would suggest what might be appropriate is to leave the draft as is but= to consider drafting a template or specific applicability statement for MP= L, which will make it clear what needs to be in an applicability statement. >=20 > Robert >=20 > On 05/09/2013 14:17, Dijk, Esko wrote: >>> Given that the MPL document can not predict the maximum rank of a deplo= yed topology, whereas the applicability statements authors *can*, would it = make sense to include a "Hop Limit range" >>> question into the applicability statement for deployments that use MPL? >> Yes, I think so. It can also be advised to choose Hop Limit by default a= s high as possible (255) to ensure propagation of the message throughout th= e MPL domain. Lower Hop Limit values can then still be specified, but would= need good arguments in the applicability statement why that is necessary/b= eneficial. >>=20 >> The fact that Hop Limit can be chosen/tuned should be mentioned though i= n the MPL I-D. >>=20 >> Esko >>=20 >> ________________________________ >> The information contained in this message may be confidential and legall= y protected under applicable law. The message is intended solely for the ad= dressee(s). If you are not the intended recipient, you are hereby notified = that any use, forwarding, dissemination, or reproduction of this message is= strictly prohibited and may be unlawful. If you are not the intended recip= ient, please contact the sender by return e-mail and destroy all copies of = the original message. >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From stokcons@xs4all.nl Tue Sep 10 05:24:18 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F86211E81A2 for ; Tue, 10 Sep 2013 05:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QaZldpwkFbo for ; Tue, 10 Sep 2013 05:24:13 -0700 (PDT) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3694711E8132 for ; Tue, 10 Sep 2013 05:24:10 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube11.xs4all.net [194.109.20.209]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id r8ACO9h2034364 for ; Tue, 10 Sep 2013 14:24:09 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-109-41.w90-0.abo.wanadoo.fr ([90.0.84.41]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 10 Sep 2013 14:24:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 10 Sep 2013 14:24:09 +0200 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <031DD135F9160444ABBE3B0C36CED618D09C6C@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618D09393@011-DB3MPN2-083.MGDPHG.emi.philips.com> <519.1378385356@sandelman.ca> <031DD135F9160444ABBE3B0C36CED618D09637@011-DB3MPN2-083.MGDPHG.emi.philips.com> <5228AF9B.30805@gridmerge.com> <03B78081B371D44390ED6E7BADBB4A772379CCFC@xmb-rcd-x02.cisco.com> <031DD135F9160444ABBE3B0C36CED618D09C6C@011-DB3MPN2-083.MGDPHG.emi.philips.com> Message-ID: <76f967f0318f08092433154444a819e1@xs4all.nl> X-Sender: stokcons@xs4all.nl (CL7G4pb6ROuuS4KFTgJeqHuv4eXCy53k) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] =?utf-8?q?trickle-mcast-05_-_Need_to_explain_role_of_Hop_L?= =?utf-8?q?imit_field_in_Data_Messages=3F?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 12:24:18 -0000 HI Esko, A statement about the applicability of hop limit will be put in home-building-01. This will be dome in relation to the existence of the MPL domain which often limits the transmission (reception) of the MPL messages. Peter Dijk, Esko schreef op 2013-09-10 13:46: > That's ok for me - MPL and P2P-RPL are currently targeted to be in > the ROLL applicability statements. > (See Michael's statement > http://www.ietf.org/mail-archive/web/roll/current/msg07816.html ; and > practical use example in > http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-01#section-4.3.3 > ) > > The template could still be updated to reflect MPL and P2P-RPL; > however the main action is to include a hop limit consideration into > draft-ietf-roll-applicability-home-building, right? > > Esko > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP Vasseur (jvasseur) > Sent: Sunday, September 08, 2013 14:16 > To: ; Routing Over Low power and Lossy > networks > Subject: Re: [Roll] trickle-mcast-05 - Need to explain role of Hop > Limit field in Data Messages? > > That seems to be a perfectly fine idea indeed. > > On Sep 5, 2013, at 6:21 PM, Robert Cragie > wrote: > > I would suggest what might be appropriate is to leave the draft as is > but to consider drafting a template or specific applicability statement > for MPL, which will make it clear what needs to be in an applicability > statement. > > Robert > > On 05/09/2013 14:17, Dijk, Esko wrote: > Given that the MPL document can not predict the maximum rank of a > deployed topology, whereas the applicability statements authors *can*, > would it make sense to include a "Hop Limit range" > question into the applicability statement for deployments that use MPL? > Yes, I think so. It can also be advised to choose Hop Limit by default > as high as possible (255) to ensure propagation of the message > throughout the MPL domain. Lower Hop Limit values can then still be > specified, but would need good arguments in the applicability statement > why that is necessary/beneficial. > > The fact that Hop Limit can be chosen/tuned should be mentioned though > in the MPL I-D. > > Esko > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From esko.dijk@philips.com Thu Sep 12 08:40:12 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811F221E80E5 for ; Thu, 12 Sep 2013 08:40:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEhFpLXXTmn8 for ; Thu, 12 Sep 2013 08:39:53 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id C10DF11E824F for ; Thu, 12 Sep 2013 08:39:31 -0700 (PDT) Received: from mail73-co9-R.bigfish.com (10.236.132.236) by CO9EHSOBE001.bigfish.com (10.236.130.64) with Microsoft SMTP Server id 14.1.225.22; Thu, 12 Sep 2013 15:39:30 +0000 Received: from mail73-co9 (localhost [127.0.0.1]) by mail73-co9-R.bigfish.com (Postfix) with ESMTP id C2D8D6013F for ; Thu, 12 Sep 2013 15:39:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -14 X-BigFish: VPS-14(zz217bI15d6O936eI542I9251Icfb8vdd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275dhz2dh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail73-co9 (localhost.localdomain [127.0.0.1]) by mail73-co9 (MessageSwitch) id 1379000368739529_7405; Thu, 12 Sep 2013 15:39:28 +0000 (UTC) Received: from CO9EHSMHS026.bigfish.com (unknown [10.236.132.241]) by mail73-co9.bigfish.com (Postfix) with ESMTP id B07E7340077 for ; Thu, 12 Sep 2013 15:39:28 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS026.bigfish.com (10.236.130.36) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 12 Sep 2013 15:39:28 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.104]) by 011-DB3MMR1-006.MGDPHG.emi.philips.com ([10.128.28.56]) with mapi id 14.03.0146.002; Thu, 12 Sep 2013 15:39:14 +0000 From: "Dijk, Esko" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 Thread-Index: AQHOqadY0aMmWd4AoUiz2UrJOd+aFJnCRkXw Date: Thu, 12 Sep 2013 15:39:14 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618016C26B4@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <20864.1378323930@sandelman.ca> In-Reply-To: <20864.1378323930@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.207.119.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:40:13 -0000 I have checked the changes in the draft w.r.t. version -04, and also the op= en tickets. In my view version -05 addresses all the open issues well; and I have no fu= rther comments. Thanks to the authors and all contributors for their good w= ork! regards, Esko -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mic= hael Richardson Sent: Wednesday, September 04, 2013 21:46 To: roll@ietf.org Subject: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mc= ast-05 A number of issues were raised this past spring by IESG and other reviewers= on draft-ietf-roll-trickle-mcast. You can review them using the custom qu= ery: http://trac.tools.ietf.org/wg/roll/trac/query?status=3Dassigned&status=3Dcl= osed&status=3Dnew&status=3Dreopened&component=3Dtrickle-mcast&group=3Dcompo= nent&col=3Did&col=3Dsummary&col=3Dcomponent&col=3Dstatus&col=3Dtype&col=3Dp= riority&col=3Dmilestone&order=3Dpriority The chairs, Document Shephard and Document Authors believe that current iss= ues are closed in the -05 revision at: https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ A diff is available at: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-roll-trickle-mcast-04= &difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-roll-trickle-mcast-05 We are starting another WG Last Call. It will run until Friday 2013-09-13 at 9am EST. Please read the document. Do you concur that it is done? Please post any and all comments. If there is something you do not like, please provide a suggestion (a diff)= about what to fix. Thank you. Michael and JP. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From gnawali@cs.uh.edu Thu Sep 12 23:15:43 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D424111E8144 for ; Thu, 12 Sep 2013 23:15:43 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1mhY62Fmxov for ; Thu, 12 Sep 2013 23:15:25 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id DBAC211E814C for ; Thu, 12 Sep 2013 23:15:24 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 47BD223CAA3 for ; Fri, 13 Sep 2013 01:15:24 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+H2+tNGhroC for ; Fri, 13 Sep 2013 01:15:18 -0500 (CDT) Received: from it.cs.uh.edu (unknown [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 866A023CA99 for ; Fri, 13 Sep 2013 01:15:18 -0500 (CDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by it.cs.uh.edu (Postfix) with ESMTP id BD3312A2809D for ; Fri, 13 Sep 2013 01:47:38 -0500 (CDT) Received: by mail-la0-f52.google.com with SMTP id ev20so626487lab.39 for ; Thu, 12 Sep 2013 23:15:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:from:date:message-id:subject:to:content-type; bh=st07OMoW4g6AQOTKPDi/bX7qVE81H+egk2W5rcJqmAg=; b=XijZ9KSCnKVfOmR53ZrRs5rBloIn7eMtDZI30ZWhMmSYqc+n/PaHLyBM2rDHqFk+g2 SKujCTDQzZTqYrxvxYusmfn7rdaRX+QxYk7EACF2a6CszvmahNPYAmP+iUVaYlnihklV GDac997lmKQVHuqP9o8gWwZyoedZYlGabJeeAuTDajZZNqu+/hIo6BGzPHEGnO0YUCjp bSzMt3JV98yh32ZsI91i0NRBowEDctpPJNevpaSaaKRND2P/SmHD267hiwjMW8VYvAYh JjdbkOnURWWY1EtaryGBm19tZGak5M/KL5m7FOuwdOg/inJcyYhPUEiodUfOCKQ6nyIT J8ng== X-Received: by 10.152.26.72 with SMTP id j8mr9520104lag.19.1379052916615; Thu, 12 Sep 2013 23:15:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.236.3 with HTTP; Thu, 12 Sep 2013 23:14:56 -0700 (PDT) From: Omprakash Gnawali Date: Fri, 13 Sep 2013 01:14:56 -0500 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] comments for draft-gnawali-roll-rpl-recommendations? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 06:15:44 -0000 Dear ROLL WG, I plan to update the draft-gnawali-roll-rpl-recommendations in the next day or two. I would love to hear about any new/old/usual/unusual experiences about RPL use so that I can collect those insights in this draft to benefit everyone in the community. Here is the URL to the current draft: http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-03 Thank you. - om_p From kerlyn2001@gmail.com Fri Sep 13 05:10:07 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278E821E8093 for ; Fri, 13 Sep 2013 05:10:07 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFEC0G3iwuGP for ; Fri, 13 Sep 2013 05:10:06 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 034F511E818D for ; Fri, 13 Sep 2013 05:10:05 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id uz6so999450obc.33 for ; Fri, 13 Sep 2013 05:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=004tX02L0LepeBN0875EbJcB7OW+MsjrDmBCpoXwOvM=; b=R15RLYBK0uUwpX1gTIAVz8vdrUzfTa9TBWNFB/WCfb3Ovk/zyfaXAvDtxItrRBpK4u gkr76LModyM/VYwpG13l+T+Gjz4zQJJcjUErZ9H0Xxk2jwwtiaF5IC879yF+x/rewZB4 kEDhCp2FqkrOWREsaM5FFfRdgbYHjZtQixMp5DZHZhTEnTN+W5iBVBAW0SIDKLc0t+R6 2sI7hiqkxQccQ23xXlZdaJ4LLD+5xDo9xATipb2AUbFHNTXhS1DTwF/a+alagHje02As /g1nFixMW/rWVPPZA/kNqvlLqrY28qFunQVkTB8kuzaNeqzFFgIQw0B2GSPvh4d2IqEC Gpug== MIME-Version: 1.0 X-Received: by 10.60.80.167 with SMTP id s7mr11839166oex.38.1379074204056; Fri, 13 Sep 2013 05:10:04 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.41.36 with HTTP; Fri, 13 Sep 2013 05:10:03 -0700 (PDT) In-Reply-To: <20864.1378323930@sandelman.ca> References: <20864.1378323930@sandelman.ca> Date: Fri, 13 Sep 2013 08:10:03 -0400 X-Google-Sender-Auth: ujbxfBraqhaOd9MmfwX0OTm9x98 Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e01228b140d40c304e642bc2f Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 12:10:07 -0000 --089e01228b140d40c304e642bc2f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson wrote: > > A number of issues were raised this past spring by IESG and other reviewers > on draft-ietf-roll-trickle-mcast. You can review them using the custom > query: > > > http://trac.tools.ietf.org/wg/roll/trac/query?status=assigned&status=closed&status=new&status=reopened&component=trickle-mcast&group=component&col=id&col=summary&col=component&col=status&col=type&col=priority&col=milestone&order=priority > > The chairs, Document Shephard and Document Authors believe that current > issues are closed in the -05 revision at: > https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ > A diff is available at: > > https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-trickle-mcast-04&difftype=--html&submit=Go%21&url2=draft-ietf-roll-trickle-mcast-05 > > We are starting another WG Last Call. > It will run until Friday 2013-09-13 at 9am EST. > > Please read the document. Do you concur that it is done? > Please post any and all comments. > The draft is looking good, but I have a few comments. Editorial: - In section 4.3, on Proactive Forwarding, the phrase "MPL Data Message message" is redundant and should be "MPL Data Message". - In the last paragraph of section 4.3 the phrase "a new MPL Data messages" should be "a new MPL Data Message". - [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 to 14.2. Technical: - I have argued that to increase MPL's applicability, PROACTIVE_FORWARDING should be a per-interface and not a per-forwarder setting. I can imagine, for example, a router that has both LLN and traditional interfaces and proactive forwarding seems unnecessary for the latter. As [RFC 4007] states: "Zone boundaries cut through nodes, not links." Suggested wording in section 5.4 could be "PROACTIVE_FORWARDING has a default value of TRUE on links where Realm-Local scope is defined, and FALSE otherwise." - Section 4.1 states: "When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL." This begs the question, why don't we just use scope = 0x04? We probably need more discussion on if and how a scope 0x03 zone boundary is automatically defined (i.e. without human intervention) and how forwarding works for scope 0x03. One suggested definition is that Realm-Local applies to links where a single interface may belong to multiple Link-Local scopes. - The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters described in section 5.5 will ultimately have to be expressed in units of time (either in this document or elsewhere) for a given link-layer in order to avoid the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The same reference states: "a protocol SHOULD set k and Imin such that Imin is at least two to three times as long as it takes to transmit k packets." Regards, -K- > If there is something you do not like, please provide a suggestion (a diff) > about what to fix. > > Thank you. > > Michael and JP. > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --089e01228b140d40c304e642bc2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson <m= cr+ietf@sandelman.ca> wrote:

A number of issues were raised this past spring by IESG and other reviewers=
on draft-ietf-roll-trickle-mcast. =A0You can review them using the custom q= uery:

http://trac.tools.ietf.org= /wg/roll/trac/query?status=3Dassigned&status=3Dclosed&status=3Dnew&= amp;status=3Dreopened&component=3Dtrickle-mcast&group=3Dcomponent&a= mp;col=3Did&col=3Dsummary&col=3Dcomponent&col=3Dstatus&col= =3Dtype&col=3Dpriority&col=3Dmilestone&order=3Dpriority

The chairs, Document Shephard and Document Authors believe that current
issues are closed in the -05 revision at:
=A0 =A0 =A0 =A0https://datatracker.ietf.org/doc/draft-ie= tf-roll-trickle-mcast/
A diff is available at:
=A0 =A0 =A0 =A0https://www.ietf.org/rfcdi= ff?url1=3Ddraft-ietf-roll-trickle-mcast-04&difftype=3D--html&submit= =3DGo%21&url2=3Ddraft-ietf-roll-trickle-mcast-05

We are starting another WG Last Call.
It will run until Friday 2013-09-13 at 9am EST.

Please read the document. =A0Do you concur that it is done?
Please post any and all comments.
=A0
The draft is looking good, but I have a few comments.<= br>
=A0
Editorial:

- In section 4.3, = on Proactive Forwarding, the phrase "MPL Data Message message"
=A0 is redundant and should be "MPL Data Message".
=
- In the last paragraph of section 4.3 the phrase "a ne= w MPL Data messages"
=A0 should be "a new MPL Data = Message".

- [I-D.droms-6man-multicast-scopes] should = be moved from section 14.1 to 14.2.


Technical:

- I have argued that to increase MPL's ap= plicability, PROACTIVE_FORWARDING
=A0 should be a per-interface and not a per-forwarder setting.= =A0 I can imagine, for
=A0 example, a router that has both LL= N and traditional interfaces and proactive
=A0 forwarding see= ms unnecessary for the latter.=A0 As [RFC 4007] states: "Zone
=A0 boundaries cut through nodes, not links."=A0 Suggested = wording in section 5.4
=A0 could be "PROACTIVE_FORWARDIN= G has a default value of TRUE on links
=A0 where Realm-Local = scope is defined, and FALSE otherwise."

- Section 4.1 states: "When used with MPL, R= ealm-Local scope is administratively
=A0 defined and used to = define the boundaries of multicast message dissemination
=A0 = by MPL."=A0 This begs the question, why don't we just use scope = =3D 0x04?=A0 We
=A0 probably need more discussion on if and how a scope 0x03 zon= e boundary
=A0 is automatically defined (i.e. without human i= ntervention) and how forwarding
=A0 works for scope 0x03.=A0 = One suggested definition is that Realm-Local applies
=A0 to links where a single interface may belong to multiple Lin= k-Local scopes.

- The DATA_MESSAGE_IMIN and CO= NTROL_MESSAGE_IMIN parameters
=A0 described in section 5.5 wi= ll ultimately have to be expressed in units of time
=A0 (either in this document or elsewhere) for a given link-laye= r in order to avoid
=A0 the "Mismatched min" issues discussed = in [RFC 6206, sect. 6.2].=A0 The same
=A0 reference states: "a prot= ocol SHOULD set k and Imin such that Imin is at least
=A0 two to three times as long as it takes to transmit k packets."
=

Regards, -K-

=A0
If there is something you do not like, please provide a suggestion (a diff)=
about what to fix.

Thank you.

Michael and JP.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair. =A0 =A0http://datatracker.ietf.org/wg/roll/charter/<= /a>


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


--089e01228b140d40c304e642bc2f-- From d.sturek@att.net Fri Sep 13 06:22:25 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063C321E80C2 for ; Fri, 13 Sep 2013 06:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fblKrJe5BKq9 for ; Fri, 13 Sep 2013 06:22:19 -0700 (PDT) Received: from nm21-vm10.access.bullet.mail.bf1.yahoo.com (nm21-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.137]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFD521E80AD for ; Fri, 13 Sep 2013 06:22:19 -0700 (PDT) Received: from [66.196.81.156] by nm21.access.bullet.mail.bf1.yahoo.com with NNFMP; 13 Sep 2013 13:22:17 -0000 Received: from [98.138.226.243] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 13 Sep 2013 13:22:17 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 13:22:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1379078537; bh=7nnXOT+3JGeo8bPD/MSO0Txh0ktPVcPGKypi0AN7AUU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=aj7Yeq66uBpu20pE1cVx/5JH8BEyOpEq8adUqhPuTvM3eplA4oMs/apwzCtRTUSDREz6UNxULN4Q1/vkvzTwQkVzBVgfa9UDCOvI+7ixjHzKohKPGd224PB4ywK35aDCJ1psKouBDvwYw1n625nvgqMsTvZAg8kM4TjhDO8XUg8= X-Yahoo-Newman-Id: 236643.37041.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: qI5jWJsVM1k0Rklm9H4wivea4rlVjv5TSwOXdT9_JYQ4L21 6ptMH9vYnKlQLYnCrPKLdAIXU7uXnHJuaXWQdFNGbo2eFAxtrON2dtwdFmQn N6iSO7AZRZEquVbrV3eyVc3ATf3UZT1MW3y9pER6ADMjSB98KJzVfJgTcJcI rluRQZPNt.bSqphQKOFVz22sFO9p7RVzX9Bh2dXnjogcXLwHO6zLYHnUTYCJ p8Kx7hx1UnyLNjd04VaXRBdHw5rORUo_MsoZRASqax3An8CFifa6Y6ar1QKq RGEpceYbkhlDjuS5w_s3XETiA_Qw4WtUTloxW3ljatQ8lJKsHdt.0WzfGJZL xkZIxiQQ0DHlNI_I7NuUGTwKzXW6gLSGLy4jMPK_MxwYKteHoKCO7PAtFyXr vRN_FtFGsBmKy1WkbYfUiZWsPidgOBf1nJfI.0qnR6OSCOMCitR_vu6VVKcE HoAGOkV9EvuF19SKvy9j1HHuxxWiVEAt6WV9eSlpXvf51qsADuvnXCqdEWxP Bfx6Fms.V3EzYFEMOPXLNJBjSji6eljDECce2A5Jal2SeIvdaykBZOyldmpf bUVEs X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.203.134 with ) by smtp114.sbc.mail.ne1.yahoo.com with SMTP; 13 Sep 2013 13:22:17 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.7.130812 Date: Fri, 13 Sep 2013 06:21:00 -0700 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3461898135_138734" Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 13:22:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3461898135_138734 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I don't agree with the proposed technical changes below, specifically: 1) "- I have argued that to increase MPL's applicability, PROACTIVE_FORWARDING should be a per-interface and not a per-forwarder setting. I can imagine, for example, a router that has both LLN and traditional interfaces and proactive forwarding seems unnecessary for the latter. As [RFC 4007] states: "Zone boundaries cut through nodes, not links." Suggested wording in section 5.4 could be "PROACTIVE_FORWARDING has a default value of TRUE on links where Realm-Local scope is defined, and FALSE otherwise." Given how forwarding is defined in the draft, I don't see how the scenario above is possible unless the links on the "traditional interfaces" happen to be members of the same MPL Domain as the LLN 2) "- Section 4.1 states: "When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL." This begs the question, why don't we just use scope = 0x04? We probably need more discussion on if and how a scope 0x03 zone boundary is automatically defined (i.e. without human intervention) and how forwarding works for scope 0x03. One suggested definition is that Realm-Local applies to links where a single interface may belong to multiple Link-Local scopes." This argument was made some time ago and rejected. The purpose in defining and using a realm scoped address is to allow for automatic definition. The forwarding definition in the Trickle Multicast draft is by MPL Domain so the definition at the end of the paragraph above is not needed. When using FF03::FC (defined for forwarding within a MPL Domain) then all members of the MPL Domain are forwarded a copy of the multicast transmission. Section 7.2 especially makes this clear, by interface, by defining: MPLInterfaceSet - a set of MPL Interfaces that subscribe to the MPL Domain Address that identifies the MPL Domain. 3) - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters described in section 5.5 will ultimately have to be expressed in units of time (either in this document or elsewhere) for a given link-layer in order to avoid the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The same reference states: "a protocol SHOULD set k and Imin such that Imin is at least two to three times as long as it takes to transmit k packets." Since we are using these parameters as defined in RFC 6206 (Trickle Algorithm) we should not attempt to redefine them here in this draft. Don From: Kerry Lynn Reply-To: Routing Over Low power and Lossy networks Date: Friday, September 13, 2013 5:10 AM To: Routing Over Low power and Lossy networks Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson wrote: > > A number of issues were raised this past spring by IESG and other reviewers > on draft-ietf-roll-trickle-mcast. You can review them using the custom query: > > http://trac.tools.ietf.org/wg/roll/trac/query?status=assigned&status=closed&st > atus=new&status=reopened&component=trickle-mcast&group=component&col=id&col=su > mmary&col=component&col=status&col=type&col=priority&col=milestone&order=prior > ity > > The chairs, Document Shephard and Document Authors believe that current > issues are closed in the -05 revision at: > https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ > A diff is available at: > > https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-trickle-mcast-04&difftype=-- > html&submit=Go%21&url2=draft-ietf-roll-trickle-mcast-05 > > We are starting another WG Last Call. > It will run until Friday 2013-09-13 at 9am EST. > > Please read the document. Do you concur that it is done? > Please post any and all comments. > The draft is looking good, but I have a few comments. Editorial: - In section 4.3, on Proactive Forwarding, the phrase "MPL Data Message message" is redundant and should be "MPL Data Message". - In the last paragraph of section 4.3 the phrase "a new MPL Data messages" should be "a new MPL Data Message". - [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 to 14.2. Technical: - I have argued that to increase MPL's applicability, PROACTIVE_FORWARDING should be a per-interface and not a per-forwarder setting. I can imagine, for example, a router that has both LLN and traditional interfaces and proactive forwarding seems unnecessary for the latter. As [RFC 4007] states: "Zone boundaries cut through nodes, not links." Suggested wording in section 5.4 could be "PROACTIVE_FORWARDING has a default value of TRUE on links where Realm-Local scope is defined, and FALSE otherwise." - Section 4.1 states: "When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL." This begs the question, why don't we just use scope = 0x04? We probably need more discussion on if and how a scope 0x03 zone boundary is automatically defined (i.e. without human intervention) and how forwarding works for scope 0x03. One suggested definition is that Realm-Local applies to links where a single interface may belong to multiple Link-Local scopes. - The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters described in section 5.5 will ultimately have to be expressed in units of time (either in this document or elsewhere) for a given link-layer in order to avoid the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The same reference states: "a protocol SHOULD set k and Imin such that Imin is at least two to three times as long as it takes to transmit k packets." Regards, -K- > If there is something you do not like, please provide a suggestion (a diff) > about what to fix. > > Thank you. > > Michael and JP. > > -- > Michael Richardson >, > Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > 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 --B_3461898135_138734 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
I don't agree with the proposed tec= hnical changes below, specifically:
1)  "- I have argued that= to increase MPL's applicability, PROACTIVE_FORWARDING
  shou= ld be a per-interface and not a per-forwarder setting.  I can imagine, = for
  example, a router that has both LLN and traditional= interfaces and proactive
  forwarding seems unnecessary = for the latter.  As [RFC 4007] states: "Zone
  bound= aries cut through nodes, not links."  Suggested wording in section 5.4<= br>
  could be "PROACTIVE_FORWARDING has a default value of T= RUE on links
  where Realm-Local scope is defined, and FA= LSE otherwise."

    Given how forwarding = is defined in the draft, I don't see how the scenario above is possible unle= ss the links on the "traditional interfaces" happen to be members of the sam= e MPL Domain as the LLN

2)  "- Section 4.1 sta= tes: "When used with MPL, Realm-Local scope is administratively
&n= bsp; defined and used to define the boundaries of multicast message dissemin= ation
  by MPL."  This begs the question, why don't = we just use scope =3D 0x04?  We
  probably need more d= iscussion on if and how a scope 0x03 zone boundary
  is a= utomatically defined (i.e. without human intervention) and how forwarding
  works for scope 0x03.  One suggested definition is t= hat Realm-Local applies
  to links where a single interfa= ce may belong to multiple Link-Local scopes."
     =
      This argument was made some time ago and rej= ected.   The purpose in defining and using a realm scoped address is to= allow for automatic definition.   The forwarding definition in the Tri= ckle Multicast draft is by MPL Domain so the definition at the end of the pa= ragraph above is not needed.   When using FF03::FC (defined for forward= ing within a MPL Domain) then all members of the MPL Domain are forwarded a = copy of the multicast transmission.  Section 7.2 especially makes this = clear, by interface, by defining:
   MPLInterfaceSet  - a set=
 of MPL Interfaces that subscribe to the MPL
          Domain Address that identifies the MPL Domain.
3)  - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN para= meters
  described in section 5.5 will ultimately have to be = expressed in units of time
  (either in this document or = elsewhere) for a given link-layer in order to avoid
  the "Mismatche= d min" issues discussed in [RFC 6206, sect. 6.2].  The same
  r= eference states: "a protocol SHOULD set k and Imin such that Imin is at leas= t
  two to three times as long as it takes to transmit k packets."

     Since we are using these paramet= ers as defined in RFC 6206 (Trickle Algorithm) we should not attempt to rede= fine them here in this draft.

Don


From: Kerry Lynn <<= a href=3D"mailto:kerlyn@ieee.org">kerlyn@ieee.org>
Reply-To: Routing Over Low power and Lossy networks &l= t;roll@ietf.org>
Date: Friday, September 13, 2013 5:10 AM
To: Routing Over Low power and Lossy networks &l= t;roll@ietf.org>
Subject: Re: [Roll] WGLC - Working Group Last Call - dr= aft-ietf-roll-trickle-mcast-05

On Wed= , Sep 4, 2013 at 3:45 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

A number of issues were raised this past spring by IESG and other reviewers=
on draft-ietf-roll-trickle-mcast.  You can review them using the custo= m query:

http://trac.tools.ietf.org/wg/roll/trac/query?st= atus=3Dassigned&status=3Dclosed&status=3Dnew&status=3Dreopened&compo= nent=3Dtrickle-mcast&group=3Dcomponent&col=3Did&col=3Dsummary&col=3Dco= mponent&col=3Dstatus&col=3Dtype&col=3Dpriority&col=3Dmilestone&o= rder=3Dpriority

The chairs, Document Shephard and Document Authors believe that current
= issues are closed in the -05 revision at:
       https://datatracker.ietf.org/doc/d= raft-ietf-roll-trickle-mcast/
A diff is available at:
       https://www.ietf.org/rfcdiff= ?url1=3Ddraft-ietf-roll-trickle-mcast-04&difftype=3D--html&submit=3DGo%21&= amp;url2=3Ddraft-ietf-roll-trickle-mcast-05

We are starting another WG Last Call.
It will run until Friday 2013-09-13 at 9am EST.

Please read the document.  Do you concur that it is done?
Please post any and all comments.
 
The draft is looking good, but I have a few comment= s.
 
Editorial:

- In section = 4.3, on Proactive Forwarding, the phrase "MPL Data Message message"
  is redundant and should be "MPL Data Message".

- In the last paragraph of section 4.3 the phrase "a new MPL Data messages= "
  should be "a new MPL Data Message".

- [I-D.droms-6man-multicast-scopes] should be moved from sec= tion 14.1 to 14.2.


Technical:
- I have argued that to increase MPL's applicability, PROACTIVE_= FORWARDING
  should be a per-interface and not a per-forw= arder setting.  I can imagine, for
  example, a rout= er that has both LLN and traditional interfaces and proactive
=   forwarding seems unnecessary for the latter.  As [RFC 4007] stat= es: "Zone
  boundaries cut through nodes, not links."&nbs= p; Suggested wording in section 5.4
  could be "PROACTIVE= _FORWARDING has a default value of TRUE on links
  where = Realm-Local scope is defined, and FALSE otherwise."

=
- Section 4.1 states: "When used with MPL, Realm-Local scope is adminis= tratively
  defined and used to define the boundaries of = multicast message dissemination
  by MPL."  This beg= s the question, why don't we just use scope =3D 0x04?  We
&= nbsp; probably need more discussion on if and how a scope 0x03 zone boundary=
  is automatically defined (i.e. without human intervent= ion) and how forwarding
  works for scope 0x03.  One= suggested definition is that Realm-Local applies
  to li= nks where a single interface may belong to multiple Link-Local scopes.

- The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN par= ameters
  described in section 5.5 will ultimately have t= o be expressed in units of time
  (either in this documen= t or elsewhere) for a given link-layer in order to avoid
  the "Mism= atched min" issues discussed in [RFC 6206, sect. 6.2].  The same
&nb= sp; reference states: "a protocol SHOULD set k and Imin such that Imin is at= least
  two to three times as long as it takes to transmit k packets."

Regards, -K-

 
If there is something you do not like, please provide a suggestion (a diff)=
about what to fix.

Thank you.

Michael and JP.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/=


______________________________________________= _
Roll mailing list
Roll@ie= tf.org
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll --B_3461898135_138734-- From trac+roll@trac.tools.ietf.org Fri Sep 13 06:46:12 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671EA11E80F6 for ; Fri, 13 Sep 2013 06:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48O+59QrsYWN for ; Fri, 13 Sep 2013 06:46:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9703C21F9C90 for ; Fri, 13 Sep 2013 06:46:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:60645 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VKThC-0000Z1-U1; Fri, 13 Sep 2013 15:46:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, mariainesrobles@gmail.com, mcr@sandelman.ca X-Trac-Project: roll Date: Fri, 13 Sep 2013 13:46:02 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/roll/trac/ticket/103#comment:3 Message-ID: <073.f76f1c320b185c4fe9214f2f2c0ddc58@trac.tools.ietf.org> References: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-Trac-Ticket-ID: 103 In-Reply-To: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, mariainesrobles@gmail.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130913134611.9703C21F9C90@ietfa.amsl.com> Resent-Date: Fri, 13 Sep 2013 06:46:11 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 13:46:12 -0000 #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS Changes (by mcr@sandelman.ca): * status: closed => reopened * resolution: fixed => Comment: Don Sturek writes: {{{ 1) "- I have argued that to increase MPL's applicability, PROACTIVE_FORWARDING should be a per-interface and not a per-forwarder setting. I can imagine, for example, a router that has both LLN and traditional interfaces and proactive forwarding seems unnecessary for the latter. As [RFC 4007] states: "Zone boundaries cut through nodes, not links." Suggested wording in section 5.4 could be "PROACTIVE_FORWARDING has a default value of TRUE on links where Realm-Local scope is defined, and FALSE otherwise." Given how forwarding is defined in the draft, I don't see how the scenario above is possible unless the links on the "traditional interfaces" happen to be members of the same MPL Domain as the LLN }}} -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Fri Sep 13 06:46:37 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E622A11E80EA for ; Fri, 13 Sep 2013 06:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzQvlvC5p9XJ for ; Fri, 13 Sep 2013 06:46:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F40EF21F9C90 for ; Fri, 13 Sep 2013 06:46:35 -0700 (PDT) Received: from localhost ([127.0.0.1]:60676 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VKThg-0000tQ-VZ; Fri, 13 Sep 2013 15:46:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Fri, 13 Sep 2013 13:46:32 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/132#comment:5 Message-ID: <082.77025347de98150b9e23fbe62aa3ea80@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 13:46:37 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Changes (by mcr@sandelman.ca): * status: closed => reopened * resolution: fixed => Comment: Don Sturek writes: {{{ 2) "- Section 4.1 states: "When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL." This begs the question, why don't we just use scope = 0x04? We probably need more discussion on if and how a scope 0x03 zone boundary is automatically defined (i.e. without human intervention) and how forwarding works for scope 0x03. One suggested definition is that Realm-Local applies to links where a single interface may belong to multiple Link-Local scopes." }}} -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From kerlyn2001@gmail.com Fri Sep 13 06:58:39 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A39321F9FD7 for ; Fri, 13 Sep 2013 06:58:39 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCNKu4fpHuw0 for ; Fri, 13 Sep 2013 06:58:38 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id BE4E321F9FD6 for ; Fri, 13 Sep 2013 06:58:37 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k18so1187301oag.12 for ; Fri, 13 Sep 2013 06:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=qgOz7LW9fsp/LN9EmRiBIuZ2iNaLwMDxkiwVL8uOesY=; b=FrZgbmPvVBk0rJpeJN2pIggzOnYPOIqP9hPqdGtzuaX1R3VWzYALMynrrHhaUN9d5E 1sAMymrd8zzvo/VXxVbQyW0cE7yeh0F+GwEjktZ4H66szpUCebPa62Qh4RrjehYqj0IO 4IRRbiw6JblCmuUb7syx8sdkaDp7olYVE/S+5jF6rAFIZQ8RgxCOiu4t5Am+j/vzTCQV SL41IkI1TCu3GKa9JoWBReTNOwmGXZumK4rrwTi1l4ebwQxa+LQKpM3ntbulzCFceiz4 ntsNbLImyFW/XibZ4824yYr+MWp4N7AGD98K1XBNBXv2V5hP0T2BIXIo9Fr9c27akzfY B/Kw== MIME-Version: 1.0 X-Received: by 10.60.60.5 with SMTP id d5mr12404307oer.0.1379080717251; Fri, 13 Sep 2013 06:58:37 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.41.36 with HTTP; Fri, 13 Sep 2013 06:58:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Sep 2013 09:58:37 -0400 X-Google-Sender-Auth: vkpqlyc_ba2esrSErhs0dUYre_g Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e0149c3c044bb2d04e6444094 Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 13:58:39 -0000 --089e0149c3c044bb2d04e6444094 Content-Type: text/plain; charset=ISO-8859-1 Hi Don, On Fri, Sep 13, 2013 at 9:21 AM, Don Sturek wrote: > I don't agree with the proposed technical changes below, specifically: > 1) "- I have argued that to increase MPL's applicability, > PROACTIVE_FORWARDING > should be a per-interface and not a per-forwarder setting. I can > imagine, for > example, a router that has both LLN and traditional interfaces and > proactive > forwarding seems unnecessary for the latter. As [RFC 4007] states: "Zone > boundaries cut through nodes, not links." Suggested wording in section > 5.4 > could be "PROACTIVE_FORWARDING has a default value of TRUE on links > where Realm-Local scope is defined, and FALSE otherwise." > > Given how forwarding is defined in the draft, I don't see how the > scenario above is possible unless the links on the "traditional interfaces" > happen to be members of the same MPL Domain as the LLN > I am looking at section 3, Applicability Statement, which says: "This protocol may also be used in environments where only a subset of links are considered Low-Power and Lossy links." The change I proposed is minimal and would improve dynamic protocol behavior on non-LLN links. > > 2) "- Section 4.1 states: "When used with MPL, Realm-Local scope is > administratively > defined and used to define the boundaries of multicast message > dissemination > by MPL." This begs the question, why don't we just use scope = 0x04? We > probably need more discussion on if and how a scope 0x03 zone boundary > is automatically defined (i.e. without human intervention) and how > forwarding > works for scope 0x03. One suggested definition is that Realm-Local > applies > to links where a single interface may belong to multiple Link-Local > scopes." > > This argument was made some time ago and rejected. The purpose in > defining and using a realm scoped address is to allow for automatic > definition. > I think I'm just confused about the desire for automatic definition of the Realm-Local scope and the several statements in the draft that it's administratively configured. Asking as an implementer, how do I determine whether an interface is in a Realm- Local zone? Is it particular to LLN links? I'm not sure whether the draft is intending to reserve the ability to configure which links are in the MPLInterfaceSet. However it seems that Realm-Local scope, like other multicast scopes, must have a consistent definition for any and all protocols that use it. > The forwarding definition in the Trickle Multicast draft is by MPL Domain > so the definition at the end of the paragraph above is not needed. When > using FF03::FC (defined for forwarding within a MPL Domain) then all > members of the MPL Domain are forwarded a copy of the multicast > transmission. Section 7.2 especially makes this clear, by interface, by > defining: > > MPLInterfaceSet - a set of MPL Interfaces that subscribe to the MPL > Domain Address that identifies the MPL Domain. > > > 3) - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters > described in section 5.5 will ultimately have to be expressed in units > of time > (either in this document or elsewhere) for a given link-layer in order > to avoid > the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The same > reference states: "a protocol SHOULD set k and Imin such that Imin is at > least > two to three times as long as it takes to transmit k packets." > > Since we are using these parameters as defined in RFC 6206 (Trickle > Algorithm) we should not attempt to redefine them here in this draft. > Do the terms "expected link-layer latency" and "worst-case link-layer latency" (used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN, respectively) have commonly defined definitions, e.g. in 802.15.4? If so, what are they? I couldn't seem to determine this from the 802.15.4 spec. Thanks, -K- > > Don > > > From: Kerry Lynn > Reply-To: Routing Over Low power and Lossy networks > Date: Friday, September 13, 2013 5:10 AM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] WGLC - Working Group Last Call - > draft-ietf-roll-trickle-mcast-05 > > On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson wrote: > >> >> A number of issues were raised this past spring by IESG and other >> reviewers >> on draft-ietf-roll-trickle-mcast. You can review them using the custom >> query: >> >> >> http://trac.tools.ietf.org/wg/roll/trac/query?status=assigned&status=closed&status=new&status=reopened&component=trickle-mcast&group=component&col=id&col=summary&col=component&col=status&col=type&col=priority&col=milestone&order=priority >> >> The chairs, Document Shephard and Document Authors believe that current >> issues are closed in the -05 revision at: >> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ >> A diff is available at: >> >> https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-trickle-mcast-04&difftype=--html&submit=Go%21&url2=draft-ietf-roll-trickle-mcast-05 >> >> We are starting another WG Last Call. >> It will run until Friday 2013-09-13 at 9am EST. >> >> Please read the document. Do you concur that it is done? >> Please post any and all comments. >> > > The draft is looking good, but I have a few comments. > > Editorial: > > - In section 4.3, on Proactive Forwarding, the phrase "MPL Data Message > message" > is redundant and should be "MPL Data Message". > > - In the last paragraph of section 4.3 the phrase "a new MPL Data messages" > should be "a new MPL Data Message". > > - [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 to > 14.2. > > > Technical: > > - I have argued that to increase MPL's applicability, PROACTIVE_FORWARDING > should be a per-interface and not a per-forwarder setting. I can > imagine, for > example, a router that has both LLN and traditional interfaces and > proactive > forwarding seems unnecessary for the latter. As [RFC 4007] states: "Zone > boundaries cut through nodes, not links." Suggested wording in section > 5.4 > could be "PROACTIVE_FORWARDING has a default value of TRUE on links > where Realm-Local scope is defined, and FALSE otherwise." > > - Section 4.1 states: "When used with MPL, Realm-Local scope is > administratively > defined and used to define the boundaries of multicast message > dissemination > by MPL." This begs the question, why don't we just use scope = 0x04? We > probably need more discussion on if and how a scope 0x03 zone boundary > is automatically defined (i.e. without human intervention) and how > forwarding > works for scope 0x03. One suggested definition is that Realm-Local > applies > to links where a single interface may belong to multiple Link-Local > scopes. > > - The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters > described in section 5.5 will ultimately have to be expressed in units > of time > (either in this document or elsewhere) for a given link-layer in order > to avoid > the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The same > reference states: "a protocol SHOULD set k and Imin such that Imin is at > least > two to three times as long as it takes to transmit k packets." > > Regards, -K- > > > >> If there is something you do not like, please provide a suggestion (a >> diff) >> about what to fix. >> >> Thank you. >> >> Michael and JP. >> >> -- >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --089e0149c3c044bb2d04e6444094 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Don,

On Fri, Sep 13, 2013 at 9:21 AM, Don S= turek <d.sturek@att.net> wrote:
I don't agree with the pro= posed technical changes below, specifically:
1) =A0"- I have argued that to increase MPL's applicability, = PROACTIVE_FORWARDING
=A0 should be a per-interf= ace and not a per-forwarder setting.=A0 I can imagine, for
= =A0 example, a router that has both LLN and traditional interfaces and proa= ctive
=A0 forwarding seems unnecessary for the latter.=A0 As [RFC 4007= ] states: "Zone
=A0 boundaries cut through nodes, not li= nks."=A0 Suggested wording in section 5.4
=A0 could be &= quot;PROACTIVE_FORWARDING has a default value of TRUE on links
=A0 where Realm-Local scope is defined, and FALSE otherwise.&quo= t;

=A0 =A0 Given how forwarding is defined i= n the draft, I don't see how the scenario above is possible unless the = links on the "traditional interfaces" happen to be members of the= same MPL Domain as the LLN

I am looking at section 3, Applicabi= lity Statement, which says: "This protocol
may also be u= sed in environments where only a subset of links are considered
Low-Power and Lossy links."=A0 The change I proposed is minimal a= nd would
improve dynamic protocol behavior on non-LLN links. =

2) =A0"- Section 4.1 states: "When u= sed with MPL, Realm-Local scope is administratively
=
=A0 defined and used to define the boundaries of multicast message dissemin= ation
=A0 by MPL."=A0 This begs the question, why don= 9;t we just use scope =3D 0x04?=A0 We
=A0 probably need more = discussion on if and how a scope 0x03 zone boundary
=A0 is automatically defined (i.e. without human intervention) a= nd how forwarding
=A0 works for scope 0x03.=A0 One suggested = definition is that Realm-Local applies
=A0 to links where a s= ingle interface may belong to multiple Link-Local scopes."
=A0 =A0 =A0
=A0 =A0 =A0 This argument was made some ti= me ago and rejected. =A0 The purpose in defining and using a realm scoped a= ddress is to allow for automatic definition.
<= br>
I think I'm just confused about the desire for automatic definition of = the Realm-Local
scope and the several statements in the draft that it= 9;s administratively configured.
Asking as an implementer, how do I det= ermine whether an interface is in a Realm-
Local zone?=A0 Is it particular to LLN links?

I'm not= sure whether the draft is intending to reserve the ability to configure wh= ich
links are in the MPLInterfaceSet.=A0 However it seems that Realm-Loc= al scope, like
other multicast scopes, must have a consistent definition for an= y and all protocols
that use it.
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
The forwarding definition in the Trickle Multicast draft is b= y MPL Domain so the definition at the end of the paragraph above is not nee= ded. =A0 When using FF03::FC (defined for forwarding within a MPL Domain) t= hen all members of the MPL Domain are forwarded a copy of the multicast tra= nsmission. =A0Section 7.2 especially makes this clear, by interface, by def= ining:
   MPLInterfaceSet  - a set of MPL Interfaces that subscribe to t=
he MPL
          Domain Address that identifies the MPL Domain.
3) =A0- "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN p= arameters
=A0 described in section 5.5 will ult= imately have to be expressed in units of time
=A0 (either in this document or elsewhere) for a given link-laye= r in order to avoid
=A0 the "Mismatched min" issues discussed = in [RFC 6206, sect. 6.2].=A0 The same
=A0 reference states: "a prot= ocol SHOULD set k and Imin such that Imin is at least
=A0 two to three times as long as it takes to transmit k packets."

=A0 =A0 =A0Since we are using these parameters = as defined in RFC 6206 (Trickle Algorithm) we should not attempt to redefin= e them here in this draft.

Do the terms "expected link-lay= er latency" and "worst-case link-layer latency"
(used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,
respective= ly) have commonly defined definitions, e.g. in 802.15.4?=A0 If so,
what are they?=A0 I couldn't seem to determine this from the 802.15.4 s= pec.

Thanks, -K-
=A0

Don


<= div style=3D"border-right:medium none;padding-right:0in;padding-left:0in;pa= dding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font= -family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left= :medium none"> From: Kerry Lynn <kerlyn@ieee.org>
Reply-To: Routing Over Low power and Lossy= networks <roll@ietf.= org>
Date: Friday, September 13, 2013 5= :10 AM
To: Routing Over Low pow= er and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] WGLC - Working= Group Last Call - draft-ietf-roll-trickle-mcast-05

On Wed, Sep 4, 2013 at 3:45 PM, Mi= chael Richardson <mcr+ietf@sandelman.ca> wrote:

A number of issues were raised this past spring by IESG and other reviewers=
on draft-ietf-roll-trickle-mcast. =A0You can review them using the custom q= uery:

http://trac.to= ols.ietf.org/wg/roll/trac/query?status=3Dassigned&status=3Dclosed&s= tatus=3Dnew&status=3Dreopened&component=3Dtrickle-mcast&group= =3Dcomponent&col=3Did&col=3Dsummary&col=3Dcomponent&col=3Ds= tatus&col=3Dtype&col=3Dpriority&col=3Dmilestone&order=3Dpri= ority

The chairs, Document Shephard and Document Authors believe that current
issues are closed in the -05 revision at:
=A0 =A0 =A0 =A0https://datatracker.ietf.org/doc/draft-ie= tf-roll-trickle-mcast/
A diff is available at:
=A0 =A0 =A0 =A0https://www.ietf.org/rfcdi= ff?url1=3Ddraft-ietf-roll-trickle-mcast-04&difftype=3D--html&submit= =3DGo%21&url2=3Ddraft-ietf-roll-trickle-mcast-05

We are starting another WG Last Call.
It will run until Friday 2013-09-13 at 9am EST.

Please read the document. =A0Do you concur that it is done?
Please post any and all comments.
=A0
The draft is looking good, but I have a few comments.<= br>
=A0
Editorial:

- In section 4.3, = on Proactive Forwarding, the phrase "MPL Data Message message"
=A0 is redundant and should be "MPL Data Message".
=
- In the last paragraph of section 4.3 the phrase "a ne= w MPL Data messages"
=A0 should be "a new MPL Data = Message".

- [I-D.droms-6man-multicast-scopes] should be moved fr= om section 14.1 to 14.2.


Technical:=

- I have argued that to increase MPL's applicability= , PROACTIVE_FORWARDING
=A0 should be a per-interface and not a per-forwarder setting.= =A0 I can imagine, for
=A0 example, a router that has both LL= N and traditional interfaces and proactive
=A0 forwarding see= ms unnecessary for the latter.=A0 As [RFC 4007] states: "Zone
=A0 boundaries cut through nodes, not links."=A0 Suggested = wording in section 5.4
=A0 could be "PROACTIVE_FORWARDIN= G has a default value of TRUE on links
=A0 where Realm-Local = scope is defined, and FALSE otherwise."

- Section 4.1 states: "When used with MPL, R= ealm-Local scope is administratively
=A0 defined and used to = define the boundaries of multicast message dissemination
=A0 = by MPL."=A0 This begs the question, why don't we just use scope = =3D 0x04?=A0 We
=A0 probably need more discussion on if and how a scope 0x03 zon= e boundary
=A0 is automatically defined (i.e. without human i= ntervention) and how forwarding
=A0 works for scope 0x03.=A0 = One suggested definition is that Realm-Local applies
=A0 to links where a single interface may belong to multiple Lin= k-Local scopes.

- The DATA_MESSAGE_IMIN and CO= NTROL_MESSAGE_IMIN parameters
=A0 described in section 5.5 wi= ll ultimately have to be expressed in units of time
=A0 (either in this document or elsewhere) for a given link-laye= r in order to avoid
=A0 the "Mismatched min" issues discussed = in [RFC 6206, sect. 6.2].=A0 The same
=A0 reference states: "a prot= ocol SHOULD set k and Imin such that Imin is at least
=A0 two to three times as long as it takes to transmit k packets."
=

Regards, -K-

=A0
If there is something you do not like, please provide a suggestion (a diff)=
about what to fix.

Thank you.

Michael and JP.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair. =A0 =A0http://datatracker.ietf.org/wg/roll/charter/<= /a>


______________________________________________= _
Roll mailing list
Rol= l@ietf.org
https://www.ietf.org/mailman/listinfo/roll


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

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

--089e0149c3c044bb2d04e6444094-- From kerlyn2001@gmail.com Fri Sep 13 07:02:37 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A99A11E8212 for ; Fri, 13 Sep 2013 07:02:37 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFzdOOurjSNd for ; Fri, 13 Sep 2013 07:02:36 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9428C11E8204 for ; Fri, 13 Sep 2013 07:02:36 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i4so1192759oah.9 for ; Fri, 13 Sep 2013 07:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=GlFd70HUYWI3pELAIVO8doeHIitB9qxAppSv0E22wM8=; b=eV68c1ywF49GBMa7tAg/HQB6Tr4h2o6bUi/p8TmXE7QTb9Gy+X90KAqvyNAjuTzIKZ nHu5dTodyoZsOlWH+1fMyhn9yF44dNmxts8dtLBDt0Y0qs55vuvMs1hekfE35jioUjUf rD/cQght1fM1Jf5X9EcSNKk2rpSJiwT5pOyym2lLEFIoB7cMMDvX11Kb37Yx7G2HZX8P 8nrue7DK1d51rNUgV1f1I8FyrC1OLiDwHK1QgxgGoXZadqZpw1hxMdDgPVonJ9ofmb7N SGCggfwY5WKuWX7M98Lf/dj9mG/dyniTxO7fPhKwZtPcf9z10RxIjoA7IjqhLjGpUJ/V r8YA== MIME-Version: 1.0 X-Received: by 10.182.113.195 with SMTP id ja3mr12418995obb.46.1379080956093; Fri, 13 Sep 2013 07:02:36 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.41.36 with HTTP; Fri, 13 Sep 2013 07:02:36 -0700 (PDT) In-Reply-To: <082.77025347de98150b9e23fbe62aa3ea80@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.77025347de98150b9e23fbe62aa3ea80@trac.tools.ietf.org> Date: Fri, 13 Sep 2013 10:02:36 -0400 X-Google-Sender-Auth: OU2G5xlkYgerehlk3J0LYyzcN2Y Message-ID: From: Kerry Lynn To: "roll@ietf.org" Content-Type: multipart/alternative; boundary=089e013d0db0812cb204e6444e5e Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 14:02:37 -0000 --089e013d0db0812cb204e6444e5e Content-Type: text/plain; charset=ISO-8859-1 Actually, that was my comment. It seems to me that the MPL draft and draft-droms-6man-multicast-scopes-02 may be inconsistent in whether Realm-Local scopes are administratively or automatically defined. -K- On Fri, Sep 13, 2013 at 9:46 AM, roll issue tracker < trac+roll@trac.tools.ietf.org> wrote: > #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - > subnet-local > > Changes (by mcr@sandelman.ca): > > * status: closed => reopened > * resolution: fixed => > > > Comment: > > Don Sturek writes: > {{{ > 2) "- Section 4.1 states: "When used with MPL, Realm-Local scope is > administratively > defined and used to define the boundaries of multicast message > dissemination > by MPL." This begs the question, why don't we just use scope = 0x04? > We > probably need more discussion on if and how a scope 0x03 zone boundary > is automatically defined (i.e. without human intervention) and how > forwarding > works for scope 0x03. One suggested definition is that Realm-Local > applies > to links where a single interface may belong to multiple Link-Local > scopes." > }}} > > -- > ---------------------------------------+------------------------------ > Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com > Type: defect | Status: reopened > Priority: major | Milestone: > Component: trickle-mcast | Version: > Severity: In WG Last Call | Resolution: > Keywords: | > ---------------------------------------+------------------------------ > > Ticket URL: > roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --089e013d0db0812cb204e6444e5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Actually, that was my comment.=A0 It seems to me= that the MPL draft and
draft-droms-6man-multicast-scopes-02 may b= e inconsistent in whether
Realm-Local scopes are administratively = or automatically defined.

-K-



On Fri, Sep 13, 2013 at 9:46 AM, roll issue tracker <t= rac+roll@trac.tools.ietf.org> wrote:
#132: draft-ietf-roll-tric= kle-mcast-04 - Clarify scope value of 3 - subnet-local

Changes (by mcr@sandelman.ca)= :

=A0* status: =A0closed =3D> reopened
=A0* resolution: =A0fixed =3D>


Comment:

=A0Don Sturek writes:
=A0{{{
=A02) =A0"- Section 4.1 states: "When used with MPL, Realm-Local = scope is
=A0administratively
=A0 =A0defined and used to define the boundaries of multicast message
=A0dissemination
=A0 =A0by MPL." =A0This begs the question, why don't we just use s= cope =3D 0x04?
=A0We
=A0 =A0probably need more discussion on if and how a scope 0x03 zone bounda= ry
=A0 =A0is automatically defined (i.e. without human intervention) and how =A0forwarding
=A0 =A0works for scope 0x03. =A0One suggested definition is that Realm-Loca= l
=A0applies
=A0 =A0to links where a single interface may belong to multiple Link-Local<= br> =A0scopes."
=A0}}}

--
---------------------------------------+------------------------------
=A0Reporter: =A0mariainesroble= s@gmail.com =A0| =A0 =A0 =A0 Owner: =A0johui@cisco.com
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0Status: =A0reopened
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| =A0 Milestone:
Component: =A0trickle-mcast =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0= =A0| =A0Resolution:
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
---------------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/tr= ac/ticket/132#comment:5>
roll <http://tools.ietf.org/wg/roll/>
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--089e013d0db0812cb204e6444e5e-- From mcr@sandelman.ca Fri Sep 13 07:04:08 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AC721F9C54 for ; Fri, 13 Sep 2013 07:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-giQnL4QgDO for ; Fri, 13 Sep 2013 07:04:04 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id DE24511E80EA for ; Fri, 13 Sep 2013 07:04:03 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 309272024C for ; Fri, 13 Sep 2013 11:12:35 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E271463AF0; Fri, 13 Sep 2013 10:03:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D2AB263781 for ; Fri, 13 Sep 2013 10:03:54 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 14:04:08 -0000 --=-=-= Don Sturek wrote: > 1) "- I have argued that to increase MPL's applicability, > PROACTIVE_FORWARDING should be a per-interface and not a per-forwarder > setting. I can imagine, for example, a router that has both LLN and I think that the IETF *functional requirements* question is really: Can an implementer make it per-interface without having an impact on the implementation in other nodes? If the answer is, there is no impact, then it really doesn't matter. Other "ip-forwarding" settings have been described as per-router and generalized into per-interface many times before. I have added your comments to ticket #103, which I re-opened. I will close it again today --- I would appreciate comments in the mailing list as to whether there is anything to fix here. > 2) "- Section 4.1 states: "When used with MPL, Realm-Local scope is > administratively defined and used to define the boundaries of multicast > message dissemination by MPL." This begs the question, why don't we > just use scope = 0x04? We probably need more discussion on if and how > a scope 0x03 zone boundary is automatically defined (i.e. without human > intervention) and how forwarding works for scope 0x03. One suggested > definition is that Realm-Local applies to links where a single > interface may belong to multiple Link-Local scopes." I have added your text to ticket #132, and re-opened it. I would like to close it today. I think that we are not using scope 4 because we are able to automatically define the edge. Can you suggest some text would permit MPL to automatically define the scope based upon the flood of the prefix found in the DIO PIO? Is that what you had in mind? > not needed. When using FF03::FC (defined for forwarding within a MPL > Domain) then all members of the MPL Domain are forwarded a copy of the > multicast transmission. Section 7.2 especially makes this clear, by > interface, by defining: I think that you haven't answer the question, just swapped "Real-Local scope" for "MPL Domain" > 3) - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters > described in section 5.5 will ultimately have to be expressed in units > of time (either in this document or elsewhere) for a given link-layer > in order to avoid the "Mismatched min" issues discussed in [RFC 6206, > sect. 6.2]. The same reference states: "a protocol SHOULD set k and > Imin such that Imin is at least two to three times as long as it takes > to transmit k packets." I'm suffering from unclosed quotes here. I don't see section 5.5 as redefining the parameters at all. It seems to just re-iterate them. What is the suggested remedy here? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUjMbR4qHRg3pndX9AQJZ+QQAuWI6HogsNFeukrPG+14U6DOfz9nLMAJv Enva15JtXgKxwo+DSamZ78m0wJUvOgDJC6+NfjDVteu8c3cyeabd5Q6Yrt3uI3zX 8pzOdOoONPHwp3wrcyHB6NHhUihfmC0kcDSIiDqlj2vYmtfDEBgYLOOY9gUogxE4 Efva2dSBfbc= =defb -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Fri Sep 13 07:45:37 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E922321E80A7 for ; Fri, 13 Sep 2013 07:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-pK-+d4CWvE for ; Fri, 13 Sep 2013 07:45:31 -0700 (PDT) Received: from nm22-vm5.access.bullet.mail.bf1.yahoo.com (nm22-vm5.access.bullet.mail.bf1.yahoo.com [216.109.115.148]) by ietfa.amsl.com (Postfix) with ESMTP id E22C111E80F6 for ; Fri, 13 Sep 2013 07:45:30 -0700 (PDT) Received: from [66.196.81.158] by nm22.access.bullet.mail.bf1.yahoo.com with NNFMP; 13 Sep 2013 14:45:28 -0000 Received: from [98.138.84.172] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 13 Sep 2013 14:45:28 -0000 Received: from [127.0.0.1] by smtp106.sbc.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 14:45:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1379083528; bh=YQ4m1uMPNEmLqUtg+WQ4qBWqPkZARnh6vP/cqDlmjMo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=Yk3CUT4OJLwCjiag7lcQ5jQJhSjEV4pnLyKFZhKQG/DUGeTBN+tQX2nuk9Ow2GdFuHocAdPVBogquvT85q0fK8tjRwyyAV4oMFfPF+vjdTbA/p2ZWWtjrKfRGcUiJ6s0Eo6bbUF2z0waKc9OMhX7eoCOJL+snv+GlMiRQnTHRxM= X-Yahoo-Newman-Id: 487915.19355.bm@smtp106.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: axtFCwkVM1nsoYYUCRw1VAeiKCSLx3RyE4VyN_uMl80f8Oh 4a8RDHXv617bULwrz_1.wQE09wp9.7xdtzw2ajMgyV6BKhNXJNxfJR67v2Yl f6hyQ9RHrwyn8OH5qiGXIeF6Obf3KppcOt.yCdkVlGxiJLgT__TN9Cqx_TZU uVGFn28RAOIn8s6DlyM98vkfQuc0KZ3_W9AP_nI4CS0uwYcZbYcGrm6femqw AEbucKOltLcbFEEwbf3T.NeD7XD_KZ2YsGOMP0gV82Ddr3xXGKHLUjR6lJDT k_p1tgsTDhXtNd.Mvto43OmNeTppyWWZUa3HSEO5U422A9LTk9uQr2viEQAS _1mu9wQUO95c6icNoPHE1pzR6HIwaYdROFPBkHhIhOUCEgZfuePimhj0AV6F sBrzch_9ZALfEMq7AbTuY8Z_ecf4nPABN24jegwAbcpjL7SP68.rKXzon7wC .7kQncVbtT4DcPYwH5WPLnCqOsCEKPd2p08xT5pMSB9MLbh0MB1W1LEkoRFc dE8WbHotnHbEXc_Dr9SXYI1RUC43UaWDGw2v9kJnWEExvRiI- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.203.134 with login) by smtp106.sbc.mail.ne1.yahoo.com with SMTP; 13 Sep 2013 07:45:28 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.7.130812 Date: Fri, 13 Sep 2013 07:45:25 -0700 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3461903126_431668" Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 14:45:38 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3461903126_431668 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Kerry, Two points from below: 1) "Asking as an implementer, how do I determine whether an interface is in a Realm- Local zone? Is it particular to LLN links?" As with other multicast addresses, an interface would register (opt-in) to a realm. For Trickle Multicast, it would then depend on whether the interface has subscribed to the MPL Domain Address. The difference between using realm scoped (from Ralph's draft) and administratively scoped (FF04) is the membership in the MPL Domain can be managed automatically by actions within the device. 2) "Do the terms "expected link-layer latency" and "worst-case link-layer latency" (used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN, respectively) have commonly defined definitions, e.g. in 802.15.4? If so, what are they? I couldn't seem to determine this from the 802.15.4 spec." The simple answer to this is there is not a prescribed layer 2 latency value for 802.15.4 other than the defined one hop ACK latency if you use MAC Acknowledges. Just FYI, in testing IEEE 802.15.4-2003/2006 (127 byte PDU) with just 2 devices on a clear channel, we found a typical "one hop/one packet " message latency to be around 4ms (without security) and around 12 ms (using SW based security). In my experience, the "expected link layer latency" and "worst case link layer latency" (speaking strictly about the link layer only) are just a single aspect to setting IMIN correctly. The overall application message pattern plays a larger role for these settings (for example, how frequently multicasts are generated, how many simultaneous multicasts can be generated within a given MPL Domain in a window of time that occurs within IMIN, etc.). Additionally, another major driver to these settings are the deployment characteristics of the MPL Domain member devices (for example. how many incoming message buffers are supported in the member devices MAC, how many outgoing message buffers, etc.). Perhaps the names "expected link layer latency" and "worst case link layer latency" are a bit misleading since they sound like fixed settings that would be applicable to all links of a given type when I think they are trying to describe the link layer performance with a given messaging profile in operation. Don From: Kerry Lynn Reply-To: Routing Over Low power and Lossy networks Date: Friday, September 13, 2013 6:58 AM To: Routing Over Low power and Lossy networks Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 Hi Don, On Fri, Sep 13, 2013 at 9:21 AM, Don Sturek wrote: > I don't agree with the proposed technical changes below, specifically: > 1) "- I have argued that to increase MPL's applicability, > PROACTIVE_FORWARDING > should be a per-interface and not a per-forwarder setting. I can imagine, > for > example, a router that has both LLN and traditional interfaces and proactive > forwarding seems unnecessary for the latter. As [RFC 4007] states: "Zone > boundaries cut through nodes, not links." Suggested wording in section 5.4 > could be "PROACTIVE_FORWARDING has a default value of TRUE on links > where Realm-Local scope is defined, and FALSE otherwise." > > Given how forwarding is defined in the draft, I don't see how the scenario > above is possible unless the links on the "traditional interfaces" happen to > be members of the same MPL Domain as the LLN I am looking at section 3, Applicability Statement, which says: "This protocol may also be used in environments where only a subset of links are considered Low-Power and Lossy links." The change I proposed is minimal and would improve dynamic protocol behavior on non-LLN links. > > 2) "- Section 4.1 states: "When used with MPL, Realm-Local scope is > administratively > defined and used to define the boundaries of multicast message dissemination > by MPL." This begs the question, why don't we just use scope = 0x04? We > probably need more discussion on if and how a scope 0x03 zone boundary > is automatically defined (i.e. without human intervention) and how > forwarding > works for scope 0x03. One suggested definition is that Realm-Local applies > to links where a single interface may belong to multiple Link-Local scopes." > > This argument was made some time ago and rejected. The purpose in > defining and using a realm scoped address is to allow for automatic > definition. I think I'm just confused about the desire for automatic definition of the Realm-Local scope and the several statements in the draft that it's administratively configured. Asking as an implementer, how do I determine whether an interface is in a Realm- Local zone? Is it particular to LLN links? I'm not sure whether the draft is intending to reserve the ability to configure which links are in the MPLInterfaceSet. However it seems that Realm-Local scope, like other multicast scopes, must have a consistent definition for any and all protocols that use it. > The forwarding definition in the Trickle Multicast draft is by MPL Domain so > the definition at the end of the paragraph above is not needed. When using > FF03::FC (defined for forwarding within a MPL Domain) then all members of the > MPL Domain are forwarded a copy of the multicast transmission. Section 7.2 > especially makes this clear, by interface, by defining: > MPLInterfaceSet - a set of MPL Interfaces that subscribe to the MPL > Domain Address that identifies the MPL Domain. > > 3) - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters > described in section 5.5 will ultimately have to be expressed in units of > time > (either in this document or elsewhere) for a given link-layer in order to > avoid > the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The same > reference states: "a protocol SHOULD set k and Imin such that Imin is at > least > two to three times as long as it takes to transmit k packets." > > Since we are using these parameters as defined in RFC 6206 (Trickle > Algorithm) we should not attempt to redefine them here in this draft. Do the terms "expected link-layer latency" and "worst-case link-layer latency" (used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN, respectively) have commonly defined definitions, e.g. in 802.15.4? If so, what are they? I couldn't seem to determine this from the 802.15.4 spec. Thanks, -K- > > Don > > > From: Kerry Lynn > Reply-To: Routing Over Low power and Lossy networks > Date: Friday, September 13, 2013 5:10 AM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] WGLC - Working Group Last Call - > draft-ietf-roll-trickle-mcast-05 > > On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson > wrote: >> >> A number of issues were raised this past spring by IESG and other reviewers >> on draft-ietf-roll-trickle-mcast. You can review them using the custom >> query: >> >> http://trac.tools.ietf.org/wg/roll/trac/query?status=assigned&status=closed&s >> tatus=new&status=reopened&component=trickle-mcast&group=component&col=id&col= >> summary&col=component&col=status&col=type&col=priority&col=milestone&order=pr >> iority >> >> The chairs, Document Shephard and Document Authors believe that current >> issues are closed in the -05 revision at: >> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ >> A diff is available at: >> >> https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-trickle-mcast-04&difftype=- >> -html&submit=Go%21&url2=draft-ietf-roll-trickle-mcast-05 >> >> We are starting another WG Last Call. >> It will run until Friday 2013-09-13 at 9am EST. >> >> Please read the document. Do you concur that it is done? >> Please post any and all comments. >> > The draft is looking good, but I have a few comments. > > Editorial: > > - In section 4.3, on Proactive Forwarding, the phrase "MPL Data Message > message" > is redundant and should be "MPL Data Message". > > - In the last paragraph of section 4.3 the phrase "a new MPL Data messages" > should be "a new MPL Data Message". > > - [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 to 14.2. > > > Technical: > > - I have argued that to increase MPL's applicability, PROACTIVE_FORWARDING > should be a per-interface and not a per-forwarder setting. I can imagine, > for > example, a router that has both LLN and traditional interfaces and proactive > forwarding seems unnecessary for the latter. As [RFC 4007] states: "Zone > boundaries cut through nodes, not links." Suggested wording in section 5.4 > could be "PROACTIVE_FORWARDING has a default value of TRUE on links > where Realm-Local scope is defined, and FALSE otherwise." > > - Section 4.1 states: "When used with MPL, Realm-Local scope is > administratively > defined and used to define the boundaries of multicast message dissemination > by MPL." This begs the question, why don't we just use scope = 0x04? We > probably need more discussion on if and how a scope 0x03 zone boundary > is automatically defined (i.e. without human intervention) and how > forwarding > works for scope 0x03. One suggested definition is that Realm-Local applies > to links where a single interface may belong to multiple Link-Local scopes. > > - The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters > described in section 5.5 will ultimately have to be expressed in units of > time > (either in this document or elsewhere) for a given link-layer in order to > avoid > the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The same > reference states: "a protocol SHOULD set k and Imin such that Imin is at > least > two to three times as long as it takes to transmit k packets." > > Regards, -K- > > >> If there is something you do not like, please provide a suggestion (a diff) >> about what to fix. >> >> Thank you. >> >> Michael and JP. >> >> -- >> Michael Richardson >, >> Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > _______________________________________________ Roll mailing list > Roll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --B_3461903126_431668 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Kerry,

Two points from below:
1)  "Asking as an implementer= , how do I determine whether an interface is in a Realm-
Local zone?&nb= sp; Is it particular to LLN links?"

      =  As with other multicast addresses, an interface would register (opt-in= ) to a realm.   For Trickle Multicast, it would then depend on whether = the interface has subscribed to the MPL Domain Address.  The difference= between using realm scoped (from Ralph's draft) and administratively scoped= (FF04) is the membership in the MPL Domain can be managed automatically by = actions within the device.

2)  "Do the terms "= expected link-layer latency" and "worst-case link-layer latency"
(used t= o define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,
respectively) have c= ommonly defined definitions, e.g. in 802.15.4?  If so,
what are they= ?  I couldn't seem to determine this from the 802.15.4 spec."

     The simple answer to this is there is no= t a prescribed layer 2 latency value for 802.15.4 other than the defined one= hop ACK latency if you use MAC Acknowledges.  Just FYI, in testing IEE= E 802.15.4-2003/2006 (127 byte PDU) with just 2 devices on a clear channel, = we found a typical "one hop/one packet " message latency to be around 4= ms (without security) and around 12 ms (using SW based security).  In m= y experience, the "expected link layer latency" and "worst case link layer l= atency" (speaking strictly about the link layer only) are just a single aspe= ct to setting IMIN correctly.   The overall application message pattern= plays a larger role for these settings (for example, how frequently multica= sts are generated, how many simultaneous multicasts can be generated within = a given MPL Domain in a window of time that occurs within IMIN, etc.).  = ;Additionally, another major driver to these settings are the deployment cha= racteristics of the MPL Domain member devices (for example. how many incomin= g message buffers are supported in the member devices MAC, how many outgoing= message buffers, etc.).  Perhaps the names "expected link layer latenc= y" and "worst case link layer latency" are a bit misleading since they sound= like fixed settings that would be applicable to all links of a given type w= hen I think they are trying to describe the link layer performance with a gi= ven messaging profile in operation.

Don
<= br>

From: Kerry Lynn= <kerlyn@ieee.org>
Reply-To: Routing Over Low power and Lossy netwo= rks <roll@ietf.org>
Date: Friday, September 13, 2013 6:58 AM
To: Routing Over Low power and Lossy netwo= rks <roll@ietf.org>
Subject: Re: [Roll] WGLC - Working Group Last Cal= l - draft-ietf-roll-trickle-mcast-05

= Hi Don,

On Fri, Sep 13, 2013 at 9:21 AM, Don Sturek <d.sturek@att.net> wrote:
I don't agree with the proposed technical= changes below, specifically:
1)  "- I have argued that to in= crease MPL's applicability, PROACTIVE_FORWARDING
&= nbsp; should be a per-interface and not a per-forwarder setting.  I can= imagine, for
  example, a router that has both LLN and t= raditional interfaces and proactive
  forwarding seems un= necessary for the latter.  As [RFC 4007] states: "Zone
&n= bsp; boundaries cut through nodes, not links."  Suggested wording in se= ction 5.4
  could be "PROACTIVE_FORWARDING has a default = value of TRUE on links
  where Realm-Local scope is defin= ed, and FALSE otherwise."

    Given= how forwarding is defined in the draft, I don't see how the scenario above = is possible unless the links on the "traditional interfaces" happen to be me= mbers of the same MPL Domain as the LLN

I am looking at section 3, Applicability Statement, which says: "Thi= s protocol
may also be used in environments where only a subse= t of links are considered
Low-Power and Lossy links."  Th= e change I proposed is minimal and would
improve dynamic proto= col behavior on non-LLN links.

2)  "- Section 4.1 states: "When used with MPL, Realm-= Local scope is administratively
  defined and used to define the boundaries of multicast message disse= mination
  by MPL."  This begs the question, why don= 't we just use scope =3D 0x04?  We
  probably need mor= e discussion on if and how a scope 0x03 zone boundary
  i= s automatically defined (i.e. without human intervention) and how forwarding=
  works for scope 0x03.  One suggested definition i= s that Realm-Local applies
  to links where a single inte= rface may belong to multiple Link-Local scopes."
    &nb= sp;
      This argument was made some time ag= o and rejected.   The purpose in defining and using a realm scoped addr= ess is to allow for automatic definition.

<= /div>
I think I'm just confused about the desire for automatic definition of the = Realm-Local
scope and the several statements in the draft that it's admin= istratively configured.
Asking as an implementer, how do I determine whe= ther an interface is in a Realm-
Local zone?  Is it particular to LLN links?

I'm not = sure whether the draft is intending to reserve the ability to configure whic= h
links are in the MPLInterfaceSet.  However it seems that Realm-Loc= al scope, like
other multicast scopes, must have a consistent = definition for any and all protocols
that use it.
 
The forwarding defini= tion in the Trickle Multicast draft is by MPL Domain so the definition at th= e end of the paragraph above is not needed.   When using FF03::FC (defi= ned for forwarding within a MPL Domain) then all members of the MPL Domain a= re forwarded a copy of the multicast transmission.  Section 7.2 especia= lly makes this clear, by interface, by defining:
   MPLInterf=
aceSet  - a set of MPL Interfaces that subscribe to the MPL
          Domain Address that identifies the MPL Domain.
3)  - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN para= meters
  described in section 5.5 will ultima= tely have to be expressed in units of time
  (either in t= his document or elsewhere) for a given link-layer in order to avoid
 = ; the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2].  The = same
  reference states: "a protocol SHOULD set k and Imin such that= Imin is at least
  two to three times as long as it takes to transmit k packets."
=

     Since we are using these param= eters as defined in RFC 6206 (Trickle Algorithm) we should not attempt to re= define them here in this draft.

= Do the terms "expected link-layer latency" and "worst-case link-layer latenc= y"
(used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,=
respectively) have commonly defined definitions, e.g. in 802.15.4? = If so,
what are they?  I couldn't seem to determine this from the 802.15.4 sp= ec.

Thanks, -K-
 

Don


<= span>
From: Kerry Lynn <<= a href=3D"mailto:kerlyn@ieee.org" target=3D"_blank">kerlyn@ieee.org>
<= span style=3D"font-weight:bold">Reply-To: Routing Over Low power and L= ossy networks <roll@ietf.o= rg>
Date: Friday, September= 13, 2013 5:10 AM
To: Routing Over= Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-= 05

On Wed, Sep 4= , 2013 at 3:45 PM, Michael Richardson <mcr+ietf@sandelman.ca> wr= ote:

A number of issues were raised this past spring by IESG and other reviewers=
on draft-ietf-roll-trickle-mcast.  You can review them using the custo= m query:

http://trac.tools.ietf.org/wg/roll/trac/query?st= atus=3Dassigned&status=3Dclosed&status=3Dnew&status=3Dreopened&compo= nent=3Dtrickle-mcast&group=3Dcomponent&col=3Did&col=3Dsummary&col=3Dco= mponent&col=3Dstatus&col=3Dtype&col=3Dpriority&col=3Dmilestone&o= rder=3Dpriority

The chairs, Document Shephard and Document Authors believe that current
= issues are closed in the -05 revision at:
       https://datatracker.ietf.org/doc/d= raft-ietf-roll-trickle-mcast/
A diff is available at:
       https://www.ietf.org/rfcdiff= ?url1=3Ddraft-ietf-roll-trickle-mcast-04&difftype=3D--html&submit=3DGo%21&= amp;url2=3Ddraft-ietf-roll-trickle-mcast-05

We are starting another WG Last Call.
It will run until Friday 2013-09-13 at 9am EST.

Please read the document.  Do you concur that it is done?
Please post any and all comments.
 
The draft is looking good, but I have a few comment= s.
 
Editorial:

- In section = 4.3, on Proactive Forwarding, the phrase "MPL Data Message message"
  is redundant and should be "MPL Data Message".

- In the last paragraph of section 4.3 the phrase "a new MPL Data messages= "
  should be "a new MPL Data Message".

- [I-D.droms-6man-multicast-scopes] should be moved from section 14.1= to 14.2.


Technical:

- I have argued that to increase MPL's applicability, PROACTIVE_FORWARDIN= G
  should be a per-interface and not a per-forwarder set= ting.  I can imagine, for
  example, a router that h= as both LLN and traditional interfaces and proactive
  fo= rwarding seems unnecessary for the latter.  As [RFC 4007] states: "Zone=
  boundaries cut through nodes, not links."  Sugges= ted wording in section 5.4
  could be "PROACTIVE_FORWARDI= NG has a default value of TRUE on links
  where Realm-Loc= al scope is defined, and FALSE otherwise."

- Se= ction 4.1 states: "When used with MPL, Realm-Local scope is administratively=
  defined and used to define the boundaries of multicast= message dissemination
  by MPL."  This begs the que= stion, why don't we just use scope =3D 0x04?  We
  pro= bably need more discussion on if and how a scope 0x03 zone boundary
  is automatically defined (i.e. without human intervention) and = how forwarding
  works for scope 0x03.  One suggeste= d definition is that Realm-Local applies
  to links where= a single interface may belong to multiple Link-Local scopes.
=
- The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters
  described in section 5.5 will ultimately have to be expr= essed in units of time
  (either in this document or else= where) for a given link-layer in order to avoid
  the "Mismatched mi= n" issues discussed in [RFC 6206, sect. 6.2].  The same
  refer= ence states: "a protocol SHOULD set k and Imin such that Imin is at least   two to three times as long as it takes to transmit k packets."

Regards, -K-

 
If there is something you do not like, please provide a suggestion (a diff)=
about what to fix.

Thank you.

Michael and JP.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/=


______________________________________________= _
Roll mailing list
Roll@ie= tf.org
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________ Roll mailing list Roll@ietf.orghttps://www.ietf.o= rg/mailman/listinfo/roll

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

=
_______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll
--B_3461903126_431668-- From kerlyn2001@gmail.com Fri Sep 13 10:02:06 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D50D11E80FC for ; Fri, 13 Sep 2013 10:02:06 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIfv99W5whCQ for ; Fri, 13 Sep 2013 10:02:05 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9626311E816D for ; Fri, 13 Sep 2013 10:02:04 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id o20so1395603oag.19 for ; Fri, 13 Sep 2013 10:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=zni9U3a3ZN02/edp3gVct3mdKDIuE78NVev3StZKbmE=; b=Ij10atOyLVEeFCm7TR1rApIh1nguO9MJm7SlODMMLCfbhOYH9AZbRLuD50ZEX5oAQD RDmM36w7LCMDJKcHcNE1FaliczJ/6hnZa8jlLBojEKz/A9qdiaymZMabMYn7YKeg23P7 PAg99x4PvSxEjohiTAAZgRxOw75hyiaVlDzEyMxfpfpLyt7ebFkJYzlvOEdM9GXh6N1H 2+k6y6uQuV7BFz22zo42k+hDJpucMs+kvDgxXtJjJBjJ5jr9Cv+52B8KnHD+T6A0oi2Z PsGHB6LbC8Hgvb//Wgcv+nyL5HkqzLdI72TzR7CQpYKXxczRLC4Q0qqNDvCSBUK+I4Dt qTsg== MIME-Version: 1.0 X-Received: by 10.60.60.5 with SMTP id d5mr13236424oer.0.1379091724063; Fri, 13 Sep 2013 10:02:04 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.41.36 with HTTP; Fri, 13 Sep 2013 10:02:03 -0700 (PDT) In-Reply-To: <10304.1379081034@sandelman.ca> References: <10304.1379081034@sandelman.ca> Date: Fri, 13 Sep 2013 13:02:03 -0400 X-Google-Sender-Auth: sRC9zML6GCnFvCyqmy8kwbA01_o Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e0149c3c05378ef04e646d014 Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 17:02:06 -0000 --089e0149c3c05378ef04e646d014 Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, On Fri, Sep 13, 2013 at 10:03 AM, Michael Richardson wrote: > > Don Sturek wrote: > > 1) "- I have argued that to increase MPL's applicability, > > PROACTIVE_FORWARDING should be a per-interface and not a > per-forwarder > > setting. I can imagine, for example, a router that has both LLN and > > I think that the IETF *functional requirements* question is really: > Can an implementer make it per-interface without having an impact on > the implementation in other nodes? > > If the answer is, there is no impact, then it really doesn't matter. > Other "ip-forwarding" settings have been described as per-router and > generalized into per-interface many times before. > > Experience shows that tuning parameters are not always exposed by a given implementation and even when they are, they are most likely left at their default value. My concern is that the suggested default for this parameter may lead to suboptimal behavior on non-LLN links (by ensuring straight flooding for some number of intervals). Even if there is "room for interpretation" on considering this a per-interface parameter, the correct default needs to be specified in this draft or else a BCP or something will be necessary. It would be good to hear Jonathan's opinion... I have added your comments to ticket #103, which I re-opened. > I will close it again today --- I would appreciate comments in the mailing > list as to whether there is anything to fix here. > > > 2) "- Section 4.1 states: "When used with MPL, Realm-Local scope is > > administratively defined and used to define the boundaries of > multicast > > message dissemination by MPL." This begs the question, why don't we > > just use scope = 0x04? We probably need more discussion on if and > how > > a scope 0x03 zone boundary is automatically defined (i.e. without > human > > intervention) and how forwarding works for scope 0x03. One suggested > > definition is that Realm-Local applies to links where a single > > interface may belong to multiple Link-Local scopes." > > I have added your text to ticket #132, and re-opened it. > I would like to close it today. > > I think that we are not using scope 4 because we are able to automatically > define the edge. Can you suggest some text would permit MPL to > automatically > define the scope based upon the flood of the prefix found in the DIO PIO? > Is that what you had in mind? > > Let me try to be more clear. Perhaps I'm reading too literally, but there seems to be a conflict between the "administratively configured" language of this draft and the "automatically configured" language of Ralph's draft. I'd just like to remove the contradiction (if indeed there is one). A link-local zone boundary, for example, occurs at the router because of the way forwarding rules are defined in [RFC 4291, sect. 2.5.6]. If we have similar clarity around defining the boundary of a realm-local zone, then it seems to me the "administratively defined" language can be removed from MPL as it relates to realm-scope. > > not needed. When using FF03::FC (defined for forwarding within a MPL > > Domain) then all members of the MPL Domain are forwarded a copy of > the > > multicast transmission. Section 7.2 especially makes this clear, by > > interface, by defining: > > I think that you haven't answer the question, just swapped "Real-Local > scope" > for "MPL Domain" > > That was Don's comment to my comment. > > 3) - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters > > described in section 5.5 will ultimately have to be expressed in > units > > of time (either in this document or elsewhere) for a given link-layer > > in order to avoid the "Mismatched min" issues discussed in [RFC 6206, > > sect. 6.2]. The same reference states: "a protocol SHOULD set k and > > Imin such that Imin is at least two to three times as long as it > takes > > to transmit k packets." > > I'm suffering from unclosed quotes here. > The first one is spurious. > I don't see section 5.5 as redefining the parameters at all. It seems > to just re-iterate them. What is the suggested remedy here? > > [RFC 6206, sect. 5] says "the default value of Imin SHOULD be specified in terms of the worst-case latency of a link-layer transmission." I'm simply asking where one goes to find, e.g., the worst-case link-layer latency of 802.15.4. Perhaps the remedy is to include this value in Applicability Statements as has been agreed for hop limit values. I think it's important that all forwarders in a MPL Domain agree on this value but I was wrong in my earlier comment about the reason. It's not RFC 6206, sect. 6.2] that applies, but [RFC 6206, sect. 6.3] (since Imax is equal to Imin). Regards, -K- > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > > > -- > Michael Richardson , Sandelman Software Works > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --089e0149c3c05378ef04e646d014 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael,

On Fri, Sep 13, 2013 at 10:03 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Don Sturek <d.sturek@att.net>= wrote:
=A0 =A0 > 1) "- I have argued that to increase MPL's applicabil= ity,
=A0 =A0 > PROACTIVE_FORWARDING should be a per-interface and not a per-f= orwarder
=A0 =A0 > setting. =A0I can imagine, for example, a router that has both= LLN and

I think that the IETF *functional requirements* question is really: =A0 Can an implementer make it per-interface without having an impact on =A0 the implementation in other nodes?

If the answer is, there is no impact, then it really doesn't matter. Other "ip-forwarding" settings have been described as per-router = and
generalized into per-interface many times before.

Experience shows that tuning parameters are not alway= s exposed by a
given implementation and even when they are, t= hey are most likely left
at their default value.
=A0
My concern is that the suggested default for this parameter may = lead to
suboptimal behavior on non-LLN links (by ensuring straight flood= ing for
some number of intervals).

Even if there is &q= uot;room for interpretation" on considering this a per-interface
parameter, the correct default needs to be specified in this draft or else = a
BCP or something will be necessary.

It wo= uld be good to hear Jonathan's opinion...

I have added your comments to ticket #103, which I re-opened.
I will close it again today --- I would appreciate comments in the mailing<= br> list as to whether there is anything to fix here.

=A0 =A0 > 2) "- Section 4.1 states: "When used with MPL, Realm= -Local scope is
=A0 =A0 > administratively defined and used to define the boundaries of = multicast
=A0 =A0 > message dissemination by MPL." =A0This begs the question,= why don't we
=A0 =A0 > just use scope =3D 0x04? =A0We probably need more discussion o= n if and how
=A0 =A0 > a scope 0x03 zone boundary is automatically defined (i.e. with= out human
=A0 =A0 > intervention) and how forwarding works for scope 0x03. =A0One = suggested
=A0 =A0 > definition is that Realm-Local applies to links where a single=
=A0 =A0 > interface may belong to multiple Link-Local scopes."

I have added your text to ticket #132, and re-opened it.
I would like to close it today.

I think that we are not using scope 4 because we are able to automatically<= br> define the edge. =A0Can you suggest some text would permit MPL to automatic= ally
define the scope based upon the flood of the prefix found in the DIO PIO? Is that what you had in mind?

Let me try to be more clear.= =A0 Perhaps I'm reading too literally, but there seems
to= be a conflict between the "administratively configured" language= of this draft
and the "automatically configured" language of Ralph&#= 39;s draft.=A0 I'd just like to
remove the contradiction (if indeed = there is one).

A link-local zone boundary, for example, occurs at th= e router because of the way
forwarding rules are defined in [RFC 4291, sect. 2.5.6]. If we have similar= clarity
around defining the boundary of a realm-local zone, then it see= ms to me the
"administratively defined" language can be remove= d from MPL as it relates to
realm-scope.
=A0
=A0 =A0 > not needed. =A0When using FF03::FC (defined for forwarding wit= hin a MPL
=A0 =A0 > Domain) then all members of the MPL Domain are forwarded a cop= y of the
=A0 =A0 > multicast transmission. =A0Section 7.2 especially makes this c= lear, by
=A0 =A0 > interface, by defining:

I think that you haven't answer the question, just swapped "= Real-Local scope"
for "MPL Domain"

That was Don's comment to= my comment.
=A0
=A0 =A0 > 3) - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN para= meters
=A0 =A0 > described in section 5.5 will ultimately have to be expressed = in units
=A0 =A0 > of time (either in this document or elsewhere) for a given lin= k-layer
=A0 =A0 > in order to avoid the "Mismatched min" issues discus= sed in [RFC 6206,
=A0 =A0 > sect. 6.2]. =A0The same reference states: "a protocol SHO= ULD set k and
=A0 =A0 > Imin such that Imin is at least two to three times as long as = it takes
=A0 =A0 > to transmit k packets."

I'm suffering from unclosed quotes here.
The first one is spurious.
=A0
I don't see section 5.5 as redefining the parameters at all. It seems to just re-iterate them. =A0What is the suggested remedy here?

[RFC 6206, sect. 5] says "the default value of I= min SHOULD be specified in terms
of the worst-case latency of a link-lay= er transmission."=A0 I'm simply asking where
one goe= s to find, e.g., the worst-case link-layer latency of 802.15.4.=A0 Perhaps = the
remedy is to include this value in Applicability Statements as h= as been agreed for
hop limit values.=A0 I think it's impo= rtant that all forwarders in a MPL Domain agree
on this value= but I was wrong in my earlier comment about the reason.=A0 It's not RFC 6206, sect. 6.2] that applies, but [RFC 6206, sect. 6.3] (since Imax is= equal
to Imin).

Regards, -K-
=A0
--
] =A0 =A0 =A0 =A0 =A0 =A0 =A0 Never tell me the odds! =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | ipv6 mesh networks [
] =A0 Michael Richardson, Sandelman Software Works =A0 =A0 =A0 =A0| network= architect =A0[
] =A0 =A0 mcr@sandelman.ca =A0http://www.sandelman.ca/<= /a> =A0 =A0 =A0 =A0| =A0 ruby on rails =A0 =A0[



--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works



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


--089e0149c3c05378ef04e646d014-- From kerlyn2001@gmail.com Fri Sep 13 10:56:38 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02E221F9FA4 for ; Fri, 13 Sep 2013 10:56:37 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HJgvyYoUmUn for ; Fri, 13 Sep 2013 10:56:34 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5302211E816D for ; Fri, 13 Sep 2013 10:56:30 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id uy5so1387541obc.37 for ; Fri, 13 Sep 2013 10:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=gG2FcX7RVVn4HItmxhL2nrCZ++RJW6Vc2Ru2yfeEIE8=; b=BBgEYNT0zICu4u7A8VtqjNpUHjO9gbsXqTIjlWgAiF+OU04NkhHQ6VK0WgVxJbYIgM 3gf996CA8g5toiLzLtmGP/na7w9FAA3XwT0X3HVtO0hqErLm6MTwT10ENd4P55qoEuhK smhftbnb3+F8QvdA1KI7SF82cZBv/nxaz8kU1j+oT6POw8ONcS+b6FdVqhwjWZMR0jKm Lc34z2DOia+bHdrlESEP9uLaudD/Dp3ZVLhGh6Bfw/U6CY0Q3o7bKHiVIBx39UoIpKNR LOZbK366/7tmkVu7Injnf2jooQZBArdRZkO/r5dyy/CYURyJlZRRAmJ4EVWfQz3YaLl9 OVtA== MIME-Version: 1.0 X-Received: by 10.182.148.69 with SMTP id tq5mr1496821obb.97.1379094988717; Fri, 13 Sep 2013 10:56:28 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.41.36 with HTTP; Fri, 13 Sep 2013 10:56:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Sep 2013 13:56:28 -0400 X-Google-Sender-Auth: F3FnzSEtBHATnYNkpjueFYZUB5c Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e013a0ad0ea05ec04e64792bb Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 17:56:38 -0000 --089e013a0ad0ea05ec04e64792bb Content-Type: text/plain; charset=ISO-8859-1 Don, thanks for your additional comments... On Fri, Sep 13, 2013 at 10:45 AM, Don Sturek wrote: > Hi Kerry, > > Two points from below: > 1) "Asking as an implementer, how do I determine whether an interface is > in a Realm- > Local zone? Is it particular to LLN links?" > > As with other multicast addresses, an interface would register > (opt-in) to a realm. For Trickle Multicast, it would then depend on > whether the interface has subscribed to the MPL Domain Address. The > difference between using realm scoped (from Ralph's draft) and > administratively scoped (FF04) is the membership in the MPL Domain can be > managed automatically by actions within the device. > > I'm willing to accept that I may be the only one who's confused. Let me illustrate with an example: (A)-BR1---BR2-(B) Let's say we have two LLNs, A and B, connected by BRs and a traditional link like WiFi or ethernet. Further, there are MPL forwarders deployed in both A and B. (I'd imagine that the LLN interfaces on the BRs are MPL forwarders.) Are there two separate realm-local zones? If that is the case then it seems there should be some intrinsic property that allows a router to determine if a link is in the scope zone or not. For example, if we were talking about link- local scope zones and the example about consisted of traditional links and routers, then the scope boundaries would be defined as cutting through the routers and would be the same for all link-local multicast protocols. That is, there would be no inter-connectivity between a node in A and a node in B that were subscribed to the same multicast group. I'm mainly interested in resolving the apparent contradiction between the "administratively configured" language in the MPL draft and the "automatically configured" language in Ralph's draft (and in your comment). 2) "Do the terms "expected link-layer latency" and "worst-case link-layer > latency" > (used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN, > respectively) have commonly defined definitions, e.g. in 802.15.4? If so, > what are they? I couldn't seem to determine this from the 802.15.4 spec." > > The simple answer to this is there is not a prescribed layer 2 > latency value for 802.15.4 other than the defined one hop ACK latency if > you use MAC Acknowledges. Just FYI, in testing IEEE 802.15.4-2003/2006 > (127 byte PDU) with just 2 devices on a clear channel, we found a > typical "one hop/one packet " message latency to be around 4ms (without > security) and around 12 ms (using SW based security). In my experience, > the "expected link layer latency" and "worst case link layer latency" > (speaking strictly about the link layer only) are just a single aspect to > setting IMIN correctly. The overall application message pattern plays a > larger role for these settings (for example, how frequently multicasts are > generated, how many simultaneous multicasts can be generated within a given > MPL Domain in a window of time that occurs within IMIN, etc.). > Additionally, another major driver to these settings are the deployment > characteristics of the MPL Domain member devices (for example. how many > incoming message buffers are supported in the member devices MAC, how many > outgoing message buffers, etc.). Perhaps the names "expected link layer > latency" and "worst case link layer latency" are a bit misleading since > they sound like fixed settings that would be applicable to all links of a > given type when I think they are trying to describe the link layer > performance with a given messaging profile in operation. > > Do you agree that all nodes in a given LLN SHOULD agree on a common value for Imin? I don't have any problem with declaring it out of scope for the present draft, but practically speaking it seems there should be a way to a) define a reasonable default for a given link layer, and b) distribute a modified value (I think Yusuke Doi is working on a DHCPv6 option for MPL parameters). Regards, -K- > Don > > > From: Kerry Lynn > Reply-To: Routing Over Low power and Lossy networks > Date: Friday, September 13, 2013 6:58 AM > > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] WGLC - Working Group Last Call - > draft-ietf-roll-trickle-mcast-05 > > Hi Don, > > On Fri, Sep 13, 2013 at 9:21 AM, Don Sturek wrote: > >> I don't agree with the proposed technical changes below, specifically: >> 1) "- I have argued that to increase MPL's applicability, >> PROACTIVE_FORWARDING >> should be a per-interface and not a per-forwarder setting. I can >> imagine, for >> example, a router that has both LLN and traditional interfaces and >> proactive >> forwarding seems unnecessary for the latter. As [RFC 4007] states: >> "Zone >> boundaries cut through nodes, not links." Suggested wording in section >> 5.4 >> could be "PROACTIVE_FORWARDING has a default value of TRUE on links >> where Realm-Local scope is defined, and FALSE otherwise." >> >> Given how forwarding is defined in the draft, I don't see how the >> scenario above is possible unless the links on the "traditional interfaces" >> happen to be members of the same MPL Domain as the LLN >> > > I am looking at section 3, Applicability Statement, which says: "This > protocol > may also be used in environments where only a subset of links are > considered > Low-Power and Lossy links." The change I proposed is minimal and would > improve dynamic protocol behavior on non-LLN links. > >> >> 2) "- Section 4.1 states: "When used with MPL, Realm-Local scope is >> administratively >> defined and used to define the boundaries of multicast message >> dissemination >> by MPL." This begs the question, why don't we just use scope = 0x04? >> We >> probably need more discussion on if and how a scope 0x03 zone boundary >> is automatically defined (i.e. without human intervention) and how >> forwarding >> works for scope 0x03. One suggested definition is that Realm-Local >> applies >> to links where a single interface may belong to multiple Link-Local >> scopes." >> >> This argument was made some time ago and rejected. The purpose in >> defining and using a realm scoped address is to allow for automatic >> definition. >> > > I think I'm just confused about the desire for automatic definition of the > Realm-Local > scope and the several statements in the draft that it's administratively > configured. > Asking as an implementer, how do I determine whether an interface is in a > Realm- > Local zone? Is it particular to LLN links? > > I'm not sure whether the draft is intending to reserve the ability to > configure which > links are in the MPLInterfaceSet. However it seems that Realm-Local > scope, like > other multicast scopes, must have a consistent definition for any and all > protocols > that use it. > > >> The forwarding definition in the Trickle Multicast draft is by MPL Domain >> so the definition at the end of the paragraph above is not needed. When >> using FF03::FC (defined for forwarding within a MPL Domain) then all >> members of the MPL Domain are forwarded a copy of the multicast >> transmission. Section 7.2 especially makes this clear, by interface, by >> defining: >> >> MPLInterfaceSet - a set of MPL Interfaces that subscribe to the MPL >> Domain Address that identifies the MPL Domain. >> >> >> 3) - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters >> described in section 5.5 will ultimately have to be expressed in units >> of time >> (either in this document or elsewhere) for a given link-layer in order >> to avoid >> the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The >> same >> reference states: "a protocol SHOULD set k and Imin such that Imin is >> at least >> two to three times as long as it takes to transmit k packets." >> >> Since we are using these parameters as defined in RFC 6206 (Trickle >> Algorithm) we should not attempt to redefine them here in this draft. >> > > Do the terms "expected link-layer latency" and "worst-case link-layer > latency" > (used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN, > respectively) have commonly defined definitions, e.g. in 802.15.4? If so, > what are they? I couldn't seem to determine this from the 802.15.4 spec. > > Thanks, -K- > > >> >> Don >> >> >> From: Kerry Lynn >> Reply-To: Routing Over Low power and Lossy networks >> Date: Friday, September 13, 2013 5:10 AM >> To: Routing Over Low power and Lossy networks >> Subject: Re: [Roll] WGLC - Working Group Last Call - >> draft-ietf-roll-trickle-mcast-05 >> >> On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson > > wrote: >> >>> >>> A number of issues were raised this past spring by IESG and other >>> reviewers >>> on draft-ietf-roll-trickle-mcast. You can review them using the custom >>> query: >>> >>> >>> http://trac.tools.ietf.org/wg/roll/trac/query?status=assigned&status=closed&status=new&status=reopened&component=trickle-mcast&group=component&col=id&col=summary&col=component&col=status&col=type&col=priority&col=milestone&order=priority >>> >>> The chairs, Document Shephard and Document Authors believe that current >>> issues are closed in the -05 revision at: >>> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ >>> A diff is available at: >>> >>> https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-trickle-mcast-04&difftype=--html&submit=Go%21&url2=draft-ietf-roll-trickle-mcast-05 >>> >>> We are starting another WG Last Call. >>> It will run until Friday 2013-09-13 at 9am EST. >>> >>> Please read the document. Do you concur that it is done? >>> Please post any and all comments. >>> >> >> The draft is looking good, but I have a few comments. >> >> Editorial: >> >> - In section 4.3, on Proactive Forwarding, the phrase "MPL Data Message >> message" >> is redundant and should be "MPL Data Message". >> >> - In the last paragraph of section 4.3 the phrase "a new MPL Data >> messages" >> should be "a new MPL Data Message". >> >> - [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 to >> 14.2. >> >> >> Technical: >> >> - I have argued that to increase MPL's applicability, PROACTIVE_FORWARDING >> should be a per-interface and not a per-forwarder setting. I can >> imagine, for >> example, a router that has both LLN and traditional interfaces and >> proactive >> forwarding seems unnecessary for the latter. As [RFC 4007] states: >> "Zone >> boundaries cut through nodes, not links." Suggested wording in section >> 5.4 >> could be "PROACTIVE_FORWARDING has a default value of TRUE on links >> where Realm-Local scope is defined, and FALSE otherwise." >> >> - Section 4.1 states: "When used with MPL, Realm-Local scope is >> administratively >> defined and used to define the boundaries of multicast message >> dissemination >> by MPL." This begs the question, why don't we just use scope = 0x04? >> We >> probably need more discussion on if and how a scope 0x03 zone boundary >> is automatically defined (i.e. without human intervention) and how >> forwarding >> works for scope 0x03. One suggested definition is that Realm-Local >> applies >> to links where a single interface may belong to multiple Link-Local >> scopes. >> >> - The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters >> described in section 5.5 will ultimately have to be expressed in units >> of time >> (either in this document or elsewhere) for a given link-layer in order >> to avoid >> the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The >> same >> reference states: "a protocol SHOULD set k and Imin such that Imin is >> at least >> two to three times as long as it takes to transmit k packets." >> >> Regards, -K- >> >> >> >>> If there is something you do not like, please provide a suggestion (a >>> diff) >>> about what to fix. >>> >>> Thank you. >>> >>> Michael and JP. >>> >>> -- >>> Michael Richardson , Sandelman Software Works >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >> _______________________________________________ Roll mailing list >> Roll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --089e013a0ad0ea05ec04e64792bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Don, thanks for your additional comments...

On Fri, Sep 13, 2013 at 10:45 AM, Don Sturek <d.st= urek@att.net> wrote:
Hi = Kerry,

Two points from below:
1) =A0"Asking as = an implementer, how do I determine whether an interface is in a Realm-
Local zone?=A0 Is it particular to LLN links?"
=
=A0 =A0 =A0 =A0As with other multicast addresses, an inter= face would register (opt-in) to a realm. =A0 For Trickle Multicast, it woul= d then depend on whether the interface has subscribed to the MPL Domain Add= ress. =A0The difference between using realm scoped (from Ralph's draft)= and administratively scoped (FF04) is the membership in the MPL Domain can= be managed automatically by actions within the device.

I'm willing to accept that I may= be the only one who's confused.=A0 Let me illustrate
wit= h an example:

(A)-BR1---BR2-(B)

Let'= ;s say we have two LLNs, A and B, connected by BRs and a traditional link like WiFi or ethernet.=A0 Further, there are MPL forwarders deployed in bot= h A
and B.=A0 (I'd imagine that the LLN interfaces on the= BRs are MPL forwarders.)
Are there two separate realm-local zones?=A0 I= f that is the case then it seems
there should be some intrinsic property that allows a router to = determine if a
link is in the scope zone or not.=A0 For examp= le, if we were talking about link-
local scope zones and the example abo= ut consisted of traditional links and
routers, then the scope boundaries would be defined as cutting through the<= br>routers and would be the same for all link-local multicast protocols.=A0= That is,
there would be no inter-connectivity between a node= in A and a node in B that
were subscribed to the same multicast group.

I= 'm mainly interested in resolving the apparent contradiction between th= e
"administratively configured" language in the MPL= draft and the "automatically
configured" language in Ralph's draft (and in your comm= ent).


2) =A0"Do the terms "expected link-layer latency&= quot; and "worst-case link-layer latency"
(= used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,
respectively)= have commonly defined definitions, e.g. in 802.15.4?=A0 If so,
what are they?=A0 I couldn't seem to determine this from the 802.15.4 s= pec."

=A0 =A0 =A0The simple answer to t= his is there is not a prescribed layer 2 latency value for 802.15.4 other t= han the defined one hop ACK latency if you use MAC Acknowledges. =A0Just FY= I, in testing IEEE 802.15.4-2003/2006 (127 byte PDU) with just 2 devices on= a clear channel, we found a typical=A0"one hop/one packet " mess= age latency to be around 4ms (without security) and around 12 ms (using SW = based security). =A0In my experience, the "expected link layer latency= " and "worst case link layer latency" (speaking strictly abo= ut the link layer only) are just a single aspect to setting IMIN correctly.= =A0 The overall application message pattern plays a larger role for these = settings (for example, how frequently multicasts are generated, how many si= multaneous multicasts can be generated within a given MPL Domain in a windo= w of time that occurs within IMIN, etc.). =A0Additionally, another major dr= iver to these settings are the deployment characteristics of the MPL Domain= member devices (for example. how many incoming message buffers are support= ed in the member devices MAC, how many outgoing message buffers, etc.). =A0= Perhaps the names "expected link layer latency" and "worst c= ase link layer latency" are a bit misleading since they sound like fix= ed settings that would be applicable to all links of a given type when I th= ink they are trying to describe the link layer performance with a given mes= saging profile in operation.

Do you agree that all nodes in= a given LLN SHOULD agree on a common
value for Imin?=A0 I don't hav= e any problem with declaring it out of scope for
the present draft, but = practically speaking it seems there should be a way to
a) define a reasonable default for a given link layer, and b) di= stribute a modified
value (I think Yusuke Doi is working on a DHCPv6 opt= ion for MPL parameters).

Regards, -K-
=A0
Don


=
From: Kerry Lynn= <kerlyn@ieee.org>
Reply-To: Routing Over L= ow power and Lossy networks <roll@ietf.org>
Date: Friday, September 13, = 2013 6:58 AM

To:= Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] WGLC - Working= Group Last Call - draft-ietf-roll-trickle-mcast-05

Hi Don,

On= Fri, Sep 13, 2013 at 9:21 AM, Don Sturek <d.sturek@att.net> = wrote:
I don't agree with the proposed technical changes below, specifica= lly:
1) =A0"- I have argued that to increase MPL's appli= cability, PROACTIVE_FORWARDING
=A0 should be a per-interface= and not a per-forwarder setting.=A0 I can imagine, for
=A0 example, a router that has both LLN and traditional interfac= es and proactive
=A0 forwarding seems unnecessary for the lat= ter.=A0 As [RFC 4007] states: "Zone
=A0 boundaries cut t= hrough nodes, not links."=A0 Suggested wording in section 5.4
=A0 could be "PROACTIVE_FORWARDING has a default value of T= RUE on links
=A0 where Realm-Local scope is defined, and FALS= E otherwise."

=A0 =A0 Given how forward= ing is defined in the draft, I don't see how the scenario above is poss= ible unless the links on the "traditional interfaces" happen to b= e members of the same MPL Domain as the LLN

I am looking at section 3, Applicabi= lity Statement, which says: "This protocol
may also be u= sed in environments where only a subset of links are considered
Low-Power and Lossy links."=A0 The change I proposed is minimal a= nd would
improve dynamic protocol behavior on non-LLN links. =

2) =A0"- Section 4.1 states: "When u= sed with MPL, Realm-Local scope is administratively
=A0 defined and used to define the boundaries of multicast message dissemin= ation
=A0 by MPL."=A0 This begs the question, why don= 9;t we just use scope =3D 0x04?=A0 We
=A0 probably need more = discussion on if and how a scope 0x03 zone boundary
=A0 is automatically defined (i.e. without human intervention) a= nd how forwarding
=A0 works for scope 0x03.=A0 One suggested = definition is that Realm-Local applies
=A0 to links where a s= ingle interface may belong to multiple Link-Local scopes."
=A0 =A0 =A0
=A0 =A0 =A0 This argument was made some ti= me ago and rejected. =A0 The purpose in defining and using a realm scoped a= ddress is to allow for automatic definition.
<= br>
I think I'm just confused about the desire for automatic definition of = the Realm-Local
scope and the several statements in the draft that it= 9;s administratively configured.
Asking as an implementer, how do I det= ermine whether an interface is in a Realm-
Local zone?=A0 Is it particular to LLN links?

I'm not= sure whether the draft is intending to reserve the ability to configure wh= ich
links are in the MPLInterfaceSet.=A0 However it seems that Realm-Loc= al scope, like
other multicast scopes, must have a consistent definition for an= y and all protocols
that use it.
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
The forwarding definition in the Trickle Multicast draft is b= y MPL Domain so the definition at the end of the paragraph above is not nee= ded. =A0 When using FF03::FC (defined for forwarding within a MPL Domain) t= hen all members of the MPL Domain are forwarded a copy of the multicast tra= nsmission. =A0Section 7.2 especially makes this clear, by interface, by def= ining:
   MPLInterfaceSet  - a set of MPL Interfaces that subscribe to t=
he MPL
          Domain Address that identifies the MPL Domain.
3) =A0- "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN p= arameters
=A0 described in section 5.5 will ultimately have = to be expressed in units of time
=A0 (either in this document or elsewhere) for a given link-laye= r in order to avoid
=A0 the "Mismatched min" issues discussed = in [RFC 6206, sect. 6.2].=A0 The same
=A0 reference states: "a prot= ocol SHOULD set k and Imin such that Imin is at least
=A0 two to three times as long as it takes to transmit k packets."

=A0 =A0 =A0Since we are using these parameters = as defined in RFC 6206 (Trickle Algorithm) we should not attempt to redefin= e them here in this draft.

Do the terms "expected link-lay= er latency" and "worst-case link-layer latency"
(used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,
respective= ly) have commonly defined definitions, e.g. in 802.15.4?=A0 If so,
what are they?=A0 I couldn't seem to determine this from the 802.15.4 s= pec.

Thanks, -K-
=A0

Don


<= div>
From: Kerry Lynn <kerlyn@ieee.org>
Reply-To: Routing Over Low power and Lossy= networks <roll@ietf.= org>
Date: Friday, September 13, 2013 5= :10 AM
To: Routing Over Low pow= er and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] WGLC - Working= Group Last Call - draft-ietf-roll-trickle-mcast-05

On Wed, Sep = 4, 2013 at 3:45 PM, Michael Richardson <mcr+ietf@sandelman.ca><= /span> wrote:

A number of issues were raised this past spring by IESG and other reviewers=
on draft-ietf-roll-trickle-mcast. =A0You can review them using the custom q= uery:

http://trac.to= ols.ietf.org/wg/roll/trac/query?status=3Dassigned&status=3Dclosed&s= tatus=3Dnew&status=3Dreopened&component=3Dtrickle-mcast&group= =3Dcomponent&col=3Did&col=3Dsummary&col=3Dcomponent&col=3Ds= tatus&col=3Dtype&col=3Dpriority&col=3Dmilestone&order=3Dpri= ority

The chairs, Document Shephard and Document Authors believe that current
issues are closed in the -05 revision at:
=A0 =A0 =A0 =A0https://datatracker.ietf.org/doc/draft-ie= tf-roll-trickle-mcast/
A diff is available at:
=A0 =A0 =A0 =A0https://www.ietf.org/rfcdi= ff?url1=3Ddraft-ietf-roll-trickle-mcast-04&difftype=3D--html&submit= =3DGo%21&url2=3Ddraft-ietf-roll-trickle-mcast-05

We are starting another WG Last Call.
It will run until Friday 2013-09-13 at 9am EST.

Please read the document. =A0Do you concur that it is done?
Please post any and all comments.
=A0
The draft is looking good, but I have a few comments.<= br>
=A0
Editorial:

- In section 4.3, = on Proactive Forwarding, the phrase "MPL Data Message message"
=A0 is redundant and should be "MPL Data Message".
=
- In the last paragraph of section 4.3 the phrase "a ne= w MPL Data messages"
=A0 should be "a new MPL Data = Message".

- [I-D.droms-6man-multicast-scopes] should be moved fr= om section 14.1 to 14.2.


Technical:=

- I have argued that to increase MPL's applicability= , PROACTIVE_FORWARDING
=A0 should be a per-interface and not a per-forwarder setting.= =A0 I can imagine, for
=A0 example, a router that has both LL= N and traditional interfaces and proactive
=A0 forwarding see= ms unnecessary for the latter.=A0 As [RFC 4007] states: "Zone
=A0 boundaries cut through nodes, not links."=A0 Suggested = wording in section 5.4
=A0 could be "PROACTIVE_FORWARDIN= G has a default value of TRUE on links
=A0 where Realm-Local = scope is defined, and FALSE otherwise."

- Section 4.1 states: "When used with MPL, R= ealm-Local scope is administratively
=A0 defined and used to = define the boundaries of multicast message dissemination
=A0 = by MPL."=A0 This begs the question, why don't we just use scope = =3D 0x04?=A0 We
=A0 probably need more discussion on if and how a scope 0x03 zon= e boundary
=A0 is automatically defined (i.e. without human i= ntervention) and how forwarding
=A0 works for scope 0x03.=A0 = One suggested definition is that Realm-Local applies
=A0 to links where a single interface may belong to multiple Lin= k-Local scopes.

- The DATA_MESSAGE_IMIN and CO= NTROL_MESSAGE_IMIN parameters
=A0 described in section 5.5 wi= ll ultimately have to be expressed in units of time
=A0 (either in this document or elsewhere) for a given link-laye= r in order to avoid
=A0 the "Mismatched min" issues discussed = in [RFC 6206, sect. 6.2].=A0 The same
=A0 reference states: "a prot= ocol SHOULD set k and Imin such that Imin is at least
=A0 two to three times as long as it takes to transmit k packets."
=

Regards, -K-

=A0
If there is something you do not like, please provide a suggestion (a diff)=
about what to fix.

Thank you.

Michael and JP.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair. =A0 =A0http://datatracker.ietf.org/wg/roll/charter/<= /a>


______________________________________________= _
Roll mailing list
Rol= l@ietf.org
https://www.ietf.org/mailman/listinfo/roll


_______________________________________________ Roll mailing list Roll@ietf.orghttps://w= ww.ietf.org/mailman/listinfo/roll

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

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

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll
--089e013a0ad0ea05ec04e64792bb-- From rdroms.ietf@gmail.com Fri Sep 13 11:06:53 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0172E21E80DB for ; Fri, 13 Sep 2013 11:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mr2LpZD5H89d for ; Fri, 13 Sep 2013 11:06:52 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 19AD521F9AE3 for ; Fri, 13 Sep 2013 11:06:37 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id x12so1118466qcv.36 for ; Fri, 13 Sep 2013 11:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=0ktQcFMlxdAMybg2T9NfzCDLi4vKFOafs0uNK2DAUB4=; b=W5F6japxLbp4X8cqAd/0CxoqKOizI5vdf0uXkK472mAZk3Q3h7/WKEGYQofDxyBa7n xlJJrdwZUD/J/BLSYTt0jXNhM32spxq642EOIYsRvmRnC9/yLJujbR7AiqkWoUbCN3wc dksqc4ASJ2HPPrHA/vzCQL9Hgg5RrL/olcuRI3pO+ohAkTmrCs30RnBNd/EkkylTNR4S LJPCSIsmglydFfTYDyhQl5adJx4Pvyr+sNXV92Y1Bdmuqf6errbuXK7ikoqRxd+6PqKT L6y/GF7Q9ETQmb5v7MtIK6DUMZdzbYRbqLNRK/hIU4uDVAnhobdLSG35LgnrPl35bJyR LUSw== X-Received: by 10.49.27.137 with SMTP id t9mr27345494qeg.70.1379095595472; Fri, 13 Sep 2013 11:06:35 -0700 (PDT) Received: from che-vpn-cluster-2-366.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id a7sm21713515qew.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 11:06:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: Date: Fri, 13 Sep 2013 14:06:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3072B0E1-55AE-4DF7-8061-0B2A28961801@gmail.com> References: To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1508) Subject: Re: [Roll] comments for draft-gnawali-roll-rpl-recommendations? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 18:06:53 -0000 Interesting and useful doc. Unless explicitly noted, do the recommendations apply to both storing = and non-storing modes? Are your recommendations based on deployments, simulations, protocol = analysis? Do you have any references you can cite that provide the = input for your recommendations? - Ralph On Sep 13, 2013, at 2:14 AM 9/13/13, Omprakash Gnawali = wrote: > Dear ROLL WG, >=20 > I plan to update the draft-gnawali-roll-rpl-recommendations in the > next day or two. I would love to hear about any new/old/usual/unusual > experiences about RPL use so that I can collect those insights in this > draft to benefit everyone in the community. >=20 > Here is the URL to the current draft: > http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-03 >=20 > Thank you. >=20 > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Fri Sep 13 11:53:20 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87A821E80CF for ; Fri, 13 Sep 2013 11:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZvxhMrJXban for ; Fri, 13 Sep 2013 11:53:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 6A29121E80DB for ; Fri, 13 Sep 2013 11:53:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E83B320170 for ; Fri, 13 Sep 2013 16:01:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D4C7763AF0; Fri, 13 Sep 2013 14:53:04 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C33B963781 for ; Fri, 13 Sep 2013 14:53:04 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.77025347de98150b9e23fbe62aa3ea80@trac.tools.ietf.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 18:53:20 -0000 --=-=-= Kerry Lynn wrote: > Actually, that was my comment. Oh, sorry for he confusion. > It seems to me that the MPL draft and > draft-droms-6man-multicast-scopes-02 may be inconsistent in whether > Realm-Local scopes are administratively or automatically defined. I believe that droms-6man-multicast-scopes-02 is supposed to say that scope-3 is to be defined automatically by a process to be described by a user of it. And so trickle-mcast ought to define how to automatically define it. I think that it ought to be defined to be the boundary of the DAG that contains the same (/64) prefix. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUjNfDYqHRg3pndX9AQKykAP7BhTy19i885BnnHMvSYyJKLIhEYyCVkkO /bbSbsiAIxrnRfC25dqvDYQlvkTrViua3lt9+j6DW9qaJYTu3JorUQK60sC4XdyL AEjs3P/IRQ/7i2MYfdE/LH4BwxR2/gFlBHQO4uI152xv4gaaDBUUJAFmj2a4cL5T 4bjUCFZJVNU= =r6Hp -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Fri Sep 13 11:59:54 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF4211E81A7 for ; Fri, 13 Sep 2013 11:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fDdNCrcARZ9 for ; Fri, 13 Sep 2013 11:59:42 -0700 (PDT) Received: from nm23-vm3.access.bullet.mail.gq1.yahoo.com (nm23-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7D921F9D3B for ; Fri, 13 Sep 2013 11:58:37 -0700 (PDT) Received: from [216.39.60.167] by nm23.access.bullet.mail.gq1.yahoo.com with NNFMP; 13 Sep 2013 18:58:36 -0000 Received: from [67.195.23.146] by tm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 13 Sep 2013 18:58:36 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.gq1.yahoo.com with NNFMP; 13 Sep 2013 18:58:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1379098716; bh=J/tIPEqpMWkbF9fRR4t01jyy02OV5YgQaleJOuIo69o=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=wsHMBxjBgwwc/foTDLHhWzCagG4lZhNGCEs4231tZKb9u7WKFI7OYex2Xik/6m0GTIOIxQpGsWxXq7ASO/g5HYu34O8m51gtL9smXSbf87HScdhPoXYfQRsxv1BWzyHs7JAyfb3IdwYyEAylS9swZKkhEQNvqg3x529EPUUBkBY= X-Yahoo-Newman-Id: 624599.96480.bm@smtp118.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: jG_dpdMVM1liZoyR3WTvRVanXdFq8LjYOBNsLHMFQZ9mR3T QC6mWUaaiHGMl2O.qKdvfPtj2og.9ywP21vuNPmr3xjWHT._GfVP4iIYiA_m rSmnMNXE9b1UMxbXE_AEBto2f_tHxdBCJRTiYz9dGyWXdiKy9YkPOnR5q66j GYOr98w4E6boXbFTZFu2NIe5QDXGlR1fDAL0Nqr8fq4fKSgE4YoXf.hVRAQl Moa7b3dISL6dYkWU6ZGCTIV7ghjKpmVUA8m.0nPXRmMggW8vkQ4v0YDsCeXR ubzY6v1S1ADS8hC4wCaj96BPZv7cWgiUJz9oPpQlLs5NGx8QT.bsHp.d2.QY cjiwDEwiDVOhewT6lyFUVnjr6dw9iEqBa6Ve2jjXbyMQvXzPrgbj15qIN80n gyogdid.SVUBB.Xz4CWgU9AbEFzkjnW.amvz2NCLbDBfMm29.ff36IstET8C ERWTtmjbwOLuK_hDPBUQXTTeTzuLHWGdXQNJW2bZykXl8T2yIXYFLOwykymX OZ8h6O5j9cU2ORAh5Hr.CO6h1sR9NpLVJxeNb1JIt7A7QGPUxa_SSC4N2 X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.1.1.129] (d.sturek@66.27.60.174 with ) by smtp118.sbc.mail.gq1.yahoo.com with SMTP; 13 Sep 2013 18:58:36 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.7.130812 Date: Fri, 13 Sep 2013 11:58:32 -0700 From: Don Sturek To: Routing Over Low power and Lossy networks Message-ID: Thread-Topic: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3461918314_569935" Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 18:59:54 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3461918314_569935 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable HI Kerry, So again, two points to comment on=8A..: 1) "(A)-BR1---BR2-(B) Let's say we have two LLNs, A and B, connected by BRs and a traditional lin= k like WiFi or ethernet=8A=8A." In general it is possible to have the "traditional link" between BR1 and BR2 to support ROLL RPL and therefore include the "traditional link" interfaces as part of the MPL Domain. I believe this would depend on the routing scope declared in BR1 and BR2 for those interfaces. Most of the deployments I have seen would have (A) and (B) in different MPL Domain realms. This would solely be defined in BR1 and BR2 a= s to which interfaces they include to support RPL routing. 2) "Do you agree that all nodes in a given LLN SHOULD agree on a common value for Imin? =8A=8A " I believe it is requirement that all devices in a given MPL Domain MUST agree on a common value for IMIN, IMAX and k. In terms of a default, we can certainly create such values applicable to given deployment topology and an assumed messaging profile but I really think some work should go int= o an applicability statement that would provide additional guidance on how to tune these values. I think I mentioned this before but we did (in ZigBee IP) create a 30 node, 3 hop network supporting a ROLL RPL instance, instrumented all devices, created a single multicast message and measured how many devices in the network saw at least a single copy of the transmission using various settings for IMIN, IMAX and k. A process simila= r to this (with knowledge of the topology and messaging profile) is needed fo= r tuning these values in a real deployment setting. Don From: Kerry Lynn Reply-To: Routing Over Low power and Lossy networks Date: Friday, September 13, 2013 10:56 AM To: Routing Over Low power and Lossy networks Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 Don, thanks for your additional comments... On Fri, Sep 13, 2013 at 10:45 AM, Don Sturek wrote: > Hi Kerry, >=20 > Two points from below: > 1) "Asking as an implementer, how do I determine whether an interface is= in a > Realm- > Local zone? Is it particular to LLN links?" >=20 > As with other multicast addresses, an interface would register (op= t-in) > to a realm. For Trickle Multicast, it would then depend on whether the > interface has subscribed to the MPL Domain Address. The difference betwe= en > using realm scoped (from Ralph's draft) and administratively scoped (FF04= ) is > the membership in the MPL Domain can be managed automatically by actions > within the device. >=20 I'm willing to accept that I may be the only one who's confused. Let me illustrate with an example: (A)-BR1---BR2-(B) Let's say we have two LLNs, A and B, connected by BRs and a traditional lin= k like WiFi or ethernet. Further, there are MPL forwarders deployed in both = A and B. (I'd imagine that the LLN interfaces on the BRs are MPL forwarders.= ) Are there two separate realm-local zones? If that is the case then it seem= s there should be some intrinsic property that allows a router to determine i= f a link is in the scope zone or not. For example, if we were talking about link- local scope zones and the example about consisted of traditional links and routers, then the scope boundaries would be defined as cutting through the routers and would be the same for all link-local multicast protocols. That is, there would be no inter-connectivity between a node in A and a node in B that were subscribed to the same multicast group. I'm mainly interested in resolving the apparent contradiction between the "administratively configured" language in the MPL draft and the "automatically configured" language in Ralph's draft (and in your comment). > 2) "Do the terms "expected link-layer latency" and "worst-case link-laye= r > latency" > (used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN, > respectively) have commonly defined definitions, e.g. in 802.15.4? If so= , > what are they? I couldn't seem to determine this from the 802.15.4 spec.= " >=20 > The simple answer to this is there is not a prescribed layer 2 laten= cy > value for 802.15.4 other than the defined one hop ACK latency if you use = MAC > Acknowledges. Just FYI, in testing IEEE 802.15.4-2003/2006 (127 byte PDU= ) > with just 2 devices on a clear channel, we found a typical "one hop/one p= acket > " message latency to be around 4ms (without security) and around 12 ms (u= sing > SW based security). In my experience, the "expected link layer latency" = and > "worst case link layer latency" (speaking strictly about the link layer o= nly) > are just a single aspect to setting IMIN correctly. The overall applica= tion > message pattern plays a larger role for these settings (for example, how > frequently multicasts are generated, how many simultaneous multicasts can= be > generated within a given MPL Domain in a window of time that occurs withi= n > IMIN, etc.). Additionally, another major driver to these settings are th= e > deployment characteristics of the MPL Domain member devices (for example.= how > many incoming message buffers are supported in the member devices MAC, ho= w > many outgoing message buffers, etc.). Perhaps the names "expected link l= ayer > latency" and "worst case link layer latency" are a bit misleading since t= hey > sound like fixed settings that would be applicable to all links of a give= n > type when I think they are trying to describe the link layer performance = with > a given messaging profile in operation. >=20 Do you agree that all nodes in a given LLN SHOULD agree on a common value for Imin? I don't have any problem with declaring it out of scope fo= r the present draft, but practically speaking it seems there should be a way to a) define a reasonable default for a given link layer, and b) distribute a modified value (I think Yusuke Doi is working on a DHCPv6 option for MPL parameters)= . Regards, -K- =20 > Don >=20 >=20 > From: Kerry Lynn > Reply-To: Routing Over Low power and Lossy networks > Date: Friday, September 13, 2013 6:58 AM >=20 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] WGLC - Working Group Last Call - > draft-ietf-roll-trickle-mcast-05 >=20 > Hi Don, >=20 > On Fri, Sep 13, 2013 at 9:21 AM, Don Sturek wrote: >> I don't agree with the proposed technical changes below, specifically: >> 1) "- I have argued that to increase MPL's applicability, >> PROACTIVE_FORWARDING >> should be a per-interface and not a per-forwarder setting. I can imag= ine, >> for >> example, a router that has both LLN and traditional interfaces and >> proactive >> forwarding seems unnecessary for the latter. As [RFC 4007] states: "Z= one >> boundaries cut through nodes, not links." Suggested wording in sectio= n 5.4 >> could be "PROACTIVE_FORWARDING has a default value of TRUE on links >> where Realm-Local scope is defined, and FALSE otherwise." >>=20 >> Given how forwarding is defined in the draft, I don't see how the >> scenario above is possible unless the links on the "traditional interfac= es" >> happen to be members of the same MPL Domain as the LLN >=20 > I am looking at section 3, Applicability Statement, which says: "This pro= tocol > may also be used in environments where only a subset of links are conside= red > Low-Power and Lossy links." The change I proposed is minimal and would > improve dynamic protocol behavior on non-LLN links. >>=20 >> 2) "- Section 4.1 states: "When used with MPL, Realm-Local scope is >> administratively >> defined and used to define the boundaries of multicast message >> dissemination >> by MPL." This begs the question, why don't we just use scope =3D 0x04? = We >> probably need more discussion on if and how a scope 0x03 zone boundary >> is automatically defined (i.e. without human intervention) and how >> forwarding >> works for scope 0x03. One suggested definition is that Realm-Local ap= plies >> to links where a single interface may belong to multiple Link-Local >> scopes." >> =20 >> This argument was made some time ago and rejected. The purpose i= n >> defining and using a realm scoped address is to allow for automatic >> definition. >=20 > I think I'm just confused about the desire for automatic definition of th= e > Realm-Local > scope and the several statements in the draft that it's administratively > configured.=20 > Asking as an implementer, how do I determine whether an interface is in a > Realm- > Local zone? Is it particular to LLN links? >=20 > I'm not sure whether the draft is intending to reserve the ability to > configure which > links are in the MPLInterfaceSet. However it seems that Realm-Local scop= e, > like > other multicast scopes, must have a consistent definition for any and all > protocols > that use it. > =20 >> The forwarding definition in the Trickle Multicast draft is by MPL Domai= n so >> the definition at the end of the paragraph above is not needed. When u= sing >> FF03::FC (defined for forwarding within a MPL Domain) then all members o= f the >> MPL Domain are forwarded a copy of the multicast transmission. Section = 7.2 >> especially makes this clear, by interface, by defining: >> MPLInterfaceSet - a set of MPL Interfaces that subscribe to the MPL >> Domain Address that identifies the MPL Domain. >>=20 >> 3) - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters >> described in section 5.5 will ultimately have to be expressed in units= of >> time >> (either in this document or elsewhere) for a given link-layer in order= to >> avoid >> the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The s= ame >> reference states: "a protocol SHOULD set k and Imin such that Imin is = at >> least >> two to three times as long as it takes to transmit k packets." >>=20 >> Since we are using these parameters as defined in RFC 6206 (Trickle >> Algorithm) we should not attempt to redefine them here in this draft. >=20 > Do the terms "expected link-layer latency" and "worst-case link-layer lat= ency" > (used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN, > respectively) have commonly defined definitions, e.g. in 802.15.4? If so= , > what are they? I couldn't seem to determine this from the 802.15.4 spec. >=20 > Thanks, -K- > =20 >>=20 >> Don >>=20 >>=20 >> From: Kerry Lynn >> Reply-To: Routing Over Low power and Lossy networks >> Date: Friday, September 13, 2013 5:10 AM >> To: Routing Over Low power and Lossy networks >> Subject: Re: [Roll] WGLC - Working Group Last Call - >> draft-ietf-roll-trickle-mcast-05 >>=20 >> On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson >> wrote: >>>=20 >>> A number of issues were raised this past spring by IESG and other revie= wers >>> on draft-ietf-roll-trickle-mcast. You can review them using the custom >>> query: >>>=20 >>> http://trac.tools.ietf.org/wg/roll/trac/query?status=3Dassigned&status=3Dcl= osed& >>> status=3Dnew&status=3Dreopened&component=3Dtrickle-mcast&group=3Dcomponent&col=3D= id&co >>> l=3Dsummary&col=3Dcomponent&col=3Dstatus&col=3Dtype&col=3Dpriority&col=3Dmilestone&= order >>> =3Dpriority >>>=20 >>> The chairs, Document Shephard and Document Authors believe that current >>> issues are closed in the -05 revision at: >>> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ >>> A diff is available at: >>> =20 >>> https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-roll-trickle-mcast-04&diff= type=3D >>> --html&submit=3DGo%21&url2=3Ddraft-ietf-roll-trickle-mcast-05 >>>=20 >>> We are starting another WG Last Call. >>> It will run until Friday 2013-09-13 at 9am EST. >>>=20 >>> Please read the document. Do you concur that it is done? >>> Please post any and all comments. >>> =20 >> The draft is looking good, but I have a few comments. >> =20 >> Editorial: >>=20 >> - In section 4.3, on Proactive Forwarding, the phrase "MPL Data Message >> message" >> is redundant and should be "MPL Data Message". >>=20 >> - In the last paragraph of section 4.3 the phrase "a new MPL Data messag= es" >> should be "a new MPL Data Message". >>=20 >> - [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 to >> 14.2. >>=20 >>=20 >> Technical: >>=20 >> - I have argued that to increase MPL's applicability, PROACTIVE_FORWARDI= NG >> should be a per-interface and not a per-forwarder setting. I can imag= ine, >> for >> example, a router that has both LLN and traditional interfaces and >> proactive >> forwarding seems unnecessary for the latter. As [RFC 4007] states: "Z= one >> boundaries cut through nodes, not links." Suggested wording in sectio= n 5.4 >> could be "PROACTIVE_FORWARDING has a default value of TRUE on links >> where Realm-Local scope is defined, and FALSE otherwise." >>=20 >> - Section 4.1 states: "When used with MPL, Realm-Local scope is >> administratively >> defined and used to define the boundaries of multicast message >> dissemination >> by MPL." This begs the question, why don't we just use scope =3D 0x04? = We >> probably need more discussion on if and how a scope 0x03 zone boundary >> is automatically defined (i.e. without human intervention) and how >> forwarding >> works for scope 0x03. One suggested definition is that Realm-Local ap= plies >> to links where a single interface may belong to multiple Link-Local sc= opes. >>=20 >> - The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters >> described in section 5.5 will ultimately have to be expressed in units= of >> time >> (either in this document or elsewhere) for a given link-layer in order= to >> avoid >> the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The s= ame >> reference states: "a protocol SHOULD set k and Imin such that Imin is = at >> least >> two to three times as long as it takes to transmit k packets." >>=20 >> Regards, -K- >>=20 >> =20 >>> If there is something you do not like, please provide a suggestion (a d= iff) >>> about what to fix. >>>=20 >>> Thank you. >>>=20 >>> Michael and JP. >>>=20 >>> -- >>> Michael Richardson >>> >, Sandelman Software Works >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>>=20 >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>>=20 >>=20 >> _______________________________________________ Roll mailing list >> Roll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 > _______________________________________________ Roll mailing list > Roll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > 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 --B_3461918314_569935 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
HI Kerry,

So again, two points to comment on…..:
1)  "(A= )-BR1---BR2-(B)

Let's say we have two LLNs, A and B= , connected by BRs and a traditional link
like WiFi or ethernet…= 230;."

      In general it is possib= le to have the "traditional link" between BR1 and BR2 to support ROLL RPL an= d therefore include the "traditional link" interfaces as part of the MPL Dom= ain.   I believe this would depend on the routing scope declared in BR1= and BR2 for those interfaces.
      Most of the de= ployments I have seen would have (A) and (B) in different MPL Domain realms.=  This would solely be defined in BR1 and BR2 as to which interfaces th= ey include to support RPL routing.

2)  "Do you= agree that all nodes in a given LLN SHOULD agree on a common
value for= Imin? ……  "

      I beli= eve it is requirement that all devices in a given MPL Domain MUST agree on a= common value for IMIN, IMAX and k.  In terms of a default, we can cert= ainly create such values applicable to given deployment topology and an assu= med messaging profile but I really think some work should go into an applica= bility statement that would provide additional guidance on how to tune these= values.  I think I mentioned this before but we did (in ZigBee IP) cre= ate a 30 node, 3 hop network supporting a ROLL RPL instance, instrumented al= l devices, created a single multicast message and measured how many devices = in the network saw at least a single copy of the transmission using various = settings for IMIN, IMAX and k.  A process similar to this (with knowled= ge of the topology and messaging profile) is needed for tuning these values = in a real deployment setting.

Don


From: Kerry Lynn <kerlyn@ieee.org>
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
Date: Friday, September 13, 2013 10:56 AM
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] WGLC - Working Group Last Call - draft-i= etf-roll-trickle-mcast-05

Don, thanks= for your additional comments...

On Fri= , Sep 13, 2013 at 10:45 AM, Don Sturek <d.sturek@att.net> wrote:
<= div class=3D"gmail_quote">
Hi Kerry,
=

Two points from below:
1)  "Asking as an = implementer, how do I determine whether an interface is in a Realm-
Local zone?  Is it particular to LLN links?"

       As with other multicast addresses, an= interface would register (opt-in) to a realm.   For Trickle Multicast,= it would then depend on whether the interface has subscribed to the MPL Dom= ain Address.  The difference between using realm scoped (from Ralph's d= raft) and administratively scoped (FF04) is the membership in the MPL Domain= can be managed automatically by actions within the device.

I'm willing to accept that I may be the only one= who's confused.  Let me illustrate
with an example:
<= br>
(A)-BR1---BR2-(B)

Let's say we have two LLNs= , A and B, connected by BRs and a traditional link
like WiFi or ethernet.  Further, there are MPL forwarders deployed in = both A
and B.  (I'd imagine that the LLN interfaces on th= e BRs are MPL forwarders.)
Are there two separate realm-local zones? = ; If that is the case then it seems
there should be some intri= nsic property that allows a router to determine if a
link is i= n the scope zone or not.  For example, if we were talking about link-local scope zones and the example about consisted of traditional links and=
routers, then the scope boundaries would be defined as cutting through the<= br>routers and would be the same for all link-local multicast protocols.&nbs= p; That is,
there would be no inter-connectivity between a nod= e in A and a node in B that
were subscribed to the same multic= ast group.

I'm mainly interested in resolving the apparent= contradiction between the
"administratively configured" langu= age in the MPL draft and the "automatically
configured" langua= ge in Ralph's draft (and in your comment).


2)  "Do the terms "expected = link-layer latency" and "worst-case link-layer latency"
= (used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,
respectively)= have commonly defined definitions, e.g. in 802.15.4?  If so,
what are they?  I couldn't seem to determine this from the 802.15.4 sp= ec."

     The simple answer to= this is there is not a prescribed layer 2 latency value for 802.15.4 other = than the defined one hop ACK latency if you use MAC Acknowledges.  Just= FYI, in testing IEEE 802.15.4-2003/2006 (127 byte PDU) with just 2 devices = on a clear channel, we found a typical "one hop/one packet " message la= tency to be around 4ms (without security) and around 12 ms (using SW based s= ecurity).  In my experience, the "expected link layer latency" and "wor= st case link layer latency" (speaking strictly about the link layer only) ar= e just a single aspect to setting IMIN correctly.   The overall applica= tion message pattern plays a larger role for these settings (for example, ho= w frequently multicasts are generated, how many simultaneous multicasts can = be generated within a given MPL Domain in a window of time that occurs withi= n IMIN, etc.).  Additionally, another major driver to these settings ar= e the deployment characteristics of the MPL Domain member devices (for examp= le. how many incoming message buffers are supported in the member devices MA= C, how many outgoing message buffers, etc.).  Perhaps the names "expect= ed link layer latency" and "worst case link layer latency" are a bit mislead= ing since they sound like fixed settings that would be applicable to all lin= ks of a given type when I think they are trying to describe the link layer p= erformance with a given messaging profile in operation.

=
Do you agree that all nodes in a given LLN SHO= ULD agree on a common
value for Imin?  I don't have any problem with= declaring it out of scope for
the present draft, but practically speakin= g it seems there should be a way to
a) define a reasonable def= ault for a given link layer, and b) distribute a modified
value (I think = Yusuke Doi is working on a DHCPv6 option for MPL parameters).

<= div>Regards, -K-
 
Don


From: Kerry Lynn <kerlyn@ieee.org>
Reply-To: Routing Over Low power and Lossy ne= tworks <roll@ietf.org&= gt;
Date: Friday, September = 13, 2013 6:58 AM

To: = Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf= -roll-trickle-mcast-05

Hi= Don,

On Fri, Sep 13, 2013 at 9:21 AM, Don = Sturek <d.sturek@att.net> wrote:
=
I don't agree with the proposed technical changes below, specific= ally:
1)  "- I have argued that to increase MPL's applicabili= ty, PROACTIVE_FORWARDING
  should be a per-interface and= not a per-forwarder setting.  I can imagine, for
  = example, a router that has both LLN and traditional interfaces and proactive=
  forwarding seems unnecessary for the latter.  As = [RFC 4007] states: "Zone
  boundaries cut through nodes, = not links."  Suggested wording in section 5.4
  coul= d be "PROACTIVE_FORWARDING has a default value of TRUE on links
  where Realm-Local scope is defined, and FALSE otherwise."

    Given how forwarding is defined in the d= raft, I don't see how the scenario above is possible unless the links on the= "traditional interfaces" happen to be members of the same MPL Domain as the= LLN

I am looking at section 3, = Applicability Statement, which says: "This protocol
may also b= e used in environments where only a subset of links are considered
=
Low-Power and Lossy links."  The change I proposed is minimal and = would
improve dynamic protocol behavior on non-LLN links.
=

2)  "- Sectio= n 4.1 states: "When used with MPL, Realm-Local scope is administratively
  defined and used to define the boundaries of multicast message disse= mination
  by MPL."  This begs the question, why don= 't we just use scope =3D 0x04?  We
  probably need mor= e discussion on if and how a scope 0x03 zone boundary
  i= s automatically defined (i.e. without human intervention) and how forwarding=
  works for scope 0x03.  One suggested definition i= s that Realm-Local applies
  to links where a single inte= rface may belong to multiple Link-Local scopes."
    &nb= sp;
      This argument was made some time ag= o and rejected.   The purpose in defining and using a realm scoped addr= ess is to allow for automatic definition.

<= /div>
I think I'm just confused about the desire for automatic definition of the = Realm-Local
scope and the several statements in the draft that it's admin= istratively configured.
Asking as an implementer, how do I determine whe= ther an interface is in a Realm-
Local zone?  Is it particular to LLN links?

I'm not = sure whether the draft is intending to reserve the ability to configure whic= h
links are in the MPLInterfaceSet.  However it seems that Realm-Loc= al scope, like
other multicast scopes, must have a consistent = definition for any and all protocols
that use it.
 
The forwarding defini= tion in the Trickle Multicast draft is by MPL Domain so the definition at th= e end of the paragraph above is not needed.   When using FF03::FC (defi= ned for forwarding within a MPL Domain) then all members of the MPL Domain a= re forwarded a copy of the multicast transmission.  Section 7.2 especia= lly makes this clear, by interface, by defining:
   MPLInterf=
aceSet  - a set of MPL Interfaces that subscribe to the MPL
          Domain Address that identifies the MPL Domain.
3)  - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN para= meters
  described in section 5.5 will ultimately have t= o be expressed in units of time
  (either in this documen= t or elsewhere) for a given link-layer in order to avoid
  the "Mism= atched min" issues discussed in [RFC 6206, sect. 6.2].  The same
&nb= sp; reference states: "a protocol SHOULD set k and Imin such that Imin is at= least
  two to three times as long as it takes to transmit k packets."
=

     Since we are using these param= eters as defined in RFC 6206 (Trickle Algorithm) we should not attempt to re= define them here in this draft.

= Do the terms "expected link-layer latency" and "worst-case link-layer latenc= y"
(used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,=
respectively) have commonly defined definitions, e.g. in 802.15.4? = If so,
what are they?  I couldn't seem to determine this from the 802.15.4 sp= ec.

Thanks, -K-
 

Don


From: Kerry Lynn <kerlyn@ieee.org>
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
Date: Friday, September 13, 2013 5:10 AM
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] WGLC - Working Group Last Call= - draft-ietf-roll-trickle-mcast-05

On Wed, Sep 4, 2013 at 3:45 PM, Mi= chael Richardson <mcr+ietf@sandelman.ca> wrote:

A number of issues were raised this past spring by IESG and other reviewers=
on draft-ietf-roll-trickle-mcast.  You can review them using the custo= m query:

http://trac.tools.ietf.org/wg/roll/trac/query?st= atus=3Dassigned&status=3Dclosed&status=3Dnew&status=3Dreopened&compo= nent=3Dtrickle-mcast&group=3Dcomponent&col=3Did&col=3Dsummary&col=3Dco= mponent&col=3Dstatus&col=3Dtype&col=3Dpriority&col=3Dmilestone&o= rder=3Dpriority

The chairs, Document Shephard and Document Authors believe that current
= issues are closed in the -05 revision at:
       https://datatracker.ietf.org/doc/d= raft-ietf-roll-trickle-mcast/
A diff is available at:
       https://www.ietf.org/rfcdiff= ?url1=3Ddraft-ietf-roll-trickle-mcast-04&difftype=3D--html&submit=3DGo%21&= amp;url2=3Ddraft-ietf-roll-trickle-mcast-05

We are starting another WG Last Call.
It will run until Friday 2013-09-13 at 9am EST.

Please read the document.  Do you concur that it is done?
Please post any and all comments.
 
The draft is looking good, but I have a few comment= s.
 
Editorial:

- In section = 4.3, on Proactive Forwarding, the phrase "MPL Data Message message"
  is redundant and should be "MPL Data Message".

- In the last paragraph of section 4.3 the phrase "a new MPL Data messages= "
  should be "a new MPL Data Message".

- [I-D.droms-6man-multicast-scopes] should be moved from section 14.1= to 14.2.


Technical:

- I have argued that to increase MPL's applicability, PROACTIVE_FORWARDIN= G
  should be a per-interface and not a per-forwarder set= ting.  I can imagine, for
  example, a router that h= as both LLN and traditional interfaces and proactive
  fo= rwarding seems unnecessary for the latter.  As [RFC 4007] states: "Zone=
  boundaries cut through nodes, not links."  Sugges= ted wording in section 5.4
  could be "PROACTIVE_FORWARDI= NG has a default value of TRUE on links
  where Realm-Loc= al scope is defined, and FALSE otherwise."

- Se= ction 4.1 states: "When used with MPL, Realm-Local scope is administratively=
  defined and used to define the boundaries of multicast= message dissemination
  by MPL."  This begs the que= stion, why don't we just use scope =3D 0x04?  We
  pro= bably need more discussion on if and how a scope 0x03 zone boundary
  is automatically defined (i.e. without human intervention) and = how forwarding
  works for scope 0x03.  One suggeste= d definition is that Realm-Local applies
  to links where= a single interface may belong to multiple Link-Local scopes.
=
- The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters
  described in section 5.5 will ultimately have to be expr= essed in units of time
  (either in this document or else= where) for a given link-layer in order to avoid
  the "Mismatched mi= n" issues discussed in [RFC 6206, sect. 6.2].  The same
  refer= ence states: "a protocol SHOULD set k and Imin such that Imin is at least   two to three times as long as it takes to transmit k packets."

Regards, -K-

 
If there is something you do not like, please provide a suggestion (a diff)=
about what to fix.

Thank you.

Michael and JP.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/=


______________________________________________= _
Roll mailing list
Roll@ie= tf.org
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________ Roll mailing list Roll@ietf.orghttps://www.ietf.o= rg/mailman/listinfo/roll

___= ____________________________________________
Roll mailing list
Roll@ie= tf.org
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________ Roll mailing list Roll@ietf.orghttps://www.ietf.o= rg/mailman/listinfo/roll

___________________= ____________________________
Roll mailing list
Roll@ietf.org
https://w= ww.ietf.org/mailman/listinfo/roll
_______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll --B_3461918314_569935-- From kerlyn2001@gmail.com Fri Sep 13 13:06:31 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEB821E8084 for ; Fri, 13 Sep 2013 13:06:30 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVMj1WNOOeXA for ; Fri, 13 Sep 2013 13:06:29 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4799011E80D5 for ; Fri, 13 Sep 2013 13:06:29 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id j10so1627959oah.13 for ; Fri, 13 Sep 2013 13:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=B+UoOumSKbU1XyUZIogc33xg0pfxMA804SXPBp/Phu4=; b=kgikkcsyJqKx39sib5PaCWfmrlKSd+SwDDw1fiiNMqbDYxcaQcjKxDMdwM/Cgi5Weu knbWwaNZGuBCGZP/UBr9r4qAgvSVBjhDoEAEOSrOluctAk6B8EI/jCrY0pkgGUo9pVx2 Xg79hajf4z4Vwj755p5sjB/9YgE0AYraY9DtXFpBK4/B9zGuDK3hEUZzrd4wyeZUXWwA roNw5JGSVyDl5FaWxNVP+AFRw7sQY3C+OcgBxHRzvOk5iA8iMHtDPIZGdtsGEodzmP1U HARa4qfHOS8uM4QMWPr9pXxJQzIjbFRPOfnoCQ8WaVwz/XRvr4fRgoZMWkz/G13G2wpP OwRw== MIME-Version: 1.0 X-Received: by 10.60.60.5 with SMTP id d5mr13908772oer.0.1379102788798; Fri, 13 Sep 2013 13:06:28 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.41.36 with HTTP; Fri, 13 Sep 2013 13:06:28 -0700 (PDT) In-Reply-To: <27577.1379098384@sandelman.ca> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.77025347de98150b9e23fbe62aa3ea80@trac.tools.ietf.org> <27577.1379098384@sandelman.ca> Date: Fri, 13 Sep 2013 16:06:28 -0400 X-Google-Sender-Auth: KNWSVt0ePMhAnJOYaALpzBLSqe4 Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e0149c3c0d5d0d404e649630b Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 20:06:31 -0000 --089e0149c3c0d5d0d404e649630b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 13, 2013 at 2:53 PM, Michael Richardson wrote: > > Kerry Lynn wrote: > > Actually, that was my comment. > > Oh, sorry for he confusion. > > > It seems to me that the MPL draft and > > draft-droms-6man-multicast-scopes-02 may be inconsistent in whether > > Realm-Local scopes are administratively or automatically defined. > > I believe that droms-6man-multicast-scopes-02 is supposed to say that > scope-3 is to be defined automatically by a process to be described by a > user > of it. > > Correct me if I'm wrong, but in the case of all other multicast scopes isn't the zone boundary established by router configuration? [RFC 4007, sect. 5] says as much: "The boundaries of zones of a scope other than interface-local, link- local, and global must be defined and configured by network administrators." Note this contradicts [RFC 4291, sect, 2.7], which states: "Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration." This last statement is probably the reason for the "automatic configuration" language in Ralph's draft. And so trickle-mcast ought to define how to automatically define it. > > [RFC 4007] defines several attributes of a zone, including "Zones of the same scope cannot overlap; i.e., they can have no links or interfaces in common." I think the upshot is that a scope zone is defined in terms of network topology. > I think that it ought to be defined to be the boundary of the DAG > that contains the same (/64) prefix. > > This is probably a good working definition and *is* based on topology; I would argue that this definition probably belongs in [RFC 4944] and not in MPL. As draft-droms-6man-multicast-scopes-02 says: "... a scope definition would be appropriate for publication in an "IPv6-over-foo" RFC. I don't know that we'll close this ticket today unless some greybeards weigh in... Regards, -K- > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --089e0149c3c0d5d0d404e649630b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 13, 2013 at 2:53 PM, Michael Richardson <= mcr+ietf@sandelman.ca> wrote:
<= div class=3D"gmail_quote">

Kerry Lynn <kerlyn@ieee.org> w= rote:
=A0 =A0 > Actually, that was my comment.

Oh, sorry for he confusion.

=A0 =A0 > It seems to me that the MPL draft and
=A0 =A0 > draft-droms-6man-multicast-scopes-02 may be inconsistent in wh= ether
=A0 =A0 > Realm-Local scopes are administratively or automatically defin= ed.

I believe that droms-6man-multicast-scopes-02 is supposed to say that=
scope-3 is to be defined automatically by a process to be described by a us= er
of it.

Correct me if I'm wrong, but in the case of all o= ther multicast scopes isn't the
zone boundary established= by router configuration?=A0 [RFC 4007, sect. 5] says
as much: "The= boundaries of zones of a scope other than interface-local, link-
local, and global must be defined and configured by network admi= nistrators."
Note this contradicts [RFC 4291, sect, 2.7]= , which states: "Admin-Local scope
is the smallest scope= that must be administratively configured, i.e., not automatically
derived from physical connectivity or other, non-multicast-relat= ed configuration."
This last statement is probably the r= eason for the "automatic configuration"
language in Ralph'= s draft.

And so trickle-mcast ought to define how to automatically define it.

[RFC 4007] defines several attributes of a zone, incl= uding "Zones of the same
scope cannot overlap; i.e., the= y can have no links or interfaces in common."
I think th= e upshot is that a scope zone is defined in terms of network topology.
=A0
I think that it ought to be defined to be the boundary of the DAG
that contains the same (/64) prefix.

This is probably a good working definition and *is* b= ased on topology; I
would argue that this definition probably belongs in= [RFC 4944] and not
in MPL.=A0 As draft-droms-6man-multicast-scopes-02 s= ays: "... a scope
definition would be appropriate for publication in an "IPv6= -over-foo" RFC.

I don't know that we'll clos= e this ticket today unless some greybeards
weigh in...

Regards, -K-
=A0
--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair. =A0 =A0http://datatracker.ietf.org/wg/roll/charter/<= /a>


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


--089e0149c3c0d5d0d404e649630b-- From kerlyn2001@gmail.com Fri Sep 13 13:10:59 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C297D11E80D5 for ; Fri, 13 Sep 2013 13:10:59 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcSTJXv7149X for ; Fri, 13 Sep 2013 13:10:57 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 86C9311E80D3 for ; Fri, 13 Sep 2013 13:10:57 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h1so1612383oag.38 for ; Fri, 13 Sep 2013 13:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=op+Y+5Vsmt/rTGmB96pZAkNzVWTHLjOQjwdQ4MneoD4=; b=dbz60HjIT7MBgEBDw+vfn4nzICSLUocOejhs1kMGsLatCf0u9byn7Nmd4yMgo1OHT/ uAdjhF4uoG9TZPv2h0ckLkAD4Kx6+8Thjz8mjjAuJ3YoAin9aZ1KB/kuLyBe3+DDZWoF ckzKqDA1rKFwjWi9YTJvLmGNlYcjoCes15XzdvU5453GCSRHjse/I610eDHsg1oGGV2t HZI3gLaRwfrbHS7rCnYct4lJDgC13TjG7FHwMcPOwBk+kksO7VkOqE53r2iGjL+bn7so IltqJ3++o6F8wf02UHQSHnfRH9qPw3sGFjdhFg4+GHfml5t/ihQT4DxaKblfJRgbdlur fvwA== MIME-Version: 1.0 X-Received: by 10.182.29.233 with SMTP id n9mr13982823obh.38.1379103053995; Fri, 13 Sep 2013 13:10:53 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.41.36 with HTTP; Fri, 13 Sep 2013 13:10:53 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Sep 2013 16:10:53 -0400 X-Google-Sender-Auth: AnooJi4Odxr2twUW-AoQp_mcp_s Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c2047aa4656104e6497339 Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 20:11:00 -0000 --001a11c2047aa4656104e6497339 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Sep 13, 2013 at 2:58 PM, Don Sturek wrote: > HI Kerry, > > So again, two points to comment on=85..: > 1) "(A)-BR1---BR2-(B) > > Let's say we have two LLNs, A and B, connected by BRs and a traditional > link > like WiFi or ethernet=85=85." > > In general it is possible to have the "traditional link" between BR= 1 > and BR2 to support ROLL RPL and therefore include the "traditional link" > interfaces as part of the MPL Domain. I believe this would depend on th= e > routing scope declared in BR1 and BR2 for those interfaces. > Most of the deployments I have seen would have (A) and (B) in > different MPL Domain realms. This would solely be defined in BR1 and BR2 > as to which interfaces they include to support RPL routing. > > 2) "Do you agree that all nodes in a given LLN SHOULD agree on a common > value for Imin? =85=85 " > > I believe it is requirement that all devices in a given MPL Domain > MUST agree on a common value for IMIN, IMAX and k. In terms of a default= , > we can certainly create such values applicable to given deployment topolo= gy > and an assumed messaging profile but I really think some work should go > into an applicability statement that would provide additional guidance on > how to tune these values. I think I mentioned this before but we did (in > ZigBee IP) create a 30 node, 3 hop network supporting a ROLL RPL instance= , > instrumented all devices, created a single multicast message and measured > how many devices in the network saw at least a single copy of the > transmission using various settings for IMIN, IMAX and k. A process > similar to this (with knowledge of the topology and messaging profile) is > needed for tuning these values in a real deployment setting. > > ACK. Thanks for your explanations. -K- > Don > > > From: Kerry Lynn > Reply-To: Routing Over Low power and Lossy networks > Date: Friday, September 13, 2013 10:56 AM > > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] WGLC - Working Group Last Call - > draft-ietf-roll-trickle-mcast-05 > > Don, thanks for your additional comments... > > On Fri, Sep 13, 2013 at 10:45 AM, Don Sturek wrote: > >> Hi Kerry, >> >> Two points from below: >> 1) "Asking as an implementer, how do I determine whether an interface i= s >> in a Realm- >> Local zone? Is it particular to LLN links?" >> >> As with other multicast addresses, an interface would register >> (opt-in) to a realm. For Trickle Multicast, it would then depend on >> whether the interface has subscribed to the MPL Domain Address. The >> difference between using realm scoped (from Ralph's draft) and >> administratively scoped (FF04) is the membership in the MPL Domain can b= e >> managed automatically by actions within the device. >> >> I'm willing to accept that I may be the only one who's confused. Let me > illustrate > with an example: > > (A)-BR1---BR2-(B) > > Let's say we have two LLNs, A and B, connected by BRs and a traditional > link > like WiFi or ethernet. Further, there are MPL forwarders deployed in bot= h > A > and B. (I'd imagine that the LLN interfaces on the BRs are MPL > forwarders.) > Are there two separate realm-local zones? If that is the case then it > seems > there should be some intrinsic property that allows a router to determine > if a > link is in the scope zone or not. For example, if we were talking about > link- > local scope zones and the example about consisted of traditional links an= d > routers, then the scope boundaries would be defined as cutting through th= e > routers and would be the same for all link-local multicast protocols. > That is, > there would be no inter-connectivity between a node in A and a node in B > that > were subscribed to the same multicast group. > > I'm mainly interested in resolving the apparent contradiction between the > "administratively configured" language in the MPL draft and the > "automatically > configured" language in Ralph's draft (and in your comment). > > > 2) "Do the terms "expected link-layer latency" and "worst-case link-laye= r >> latency" >> (used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN, >> respectively) have commonly defined definitions, e.g. in 802.15.4? If s= o, >> what are they? I couldn't seem to determine this from the 802.15.4 spec= ." >> >> The simple answer to this is there is not a prescribed layer 2 >> latency value for 802.15.4 other than the defined one hop ACK latency if >> you use MAC Acknowledges. Just FYI, in testing IEEE 802.15.4-2003/2006 >> (127 byte PDU) with just 2 devices on a clear channel, we found a >> typical "one hop/one packet " message latency to be around 4ms (without >> security) and around 12 ms (using SW based security). In my experience, >> the "expected link layer latency" and "worst case link layer latency" >> (speaking strictly about the link layer only) are just a single aspect t= o >> setting IMIN correctly. The overall application message pattern plays = a >> larger role for these settings (for example, how frequently multicasts a= re >> generated, how many simultaneous multicasts can be generated within a gi= ven >> MPL Domain in a window of time that occurs within IMIN, etc.). >> Additionally, another major driver to these settings are the deployment >> characteristics of the MPL Domain member devices (for example. how many >> incoming message buffers are supported in the member devices MAC, how ma= ny >> outgoing message buffers, etc.). Perhaps the names "expected link layer >> latency" and "worst case link layer latency" are a bit misleading since >> they sound like fixed settings that would be applicable to all links of = a >> given type when I think they are trying to describe the link layer >> performance with a given messaging profile in operation. >> >> Do you agree that all nodes in a given LLN SHOULD agree on a common > value for Imin? I don't have any problem with declaring it out of scope > for > the present draft, but practically speaking it seems there should be a wa= y > to > a) define a reasonable default for a given link layer, and b) distribute = a > modified > value (I think Yusuke Doi is working on a DHCPv6 option for MPL > parameters). > > Regards, -K- > > >> Don >> >> >> From: Kerry Lynn >> Reply-To: Routing Over Low power and Lossy networks >> Date: Friday, September 13, 2013 6:58 AM >> >> To: Routing Over Low power and Lossy networks >> Subject: Re: [Roll] WGLC - Working Group Last Call - >> draft-ietf-roll-trickle-mcast-05 >> >> Hi Don, >> >> On Fri, Sep 13, 2013 at 9:21 AM, Don Sturek wrote: >> >>> I don't agree with the proposed technical changes below, specifically: >>> 1) "- I have argued that to increase MPL's applicability, >>> PROACTIVE_FORWARDING >>> should be a per-interface and not a per-forwarder setting. I can >>> imagine, for >>> example, a router that has both LLN and traditional interfaces and >>> proactive >>> forwarding seems unnecessary for the latter. As [RFC 4007] states: >>> "Zone >>> boundaries cut through nodes, not links." Suggested wording in >>> section 5.4 >>> could be "PROACTIVE_FORWARDING has a default value of TRUE on links >>> where Realm-Local scope is defined, and FALSE otherwise." >>> >>> Given how forwarding is defined in the draft, I don't see how the >>> scenario above is possible unless the links on the "traditional interfa= ces" >>> happen to be members of the same MPL Domain as the LLN >>> >> >> I am looking at section 3, Applicability Statement, which says: "This >> protocol >> may also be used in environments where only a subset of links are >> considered >> Low-Power and Lossy links." The change I proposed is minimal and would >> improve dynamic protocol behavior on non-LLN links. >> >>> >>> 2) "- Section 4.1 states: "When used with MPL, Realm-Local scope is >>> administratively >>> defined and used to define the boundaries of multicast message >>> dissemination >>> by MPL." This begs the question, why don't we just use scope =3D 0x0= 4? >>> We >>> probably need more discussion on if and how a scope 0x03 zone boundar= y >>> is automatically defined (i.e. without human intervention) and how >>> forwarding >>> works for scope 0x03. One suggested definition is that Realm-Local >>> applies >>> to links where a single interface may belong to multiple Link-Local >>> scopes." >>> >>> This argument was made some time ago and rejected. The purpose >>> in defining and using a realm scoped address is to allow for automatic >>> definition. >>> >> >> I think I'm just confused about the desire for automatic definition of >> the Realm-Local >> scope and the several statements in the draft that it's administratively >> configured. >> Asking as an implementer, how do I determine whether an interface is in = a >> Realm- >> Local zone? Is it particular to LLN links? >> >> I'm not sure whether the draft is intending to reserve the ability to >> configure which >> links are in the MPLInterfaceSet. However it seems that Realm-Local >> scope, like >> other multicast scopes, must have a consistent definition for any and al= l >> protocols >> that use it. >> >> >>> The forwarding definition in the Trickle Multicast draft is by MPL >>> Domain so the definition at the end of the paragraph above is not neede= d. >>> When using FF03::FC (defined for forwarding within a MPL Domain) then a= ll >>> members of the MPL Domain are forwarded a copy of the multicast >>> transmission. Section 7.2 especially makes this clear, by interface, b= y >>> defining: >>> >>> MPLInterfaceSet - a set of MPL Interfaces that subscribe to the MPL >>> Domain Address that identifies the MPL Domain. >>> >>> >>> 3) - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters >>> described in section 5.5 will ultimately have to be expressed in unit= s >>> of time >>> (either in this document or elsewhere) for a given link-layer in orde= r >>> to avoid >>> the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The >>> same >>> reference states: "a protocol SHOULD set k and Imin such that Imin is >>> at least >>> two to three times as long as it takes to transmit k packets." >>> >>> Since we are using these parameters as defined in RFC 6206 (Trickl= e >>> Algorithm) we should not attempt to redefine them here in this draft. >>> >> >> Do the terms "expected link-layer latency" and "worst-case link-layer >> latency" >> (used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN, >> respectively) have commonly defined definitions, e.g. in 802.15.4? If s= o, >> what are they? I couldn't seem to determine this from the 802.15.4 spec= . >> >> Thanks, -K- >> >> >>> >>> Don >>> >>> >>> From: Kerry Lynn >>> Reply-To: Routing Over Low power and Lossy networks >>> Date: Friday, September 13, 2013 5:10 AM >>> To: Routing Over Low power and Lossy networks >>> Subject: Re: [Roll] WGLC - Working Group Last Call - >>> draft-ietf-roll-trickle-mcast-05 >>> >>> On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson < >>> mcr+ietf@sandelman.ca> wrote: >>> >>>> >>>> A number of issues were raised this past spring by IESG and other >>>> reviewers >>>> on draft-ietf-roll-trickle-mcast. You can review them using the custo= m >>>> query: >>>> >>>> >>>> http://trac.tools.ietf.org/wg/roll/trac/query?status=3Dassigned&status= =3Dclosed&status=3Dnew&status=3Dreopened&component=3Dtrickle-mcast&group=3D= component&col=3Did&col=3Dsummary&col=3Dcomponent&col=3Dstatus&col=3Dtype&co= l=3Dpriority&col=3Dmilestone&order=3Dpriority >>>> >>>> The chairs, Document Shephard and Document Authors believe that curren= t >>>> issues are closed in the -05 revision at: >>>> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ >>>> A diff is available at: >>>> >>>> https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-roll-trickle-mcast-04&d= ifftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-roll-trickle-mcast-05 >>>> >>>> We are starting another WG Last Call. >>>> It will run until Friday 2013-09-13 at 9am EST. >>>> >>>> Please read the document. Do you concur that it is done? >>>> Please post any and all comments. >>>> >>> >>> The draft is looking good, but I have a few comments. >>> >>> Editorial: >>> >>> - In section 4.3, on Proactive Forwarding, the phrase "MPL Data Message >>> message" >>> is redundant and should be "MPL Data Message". >>> >>> - In the last paragraph of section 4.3 the phrase "a new MPL Data >>> messages" >>> should be "a new MPL Data Message". >>> >>> - [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 >>> to 14.2. >>> >>> >>> Technical: >>> >>> - I have argued that to increase MPL's applicability, >>> PROACTIVE_FORWARDING >>> should be a per-interface and not a per-forwarder setting. I can >>> imagine, for >>> example, a router that has both LLN and traditional interfaces and >>> proactive >>> forwarding seems unnecessary for the latter. As [RFC 4007] states: >>> "Zone >>> boundaries cut through nodes, not links." Suggested wording in >>> section 5.4 >>> could be "PROACTIVE_FORWARDING has a default value of TRUE on links >>> where Realm-Local scope is defined, and FALSE otherwise." >>> >>> - Section 4.1 states: "When used with MPL, Realm-Local scope is >>> administratively >>> defined and used to define the boundaries of multicast message >>> dissemination >>> by MPL." This begs the question, why don't we just use scope =3D 0x0= 4? >>> We >>> probably need more discussion on if and how a scope 0x03 zone boundar= y >>> is automatically defined (i.e. without human intervention) and how >>> forwarding >>> works for scope 0x03. One suggested definition is that Realm-Local >>> applies >>> to links where a single interface may belong to multiple Link-Local >>> scopes. >>> >>> - The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters >>> described in section 5.5 will ultimately have to be expressed in unit= s >>> of time >>> (either in this document or elsewhere) for a given link-layer in orde= r >>> to avoid >>> the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2]. The >>> same >>> reference states: "a protocol SHOULD set k and Imin such that Imin is >>> at least >>> two to three times as long as it takes to transmit k packets." >>> >>> Regards, -K- >>> >>> >>> >>>> If there is something you do not like, please provide a suggestion (a >>>> diff) >>>> about what to fix. >>>> >>>> Thank you. >>>> >>>> Michael and JP. >>>> >>>> -- >>>> Michael Richardson , Sandelman Software Works >>>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>>> >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> _______________________________________________ Roll mailing list >> Roll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001a11c2047aa4656104e6497339 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 13, 2013 at 2:58 PM, Don Sturek <d.sturek@att.= net> wrote:
HI Kerry,

So again, two points to co= mment on=85..:
1) =A0"(A)-BR1---BR2-(B)

=
Let's say we have two LLNs, A and B, connected by BRs= and a traditional link
like WiFi or ethernet=85=85."

=A0 =A0 =A0 In general it is possible to have the "t= raditional link" between BR1 and BR2 to support ROLL RPL and therefore= include the "traditional link" interfaces as part of the MPL Dom= ain. =A0 I believe this would depend on the routing scope declared in BR1 a= nd BR2 for those interfaces.
=A0 =A0 =A0 Most of the deployments I have seen would have (A) and (B)= in different MPL Domain realms. =A0This would solely be defined in BR1 and= BR2 as to which interfaces they include to support RPL routing.
=
2) =A0"Do you agree that all nodes in a given LLN SHOULD ag= ree on a common
value for Imin? =85=85 =A0"

= =A0 =A0 =A0 I believe it is requirement that all devices in a given MPL Dom= ain MUST agree on a common value for IMIN, IMAX and k. =A0In terms of a def= ault, we can certainly create such values applicable to given deployment to= pology and an assumed messaging profile but I really think some work should= go into an applicability statement that would provide additional guidance = on how to tune these values. =A0I think I mentioned this before but we did = (in ZigBee IP) create a 30 node, 3 hop network supporting a ROLL RPL instan= ce, instrumented all devices, created a single multicast message and measur= ed how many devices in the network saw at least a single copy of the transm= ission using various settings for IMIN, IMAX and k. =A0A process similar to= this (with knowledge of the topology and messaging profile) is needed for = tuning these values in a real deployment setting.


ACK.=A0 Thanks for yo= ur explanations.

-K-
=A0
Don


From: Kerry Lynn= <kerlyn@ieee.org>
Reply-To: Routing Over L= ow power and Lossy networks <roll@ietf.org>
Date: Friday, September 13, = 2013 10:56 AM

To= : Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] WGLC - Working= Group Last Call - draft-ietf-roll-trickle-mcast-05

Don, thanks for your a= dditional comments...

On Fri, Sep 13, 2013 at 10:45 AM, Don S= turek <d.sturek@att.net> wrote:
Hi Kerry,

Two points from below:
1) =A0"Asking as an implementer, how do I determine whether an = interface is in a Realm-
Local zone?=A0 Is it particular to LLN links?"

=A0 =A0 =A0 =A0As with other multicast addresses, an interface would= register (opt-in) to a realm. =A0 For Trickle Multicast, it would then dep= end on whether the interface has subscribed to the MPL Domain Address. =A0T= he difference between using realm scoped (from Ralph's draft) and admin= istratively scoped (FF04) is the membership in the MPL Domain can be manage= d automatically by actions within the device.

I'm willing to accept that I may= be the only one who's confused.=A0 Let me illustrate
wit= h an example:

(A)-BR1---BR2-(B)

Let'= ;s say we have two LLNs, A and B, connected by BRs and a traditional link like WiFi or ethernet.=A0 Further, there are MPL forwarders deployed in bot= h A
and B.=A0 (I'd imagine that the LLN interfaces on the= BRs are MPL forwarders.)
Are there two separate realm-local zones?=A0 I= f that is the case then it seems
there should be some intrinsic property that allows a router to = determine if a
link is in the scope zone or not.=A0 For examp= le, if we were talking about link-
local scope zones and the example abo= ut consisted of traditional links and
routers, then the scope boundaries would be defined as cutting through the<= br>routers and would be the same for all link-local multicast protocols.=A0= That is,
there would be no inter-connectivity between a node= in A and a node in B that
were subscribed to the same multicast group.

I= 'm mainly interested in resolving the apparent contradiction between th= e
"administratively configured" language in the MPL= draft and the "automatically
configured" language in Ralph's draft (and in your comm= ent).


2) =A0"Do the terms "expected link-layer latency&= quot; and "worst-case link-layer latency"
(used to defin= e DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,
respectively) have commonl= y defined definitions, e.g. in 802.15.4?=A0 If so,
what are they?=A0 I couldn't seem to determine this from the 802.15.4 s= pec."

=A0 =A0 =A0The simple answer to t= his is there is not a prescribed layer 2 latency value for 802.15.4 other t= han the defined one hop ACK latency if you use MAC Acknowledges. =A0Just FY= I, in testing IEEE 802.15.4-2003/2006 (127 byte PDU) with just 2 devices on= a clear channel, we found a typical=A0"one hop/one packet " mess= age latency to be around 4ms (without security) and around 12 ms (using SW = based security). =A0In my experience, the "expected link layer latency= " and "worst case link layer latency" (speaking strictly abo= ut the link layer only) are just a single aspect to setting IMIN correctly.= =A0 The overall application message pattern plays a larger role for these = settings (for example, how frequently multicasts are generated, how many si= multaneous multicasts can be generated within a given MPL Domain in a windo= w of time that occurs within IMIN, etc.). =A0Additionally, another major dr= iver to these settings are the deployment characteristics of the MPL Domain= member devices (for example. how many incoming message buffers are support= ed in the member devices MAC, how many outgoing message buffers, etc.). =A0= Perhaps the names "expected link layer latency" and "worst c= ase link layer latency" are a bit misleading since they sound like fix= ed settings that would be applicable to all links of a given type when I th= ink they are trying to describe the link layer performance with a given mes= saging profile in operation.

Do you agree that all nodes in= a given LLN SHOULD agree on a common
value for Imin?=A0 I don't hav= e any problem with declaring it out of scope for
the present draft, but = practically speaking it seems there should be a way to
a) define a reasonable default for a given link layer, and b) di= stribute a modified
value (I think Yusuke Doi is working on a DHCPv6 opt= ion for MPL parameters).

Regards, -K-
=A0
Don


=
From: Kerry Lynn <kerlyn@ieee.org>
Reply-To: Routing Over Low power and= Lossy networks <roll= @ietf.org>
Date: Friday, September 13, = 2013 6:58 AM

To: Rout= ing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] WGLC - Working= Group Last Call - draft-ietf-roll-trickle-mcast-05

Hi Don,

On Fri, Sep 13,= 2013 at 9:21 AM, Don Sturek <d.sturek@att.net> wrote:
I don't agree with the proposed technical changes below, specifica= lly:
1) =A0"- I have argued that to increase MPL's appli= cability, PROACTIVE_FORWARDING
=A0 should be a per-interface= and not a per-forwarder setting.=A0 I can imagine, for
=A0 example, a router that has both LLN and traditional interfac= es and proactive
=A0 forwarding seems unnecessary for the lat= ter.=A0 As [RFC 4007] states: "Zone
=A0 boundaries cut t= hrough nodes, not links."=A0 Suggested wording in section 5.4
=A0 could be "PROACTIVE_FORWARDING has a default value of T= RUE on links
=A0 where Realm-Local scope is defined, and FALS= E otherwise."

=A0 =A0 Given how forward= ing is defined in the draft, I don't see how the scenario above is poss= ible unless the links on the "traditional interfaces" happen to b= e members of the same MPL Domain as the LLN

I am looking at section 3, Applicabi= lity Statement, which says: "This protocol
may also be u= sed in environments where only a subset of links are considered
Low-Power and Lossy links."=A0 The change I proposed is minimal a= nd would
improve dynamic protocol behavior on non-LLN links. =

2) =A0"- Section 4.1 states: "When u= sed with MPL, Realm-Local scope is administratively
=A0 defined and used to define the boundaries of multicast message dissemin= ation
=A0 by MPL."=A0 This begs the question, why don= 9;t we just use scope =3D 0x04?=A0 We
=A0 probably need more = discussion on if and how a scope 0x03 zone boundary
=A0 is automatically defined (i.e. without human intervention) a= nd how forwarding
=A0 works for scope 0x03.=A0 One suggested = definition is that Realm-Local applies
=A0 to links where a s= ingle interface may belong to multiple Link-Local scopes."
=A0 =A0 =A0
=A0 =A0 =A0 This argument was made some ti= me ago and rejected. =A0 The purpose in defining and using a realm scoped a= ddress is to allow for automatic definition.
<= br>
I think I'm just confused about the desire for automatic definition of = the Realm-Local
scope and the several statements in the draft that it= 9;s administratively configured.
Asking as an implementer, how do I det= ermine whether an interface is in a Realm-
Local zone?=A0 Is it particular to LLN links?

I'm not= sure whether the draft is intending to reserve the ability to configure wh= ich
links are in the MPLInterfaceSet.=A0 However it seems that Realm-Loc= al scope, like
other multicast scopes, must have a consistent definition for an= y and all protocols
that use it.
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
The forwarding definition in the Trickle Multicast draft is b= y MPL Domain so the definition at the end of the paragraph above is not nee= ded. =A0 When using FF03::FC (defined for forwarding within a MPL Domain) t= hen all members of the MPL Domain are forwarded a copy of the multicast tra= nsmission. =A0Section 7.2 especially makes this clear, by interface, by def= ining:
   MPLInterfaceSet  - a set of MPL Interfaces that subscribe to t=
he MPL
          Domain Address that identifies the MPL Domain.
3) =A0- "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN p= arameters
=A0 described in section 5.5 will ultimately have = to be expressed in units of time
=A0 (either in this document or elsewhere) for a given link-laye= r in order to avoid
=A0 the "Mismatched min" issues discussed = in [RFC 6206, sect. 6.2].=A0 The same
=A0 reference states: "a prot= ocol SHOULD set k and Imin such that Imin is at least
=A0 two to three times as long as it takes to transmit k packets."

=A0 =A0 =A0Since we are using these parameters = as defined in RFC 6206 (Trickle Algorithm) we should not attempt to redefin= e them here in this draft.

Do the terms "expected link-lay= er latency" and "worst-case link-layer latency"
(used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,
respective= ly) have commonly defined definitions, e.g. in 802.15.4?=A0 If so,
what are they?=A0 I couldn't seem to determine this from the 802.15.4 s= pec.

Thanks, -K-
=A0

Don


<= div>
From: Kerry Lynn <kerlyn@ieee.org>
Reply-To: Routing Over Low power and Lossy= networks <roll@ietf.= org>
Date: Friday, September 13, 2013 5= :10 AM
To: Routing Over Low pow= er and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] WGLC - Working= Group Last Call - draft-ietf-roll-trickle-mcast-05

On Wed, Sep 4, 2013 at 3:= 45 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:=

A number of issues were raised this past spring by IESG and other reviewers=
on draft-ietf-roll-trickle-mcast. =A0You can review them using the custom q= uery:

http://trac.to= ols.ietf.org/wg/roll/trac/query?status=3Dassigned&status=3Dclosed&s= tatus=3Dnew&status=3Dreopened&component=3Dtrickle-mcast&group= =3Dcomponent&col=3Did&col=3Dsummary&col=3Dcomponent&col=3Ds= tatus&col=3Dtype&col=3Dpriority&col=3Dmilestone&order=3Dpri= ority

The chairs, Document Shephard and Document Authors believe that current
issues are closed in the -05 revision at:
=A0 =A0 =A0 =A0https://datatracker.ietf.org/doc/draft-ie= tf-roll-trickle-mcast/
A diff is available at:
=A0 =A0 =A0 =A0https://www.ietf.org/rfcdi= ff?url1=3Ddraft-ietf-roll-trickle-mcast-04&difftype=3D--html&submit= =3DGo%21&url2=3Ddraft-ietf-roll-trickle-mcast-05

We are starting another WG Last Call.
It will run until Friday 2013-09-13 at 9am EST.

Please read the document. =A0Do you concur that it is done?
Please post any and all comments.
=A0
The draft is looking good, but I have a few comments.<= br>
=A0
Editorial:

- In section 4.3, = on Proactive Forwarding, the phrase "MPL Data Message message"
=A0 is redundant and should be "MPL Data Message".
=
- In the last paragraph of section 4.3 the phrase "a ne= w MPL Data messages"
=A0 should be "a new MPL Data = Message".

- [I-D.droms-6man-multicast-scopes] should be moved fr= om section 14.1 to 14.2.


Technical:=

- I have argued that to increase MPL's applicability= , PROACTIVE_FORWARDING
=A0 should be a per-interface and not a per-forwarder setting.= =A0 I can imagine, for
=A0 example, a router that has both LL= N and traditional interfaces and proactive
=A0 forwarding see= ms unnecessary for the latter.=A0 As [RFC 4007] states: "Zone
=A0 boundaries cut through nodes, not links."=A0 Suggested = wording in section 5.4
=A0 could be "PROACTIVE_FORWARDIN= G has a default value of TRUE on links
=A0 where Realm-Local = scope is defined, and FALSE otherwise."

- Section 4.1 states: "When used with MPL, R= ealm-Local scope is administratively
=A0 defined and used to = define the boundaries of multicast message dissemination
=A0 = by MPL."=A0 This begs the question, why don't we just use scope = =3D 0x04?=A0 We
=A0 probably need more discussion on if and how a scope 0x03 zon= e boundary
=A0 is automatically defined (i.e. without human i= ntervention) and how forwarding
=A0 works for scope 0x03.=A0 = One suggested definition is that Realm-Local applies
=A0 to links where a single interface may belong to multiple Lin= k-Local scopes.

- The DATA_MESSAGE_IMIN and CO= NTROL_MESSAGE_IMIN parameters
=A0 described in section 5.5 wi= ll ultimately have to be expressed in units of time
=A0 (either in this document or elsewhere) for a given link-laye= r in order to avoid
=A0 the "Mismatched min" issues discussed = in [RFC 6206, sect. 6.2].=A0 The same
=A0 reference states: "a prot= ocol SHOULD set k and Imin such that Imin is at least
=A0 two to three times as long as it takes to transmit k packets."
=

Regards, -K-

=A0
If there is something you do not like, please provide a suggestion (a diff)=
about what to fix.

Thank you.

Michael and JP.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair. =A0 =A0http://datatracker.ietf.org/wg/roll/charter/<= /a>


______________________________________________= _
Roll mailing list
Rol= l@ietf.org
https://www.ietf.org/mailman/listinfo/roll


_______________________________________________ Roll mailing list Roll@ietf.orghttps://w= ww.ietf.org/mailman/listinfo/roll

____= ___________________________________________
Roll mailing list
Rol= l@ietf.org
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________ Roll mailing list Roll@ietf.orghttps://w= ww.ietf.org/mailman/listinfo/roll

_________= ______________________________________
Roll mailing list
Rol= l@ietf.org
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________ Roll mailing list Roll@ietf.org ht= tps://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--001a11c2047aa4656104e6497339-- From gnawali@cs.uh.edu Sun Sep 15 09:34:42 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C8211E8128 for ; Sun, 15 Sep 2013 09:34:42 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2kvQt7rTmQf for ; Sun, 15 Sep 2013 09:34:37 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 64F1C21F9EE5 for ; Sun, 15 Sep 2013 09:34:37 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id CCF7E23CA99 for ; Sun, 15 Sep 2013 11:34:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmYjyqyvsVgt for ; Sun, 15 Sep 2013 11:34:31 -0500 (CDT) Received: from it.cs.uh.edu (unknown [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id B0D2B23CA98 for ; Sun, 15 Sep 2013 11:34:31 -0500 (CDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by it.cs.uh.edu (Postfix) with ESMTP id D1DF52A280A9 for ; Sun, 15 Sep 2013 12:07:02 -0500 (CDT) Received: by mail-la0-f54.google.com with SMTP id ea20so2486934lab.27 for ; Sun, 15 Sep 2013 09:34:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=1974k5c3mESOFW6kbzRVj7jD4et9FGMGQZXrBVPSEeI=; b=i2koe97MmXXZIKGQ/MlC2g+iY31w7LlHZhgg10VO8xrV4GZ8W49yds5QABnbYO2rQ/ i6AsyyBoS26QkTmgpSnDdwJUSFItH6Mn6qKKg9IriMWIoi4x5zlEuUpnZExiWUJYrxLt xKDli4Bkh6ixcfwW3vD8iY9OoCFmZaPacbj7nCYG0eAgc0QqTgPdYMcHgdhi3kPtIyU1 L7Z2wuVp42iReUAvZZnCKw0VaENwCNLdNlLVPx8GP19cLOQZ1XtRbtyShlUGUMSvphZk OoaqYhAYZBWjjeX6HPyG1M92CUDwdpJ7XcOq/Xq+s5ct8G+IQ0z9UGqltj37s8a+Ty1g 19nA== X-Received: by 10.112.29.147 with SMTP id k19mr21514687lbh.9.1379262869799; Sun, 15 Sep 2013 09:34:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.236.3 with HTTP; Sun, 15 Sep 2013 09:34:09 -0700 (PDT) In-Reply-To: <3072B0E1-55AE-4DF7-8061-0B2A28961801@gmail.com> References: <3072B0E1-55AE-4DF7-8061-0B2A28961801@gmail.com> From: Omprakash Gnawali Date: Sun, 15 Sep 2013 11:34:09 -0500 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] comments for draft-gnawali-roll-rpl-recommendations? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 16:34:42 -0000 The recommendations are based on testbed experiments with TelosB motes and unless otherwise noted, focused on non-storing mode. The recommendations come from some published work and some unpublished work I shared with this WG 2-3 yrs ago. Recommendation #10 is based on numbers reported and survey of code. There have been a lot of RPL deployments, would be great to collect the experiences from them. - om_p On Fri, Sep 13, 2013 at 1:06 PM, Ralph Droms wrote: > Interesting and useful doc. > > Unless explicitly noted, do the recommendations apply to both storing and non-storing modes? > > Are your recommendations based on deployments, simulations, protocol analysis? Do you have any references you can cite that provide the input for your recommendations? > > - Ralph > > On Sep 13, 2013, at 2:14 AM 9/13/13, Omprakash Gnawali wrote: > >> Dear ROLL WG, >> >> I plan to update the draft-gnawali-roll-rpl-recommendations in the >> next day or two. I would love to hear about any new/old/usual/unusual >> experiences about RPL use so that I can collect those insights in this >> draft to benefit everyone in the community. >> >> Here is the URL to the current draft: >> http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-03 >> >> Thank you. >> >> - om_p >> _______________________________________________ >> 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 stokcons@xs4all.nl Mon Sep 16 01:12:19 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A4C11E80F4 for ; Mon, 16 Sep 2013 01:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.705 X-Spam-Level: * X-Spam-Status: No, score=1.705 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rnREi4mmlsK for ; Mon, 16 Sep 2013 01:11:57 -0700 (PDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA1111E80F8 for ; Mon, 16 Sep 2013 01:11:29 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id r8G8BJiD041824 for ; Mon, 16 Sep 2013 10:11:24 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-206-54.w92-145.abo.wanadoo.fr ([92.145.97.54]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 16 Sep 2013 10:11:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 16 Sep 2013 10:11:19 +0200 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl (BVDhGgbgSx0Z20m9v/cfaSXF0SVXaqCP) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 08:12:22 -0000 Hi all, I should like to comment on the point below. > > 2) "Do you agree that all nodes in a given LLN SHOULD agree on a > commonvalue for Imin? …… " > > I believe it is requirement that all devices in a given MPL Domain > MUST agree on a common value for IMIN, IMAX and k. In terms of a > default, we can certainly create such values applicable to given > deployment topology and an assumed messaging profile but I really > think some work should go into an applicability statement that would > provide additional guidance on how to tune these values. I think I > mentioned this before but we did (in ZigBee IP) create a 30 node, 3 > hop network supporting a ROLL RPL instance, instrumented all devices, > created a single multicast message and measured how many devices in > the network saw at least a single copy of the transmission using > various settings for IMIN, IMAX and k. A process similar to this (with > knowledge of the topology and messaging profile) is needed for tuning > these values in a real deployment setting. After looking for an appropriate setting for Imin, Imax and k, I slowly learnt that these settings depend on the topology of the network, the load of the network, the setting of the MAC, and eventual real-time requirements (e.g. there is a deadline), and the value of that deadline. The setting of k for example is related to the number of MPL repeaters that receive a new message and start to resend it, possibly interfering with each other and probably incrementing the c value of the next hop, where the maximum value of c is related to the Imin value. Sending a packet takes as little as 3 ms, but when the MAC stores three packets and the they all back-off a maximum number of times, delays of a few hundred milliseconds to seconds become possible. When there is buffer space for packets before and in the MAC, the Imin value can be chosen as low as 1 ms, the resend of packets is then completely determined by the load on the network. And there are many more conditions and mutual dependencies. So, I suggest to leave the default values mentioned in the draft as they are, and leave the tuning of the parameters to the people who deploy and have experience with a certain class of networks. The applicability statement can give configuration examples and suggest some best practice values. I think an analysis of a set of configurations with temporal objectives and network load is too much text for the applicability statement, and is best referred to from the applicability statement. Peter From mcr@sandelman.ca Mon Sep 16 07:59:36 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B58011E8279 for ; Mon, 16 Sep 2013 07:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIkq1PzXClD8 for ; Mon, 16 Sep 2013 07:59:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 510B811E8110 for ; Mon, 16 Sep 2013 07:59:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 90A932016F for ; Mon, 16 Sep 2013 12:08:06 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5B5B263B18; Mon, 16 Sep 2013 10:59:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 49E65636C7 for ; Mon, 16 Sep 2013 10:59:14 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 14:59:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kerry Lynn wrote: don>> =C2=A0 =C2=A0 =C2=A0 I believe it is requirement that all dev= ices in a given don>> MPL Domain MUST agree on a common value for IMIN, IMAX and k. =C2= =A0In don>> terms of a default, we can certainly create such values applicable don>> to given deployment topology and an assumed messaging profile but= I don>> really think some work should go into an applicability statement don>> that would provide additional guidance on how to tune these don>> values. =C2=A0I think I mentioned this before but we did (in ZigB= ee IP) don>> create a 30 node, 3 hop network supporting a ROLL RPL instance, don>> instrumented all devices, created a single multicast message and don>> measured how many devices in the network saw at least a single co= py don>> of the transmission using various settings for IMIN, IMAX and k. = =C2=A0A don>> process similar to this (with knowledge of the topology and don>> messaging profile) is needed for tuning these values in a real don>> deployment setting. Kerry> ACK.=C2=A0 Thanks for your explanations. With this, are your questions resolved, or are there further text changes requested? =2D- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUjccwIqHRg3pndX9AQI4PAQAmaxBctRev/0irfZePMcS1fvImRBslOXg IjISHYv2YnjtoZ3+2hi75wmjuJWbDjHsOZufDLqQ0XPNU5MR3R80OXvC3U9vWhjn pBsX+OvXXV2npfj0psAELoDXSNkZalYms6iUYSUNxyJbn+wg+NGCDVhouJZe3YMR R5P14VUFRTw= =NUv2 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Sep 16 08:16:10 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB91B11E812A for ; Mon, 16 Sep 2013 08:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMcRDPWW3dxH for ; Mon, 16 Sep 2013 08:16:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 2C54111E82A4 for ; Mon, 16 Sep 2013 08:15:54 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 769A62016F; Mon, 16 Sep 2013 12:24:40 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 41F4763B18; Mon, 16 Sep 2013 11:15:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 32F0F636C7; Mon, 16 Sep 2013 11:15:48 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 15:16:10 -0000 --=-=-= peter van der Stok wrote: >> various settings for IMIN, IMAX and k. A process similar to this (with >> knowledge of the topology and messaging profile) is needed for tuning >> these values in a real deployment setting. peter> After looking for an appropriate setting for Imin, Imax and k, I peter> slowly learnt that these settings depend on the topology of the peter> network, the load of the network, the setting of the MAC, and peter> eventual real-time requirements (e.g. there is a deadline), and peter> the value of that deadline. The setting of k for example is peter> related to the number of MPL repeaters that receive a new message peter> and start to resend it, possibly interfering with each other and peter> probably incrementing the c value of the next hop, where the peter> maximum value of c is related to the Imin value. Sending a packet peter> takes as little as 3 ms, but when the MAC stores three packets and peter> the they all back-off a maximum number of times, delays of a few peter> hundred milliseconds to seconds become possible. When there is peter> buffer space for packets before and in the MAC, the Imin value can peter> be chosen as low as 1 ms, the resend of packets is then completely peter> determined by the load on the network. This is an excellent template discussion... can I put it into the MPL parameter part of the RPL applicability template? Do you think you could rephrase this in the form of questions to be answered? -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUjcgooqHRg3pndX9AQIuTgQAtzc3gCiSzsm83fl/aLrh8zuTkCQ/xDO8 D60kLiPcNhhyhmTpecOxbjS5sH+gLuDQDF7iHgbVhTXFp+LzGEKvPTp+hizBIO7G LMhCex7xliDWevZx1vU/mYzTBaH6O0X8y8s5b9mypycobw2TExzyyhzZtXYTy73f kmR4H0bEXNA= =AiLc -----END PGP SIGNATURE----- --=-=-=-- From kerlyn2001@gmail.com Mon Sep 16 09:24:41 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E2E11E829F for ; Mon, 16 Sep 2013 09:24:41 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tUyuIcQOxIQ for ; Mon, 16 Sep 2013 09:24:40 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 40FDD21F8263 for ; Mon, 16 Sep 2013 09:24:40 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id f4so206694oah.15 for ; Mon, 16 Sep 2013 09:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=uc2YJ+bK2F4z/4ihGTKGg7Df8/hcq/srmiDkjEyPy3s=; b=jv0oYoh+Ot3hs/1Czt4Y/TZ9SdXGQIxOIYCABnOqjtYn3SjS5TIuzpwJPXvy1o1Zpb xB1gprIOUTQWsAeSld/PPIPaRzusNfqC4J/5VqU/NL4edpIOhFez7MQ/OwP0TdhfHl6X Bb2gNAjYVN5o/ozH3NSgJVCyD3Nd/sJslrJ+wI5qPa4/zz6Sttfyvh0QzTf/t+3LCCBq OGalX0+oVm85LUncsT5jJJUZ+ZwyYRDo5GUFXHD00q1V8vDPKl3SZOBpGh1feS2CZUg2 TZucYStXaguQ3v/OzP1J+PyXwvSY1kTFMMAf9qTOBBpFoIvKMQnCq7SQhzsftNpdciMG g5og== MIME-Version: 1.0 X-Received: by 10.182.121.137 with SMTP id lk9mr538263obb.32.1379348679688; Mon, 16 Sep 2013 09:24:39 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.41.36 with HTTP; Mon, 16 Sep 2013 09:24:39 -0700 (PDT) In-Reply-To: <9392.1379343554@sandelman.ca> References: <9392.1379343554@sandelman.ca> Date: Mon, 16 Sep 2013 12:24:39 -0400 X-Google-Sender-Auth: ZWookno5Vmj6Ph___yS3S1mWUr4 Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e0149ccae13080004e682a49f Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 16:24:41 -0000 --089e0149ccae13080004e682a49f Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, Do you have time for a brief chat today? 978-440-8508. Thanks, -K- On Mon, Sep 16, 2013 at 10:59 AM, Michael Richardson wrote: > > Kerry Lynn wrote: > don>> I believe it is requirement that all devices in a given > don>> MPL Domain MUST agree on a common value for IMIN, IMAX and k. In > don>> terms of a default, we can certainly create such values > applicable > don>> to given deployment topology and an assumed messaging profile > but I > don>> really think some work should go into an applicability statement > don>> that would provide additional guidance on how to tune these > don>> values. I think I mentioned this before but we did (in ZigBee > IP) > don>> create a 30 node, 3 hop network supporting a ROLL RPL instance, > don>> instrumented all devices, created a single multicast message and > don>> measured how many devices in the network saw at least a single > copy > don>> of the transmission using various settings for IMIN, IMAX and k. > A > don>> process similar to this (with knowledge of the topology and > don>> messaging profile) is needed for tuning these values in a real > don>> deployment setting. > > Kerry> ACK. Thanks for your explanations. > > With this, are your questions resolved, or are there further text changes > requested? > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --089e0149ccae13080004e682a49f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael,

Do you have time for a = brief chat today?
978-440-8508.

Thanks, -K-


On Mon, Sep 16, 201= 3 at 10:59 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Kerry Lynn <kerlyn@ieee.org> w= rote:
=A0 =A0 don>> =A0 =A0 =A0 =A0 =A0 I believe it is requirement that al= l devices in a given
=A0 =A0 don>> MPL Domain MUST agree on a common value for IMIN, IMAX = and k. =A0In
=A0 =A0 don>> terms of a default, we can certainly create such values= applicable
=A0 =A0 don>> to given deployment topology and an assumed messaging p= rofile but I
=A0 =A0 don>> really think some work should go into an applicability = statement
=A0 =A0 don>> that would provide additional guidance on how to tune t= hese
=A0 =A0 don>> values. =A0I think I mentioned this before but we did (= in ZigBee IP)
=A0 =A0 don>> create a 30 node, 3 hop network supporting a ROLL RPL i= nstance,
=A0 =A0 don>> instrumented all devices, created a single multicast me= ssage and
=A0 =A0 don>> measured how many devices in the network saw at least a= single copy
=A0 =A0 don>> of the transmission using various settings for IMIN, IM= AX and k. =A0A
=A0 =A0 don>> process similar to this (with knowledge of the topology= and
=A0 =A0 don>> messaging profile) is needed for tuning these values in= a real
=A0 =A0 don>> deployment setting.

=A0 =A0 Kerry> ACK.=A0 Thanks for your explanations.

With this, are your questions resolved, or are there further text changes requested?

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair. =A0 =A0http://datatracker.ietf.org/wg/roll/charter/<= /a>


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


--089e0149ccae13080004e682a49f-- From internet-drafts@ietf.org Mon Sep 16 16:18:46 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955A611E8151; Mon, 16 Sep 2013 16:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfQXNMmzaovV; Mon, 16 Sep 2013 16:18:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFC211E81D1; Mon, 16 Sep 2013 16:18:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130916231841.30340.29964.idtracker@ietfa.amsl.com> Date: Mon, 16 Sep 2013 16:18:41 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-template-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 23:18:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : ROLL Applicability Statement Template Author(s) : Michael C. Richardson Filename : draft-ietf-roll-applicability-template-02.txt Pages : 15 Date : 2013-09-16 Abstract: This document is a template applicability statement for the Routing over Low-power and Lossy Networks (ROLL) WG. This document is not for publication, but rather is to be used as a template. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-applicability-template-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-applicability-template-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yoshihiro.ohba@toshiba.co.jp Mon Sep 16 18:06:29 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2384111E8298 for ; Mon, 16 Sep 2013 18:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qnrpk4g0ulhK for ; Mon, 16 Sep 2013 18:06:23 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id AF56E11E82CE for ; Mon, 16 Sep 2013 18:06:16 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r8H16Fj8007675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Sep 2013 10:06:15 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r8H16Fim017747 for ; Tue, 17 Sep 2013 10:06:15 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 196 for ; Tue, 17 Sep 2013 10:06:15 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r8H16FQD017727 for ; Tue, 17 Sep 2013 10:06:15 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r8H16F44028343 for roll@ietf.org; Tue, 17 Sep 2013 10:06:15 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id LAA28332; Tue, 17 Sep 2013 10:06:14 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r8H16EYU018575 for ; Tue, 17 Sep 2013 10:06:14 +0900 (JST) Received: from tgxml329.toshiba.local by toshiba.co.jp id r8H16CxT010393; Tue, 17 Sep 2013 10:06:13 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.202]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.03.0158.001; Tue, 17 Sep 2013 10:06:12 +0900 From: To: Thread-Topic: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 Thread-Index: AQHOsL1jGSZa+eq1Hkqpp40HheEi2ZnH4kMAgAE/g5A= Date: Tue, 17 Sep 2013 01:06:12 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B18868C37@tgxml338.toshiba.local> References: <9392.1379343554@sandelman.ca> In-Reply-To: <9392.1379343554@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.17.37] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 01:06:29 -0000 RllJLCBkcmFmdC1kb2ktcm9sbC1tcGwtcGFyYW1ldGVyLWNvbmZpZ3VyYXRpb24gZGVzY3JpYmVz IGFuIGF1dG9tYXRlZCB3YXkgdG8gc2V0IGEgY29tbW9uIHZhbHVlIGZvciBJTUlOLCBJTUFYIGFu ZCBrIHVzaW5nIERIQ1AuDQoNCllvc2hpaGlybyBPaGJhDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwgUmljaGFyZHNvbg0KU2VudDogTW9uZGF5 LCBTZXB0ZW1iZXIgMTYsIDIwMTMgMTE6NTkgUE0NClRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2Vy IGFuZCBMb3NzeSBuZXR3b3Jrcw0KU3ViamVjdDogUmU6IFtSb2xsXSBXR0xDIC0gV29ya2luZyBH cm91cCBMYXN0IENhbGwgLSBkcmFmdC1pZXRmLXJvbGwtdHJpY2tsZS1tY2FzdC0wNQ0KDQoNCktl cnJ5IEx5bm4gPGtlcmx5bkBpZWVlLm9yZz4gd3JvdGU6DQogICAgZG9uPj4gICAgIMKgIMKgIMKg IEkgYmVsaWV2ZSBpdCBpcyByZXF1aXJlbWVudCB0aGF0IGFsbCBkZXZpY2VzIGluIGEgZ2l2ZW4N CiAgICBkb24+PiBNUEwgRG9tYWluIE1VU1QgYWdyZWUgb24gYSBjb21tb24gdmFsdWUgZm9yIElN SU4sIElNQVggYW5kIGsuIMKgSW4NCiAgICBkb24+PiB0ZXJtcyBvZiBhIGRlZmF1bHQsIHdlIGNh biBjZXJ0YWlubHkgY3JlYXRlIHN1Y2ggdmFsdWVzIGFwcGxpY2FibGUNCiAgICBkb24+PiB0byBn aXZlbiBkZXBsb3ltZW50IHRvcG9sb2d5IGFuZCBhbiBhc3N1bWVkIG1lc3NhZ2luZyBwcm9maWxl IGJ1dCBJDQogICAgZG9uPj4gcmVhbGx5IHRoaW5rIHNvbWUgd29yayBzaG91bGQgZ28gaW50byBh biBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudA0KICAgIGRvbj4+IHRoYXQgd291bGQgcHJvdmlkZSBh ZGRpdGlvbmFsIGd1aWRhbmNlIG9uIGhvdyB0byB0dW5lIHRoZXNlDQogICAgZG9uPj4gdmFsdWVz LiDCoEkgdGhpbmsgSSBtZW50aW9uZWQgdGhpcyBiZWZvcmUgYnV0IHdlIGRpZCAoaW4gWmlnQmVl IElQKQ0KICAgIGRvbj4+IGNyZWF0ZSBhIDMwIG5vZGUsIDMgaG9wIG5ldHdvcmsgc3VwcG9ydGlu ZyBhIFJPTEwgUlBMIGluc3RhbmNlLA0KICAgIGRvbj4+IGluc3RydW1lbnRlZCBhbGwgZGV2aWNl cywgY3JlYXRlZCBhIHNpbmdsZSBtdWx0aWNhc3QgbWVzc2FnZSBhbmQNCiAgICBkb24+PiBtZWFz dXJlZCBob3cgbWFueSBkZXZpY2VzIGluIHRoZSBuZXR3b3JrIHNhdyBhdCBsZWFzdCBhIHNpbmds ZSBjb3B5DQogICAgZG9uPj4gb2YgdGhlIHRyYW5zbWlzc2lvbiB1c2luZyB2YXJpb3VzIHNldHRp bmdzIGZvciBJTUlOLCBJTUFYIGFuZCBrLiDCoEENCiAgICBkb24+PiBwcm9jZXNzIHNpbWlsYXIg dG8gdGhpcyAod2l0aCBrbm93bGVkZ2Ugb2YgdGhlIHRvcG9sb2d5IGFuZA0KICAgIGRvbj4+IG1l c3NhZ2luZyBwcm9maWxlKSBpcyBuZWVkZWQgZm9yIHR1bmluZyB0aGVzZSB2YWx1ZXMgaW4gYSBy ZWFsDQogICAgZG9uPj4gZGVwbG95bWVudCBzZXR0aW5nLg0KDQogICAgS2Vycnk+IEFDSy7CoCBU aGFua3MgZm9yIHlvdXIgZXhwbGFuYXRpb25zLg0KDQpXaXRoIHRoaXMsIGFyZSB5b3VyIHF1ZXN0 aW9ucyByZXNvbHZlZCwgb3IgYXJlIHRoZXJlIGZ1cnRoZXIgdGV4dCBjaGFuZ2VzIHJlcXVlc3Rl ZD8NCg0KLS0NCk1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2Fu ZGVsbWFuIFNvZnR3YXJlIFdvcmtzDQpJRVRGIFJPTEwgV0cgY28tY2hhaXIuICAgIGh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy93Zy9yb2xsL2NoYXJ0ZXIvDQoNCg== From robert.cragie@gridmerge.com Tue Sep 17 02:25:54 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE4711E83CF for ; Tue, 17 Sep 2013 02:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLPMT8zkZ+X4 for ; Tue, 17 Sep 2013 02:25:41 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id E1E1E11E83C7 for ; Tue, 17 Sep 2013 02:25:39 -0700 (PDT) Received: from [94.117.44.56] (helo=[10.38.241.149]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1VLrXI-0003OL-Ma; Tue, 17 Sep 2013 10:25:32 +0100 Message-ID: <5238200F.1030109@gridmerge.com> Date: Tue, 17 Sep 2013 10:25:35 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010207040603000704010003" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 09:25:54 -0000 This is a cryptographically signed message in MIME format. --------------ms010207040603000704010003 Content-Type: multipart/alternative; boundary="------------060406000501060806080006" This is a multi-part message in MIME format. --------------060406000501060806080006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Just to weigh in with my views: On (1): I see no inconsistency with using scope 3 and the text written in=20 draft-ietf-roll-trickle-mcast-05 and=20 draft-droms-6man-multicast-scopes-02. "Automatically configured" can=20 simply mean defined or implied by the network topology. Basing the MPL=20 Domain multicast scope on the scope of the DAG prefix based on the=20 configuration of the participating router seems like a good idea and=20 example of automatically implied scope. Deployment of MPL in alternative = network topologies can imply a similar scope. An example could be given=20 in draft-ietf-roll-trickle-mcast-05 but I don't think it is necessary. On (2): I agree that all nodes in a MPL Domain MUST agree on a common value. I=20 don't think any recommended values should be given and it depends on the = applicability. In a nutshell - I think draft-ietf-roll-trickle-mcast-05 is good to go. Robert On 13/09/2013 21:10, Kerry Lynn wrote: > On Fri, Sep 13, 2013 at 2:58 PM, Don Sturek > wrote: > > HI Kerry, > > So again, two points to comment on.....: > 1) "(A)-BR1---BR2-(B) > > Let's say we have two LLNs, A and B, connected by BRs and a > traditional link > like WiFi or ethernet......." > > In general it is possible to have the "traditional link" > between BR1 and BR2 to support ROLL RPL and therefore include the > "traditional link" interfaces as part of the MPL Domain. I > believe this would depend on the routing scope declared in BR1 and > BR2 for those interfaces. > Most of the deployments I have seen would have (A) and (B) > in different MPL Domain realms. This would solely be defined in > BR1 and BR2 as to which interfaces they include to support RPL > routing. > > 2) "Do you agree that all nodes in a given LLN SHOULD agree on a > common > value for Imin? ...... " > > I believe it is requirement that all devices in a given MPL > Domain MUST agree on a common value for IMIN, IMAX and k. In > terms of a default, we can certainly create such values applicable > to given deployment topology and an assumed messaging profile but > I really think some work should go into an applicability statement > that would provide additional guidance on how to tune these > values. I think I mentioned this before but we did (in ZigBee IP) > create a 30 node, 3 hop network supporting a ROLL RPL instance, > instrumented all devices, created a single multicast message and > measured how many devices in the network saw at least a single > copy of the transmission using various settings for IMIN, IMAX and > k. A process similar to this (with knowledge of the topology and > messaging profile) is needed for tuning these values in a real > deployment setting. > > > ACK. Thanks for your explanations. > > -K- > > Don > > > From: Kerry Lynn > > Reply-To: Routing Over Low power and Lossy networks > > Date: Friday, September 13, 2013 10:56 AM > > To: Routing Over Low power and Lossy networks > > Subject: Re: [Roll] WGLC - Working Group Last Call - > draft-ietf-roll-trickle-mcast-05 > > Don, thanks for your additional comments... > > On Fri, Sep 13, 2013 at 10:45 AM, Don Sturek > wrote: > > Hi Kerry, > > Two points from below: > 1) "Asking as an implementer, how do I determine whether an > interface is in a Realm- > Local zone? Is it particular to LLN links?" > > As with other multicast addresses, an interface would > register (opt-in) to a realm. For Trickle Multicast, it would > then depend on whether the interface has subscribed to the MPL > Domain Address. The difference between using realm scoped > (from Ralph's draft) and administratively scoped (FF04) is the > membership in the MPL Domain can be managed automatically by > actions within the device. > > I'm willing to accept that I may be the only one who's confused.=20 > Let me illustrate > with an example: > > (A)-BR1---BR2-(B) > > Let's say we have two LLNs, A and B, connected by BRs and a > traditional link > like WiFi or ethernet. Further, there are MPL forwarders deployed > in both A > and B. (I'd imagine that the LLN interfaces on the BRs are MPL > forwarders.) > Are there two separate realm-local zones? If that is the case > then it seems > there should be some intrinsic property that allows a router to > determine if a > link is in the scope zone or not. For example, if we were talking > about link- > local scope zones and the example about consisted of traditional > links and > routers, then the scope boundaries would be defined as cutting > through the > routers and would be the same for all link-local multicast > protocols. That is, > there would be no inter-connectivity between a node in A and a > node in B that > were subscribed to the same multicast group. > > I'm mainly interested in resolving the apparent contradiction > between the > "administratively configured" language in the MPL draft and the > "automatically > configured" language in Ralph's draft (and in your comment). > > > 2) "Do the terms "expected link-layer latency" and > "worst-case link-layer latency" > (used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN, > respectively) have commonly defined definitions, e.g. in > 802.15.4? If so, > what are they? I couldn't seem to determine this from the > 802.15.4 spec." > > The simple answer to this is there is not a prescribed > layer 2 latency value for 802.15.4 other than the defined one > hop ACK latency if you use MAC Acknowledges. Just FYI, in > testing IEEE 802.15.4-2003/2006 (127 byte PDU) with just 2 > devices on a clear channel, we found a typical "one hop/one > packet " message latency to be around 4ms (without security) > and around 12 ms (using SW based security). In my experience, > the "expected link layer latency" and "worst case link layer > latency" (speaking strictly about the link layer only) are > just a single aspect to setting IMIN correctly. The overall > application message pattern plays a larger role for these > settings (for example, how frequently multicasts are > generated, how many simultaneous multicasts can be generated > within a given MPL Domain in a window of time that occurs > within IMIN, etc.). Additionally, another major driver to > these settings are the deployment characteristics of the MPL > Domain member devices (for example. how many incoming message > buffers are supported in the member devices MAC, how many > outgoing message buffers, etc.). Perhaps the names "expected > link layer latency" and "worst case link layer latency" are a > bit misleading since they sound like fixed settings that would > be applicable to all links of a given type when I think they > are trying to describe the link layer performance with a given > messaging profile in operation. > > Do you agree that all nodes in a given LLN SHOULD agree on a common= > value for Imin? I don't have any problem with declaring it out of > scope for > the present draft, but practically speaking it seems there should > be a way to > a) define a reasonable default for a given link layer, and b) > distribute a modified > value (I think Yusuke Doi is working on a DHCPv6 option for MPL > parameters). > > Regards, -K- > > Don > > > From: Kerry Lynn > > Reply-To: Routing Over Low power and Lossy networks > > > Date: Friday, September 13, 2013 6:58 AM > > To: Routing Over Low power and Lossy networks > > Subject: Re: [Roll] WGLC - Working Group Last Call - > draft-ietf-roll-trickle-mcast-05 > > Hi Don, > > On Fri, Sep 13, 2013 at 9:21 AM, Don Sturek > wrote: > > I don't agree with the proposed technical changes below, > specifically: > 1) "- I have argued that to increase MPL's applicability, > PROACTIVE_FORWARDING > should be a per-interface and not a per-forwarder > setting. I can imagine, for > example, a router that has both LLN and traditional > interfaces and proactive > forwarding seems unnecessary for the latter. As [RFC > 4007] states: "Zone > boundaries cut through nodes, not links." Suggested > wording in section 5.4 > could be "PROACTIVE_FORWARDING has a default value of > TRUE on links > where Realm-Local scope is defined, and FALSE otherwise."= > > Given how forwarding is defined in the draft, I don't > see how the scenario above is possible unless the links on > the "traditional interfaces" happen to be members of the > same MPL Domain as the LLN > > > I am looking at section 3, Applicability Statement, which > says: "This protocol > may also be used in environments where only a subset of links > are considered > Low-Power and Lossy links." The change I proposed is minimal > and would > improve dynamic protocol behavior on non-LLN links. > > > 2) "- Section 4.1 states: "When used with MPL, > Realm-Local scope is administratively > defined and used to define the boundaries of multicast > message dissemination > by MPL." This begs the question, why don't we just use > scope =3D 0x04? We > probably need more discussion on if and how a scope 0x03 > zone boundary > is automatically defined (i.e. without human > intervention) and how forwarding > works for scope 0x03. One suggested definition is that > Realm-Local applies > to links where a single interface may belong to multiple > Link-Local scopes." > This argument was made some time ago and rejected. > The purpose in defining and using a realm scoped address > is to allow for automatic definition. > > > I think I'm just confused about the desire for automatic > definition of the Realm-Local > scope and the several statements in the draft that it's > administratively configured. > Asking as an implementer, how do I determine whether an > interface is in a Realm- > Local zone? Is it particular to LLN links? > > I'm not sure whether the draft is intending to reserve the > ability to configure which > links are in the MPLInterfaceSet. However it seems that > Realm-Local scope, like > other multicast scopes, must have a consistent definition for > any and all protocols > that use it. > > The forwarding definition in the Trickle Multicast draft > is by MPL Domain so the definition at the end of the > paragraph above is not needed. When using FF03::FC > (defined for forwarding within a MPL Domain) then all > members of the MPL Domain are forwarded a copy of the > multicast transmission. Section 7.2 especially makes this > clear, by interface, by defining: > > MPLInterfaceSet - a set of MPL Interfaces that subscri= be to the MPL > Domain Address that identifies the MPL Domain. > > > 3) - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN > parameters > described in section 5.5 will ultimately have to be > expressed in units of time > (either in this document or elsewhere) for a given > link-layer in order to avoid > the "Mismatched min" issues discussed in [RFC 6206, > sect. 6.2]. The same > reference states: "a protocol SHOULD set k and Imin such > that Imin is at least > two to three times as long as it takes to transmit k > packets." > > Since we are using these parameters as defined in RFC > 6206 (Trickle Algorithm) we should not attempt to redefine > them here in this draft. > > > Do the terms "expected link-layer latency" and "worst-case > link-layer latency" > (used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN, > respectively) have commonly defined definitions, e.g. in > 802.15.4? If so, > what are they? I couldn't seem to determine this from the > 802.15.4 spec. > > Thanks, -K- > > > Don > > > From: Kerry Lynn >= > Reply-To: Routing Over Low power and Lossy networks > > > Date: Friday, September 13, 2013 5:10 AM > To: Routing Over Low power and Lossy networks > > > Subject: Re: [Roll] WGLC - Working Group Last Call - > draft-ietf-roll-trickle-mcast-05 > > On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson > > wrot= e: > > > A number of issues were raised this past spring by > IESG and other reviewers > on draft-ietf-roll-trickle-mcast. You can review them > using the custom query: > > http://trac.tools.ietf.org/wg/roll/trac/query?status=3D= assigned&status=3Dclosed&status=3Dnew&status=3Dreopened&component=3Dtrick= le-mcast&group=3Dcomponent&col=3Did&col=3Dsummary&col=3Dcomponent&col=3Ds= tatus&col=3Dtype&col=3Dpriority&col=3Dmilestone&order=3Dpriority > > The chairs, Document Shephard and Document Authors > believe that current > issues are closed in the -05 revision at: > https://datatracker.ietf.org/doc/draft-ietf-roll-trickl= e-mcast/ > A diff is available at: > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-roll-tri= ckle-mcast-04&difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-roll-tri= ckle-mcast-05 > > We are starting another WG Last Call. > It will run until Friday 2013-09-13 at 9am EST. > > Please read the document. Do you concur that it is don= e? > Please post any and all comments. > > The draft is looking good, but I have a few comments. > Editorial: > > - In section 4.3, on Proactive Forwarding, the phrase "MPL > Data Message message" > is redundant and should be "MPL Data Message". > > - In the last paragraph of section 4.3 the phrase "a new > MPL Data messages" > should be "a new MPL Data Message". > > - [I-D.droms-6man-multicast-scopes] should be moved from > section 14.1 to 14.2. > > > Technical: > > - I have argued that to increase MPL's applicability, > PROACTIVE_FORWARDING > should be a per-interface and not a per-forwarder > setting. I can imagine, for > example, a router that has both LLN and traditional > interfaces and proactive > forwarding seems unnecessary for the latter. As [RFC > 4007] states: "Zone > boundaries cut through nodes, not links." Suggested > wording in section 5.4 > could be "PROACTIVE_FORWARDING has a default value of > TRUE on links > where Realm-Local scope is defined, and FALSE otherwise."= > > - Section 4.1 states: "When used with MPL, Realm-Local > scope is administratively > defined and used to define the boundaries of multicast > message dissemination > by MPL." This begs the question, why don't we just use > scope =3D 0x04? We > probably need more discussion on if and how a scope 0x03 > zone boundary > is automatically defined (i.e. without human > intervention) and how forwarding > works for scope 0x03. One suggested definition is that > Realm-Local applies > to links where a single interface may belong to multiple > Link-Local scopes. > > - The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters= > described in section 5.5 will ultimately have to be > expressed in units of time > (either in this document or elsewhere) for a given > link-layer in order to avoid > the "Mismatched min" issues discussed in [RFC 6206, > sect. 6.2]. The same > reference states: "a protocol SHOULD set k and Imin such > that Imin is at least > two to three times as long as it takes to transmit k > packets." > > Regards, -K- > > If there is something you do not like, please provide > a suggestion (a diff) > about what to fix. > > Thank you. > > Michael and JP. > > -- > Michael Richardson >, Sandelman Software > Works > IETF ROLL WG co-chair. > http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ Roll > mailing list Roll@ietf.org > https://www.ietf.org/mailman/listinfo= /roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ Roll mailing > list Roll@ietf.org > https://www.ietf.org/mailman/listinfo/rol= l > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------060406000501060806080006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just to weigh in with my views:

On (1):

I see no inconsistency with using scope 3 and the text written in draft-ietf-roll-trickle-mcast-05 and draft-droms-6man-multicast-scopes-02. "Automatically configured" can simply mean defined or implied by the network topology. Basing the MPL Domain multicast scope on the scope of the DAG prefix based on the configuration of the participating router seems like a good idea and example of automatically implied scope. Deployment of MPL in alternative network topologies can imply a similar scope. An example could be given in draft-ietf-roll-trickle-mcast-05 but I don't think it is necessary.

On (2):

I agree that all nodes in a MPL Domain MUST agree on a common value. I don't think any recommended values should be given and it depends on the applicability.

In a nutshell - I think draft-ietf-roll-trickle-mcast-05 is good to go.

Robert


On 13/09/2013 21:10, Kerry Lynn wrote:=
On Fri, Sep 13, 2013 at 2:58 PM, Don Sturek <d.sturek@a= tt.net> wrote:
HI Kerry,

So again, two points to comment on…..:
1)  "(A)-BR1---BR2-(B)

Let's say we have two LLNs, A and B, connected by BRs and a traditional link
like WiFi or ethernet……."

      In general it is possible to ha= ve the "traditional link" between BR1 and BR2 to support ROLL RPL and therefore include the "traditional link" interfaces as part of the MPL Domain.   I believe = this would depend on the routing scope declared in BR1 and BR2 for those interfaces.
      Most of the deployments I have = seen would have (A) and (B) in different MPL Domain realms.  = This would solely be defined in BR1 and BR2 as to which interfaces they include to support RPL routing.

2)  "Do you agree that all nodes in a given LLN= SHOULD agree on a common
value for Imin? ……  "

      I believe it is requirement tha= t all devices in a given MPL Domain MUST agree on a common value for IMIN, IMAX and k.  In terms of a default, we can certainly create such values applicable to given deployment topology and an assumed messaging profile but I really think some work should go into an applicability statement that would provide additional guidance on how to tune these values.  I think I mentioned this before but we did (in ZigBee IP) create a 30 node, 3 hop network supporting a ROLL RPL instance, instrumented all devices, created a single multicast message and measured how many devices in the network saw at least a single copy of the transmission using various settings for IMIN, IMAX and k.  A process similar to this (with knowledge of the topology and messaging profile) is needed for tuning these values in a real deployment setting.


ACK.  Thanks for your explanations.

-K-
 
Don


= From: Kerry Lynn <kerlyn@ieee.org>
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
Date: Friday, September 13, 2013 10:56 AM

To: Routing Over Low power and Lossy networks <<= a moz-do-not-send=3D"true" href=3D"mailto:roll@ietf.org" target=3D"_blan= k">roll@ietf.org>
Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05

Don, thanks for your additional comments...

On Fri, Sep 13, 2013 at 10:45 AM, Don Sturek <d.sturek@att.net&= gt; wrote:
Hi Kerry,

Two points from below:
1)  "Asking as an implement= er, how do I determine whether an interface is in a Realm-
Local zone?  Is it particul= ar to LLN links?"

       As wi= th other multicast addresses, an interface would register (opt-in) to a realm.  = ; For Trickle Multicast, it would then depend on whether the interface has subscribed to the MPL Domain Address.  The difference between using realm scoped (from Ralph's draft) and administratively scoped (FF04) is the membership in the MPL Domain can be managed automatically by actions within the device.

I'm willing to accept that I may be the only one who's confused.  Let = me illustrate
with an example:

(A)-BR1---BR2-(B)

Let's say we have two LLNs, A and B, connected by BRs and a traditional link
like WiFi or ethernet.  Further, t= here are MPL forwarders deployed in both A
and B.  (I'd imagine that the L= LN interfaces on the BRs are MPL forwarders.)
Are there two separate realm-local zones?  If that is the case then i= t seems
there should be some intrinsic property that allows a router to determine if a
link is in the scope zone or not.&nb= sp; For example, if we were talking about link-
local scope zones and the example about consisted of traditional links and
routers, then the scope boundaries would be defined as cutting through the
routers and would be the same for all link-local multicast protocols.  T= hat is,
there would be no inter-connectivity between a node in A and a node in B that
were subscribed to the same multicast group.

I'm mainly interested in resolving the apparent contradiction between the<= br>
"administratively configured" language in the MPL draft and the "automatically
configured" language in Ralph's draft (and in your comment).


2)  "Do the terms "expected= link-layer latency" and "worst-case link-layer latency"
(used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,
respectively) have commonly defined definitions, e.g. in 802.15.4?  If so,
what are they?  I couldn't= seem to determine this from the 802.15.4 spec."

     The simple= answer to this is there is not a prescribed layer 2 latency value for 802.15.4 other than the defined one hop ACK latency if you use MAC Acknowledges.  J= ust FYI, in testing IEEE 802.15.4-2003/2006 (127 byte PDU) with just 2 devices on a clear channel, we found a typical "one hop/one packet = " message latency to be around 4ms (without security) and around 12 ms (using SW based security).  In my experience, the "expe= cted link layer latency" and "worst case link layer latency" (speaking strictly about the link layer only) are just a single aspect to setting IMIN correctly.   The overall application message pattern plays a larger role for these settings (for example, how frequently multicasts are generated, how many simultaneous multicasts can be generated within a given MPL Domain in a window of time that occurs within IMIN, etc.).  Additionally, another major= driver to these settings are the deployment characteristics of the MPL Domain member devices (for example. how many incoming message buffers are supported in the member devices MAC, how many outgoing message buffers, etc.).  Perhaps the names "expected= link layer latency" and "worst case link layer latency" are a bit misleading since they sound like fixed settings that would be applicable to all links of a given type when I think they are trying to describe the link layer performance with a given messaging profile in operation.

Do you agree that all nodes in a given LLN SHOULD agree on a common
value for Imin?  I don't have any problem with declaring it out of scope for
the present draft, but practically speaking it seems there should be a way to
a) define a reasonable default for a given link layer, and b) distribute a modified
value (I think Yusuke Doi is working on a DHCPv6 option for MPL parameters).

Regards, -K-
 
Don


= From: Kerry Lynn <kerlyn@ie= ee.org>
= Reply-To: Routing Over Low power and Lossy networks <roll@ietf= =2Eorg>
Date: Friday, September 13, 2013 6:58 AM

To: Routing Over Low power and Lossy networks <roll@ie= tf.org>
Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05

Hi Don,

On Fri, Sep 13, 2013 at 9:21 AM, Don Sturek <d.sturek@att.net&g= t; wrote:
=
I don't agree with the proposed technical changes below, specifically:
1)  "- = I have argued that to increase MPL's applicability, PROACTIVE_FORWARDING
  sho= uld be a per-interface and not a per-forwarder setting.  = I can imagine, for
  example, a router that has both LLN and traditional interfaces and proactive
  forwarding seems unnecessary for the latter.  A= s [RFC 4007] states: "Zone
  boundaries cut through nodes, not links."&nbs= p; Suggested wording in section 5.4
=
  cou= ld be "PROACTIVE_FORW= ARDING has a default value of TRUE on links
  whe= re Realm-Local scope is defined, and FALSE otherwise."

   = ; Given how forwarding is defined in the draft, I don't see how the scenario above is possible unless the links on the "traditional interfaces" happen to be members of the same MPL Domain as the LLN

I am looking at section 3, Applicability Statement, which says: "This protocol
may also be used in environments where only a subset of links are considered
Low-Power and Lossy links." = The change I proposed is minimal and would
improve dynamic protocol behavior on non-LLN links.

2)  "- Section 4.1 states: "When used with MPL, Realm-Local scope is administrativel= y
  defined = and used to define the boundaries of multicast message dissemination
  by MPL."  Thi= s begs the question, why don't we just use scope =3D 0x04?  We<= br>
  probably need more discussion on if and how a scope 0x03 zone boundary
  is automatically defined (i.e. without human intervention) and how forwarding
  wor= ks for scope 0x03.  One= suggested definition is that Realm-Local applies
  to links where a single interface may belong to multiple Link-Local scopes."
  &nb= sp;  
   = ;   This argument was made some time ago and rejected.  = ; The purpose in defining and using a realm scoped address is to allow for automatic definition.

I think I'm just confused about the desire for automatic definition of the Realm-Local
scope and the several statements in the draft that it's administratively configured.
Asking as an implementer, how do I determine whether an interface is in a Realm-
Local zone?  I= s it particular to LLN links?

I'm not sure whether the draft is intending to reserve the ability to configure which
= links are in the MPLInterfaceSet.&nb= sp; However it seems that Realm-Local scope, like
other multicast scopes, must have a consistent definition for any and all protocols
that use it.
=
 
The forwarding definition in the Trickle Multicast draft is by MPL Domain so the definition at the end of the paragraph above is not needed.   = When using FF03::FC (defined for forwarding within a MPL Domain) then all members of the MPL Domain are forwarded a copy of the multicast transmission.  Section 7= =2E2 especially makes this clear, by interface, by defining:
= 
   MPLInte=
rfaceSet  - a set of MPL Interfaces that subscribe to the MPL
          Domain Address that identifies the MPL Domain.

3)  - "= The DATA_MESSAGE_IM= IN and CONTROL_MESSAGE= _IMIN parameters
  described in section 5.5 will ultimately have to be expressed in units of time
  (ei= ther in this document or elsewhere) for a given link-layer in order to avoid<= br>   the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2].&nbs= p; The same
  referenc= e states: "a protocol SHOULD set k and Imin such that Imin is at least
  two to t= hree times as long as it takes to transmit k packets."
=

   = ;  Since we are using these parameters as defined in RFC 6206 (Trickle Algorithm) we should not attempt to redefine them here in this draft.

Do the terms "expected link-layer latency" and "worst-case link-layer latency"
(used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMI= N,
respectively) have commonly defined definitions, e.g. in 802.15.4?  = If so,
what are they? = ; I couldn't seem to determine this from the 802.15.4 spec.

Thanks, -K-
 

Don


From: Kerry Lynn <kerlyn@ieee.org>=
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
= Date: Friday, September 13, 2013 5:10 AM To: Routing Over Low power and Lossy networks <roll@ietf.org>
= Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll= -trickle-mcast-05

On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson <= ;mcr+ietf@sandelman.ca> wrote:

A number of issues were raised this past spring by IESG and other reviewers
on draft-ietf-roll= -trickle-mcast.  You can review them using the custom query:
http://trac.tools.ietf.org/wg/roll/trac/query?status=3D= assigned&status=3Dclosed&status=3Dnew&status=3Dreopened&c= omponent=3Dtrickle-mcast&group=3Dcomponent&col=3Did&col=3Dsum= mary&col=3Dcomponent&col=3Dstatus&col=3Dtype&col=3Dpriori= ty&col=3Dmilestone&order=3Dpriority

The chairs, Document Shephard and Document Authors believe that current
issues are closed in the -05 revision at:
    &= nbsp;  https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ A diff is available at:     &= nbsp;  https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-roll-tri= ckle-mcast-04&difftype=3D--html&submit=3DGo%21&url2=3Ddraft-i= etf-roll-trickle-mcast-05

We are starting another WG Last Call.
It will run until Friday 2013-09-13 at 9am EST.

Please read the document.  Do you co= ncur that it is done?
Please post any and all comments.
 
The draft is looking good, but I have a few comments.
 
Editorial:=

- In section 4.3, on Proactive Forwarding, the phrase "MPL Data Message message"
  is redundant and should be "MPL Data Message".<= br>
- In the last paragraph of section 4.3 the phrase "a new MPL Data messages"
  sho= uld be "a new MPL Data Message".<= br>
- [I= -D.droms-6man-multicast-scopes] should be moved from section 14.1 to 14.2.


Technical:=

- I have argued that to increase MPL's applicability, PROACTIVE_FORWARDING
  sho= uld be a per-interface and not a per-forwarder setting.  = I can imagine, for
  example, a router that has both LLN and traditional interfaces and proactive
  forwarding seems unnecessary for the latter.  A= s [RFC 4007] states: "Zone
  boundaries cut through nodes, not links."&nbs= p; Suggested wording in section 5.4
=
  cou= ld be "PROACTIVE_FORW= ARDING has a default value of TRUE on links
  whe= re Realm-Local scope is defined, and FALSE otherwise."
=

- Section 4.1 states: "When used with MPL, Realm-Local scope is administrativel= y
  def= ined and used to define the boundaries of multicast message dissemination
  by MPL."  Thi= s begs the question, why don't we just use scope =3D 0x04?  We<= br>
  probably need more discussion on if and how a scope 0x03 zone boundary
  is automatically defined (i.e. without human intervention) and how forwarding
  wor= ks for scope 0x03.  One= suggested definition is that Realm-Local applies
  to links where a single interface may belong to multiple Link-Local scopes.

- The DATA_MESSAGE_IM= IN and CONTROL_MESSAGE= _IMIN parameters
  described in section 5.5 will ultimately have to be expressed in units of time
  (ei= ther in this document or elsewhere) for a given link-layer in order to avoid<= br>   the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2].&nbs= p; The same
  referenc= e states: "a protocol SHOULD set k and Imin such that Imin is at least
  two to t= hree times as long as it takes to transmit k packets."

Regards, -K-

 
If there is something you do not like, please provide a suggestion (a diff)
about what to fix.

Thank you.

Michael and JP.

--
Michael Richardson <mcr+IETF@sandel= man.ca>, Sandelman Software Works<= br> IETF ROLL WG co-chair.  = ;  http://datatracker.ietf.org/wg/roll/charter/

<= br> _______________________________________________
Roll mailing list
Roll@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/roll


_______________= ________________________________ Roll mailing list Roll@ietf.orghtt= ps://www.ietf.org/mailman/listinfo/roll

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

_______________________________= ________________ Roll mailing list Roll@ietf.o= rghttps://www= =2Eietf.org/mailman/listinfo/roll

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

_______________________________________________
Roll mailing list
R= oll@ietf.org
https://www.ietf.org/mailman/listinfo/r= oll




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

--------------060406000501060806080006-- --------------ms010207040603000704010003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA5MTcwOTI1MzVaMCMGCSqGSIb3DQEJBDEWBBS2wL2gHurK8LImgjoscvrBomuyWTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAAS8jn8EbY1dgOD76MNBEl/jlED/VdvOff67vn9cta/1mnpx HE1EZg+HDyFbm6ePflRiwsXd3QOurrzfmjHp65QzQnrfBIM7wiIIHWwUYUij+pG/YUEjmUN9 FXNliP9M9vTJO3HrxY/HN+YDZWqKWo6mrrRLzsZnn+CyB+hEJqNgQgGX9YORW39VgxwwI0Bd xF3D7qjfC1PwZA6DncQbDZNamcameCkITD5dBRIT9p/k4thmuccu74+QVD9jdtm5pL+n1qOF 3kmsjC0JdLQ7Pui9PCbmf+HS5saLTl9tTC9vkP1tIo2ag949PQc1utto/0lELce40jSR9k6f VYtuNN8AAAAAAAA= --------------ms010207040603000704010003-- From stokcons@xs4all.nl Tue Sep 17 03:21:40 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF7021F8887 for ; Tue, 17 Sep 2013 03:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y6Lm9naJ0-d for ; Tue, 17 Sep 2013 03:21:35 -0700 (PDT) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2236A11E80F3 for ; Tue, 17 Sep 2013 03:21:22 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube11.xs4all.net [194.109.20.209]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id r8HALLpj003779; Tue, 17 Sep 2013 12:21:21 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-83-184.w90-28.abo.wanadoo.fr ([90.28.2.184]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 17 Sep 2013 12:21:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 17 Sep 2013 12:21:20 +0200 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <12193.1379344548@sandelman.ca> References: <12193.1379344548@sandelman.ca> Message-ID: X-Sender: stokcons@xs4all.nl (i2HQyqdPh80JmJHMBCGPqwY/bvUWFyrs) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: roll@ietf.org Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 10:21:41 -0000 Hi Michael, corresponding questions can be: 1) What are the maximum and minimum 1-hop MPL router neighbours of all the MPL routers? 2) what is the arrival rate of new packets that need repetition in a MPL router 3) Is there a deadline associated with the packets 4) What is the shortest number of hops of the longest path between sources and destinations 5) What are the values of the MAC: back-off values, retries, buffer size. 6) What is the background load of other non MPL applications. 7) arrival probability of 1-hop packets 8) other parameters I did not stumble on. The corresponding design space is incredibly large, and probably only a limited subset of the design space is viable. I have gone through only a limited number of possibilities, and analysing the consequences for MPL took me quite a large amount of time. In one of my scenarios: 1) 5 neighbours 2) once every 100 ms (rate at sources is once every 300-500 ms) 3) yes, 200 ms 4) 5 hops, with mostly 1 hop 5) no buffer, retry 1, back-off 2 6) absent 7) 100-80% leading to k=3-5, Imin =30-70 ms, repeat = 2, Imax n/a. It may help that operational boundary conditions together with appropriate MPL parameter values are published in the applicability statements. All applicability statements together may give a good hint which MPL parameters and boundary conditions to choose. My 5 cents, peter Michael Richardson schreef op 2013-09-16 17:15: > peter van der Stok wrote: > >> various settings for IMIN, IMAX and k. A process similar to this > (with > >> knowledge of the topology and messaging profile) is needed for > tuning > >> these values in a real deployment setting. > > peter> After looking for an appropriate setting for Imin, Imax and k, I > peter> slowly learnt that these settings depend on the topology of the > peter> network, the load of the network, the setting of the MAC, and > peter> eventual real-time requirements (e.g. there is a deadline), and > peter> the value of that deadline. The setting of k for example is > peter> related to the number of MPL repeaters that receive a new > message > peter> and start to resend it, possibly interfering with each other and > peter> probably incrementing the c value of the next hop, where the > peter> maximum value of c is related to the Imin value. Sending a > packet > peter> takes as little as 3 ms, but when the MAC stores three packets > and > peter> the they all back-off a maximum number of times, delays of a few > peter> hundred milliseconds to seconds become possible. When there is > peter> buffer space for packets before and in the MAC, the Imin value > can > peter> be chosen as low as 1 ms, the resend of packets is then > completely > peter> determined by the load on the network. > > This is an excellent template discussion... can I put it into the MPL > parameter part of the RPL applicability template? > > Do you think you could rephrase this in the form of questions to be > answered? > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From yusuke.doi@toshiba.co.jp Tue Sep 17 03:58:05 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8718511E83AD for ; Tue, 17 Sep 2013 03:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNJKs2nBT88S for ; Tue, 17 Sep 2013 03:57:59 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 99CC711E83E0 for ; Tue, 17 Sep 2013 03:57:22 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r8HAvGkx016542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Sep 2013 19:57:16 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r8HAvGQH016757 for ; Tue, 17 Sep 2013 19:57:16 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 323 for ; Tue, 17 Sep 2013 19:57:16 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r8HAvGJa016748 for ; Tue, 17 Sep 2013 19:57:16 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r8HAvGtR009908 for roll@ietf.org; Tue, 17 Sep 2013 19:57:16 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id VAA09905; Tue, 17 Sep 2013 19:57:16 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r8HAvGGf012790 for ; Tue, 17 Sep 2013 19:57:16 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id r8HAvFER000128; Tue, 17 Sep 2013 19:57:15 +0900 (JST) Received: from [133.196.16.145] (ncg-dhcp145.isl.rdc.toshiba.co.jp [133.196.16.145]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id A3A6197D6A; Tue, 17 Sep 2013 19:57:15 +0900 (JST) Message-ID: <5238357B.2000800@toshiba.co.jp> Date: Tue, 17 Sep 2013 19:56:59 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: consultancy@vanderstok.org References: <12193.1379344548@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org, peter van der Stok Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 10:58:06 -0000 Hi Peter, Thank you for sharing your scenario and parameters. Could you tell me how did you selected the parameters? I have following two scenarios... and considering how MPL works on the cases. Scenario A (commanding) 1) maybe up to 30 neighbours 2) a few/hour 3) end-to-end 5 seconds, 500ms per hop 4) up to 10 hops 5) not sure 6) many, including multiple threads of Scenario B 7) not sure (80%?) Scenario B (file transfer) 1) maybe up to 30 neighbors 2) 25 packets / hour 3) no deadline per packet 4) up to 10 hops 5) not sure 6) multiple threads of Scenario B and many other traffics 7) not sure (80%?) Regards, Yusuke (2013-09-17 19:21), peter van der Stok wrote: > Hi Michael, > corresponding questions can be: > > 1) What are the maximum and minimum 1-hop MPL router neighbours of all the MPL routers? > 2) what is the arrival rate of new packets that need repetition in a MPL router > 3) Is there a deadline associated with the packets > 4) What is the shortest number of hops of the longest path between sources and destinations > 5) What are the values of the MAC: back-off values, retries, buffer size. > 6) What is the background load of other non MPL applications. > 7) arrival probability of 1-hop packets > 8) other parameters I did not stumble on. > > The corresponding design space is incredibly large, and probably only a limited subset of the design space is viable. > I have gone through only a limited number of possibilities, and analysing the consequences for MPL took me quite a large amount of time. > > In one of my scenarios: > 1) 5 neighbours > 2) once every 100 ms (rate at sources is once every 300-500 ms) > 3) yes, 200 ms > 4) 5 hops, with mostly 1 hop > 5) no buffer, retry 1, back-off 2 > 6) absent > 7) 100-80% > > leading to k=3-5, Imin =30-70 ms, repeat = 2, Imax n/a. > > It may help that operational boundary conditions together with appropriate MPL parameter values are published in the applicability statements. > All applicability statements together may give a good hint which MPL parameters and boundary conditions to choose. > > My 5 cents, > > peter > > > > > > Michael Richardson schreef op 2013-09-16 17:15: >> peter van der Stok wrote: >> >> various settings for IMIN, IMAX and k. A process similar to this (with >> >> knowledge of the topology and messaging profile) is needed for tuning >> >> these values in a real deployment setting. >> >> peter> After looking for an appropriate setting for Imin, Imax and k, I >> peter> slowly learnt that these settings depend on the topology of the >> peter> network, the load of the network, the setting of the MAC, and >> peter> eventual real-time requirements (e.g. there is a deadline), and >> peter> the value of that deadline. The setting of k for example is >> peter> related to the number of MPL repeaters that receive a new message >> peter> and start to resend it, possibly interfering with each other and >> peter> probably incrementing the c value of the next hop, where the >> peter> maximum value of c is related to the Imin value. Sending a packet >> peter> takes as little as 3 ms, but when the MAC stores three packets and >> peter> the they all back-off a maximum number of times, delays of a few >> peter> hundred milliseconds to seconds become possible. When there is >> peter> buffer space for packets before and in the MAC, the Imin value can >> peter> be chosen as low as 1 ms, the resend of packets is then completely >> peter> determined by the load on the network. >> >> This is an excellent template discussion... can I put it into the MPL >> parameter part of the RPL applicability template? >> >> Do you think you could rephrase this in the form of questions to be >> answered? >> >> -- >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Tue Sep 17 05:27:07 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE9511E841A for ; Tue, 17 Sep 2013 05:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBUuZEOMDAIm for ; Tue, 17 Sep 2013 05:27:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 15A0611E8400 for ; Tue, 17 Sep 2013 05:27:01 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 251AB20188 for ; Tue, 17 Sep 2013 09:35:50 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4F70163B18; Tue, 17 Sep 2013 08:26:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2D0CA636C7 for ; Tue, 17 Sep 2013 08:26:54 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <5238200F.1030109@gridmerge.com> References: <5238200F.1030109@gridmerge.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:27:08 -0000 --=-=-= Robert Cragie wrote: > On (2): > I agree that all nodes in a MPL Domain MUST agree on a common value. I > don't think any recommended values should be given and it depends on > the applicability. What is the affect on the network if there is a mis-configuration? Can it be detected? Does the network melt-down? Or is it just a question of multicast not working very well (not reaching all nodes it should) I think that these questions will get asked by reviewers. > In a nutshell - I think draft-ietf-roll-trickle-mcast-05 is good to go. Thanks. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUjhKjYqHRg3pndX9AQKcnAP+PzylOSkW0MgSqEDd6kaBuKIEv3+b6yT5 AxsNytFmebTJwfNWQigY4KE0aLDQc54kMeGbwxRjy9dNIP3C8XuqQ9GcOnNAaIfH /cNDvH3SqUgeJJZ5Py8F+WskmqrfY/WqS7mk8uD7Twlsb7MRVRDkpFG40LyBVDVm RoQeGYsDI64= =vxtg -----END PGP SIGNATURE----- --=-=-=-- From internet-drafts@ietf.org Tue Sep 17 05:56:21 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E52E11E8437; Tue, 17 Sep 2013 05:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc-610nq1twg; Tue, 17 Sep 2013 05:56:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A192711E843E; Tue, 17 Sep 2013 05:56:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917125614.2212.62046.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 05:56:14 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-template-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:56:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : ROLL Applicability Statement Template Author(s) : Michael C. Richardson Filename : draft-ietf-roll-applicability-template-03.txt Pages : 8 Date : 2013-09-17 Abstract: This document is a template applicability statement for the Routing over Low-power and Lossy Networks (ROLL) WG. This document is not for publication, but rather is to be used as a template. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-applicability-template-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-applicability-template-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mcr@sandelman.ca Tue Sep 17 05:58:41 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851A011E811D for ; Tue, 17 Sep 2013 05:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkSUsNHknAYx for ; Tue, 17 Sep 2013 05:58:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 869BE11E8440 for ; Tue, 17 Sep 2013 05:58:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 56EB920188; Tue, 17 Sep 2013 10:07:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8AF0B63B18; Tue, 17 Sep 2013 08:58:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 79733636C7; Tue, 17 Sep 2013 08:58:12 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org In-Reply-To: References: <12193.1379344548@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:58:41 -0000 --=-=-= Peter, added your questions to: http://www.ietf.org/rfcdiff?url1=draft-ietf-roll-applicability-template-02&difftype=--html&submit=Go%21&url2=draft-ietf-roll-applicability-template-03 -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUjhR5IqHRg3pndX9AQIA6wP/UAsiRWeFcibg+T2zKqAC/sDMFJlbjw33 MtxNwRiFWDEGoLRmEfB1aB53NAoueCzIDaom9NK2D03Dr9QpT17O0J7LN7JGW+25 JRh+yFBIJAdOSbcU2NU2GmAWbfS9T/C5MZ67aYTnIyi6yMfcOl5IqjxLdi04qI1z 98/vpig9rjw= =g+k8 -----END PGP SIGNATURE----- --=-=-=-- From stokcons@xs4all.nl Tue Sep 17 06:37:52 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A6011E8221 for ; Tue, 17 Sep 2013 06:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZJYiqHoARQL for ; Tue, 17 Sep 2013 06:37:45 -0700 (PDT) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9C09411E81EB for ; Tue, 17 Sep 2013 06:37:44 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube11.xs4all.net [194.109.20.209]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id r8HDbgcm086487 for ; Tue, 17 Sep 2013 15:37:43 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-83-184.w90-28.abo.wanadoo.fr ([90.28.2.184]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 17 Sep 2013 15:37:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 17 Sep 2013 15:37:42 +0200 From: peter van der Stok To: roll@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <8322.1379420813@sandelman.ca> References: <5238200F.1030109@gridmerge.com> <8322.1379420813@sandelman.ca> Message-ID: <02043f5eab84dd1d3c8539ff90799d9f@xs4all.nl> X-Sender: stokcons@xs4all.nl (P0ubFx6rII9OIhUPx74YDjWqz6LsGGgs) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 13:37:52 -0000 Hi Michael, Some consequences: 1) Too many repeaters with too small Imin and too large repeat leads to network congestion (similar to having too high send frequency on several sources) 2) packets take too long to arrive at all destinations (assuming there is a deadline) 3) packets do not arrive at some destinations This is comparable with what happens when too many nodes start sending unicasts on the mesh. For me the MPL draft is also OK. Peter Michael Richardson schreef op 2013-09-17 14:26: > Robert Cragie wrote: > > On (2): > > > I agree that all nodes in a MPL Domain MUST agree on a common value. I > > don't think any recommended values should be given and it depends on > > the applicability. > > What is the affect on the network if there is a mis-configuration? > > Can it be detected? Does the network melt-down? > > Or is it just a question of multicast not working very well (not > reaching all > nodes it should) > I think that these questions will get asked by reviewers. > > > In a nutshell - I think draft-ietf-roll-trickle-mcast-05 is good to go. > > Thanks. > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Tue Sep 17 08:04:18 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1897221F9FA4 for ; Tue, 17 Sep 2013 08:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtLwrIOsPoBE for ; Tue, 17 Sep 2013 08:04:17 -0700 (PDT) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7B85811E8473 for ; Tue, 17 Sep 2013 08:03:00 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id a11so3802235qen.9 for ; Tue, 17 Sep 2013 08:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=nzl4HeYoA9YrfMHJN7TVXwPq3KSMYAsdxIS+ri0Gql4=; b=E3TuOY2vZoDyWV45f0xl00jyegouISwK+tvsNh9p1M1ePF9l1udcJY7wct/RV58kIS icGZVuyS24LrO1oc8Et7ZyijAqXKuhDvfxCb3k0zz+ENh5q3aZVjyx1QB5+lEoXrF1uJ nRb6vb5Ig3D78xV3NRoDt41uvVDbQ5hx4xrICQwcAyGdpsCbeT1EISq1mxq/Mvc7PBU9 AKuxg9mzS4OprAL8haDzELat2zzxlXLWcB2IQWhrtwDrFcyD3TovJKrytg7RiiATgGJs M6pwA4YBfAhYAYm/hLoVo8JTJRwHxBKQuApxaNC8Ic3b/6njQN+cVHLq0CItan69HB5s Rk9A== X-Received: by 10.224.125.2 with SMTP id w2mr7320090qar.46.1379430178730; Tue, 17 Sep 2013 08:02:58 -0700 (PDT) Received: from ?IPv6:2001:420:2c52:1316:24c2:84f3:41c7:2c5b? ([2001:420:2c52:1316:24c2:84f3:41c7:2c5b]) by mx.google.com with ESMTPSA id u8sm56255775qef.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 08:02:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: Date: Tue, 17 Sep 2013 11:02:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3072B0E1-55AE-4DF7-8061-0B2A28961801@gmail.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1508) Subject: Re: [Roll] comments for draft-gnawali-roll-rpl-recommendations? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 15:04:18 -0000 On Sep 15, 2013, at 12:34 PM 9/15/13, Omprakash Gnawali = wrote: > The recommendations are based on testbed experiments with TelosB motes > and unless otherwise noted, focused on non-storing mode. The > recommendations come from some published work and some unpublished > work I shared with this WG 2-3 yrs ago. OK. It would likely be helpful to cite some of those sources. BTW, the reference for I-D.ietf-roll-routing-metrics seems broken: [I-D.ietf-roll-routing-metrics] Vasseur, J. and D. Networks, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", =20 Citing RFC 2119 is probably unnecessary. In section 4, should the rate of dynamic changes in the network topology = be considered in setting the maximum trickle interval? In section 5, should the density of the mesh - some metric of the number = of neighbors for each node (average, median, minimum, maximum) - be = considered in setting the redundancy constant? Do the recommendations in section 9 apply only to UDP-based = uni-directional sensor data collection? SEP 2.0 uses HTTP to the sensor = nodes to collect data and control the operation of the nodes. Would = that scenario do better with a preference for route stability? - Ralph > Recommendation #10 is based on > numbers reported and survey of code. >=20 > There have been a lot of RPL deployments, would be great to collect > the experiences from them. >=20 > - om_p >=20 > On Fri, Sep 13, 2013 at 1:06 PM, Ralph Droms = wrote: >> Interesting and useful doc. >>=20 >> Unless explicitly noted, do the recommendations apply to both storing = and non-storing modes? >>=20 >> Are your recommendations based on deployments, simulations, protocol = analysis? Do you have any references you can cite that provide the = input for your recommendations? >>=20 >> - Ralph >>=20 >> On Sep 13, 2013, at 2:14 AM 9/13/13, Omprakash Gnawali = wrote: >>=20 >>> Dear ROLL WG, >>>=20 >>> I plan to update the draft-gnawali-roll-rpl-recommendations in the >>> next day or two. I would love to hear about any = new/old/usual/unusual >>> experiences about RPL use so that I can collect those insights in = this >>> draft to benefit everyone in the community. >>>=20 >>> Here is the URL to the current draft: >>> http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-03 >>>=20 >>> Thank you. >>>=20 >>> - om_p >>> _______________________________________________ >>> 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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From robert.cragie@gridmerge.com Tue Sep 17 08:04:33 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA0E11E8297 for ; Tue, 17 Sep 2013 08:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeU21nAbtlmX for ; Tue, 17 Sep 2013 08:04:28 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id BDCED11E8283 for ; Tue, 17 Sep 2013 08:03:37 -0700 (PDT) Received: from [94.116.126.107] (helo=[10.38.241.149]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1VLwoJ-0003IG-AY; Tue, 17 Sep 2013 16:03:27 +0100 Message-ID: <52386F41.8090402@gridmerge.com> Date: Tue, 17 Sep 2013 16:03:29 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: consultancy@vanderstok.org References: <5238200F.1030109@gridmerge.com> <8322.1379420813@sandelman.ca> <02043f5eab84dd1d3c8539ff90799d9f@xs4all.nl> In-Reply-To: <02043f5eab84dd1d3c8539ff90799d9f@xs4all.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070405030005060606050607" X-Authenticated-As: robert.cragie@gridmerge.com Cc: roll@ietf.org, peter van der Stok Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 15:04:33 -0000 This is a cryptographically signed message in MIME format. --------------ms070405030005060606050607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1 Robert On 17/09/2013 14:37, peter van der Stok wrote: > Hi Michael, > > > Some consequences: > 1) Too many repeaters with too small Imin and too large repeat leads=20 > to network congestion (similar to having too high send frequency on=20 > several sources) > 2) packets take too long to arrive at all destinations (assuming there = > is a deadline) > 3) packets do not arrive at some destinations > > This is comparable with what happens when too many nodes start sending = > unicasts on the mesh. > > For me the MPL draft is also OK. > > > Peter > > > Michael Richardson schreef op 2013-09-17 14:26: >> Robert Cragie wrote: >> > On (2): >> >> > I agree that all nodes in a MPL Domain MUST agree on a common value.= I >> > don't think any recommended values should be given and it depends on= >> > the applicability. >> >> What is the affect on the network if there is a mis-configuration? >> >> Can it be detected? Does the network melt-down? >> >> Or is it just a question of multicast not working very well (not=20 >> reaching all >> nodes it should) >> I think that these questions will get asked by reviewers. >> >> > In a nutshell - I think draft-ietf-roll-trickle-mcast-05 is good to = >> go. >> >> Thanks. >> >> --=20 >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >> >> >> _______________________________________________ >> 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 > --------------ms070405030005060606050607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA5MTcxNTAzMjlaMCMGCSqGSIb3DQEJBDEWBBQSxatzf1SQfhTXzIoTbti9yJ7kWzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBADE2vlDXRcpnMJNt4d1TUQjYwBO3ZMesa97UKiWK2y0Fei9s X7rE4uoDWfNe3togzZxzXTjsAV9ktUYQZCyRPi6s7uQvj3VJLKC3TpTm/kR35nredpW79ozD dz7/6Mm/fUjKhOUZqCwmxmMOWPIVYSEC3XI3gP1PyxniRaqzzydSAWOpUGCik3xFxS8MSAZq ClVashqJD5ynRJe3HiwMUt0XA03YY7dOCr8/OsyS3wvHB3zLsafqIh3wA+uqgSJpm/P/s68F ormYWhZoSlgsxixnVYusN5KjX0cz7sWEZe+DgsKHlO9isGSBWnPvxdPff0hfHi6vzJfgBwD7 5ahQ1QoAAAAAAAA= --------------ms070405030005060606050607-- From mcr@sandelman.ca Tue Sep 17 08:44:23 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8742311E8297 for ; Tue, 17 Sep 2013 08:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPGZQCPvxkjC for ; Tue, 17 Sep 2013 08:44:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 557BA11E8114 for ; Tue, 17 Sep 2013 08:44:18 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 438F320189; Tue, 17 Sep 2013 12:53:07 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 17D9763B18; Tue, 17 Sep 2013 11:44:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 074F1636C7; Tue, 17 Sep 2013 11:44:11 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <031DD135F9160444ABBE3B0C36CED618D09C6C@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618D09393@011-DB3MPN2-083.MGDPHG.emi.philips.com> <519.1378385356@sandelman.ca> <031DD135F9160444ABBE3B0C36CED618D09637@011-DB3MPN2-083.MGDPHG.emi.philips.com> <5228AF9B.30805@gridmerge.com> <03B78081B371D44390ED6E7BADBB4A772379CCFC@xmb-rcd-x02.cisco.com> <031DD135F9160444ABBE3B0C36CED618D09C6C@011-DB3MPN2-083.MGDPHG.emi.philips.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: [Roll] pushing applicability statements forward X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 15:44:23 -0000 --=-=-= Dijk, Esko wrote: > That's ok for me - MPL and P2P-RPL are currently targeted to be in the > ROLL applicability statements. (See Michael's statement > http://www.ietf.org/mail-archive/web/roll/current/msg07816.html ; and > practical use example in > http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-01#section-4.3.3 > ) > The template could still be updated to reflect MPL and P2P-RPL; however > the main action is to include a hop limit consideration into > draft-ietf-roll-applicability-home-building, right? The template is updated with some questions. Getting something concrete into home-building is the goal. Would it be useful to go through the applicability statements in Vancouver, addressing how well each document deals with the questions? We would do this section/question by question, across all the documents at the same time. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUjh4yoqHRg3pndX9AQLV/QQA6gftBwyUC0V01r/x2nkx1+ye8p22OlCO mIgDzSkDX+pZtMduq2LvSyBzP/Go7z5wz8pAQAA2VcSzTZuWYpM4ZTRDig0/avj9 sfWt+cy0fGbivo15f9fiQocwlyFA/mjTFdyj5ssn4+WpnbzPeV6095vPqM3pDpDB MwNUDOh8kPE= =qH+h -----END PGP SIGNATURE----- --=-=-=-- From stokcons@xs4all.nl Wed Sep 18 02:24:49 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8912811E8223 for ; Wed, 18 Sep 2013 02:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.776 X-Spam-Level: X-Spam-Status: No, score=0.776 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 967zLSjYepha for ; Wed, 18 Sep 2013 02:24:44 -0700 (PDT) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id B4CC711E81CF for ; Wed, 18 Sep 2013 02:24:05 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube12.xs4all.net [194.109.20.211]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id r8I9Nuv3016275; Wed, 18 Sep 2013 11:23:58 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-83-184.w90-28.abo.wanadoo.fr ([90.28.2.184]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 18 Sep 2013 11:23:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 18 Sep 2013 11:23:56 +0200 From: peter van der Stok To: Yusuke DOI Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <5238357B.2000800@toshiba.co.jp> References: <12193.1379344548@sandelman.ca> <5238357B.2000800@toshiba.co.jp> Message-ID: X-Sender: stokcons@xs4all.nl (QyRp5Utn1F+bLHNdDSa/D8OMisPS3lEJ) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: roll@ietf.org Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 09:24:49 -0000 Hi Yusuke, thanks for your interest. I got the parameter values by doing an on-paper analysis of the propagation patterns and the synchrony between the copies sent by multiple repeaters In combination with many simulations, I finally understood what went on and came up with a motivated set of parameter values. The use cases themselves were motivated by run of the mill lighting office installations. For other use cases this process will be faster though. For your case it would take some simulation try-outs (few days) to get it right. The 30 neighbours makes me think that you need a k value of 10 or higher, dependent how the propagation proceeds to the borders of the network. 25 packets /hour remove too many worries about interference. Probably a max repeat of 2 will be sufficient. I usually make the source a repeater as well to make sure that one packet arrives at least at one destination. Probably a short Imin value like 30-70 ms will do for you as well; and then you will certainly meet the deadlines. When you have bursts of packets at a repeater, say 10 within 50 ms, interference becomes important, and the behaviour of the MAC comes into play, retarding the packets and threatening the meeting of the deadline. But again, It would take a more thorough analysis to come up with numbers which can be taken seriously. Greetings, Peter Yusuke DOI schreef op 2013-09-17 12:56: > Hi Peter, > > Thank you for sharing your scenario and parameters. Could you tell me > how did you selected the parameters? > I have following two scenarios... and considering how MPL works on the > cases. > > Scenario A (commanding) > 1) maybe up to 30 neighbours > 2) a few/hour > 3) end-to-end 5 seconds, 500ms per hop > 4) up to 10 hops > 5) not sure > 6) many, including multiple threads of Scenario B > 7) not sure (80%?) > > Scenario B (file transfer) > 1) maybe up to 30 neighbors > 2) 25 packets / hour > 3) no deadline per packet > 4) up to 10 hops > 5) not sure > 6) multiple threads of Scenario B and many other traffics > 7) not sure (80%?) > > Regards, > > Yusuke > > > (2013-09-17 19:21), peter van der Stok wrote: > Hi Michael, > corresponding questions can be: > > 1) What are the maximum and minimum 1-hop MPL router neighbours of all > the MPL routers? > 2) what is the arrival rate of new packets that need repetition in a > MPL router > 3) Is there a deadline associated with the packets > 4) What is the shortest number of hops of the longest path between > sources and destinations > 5) What are the values of the MAC: back-off values, retries, buffer > size. > 6) What is the background load of other non MPL applications. > 7) arrival probability of 1-hop packets > 8) other parameters I did not stumble on. > > The corresponding design space is incredibly large, and probably only a > limited subset of the design space is viable. > I have gone through only a limited number of possibilities, and > analysing the consequences for MPL took me quite a large amount of > time. > > In one of my scenarios: > 1) 5 neighbours > 2) once every 100 ms (rate at sources is once every 300-500 ms) > 3) yes, 200 ms > 4) 5 hops, with mostly 1 hop > 5) no buffer, retry 1, back-off 2 > 6) absent > 7) 100-80% > > leading to k=3-5, Imin =30-70 ms, repeat = 2, Imax n/a. > > It may help that operational boundary conditions together with > appropriate MPL parameter values are published in the applicability > statements. > All applicability statements together may give a good hint which MPL > parameters and boundary conditions to choose. > > My 5 cents, > > peter > > > > > > Michael Richardson schreef op 2013-09-16 17:15: > peter van der Stok wrote: > >> various settings for IMIN, IMAX and k. A process similar to this (with > >> knowledge of the topology and messaging profile) is needed for tuning > >> these values in a real deployment setting. > > peter> After looking for an appropriate setting for Imin, Imax and k, I > peter> slowly learnt that these settings depend on the topology of the > peter> network, the load of the network, the setting of the MAC, and > peter> eventual real-time requirements (e.g. there is a deadline), and > peter> the value of that deadline. The setting of k for example is > peter> related to the number of MPL repeaters that receive a new > message > peter> and start to resend it, possibly interfering with each other and > peter> probably incrementing the c value of the next hop, where the > peter> maximum value of c is related to the Imin value. Sending a > packet > peter> takes as little as 3 ms, but when the MAC stores three packets > and > peter> the they all back-off a maximum number of times, delays of a few > peter> hundred milliseconds to seconds become possible. When there is > peter> buffer space for packets before and in the MAC, the Imin value > can > peter> be chosen as low as 1 ms, the resend of packets is then > completely > peter> determined by the load on the network. > > This is an excellent template discussion... can I put it into the MPL > parameter part of the RPL applicability template? > > Do you think you could rephrase this in the form of questions to be > answered? > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Wed Sep 18 11:44:23 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AA311E810B for ; Wed, 18 Sep 2013 11:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOYGOtaEzi4e for ; Wed, 18 Sep 2013 11:44:22 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C4F7311E8108 for ; Wed, 18 Sep 2013 11:44:21 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id m20so4870125qcx.29 for ; Wed, 18 Sep 2013 11:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=/GRQs2KpcfsiQvO+xFDc6KBiiueEQUqI1Qjde1SGs8k=; b=rJohbPff1vJQU2a9mdEetmg2SJWw9PEfR3ZJp1Kwl4Tyghmd6DUO6ndVbBh6JliIvt SbjE17a6bBiEKU0wHQfTuthUUJVfrH1X3VXYkFv8sfiALk1/il8f5eEWEAvr/ifU96SZ /BKYZ99UpzXk61NCK9hqq4c0BdzGgm0suTub1fqFO4OP9Pxfp8eBg/rY/0Aj3yVcbOi9 spUEw0HHVtBSMaH2zNXycRpf1/qyPqtyeTYGiSfA3rW1Ki3YMW8Ssmt8+2FnGh22wxYG oh9smJ+GtRbiwUBfXa/qJbyUyPv33CnBbOfVqOrU83LxbIP2wp2na8kYAfPgmeuxYlKG 4DJA== X-Received: by 10.49.94.172 with SMTP id dd12mr32373126qeb.4.1379529861186; Wed, 18 Sep 2013 11:44:21 -0700 (PDT) Received: from ?IPv6:2001:420:2c52:1316:24c2:84f3:41c7:2c5b? ([2001:420:2c52:1316:24c2:84f3:41c7:2c5b]) by mx.google.com with ESMTPSA id u4sm7242553qat.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 11:44:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <27577.1379098384@sandelman.ca> Date: Wed, 18 Sep 2013 14:44:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.77025347de98150b9e23fbe62aa3ea80@trac.tools.ietf.org> <27577.1379098384@sandelman.ca> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1508) Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 18:44:23 -0000 I realize I'm joining the conversation late. I reviewed the document to = see that "scop 3" was added, but I didn't read closely enough to notice = that draft-ietf-roll-trickle-mcast-05 and = draft-ietf-6man-multicast-scopes-00 are actually now in conflict with = each other. I'll explain why I think they are in conflict and then suggest how to = fix the issue. =46rom draft-ietf-roll-trickle-mcast-05: When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. =46rom draft-ietf-6man-multicast-scopes-00: Realm-Local scope is the largest scope that is automatically configured, i.e., automatically derived from physical connectivity or other, non-multicast-related configuration. Specifically, "administratively defined" seems to me to be in direct = conflict with "automatically configured". I suggest fixing the problem with two updates. First, the definition of = "scop 3" in an IP-over-IEEE802.15.4 needs to be published, based on this = text from draft-ietf-6man-multicast-scopes-00: The definition of any Realm-Local scope for a particular network technology should be published in an RFC. I suggest: When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to = include all interfaces participating in the IEEE802.15.4 multi-link subnet. This text could be added to draft-ietf-roll-trickle-mcast-05, or to = draft-ietf-6man-multicast-scopes-00 or published separately in yet = another "world's shortest RFC". Second, draft-ietf-roll-trickle-mcast-05 should be changed to read: When used with MPL, Realm-local scope is defined according to the underlying network technology; for example, [cite the = IP-over-IEEE802.15.4 definition]. As a further refinement, I suggest text be added to = draft-ietf-roll-trickle-mcast-05 to the effect of: "scop 4" can also be used with MPL to cover deployments that use administratively defined scopes that cover, for example, subnets based on different underlying network technologies. - Ralph On Sep 13, 2013, at 2:53 PM 9/13/13, Michael Richardson = wrote: >=20 > Kerry Lynn wrote: >> Actually, that was my comment. >=20 > Oh, sorry for he confusion. >=20 >> It seems to me that the MPL draft and >> draft-droms-6man-multicast-scopes-02 may be inconsistent in whether >> Realm-Local scopes are administratively or automatically defined. >=20 > I believe that droms-6man-multicast-scopes-02 is supposed to say that > scope-3 is to be defined automatically by a process to be described by = a user > of it. >=20 > And so trickle-mcast ought to define how to automatically define it. >=20 > I think that it ought to be defined to be the boundary of the DAG > that contains the same (/64) prefix. >=20 > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From kerlyn2001@gmail.com Thu Sep 19 06:07:53 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D3D21F93B1 for ; Thu, 19 Sep 2013 06:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfd5yMRGnTmb for ; Thu, 19 Sep 2013 06:07:53 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB8C21F9385 for ; Thu, 19 Sep 2013 06:07:50 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id wp18so9340269obc.8 for ; Thu, 19 Sep 2013 06:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=KnOlrAwC5irgPqKuyDSNDYLEIDn+c41Xfiw8KiFmf7U=; b=A87hWKC3b0bU4Ew+t/caXnXZaAkPQ72u99m/9epsuHuDO4qdn5fTnaGcqJxabFPVmO x2p5qXP0kUpWKlMV1JWEXw/poNJjHcADw+r0aG2sS3GAe157RkQRZbPqgMZlyGWEHeMz 0k2SfsseSfnodwqlOC8bQ+0P03cFsL11ZOkZ+hV64Q/yZ4Ti6CNzrG7qHsavmJpvcdAO 9lyk1NhwVvOapdiDQcQ3cA/xijGU6ZpbPXzZY5nFOjUphlmqp6knDHxDWQSNMd5jpBTm kYiQRZyqfIcK9vibSkK7tqZ95eOC0gv6CBinfU95Qy6QQ5tiagUUWVGtdWx1RagfuZsE oOpA== MIME-Version: 1.0 X-Received: by 10.182.241.33 with SMTP id wf1mr16634obc.59.1379596069323; Thu, 19 Sep 2013 06:07:49 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.41.36 with HTTP; Thu, 19 Sep 2013 06:07:49 -0700 (PDT) In-Reply-To: <02043f5eab84dd1d3c8539ff90799d9f@xs4all.nl> References: <5238200F.1030109@gridmerge.com> <8322.1379420813@sandelman.ca> <02043f5eab84dd1d3c8539ff90799d9f@xs4all.nl> Date: Thu, 19 Sep 2013 09:07:49 -0400 X-Google-Sender-Auth: sv85_-UaIl3DV3WPJ_ahGxt0GKc Message-ID: From: Kerry Lynn To: "consultancy@vanderstok.org" , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c2fc20a5945f04e6bc3da3 Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 13:07:53 -0000 --001a11c2fc20a5945f04e6bc3da3 Content-Type: text/plain; charset=ISO-8859-1 Hi Peter, On Tue, Sep 17, 2013 at 9:37 AM, peter van der Stok wrote: > Hi Michael, > > > Some consequences: > 1) Too many repeaters with too small Imin and too large repeat leads to > network congestion (similar to having too high send frequency on several > sources) > The Trickle Algorithm [RFC 6206] calls for exponential growth of Imax for some number of intervals in order to spread the offered load over time. Thus the claim that it can "scale to thousand-fold variations in network density". It is actually the combination of large load, large k, and small *Imax* that may contribute to congestion collapse. When Imax is limited to Imin then your statement is true. [RFC 6206] suggests Imin should be at least 2-3 times the period it takes to transmit k packets (and probably double that). Knowing k, bit rate, and message size (which seemed to be missing from your list of variables) it should be possible to determine a reasonable value for Imin. For example, an average mDNS lookup may fit in 127 octets but the worst-case may be twice that. 2) packets take too long to arrive at all destinations (assuming there is a > deadline) > This is probably not a "typical" case. It may involve trained installers to achieve this goal for large LLNs. > 3) packets do not arrive at some destinations > > This is mitigated by larger k. > This is comparable with what happens when too many nodes start sending > unicasts on the mesh. > > For me the MPL draft is also OK. > > My original comment regarding default Imin values was that they were defined in terms of "worst-case latency" for a given data link and I still think this is vague (perhaps purposely so). I think the present draft would be improved by adding a definition to section 2: Worst Case Latency - The period of time for the largest possible MPL Data Message to be received by any MPL Forwarder in the MPL Domain. Regards, -K- > > Peter > > > Michael Richardson schreef op 2013-09-17 14:26: > >> Robert Cragie wrote: >> > On (2): >> >> > I agree that all nodes in a MPL Domain MUST agree on a common value. I >> > don't think any recommended values should be given and it depends on >> > the applicability. >> >> What is the affect on the network if there is a mis-configuration? >> >> Can it be detected? Does the network melt-down? >> >> Or is it just a question of multicast not working very well (not reaching >> all >> nodes it should) >> I think that these questions will get asked by reviewers. >> >> > In a nutshell - I think draft-ietf-roll-trickle-mcast-**05 is good to >> go. >> >> Thanks. >> >> -- >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/**wg/roll/charter/ >> >> >> ______________________________**_________________ >> 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 > --001a11c2fc20a5945f04e6bc3da3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Peter,

On Tue, Sep 17, 2013 at 9:37 AM, peter va= n der Stok <stokcons@xs4all.nl> wrote:
Hi Michael,


Some consequences:
1) Too many repeaters with too small Imin and too large repeat leads to net= work congestion (similar to having too high send frequency on several sourc= es)

The Trickle Algorithm [RFC 6206] ca= lls for exponential growth of Imax for some number
of intervals in order to spread the offered load over time.=A0 T= hus the claim that it can "scale
to thousand-fold variat= ions in network density".

It is actually the combina= tion of large load, large k, and small *Imax* that may contribute to
congestion collapse.=A0 When Imax is limited to Imin then your statement is= true.=A0 [RFC 6206]
suggests Imin should be at least 2-3 times the peri= od it takes to transmit k packets (and
probably double that).=A0 Knowing= k, bit rate, and message size (which seemed to be missing
from your list of variables) it should be possible to determine a reasonabl= e value for Imin.
For example, an average mDNS lookup may fit in 127 oct= ets but the worst-case may be
twice that.

2) packets take too long to arrive at all destinations (assuming there is a= deadline)

This is probably not a "= ;typical" case.=A0 It may involve trained installers to achieve this g= oal
for large LLNs.
=A0
3) packets do not arrive at some destinations

This is mitigated by larger k.
=A0
This is comparable with what happens when too many nodes start sending unic= asts on the mesh.

For me the MPL draft is also OK.

My original comment regarding default Imin values was= that they were defined in terms
of "worst-case latency&= quot; for a given data link and I still think this is vague (perhaps
purposely so).=A0 I think the present draft would be improved by adding a d= efinition to
section 2:

Worst Case Latency - The perio= d of time for the largest possible MPL Data Message to
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 be received by any MPL = Forwarder in the MPL Domain.

Regards, -K-

Peter


Michael Richardson schreef op 2013-09-17 14:26:
Robert Cragie <robert.cragie@gridmerge.com> wrote:
> On (2):

> I agree that all nodes in a MPL Domain MUST agree on a common value. I=
> don't think any recommended values should be given and it depends = on
> the applicability.

What is the affect on the network if there is a mis-configuration?

Can it be detected? =A0Does the network melt-down?

Or is it just a question of multicast not working very well (not reaching a= ll
nodes it should)
I think that these questions will get asked by reviewers.

> In a nutshell - I think draft-ietf-roll-trickle-mcast-05 is goo= d to go.

Thanks.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair. =A0 =A0http://datatracker.ietf.org/wg/roll/ch= arter/


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

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

--001a11c2fc20a5945f04e6bc3da3-- From stokcons@xs4all.nl Thu Sep 19 07:34:39 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B2621F970E for ; Thu, 19 Sep 2013 07:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.156 X-Spam-Level: X-Spam-Status: No, score=0.156 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQI-VtCwyouF for ; Thu, 19 Sep 2013 07:34:34 -0700 (PDT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3F121F979E for ; Thu, 19 Sep 2013 07:34:33 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube12.xs4all.net [194.109.20.211]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id r8JEYP5Q092030; Thu, 19 Sep 2013 16:34:26 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-83-184.w90-28.abo.wanadoo.fr ([90.28.2.184]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 19 Sep 2013 16:34:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 19 Sep 2013 16:34:25 +0200 From: peter van der Stok To: Kerry Lynn Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <5238200F.1030109@gridmerge.com> <8322.1379420813@sandelman.ca> <02043f5eab84dd1d3c8539ff90799d9f@xs4all.nl> Message-ID: <11f21baf069808acb984eb38c338c69a@xs4all.nl> X-Sender: stokcons@xs4all.nl (JK+B0x85TDltqozEe3xQAWJoZnNHuKf+) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 14:34:39 -0000 Hi Kerry, some inline comments on your comments. The questions was: what might go wrong when MPL values are badly chosen. I tried to describe some most likely causes and effects. No attempt at completeness was intended. Kerry Lynn schreef op 2013-09-19 15:07: > Hi Peter, > > On Tue, Sep 17, 2013 at 9:37 AM, peter van der Stok > wrote: > > Hi Michael, > > Some consequences: > 1) Too many repeaters with too small Imin and too large repeat leads to > network congestion (similar to having too high send frequency on > several sources) > > The Trickle Algorithm [RFC 6206] calls for exponential growth of Imax > for some number of intervals in order to spread the offered load over > time.  Thus the > claim that it can "scale to thousand-fold variations in network > density". > > It is actually the combination of large load, large k, and small > *Imax* that may contribute to > congestion collapse.  When Imax is limited to Imin then your statement > is true.  I think a small Imin is sufficient in combination with many sources, repeaters and large repeat Stating Imax =Imin certainly helps. I was referring to an Imin=1 ms. [RFC 6206] suggests Imin should be at least 2-3 times the period it takes to > transmit k packets (and > probably double that).  Knowing k, bit rate, and message size (which > seemed to be missing > from your list of variables) it should be possible to determine a > reasonable value for Imin. > For example, an average mDNS lookup may fit in 127 octets but the > worst-case may be > twice that. > > 2) packets take too long to arrive at all destinations (assuming there > is a deadline) > > This is probably not a "typical" case.  It may involve trained > installers to achieve this goal For me it is typical. My deadlines are 200 ms. I also think that conditions on the installation (density of repeaters, bounded network load, source and destination separated by bounded number of hops) will go a long way to make deadlines meet. > > for large LLNs. > >   > > 3) packets do not arrive at some destinations > > This is mitigated by larger k. So choice of k is important >   > > This is comparable with what happens when too many nodes start sending > unicasts on the mesh. > > For me the MPL draft is also OK. > > My original comment regarding default Imin values was that they were > defined in terms > > of "worst-case latency" for a given data link and I still think this > is vague (perhaps > purposely so).  I think the present draft would be improved by adding > a definition to > section 2: > > Worst Case Latency - The period of time for the largest possible MPL > Data Message to > >                     be received by any MPL Forwarder in the MPL Domain. As stated earlier. I don't like the worst case latency. With a heavily loaded network, MAC buffers > 3, Backoff retries >2, worst case latencies can reach hundreds of msec and even seconds. The transmission time of the packet 3-6 ms can be neglected under those circumstances. Concluding, WCL should certainly not be used to set Imin. However the I-D talks default values and the wording is OK for me. > > Regards, -K- > Greetings Peter > Peter > > Michael Richardson schreef op 2013-09-17 14:26: > > Robert Cragie wrote: > On (2): > > I agree that all nodes in a MPL Domain MUST agree on a common value. I > don't think any recommended values should be given and it depends on > the applicability. > > What is the affect on the network if there is a mis-configuration? > > Can it be detected?  Does the network melt-down? > > Or is it just a question of multicast not working very well (not > reaching all > nodes it should) > I think that these questions will get asked by reviewers. > > In a nutshell - I think draft-ietf-roll-trickle-mcast-05 is good to go. > > Thanks. > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/ > [1] > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll [2] > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll [2] > > > > Links: > ------ > [1] http://datatracker.ietf.org/wg/roll/charter/ > [2] https://www.ietf.org/mailman/listinfo/roll From trac+roll@trac.tools.ietf.org Fri Sep 20 07:32:38 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A4C21F9AE3 for ; Fri, 20 Sep 2013 07:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkcckm+WchCv for ; Fri, 20 Sep 2013 07:32:38 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2B83221F84D0 for ; Fri, 20 Sep 2013 07:32:37 -0700 (PDT) Received: from localhost ([127.0.0.1]:33434 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VN1l1-0007dh-NQ; Fri, 20 Sep 2013 16:32:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Fri, 20 Sep 2013 14:32:31 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org:443/wg/roll/trac/ticket/132#comment:6 Message-ID: <082.43d952a80486426da0d4499c38c22294@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 14:32:39 -0000 #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Comment (by rdroms@cisco.com): As posted to the roll mailing list: I realize I'm joining the conversation late. I reviewed the document to see that "scop 3" was added, but I didn't read closely enough to notice that draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast- scopes-00 are actually now in conflict with each other. I'll explain why I think they are in conflict and then suggest how to fix the issue. From draft-ietf-roll-trickle-mcast-05: When used with MPL, Realm-Local scope is administratively defined and used to define the boundaries of multicast message dissemination by MPL. From draft-ietf-6man-multicast-scopes-00: Realm-Local scope is the largest scope that is automatically configured, i.e., automatically derived from physical connectivity or other, non-multicast-related configuration. Specifically, "administratively defined" seems to me to be in direct conflict with "automatically configured". I suggest fixing the problem with two updates. First, the definition of "scop 3" in an IP-over-IEEE802.15.4 needs to be published, based on this text from draft-ietf-6man-multicast-scopes-00: The definition of any Realm-Local scope for a particular network technology should be published in an RFC. I suggest: When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to include all interfaces participating in the IEEE802.15.4 multi-link subnet. This text could be added to draft-ietf-roll-trickle-mcast-05, or to draft- ietf-6man-multicast-scopes-00 or published separately in yet another "world's shortest RFC". Second, draft-ietf-roll-trickle-mcast-05 should be changed to read: When used with MPL, Realm-local scope is defined according to the underlying network technology; for example, [cite the IP-over- IEEE802.15.4 definition]. As a further refinement, I suggest text be added to draft-ietf-roll- trickle-mcast-05 to the effect of: "scop 4" can also be used with MPL to cover deployments that use administratively defined scopes that cover, for example, subnets based on different underlying network technologies. -- ---------------------------------------+------------------------------ Reporter: mariainesrobles@gmail.com | Owner: johui@cisco.com Type: defect | Status: reopened Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------------+------------------------------ Ticket URL: roll From mcr@sandelman.ca Fri Sep 20 12:02:41 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DCC21F9DE9 for ; Fri, 20 Sep 2013 12:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPGAhUtLZEYX for ; Fri, 20 Sep 2013 12:02:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id A8FAF21F9DDE for ; Fri, 20 Sep 2013 12:02:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9D92520168; Fri, 20 Sep 2013 16:11:30 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 970DD63B18; Fri, 20 Sep 2013 15:02:22 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 85F1463AEF; Fri, 20 Sep 2013 15:02:22 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <082.43d952a80486426da0d4499c38c22294@trac.tools.ietf.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.43d952a80486426da0d4499c38c22294@trac.tools.ietf.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: mariainesrobles@gmail.com, johui@cisco.com, rdroms@cisco.com Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 19:02:41 -0000 roll issue tracker wrote: > Specifically, "administratively defined" seems to me to be in direct > conflict with "automatically configured". > I suggest fixing the problem with two updates. First, the definition > of "scop 3" in an IP-over-IEEE802.15.4 needs to be published, based on > this text from draft-ietf-6man-multicast-scopes-00: > The definition of any Realm-Local scope for a particular network > technology should be published in an RFC. > I suggest: > When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to > include all interfaces participating in the IEEE802.15.4 multi-link > subnet. > This text could be added to draft-ietf-roll-trickle-mcast-05, or to > draft- ietf-6man-multicast-scopes-00 or published separately in yet > another "world's shortest RFC". Jonathan, can you update trickle-mcast-05? Ines, can you note in the Shepard write up? (on the datatracker site) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From rdroms@cisco.com Tue Sep 24 01:49:52 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E835A21F94FA for ; Tue, 24 Sep 2013 01:49:52 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edGgaL0VC4sP for ; Tue, 24 Sep 2013 01:49:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7F94A21F9AA3 for ; Tue, 24 Sep 2013 01:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1910; q=dns/txt; s=iport; t=1380012581; x=1381222181; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UaVBAvySjfORb8VENGYqoT5h6xFbTYC2IdC6rGASe/0=; b=juKgfsppmAauHMoi9nbPy+Hlx1hTj+nfdQ2oPWGJmW59efIM9vZj9SPt DvbSKQWMoBYG4YVaIKVzcDQZnJ06k6Y6Z2usk3qBOn6Kqa0/ghB2l8bkZ lyrZTMTq3riyd6zQ7r1bSBOJdgR9kdNFH8mrt6UOPFZq04MS0q9SSZxXa 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAN9QQVKtJXHA/2dsb2JhbABagwc4UsBPgSEWdIIlAQEBAwEBAQE3NAsFCwIBCBgKFBAnCyUCBA4FCId3Bgy9Io8eAjEHgx2BAAOpc4FmgT6CKg X-IronPort-AV: E=Sophos;i="4.90,969,1371081600"; d="scan'208";a="260691020" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 24 Sep 2013 08:49:41 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8O8nefY024452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Sep 2013 08:49:40 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.202]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 03:49:40 -0500 From: "Ralph Droms (rdroms)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local Thread-Index: AQHOtg5A+x+5NCVwjUKYwe+TUJXHrg== Date: Tue, 24 Sep 2013 08:49:39 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA301B6762F@xmb-aln-x04.cisco.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.43d952a80486426da0d4499c38c22294@trac.tools.ietf.org> <5691.1379703742@sandelman.ca> In-Reply-To: <5691.1379703742@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.185] Content-Type: text/plain; charset="us-ascii" Content-ID: <15B4841F5800F345B057C5056501022F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mariainesrobles@gmail.com" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 08:49:53 -0000 Inline... On Sep 20, 2013, at 8:02 PM 9/20/13, Michael Richardson = wrote: > roll issue tracker wrote: >> Specifically, "administratively defined" seems to me to be in direct >> conflict with "automatically configured". >=20 >> I suggest fixing the problem with two updates. First, the definition >> of "scop 3" in an IP-over-IEEE802.15.4 needs to be published, based on >> this text from draft-ietf-6man-multicast-scopes-00: >=20 >> The definition of any Realm-Local scope for a particular network >> technology should be published in an RFC. >=20 >> I suggest: >=20 >> When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to >> include all interfaces participating in the IEEE802.15.4 multi-link >> subnet. >=20 >> This text could be added to draft-ietf-roll-trickle-mcast-05, or to >> draft- ietf-6man-multicast-scopes-00 or published separately in yet >> another "world's shortest RFC". >=20 > Jonathan, can you update trickle-mcast-05? It would be good to get some discussion about the specific language and met= hod of publishing the definition of "scop 3" an IEEE802.15.4 subnet. I've done a little research and I can't find any definition that might be a= ppropriate. Anyone have a reference that might be used here? If not, is the definition I suggested above OK? Where should it be published? - Ralph > Ines, can you note in the Shepard write up? (on the datatracker site) >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From cabo@tzi.org Tue Sep 24 01:56:16 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD6A21E8064 for ; Tue, 24 Sep 2013 01:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.16 X-Spam-Level: X-Spam-Status: No, score=-106.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB2Azul-KFYR for ; Tue, 24 Sep 2013 01:56:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 588F011E80D3 for ; Tue, 24 Sep 2013 01:56:10 -0700 (PDT) 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.4/8.14.4) with ESMTP id r8O8u8WJ007983 for ; Tue, 24 Sep 2013 10:56:08 +0200 (CEST) Received: from [192.168.217.105] (p548903C6.dip0.t-ipconnect.de [84.137.3.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 13054CA4; Tue, 24 Sep 2013 10:56:08 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Carsten Bormann In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA301B6762F@xmb-aln-x04.cisco.com> Date: Tue, 24 Sep 2013 10:56:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <267C5CE2-8424-431B-A680-93EA1E725AE3@tzi.org> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.43d952a80486426da0d4499c38c22294@trac.tools.ietf.org> <5691.1379703742@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA301B6762F@xmb-aln-x04.cisco.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1510) Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 08:56:16 -0000 On Sep 24, 2013, at 10:49, "Ralph Droms (rdroms)" = wrote: >>> When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined = to >>> include all interfaces participating in the IEEE802.15.4 multi-link >>> subnet. While this solves the special case of a 6LoWPAN (it might actually want = to use the term 6LoWPAN for that), I always understood the RPL approach = to go beyond networks delimited by the use of a specific link layer = technology. Wouldn't it be natural to have a MPL scope be congruent with the network = covered by a RPL scope? (Now, there may be several of those around in a network, but I'd at = least try to start from there.) Again, this is a natural thing to do in a 6LoWPAN, we just seem to lack = the term for a scope that happens to include other than 802.15.4 radios. Gr=FC=DFe, Carsten From rdroms.ietf@gmail.com Tue Sep 24 02:04:09 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1153821E8053 for ; Tue, 24 Sep 2013 02:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CmvEQjQNbcp for ; Tue, 24 Sep 2013 02:04:08 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 27B3C21E8051 for ; Tue, 24 Sep 2013 02:04:07 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id q59so4320440wes.27 for ; Tue, 24 Sep 2013 02:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=N/CB9TnMEGcA3xBVq4oR8wH1v8xjjqYkuhBGnRVQjTw=; b=x98OT9Yq519WcyAQQryTcdQxuvqRbeBIhFeVOAPp9LxCJNyb+d0PR4cz/QXfc5FDmK EnWPD5wNn62PrckfnXQa+BygCNh9Vr+xsXiAYNBs3UBABmFiFzkSFIGi5tvQ/vkjXjES XvTxbaIe4zn/8o3StCT9uMad6cPMkvLqVifA/psvFyaQTx7y0pqy1WvnpxQWoOQ/7nNu ZRZqU5SeO/u5BTs/7RNe8zqEBNnhd3wDc4ZwGOVpQ8BZT6l8yd3lAfEOsokR1F0i5c9g NxlGHduuG1jOJCR2LKbVVRltYOn/aCm8VsQhpER28AL1ZuW+nMKdDmbe3eSSihKmBUTJ himg== X-Received: by 10.194.109.35 with SMTP id hp3mr465783wjb.55.1380013447175; Tue, 24 Sep 2013 02:04:07 -0700 (PDT) Received: from [10.0.250.24] ([82.110.242.162]) by mx.google.com with ESMTPSA id iz19sm5382868wic.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 02:04:05 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <267C5CE2-8424-431B-A680-93EA1E725AE3@tzi.org> Date: Tue, 24 Sep 2013 10:04:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <22DDED80-9B21-4D42-B73D-11FC06EEA2B3@gmail.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.43d952a80486426da0d4499c38c22294@trac.tools.ietf.org> <5691.1379703742@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA301B6762F@xmb-aln-x04.cisco.com> <267C5CE2-8424-431B-A680-93EA1E725AE3@tzi.org> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1508) Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 09:04:09 -0000 On Sep 24, 2013, at 9:56 AM 9/24/13, Carsten Bormann = wrote: > On Sep 24, 2013, at 10:49, "Ralph Droms (rdroms)" = wrote: >=20 >>>> When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined = to >>>> include all interfaces participating in the IEEE802.15.4 multi-link >>>> subnet. >=20 > While this solves the special case of a 6LoWPAN (it might actually = want to use the term 6LoWPAN for that), I always understood the RPL = approach to go beyond networks delimited by the use of a specific link = layer technology. >=20 > Wouldn't it be natural to have a MPL scope be congruent with the = network covered by a RPL scope? > (Now, there may be several of those around in a network, but I'd at = least try to start from there.) >=20 > Again, this is a natural thing to do in a 6LoWPAN, we just seem to = lack the term for a scope that happens to include other than 802.15.4 = radios. This point is where my suggestion for "scop 4" enters the picture. I = suggest "scop 3" for the L2-defined topology and "scop 4" for the = administratively defined, RPL-congruent topology. - Ralph >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Tue Sep 24 02:09:03 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E5F21F9C90 for ; Tue, 24 Sep 2013 02:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMgMesyBj1Pj for ; Tue, 24 Sep 2013 02:09:02 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3DD21F9C05 for ; Tue, 24 Sep 2013 02:09:02 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id gh4so2900740qeb.2 for ; Tue, 24 Sep 2013 02:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=D9JpE/FvP6n4vo0VwwrNJCklHN2yV/nWa+dcrmWrY6Q=; b=e0xoMEIo2jRa9DbMAqNEWy3VT19sy9PKX5rhYtJW9SV+DlV1yHWVP73in6eSqJa2Mj Np67xoSM5MiP4FAIyQVVYSKJTKoTIjTxN9RMXLsMdv3XWOMn0xABul5stStmgp+SRRkr BKhl47mjB1aMcaoufUEnOsQ3BS5qPbrdOliw7hrZUzmOkfm0FNFVrkbKgdIyzytcDEJ1 UpobClLXi9RWUr3Bzy9mNXDbfJGWLoBvz3doSIFS31NwQA4iXV1zkHiFKIY/7MSsOixD GiVkSgfaDQIHNv58YWx7e7lYh708CfF8OpNpsimfyXOOSn9fAb0jw1dsYWoHpmdh0YeG 1C9A== X-Received: by 10.224.29.10 with SMTP id o10mr5130276qac.119.1380013738034; Tue, 24 Sep 2013 02:08:58 -0700 (PDT) Received: from [10.86.255.218] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id f5sm50548935qev.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 02:08:57 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <267C5CE2-8424-431B-A680-93EA1E725AE3@tzi.org> Date: Tue, 24 Sep 2013 10:08:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1A0F1183-B576-4CE0-90FF-1D3D2B811FED@gmail.com> References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org> <082.43d952a80486426da0d4499c38c22294@trac.tools.ietf.org> <5691.1379703742@sandelman.ca> <4518F39EB578034D8C99A9B7776CDBA301B6762F@xmb-aln-x04.cisco.com> <267C5CE2-8424-431B-A680-93EA1E725AE3@tzi.org> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1508) Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 09:09:03 -0000 On Sep 24, 2013, at 9:56 AM 9/24/13, Carsten Bormann = wrote: > On Sep 24, 2013, at 10:49, "Ralph Droms (rdroms)" = wrote: >=20 >>>> When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined = to >>>> include all interfaces participating in the IEEE802.15.4 multi-link >>>> subnet. >=20 > While this solves the special case of a 6LoWPAN (it might actually = want to use the term 6LoWPAN for that), I always understood the RPL = approach to go beyond networks delimited by the use of a specific link = layer technology. >=20 > Wouldn't it be natural to have a MPL scope be congruent with the = network covered by a RPL scope? > (Now, there may be several of those around in a network, but I'd at = least try to start from there.) Yeah, that issue came to mind when I thought about congruence between = MPL and RPL scopes: how is some MPL message, marked as "scop 3", = associated with a specific RPL scope when there are overlapping RPL = scopes? - Ralph >=20 > Again, this is a natural thing to do in a 6LoWPAN, we just seem to = lack the term for a scope that happens to include other than 802.15.4 = radios. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Sep 26 05:16:12 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E115221F9FEE for ; Thu, 26 Sep 2013 05:16:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0swrZO33Zfh for ; Thu, 26 Sep 2013 05:16:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6F521F9FC6 for ; Thu, 26 Sep 2013 05:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2944; q=dns/txt; s=iport; t=1380197767; x=1381407367; h=from:to:subject:date:message-id:mime-version; bh=WuZumAWu/eueZpBaG+LWdA9sRK7buA2rL/+dfptHGhs=; b=NwseyAdwJ4uKtNbQZiiFpksKpW5jpFfrejK87USdSuaNBFpFq/LrFKeQ cnihlrTei+L1vRWjzt7F5F3udTq26r3D04yaRFpP2Coe8t4sCEGxtAQUJ +i0dZcEE/dkXXsttrAaR/Ncsn7xthLcJOPlSPlYZBdW5QJFgQkzRSBwW5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FANokRFKtJV2c/2dsb2JhbABbgkNEgQrAU4EjFnSCJwEEgQsBDB5WJwQbh36bP6FNjyCDVYEBA6l1gySCKg X-IronPort-AV: E=Sophos;i="4.90,985,1371081600"; d="scan'208,217";a="264723864" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 26 Sep 2013 12:16:06 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8QCG6kt024230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Sep 2013 12:16:06 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.92]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 07:16:06 -0500 From: "JP Vasseur (jvasseur)" To: Routing Over Low power and Lossy networks Thread-Topic: Applicability Statements Documents Thread-Index: AQHOurIsuKnIt0Zdg0iHwspwmGFIqg== Date: Thu, 26 Sep 2013 12:16:05 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77238284EB@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77238284EBxmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: [Roll] Applicability Statements Documents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 12:16:13 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77238284EBxmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all (especially to the authors), As you know, we are dramatically lagging behind with regards to our applica= bility statements (AMI, home, industrial, ...). As a reminder: Feb 2013 Submit first draft of RPL applicability statement for Home = Automation applications to the IESG to be considered as an Informational RF= C Feb 2013 Submit first draft of RPL applicability statement for Build= ing Automation applications to the IESG to be considered as an Informationa= l RFC Feb 2013 Submit first draft of RPL applicability statement for Indus= trial applications to the IESG to be considered as an Informational RFC So we would really appreciate if the authors could give us an update on the= se WG documents, copying the list. Many Thanks ! JP and Michael. --_000_03B78081B371D44390ED6E7BADBB4A77238284EBxmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Dear all (especially to the authors),

As you know, we are dramatically lagging behind with regards to our ap= plicability statements (AMI, home, industrial, ...). As a reminder:


Feb 2013 Submit first draft of RPL applicability statement for Home Automation a= pplications to the IESG to be considered as an Informational RFC
Feb 2013 Submit first draft of RPL applicability statement for Building Automati= on applications to the IESG to be considered as an Informational RFC
Feb 2013 Submit first draft of RPL applicability statement for Industrial applic= ations to the IESG to be considered as an Informational RFC

So we would really appreciate if the authors could give us an update&n= bsp;on these WG documents, copying the list.

Many Thanks !

JP and Michael.
--_000_03B78081B371D44390ED6E7BADBB4A77238284EBxmbrcdx02ciscoc_-- From pthubert@cisco.com Fri Sep 27 05:00:47 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F53F21E808D for ; Fri, 27 Sep 2013 05:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.755 X-Spam-Level: X-Spam-Status: No, score=-9.755 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sSKNf-RnwQ4 for ; Fri, 27 Sep 2013 05:00:42 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA4711E814D for ; Fri, 27 Sep 2013 05:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12866; q=dns/txt; s=iport; t=1380283234; x=1381492834; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=HtFTuWhxEiScecn4zIUzqeOP1tj+EYlgLEOOX5zbXFE=; b=Pl0gRNqK5+KVJqCOHh/oEfBfhxfQWh1uJSy1idnUfMc6wJjaIje+s84a yxSfz140KxOQ0IMsQGGLgK01Jucf6OhQg12ZXzY/RMWpSLFetJklwUeEw qipKDQsuOCi6dp+xTD0JNAbfhG9r5BpU8QTiU8ZttkrmV8Wb2P5Hk7VhZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAOdxRVKtJXHA/2dsb2JhbABZgkNEOFK4CIhCgR4WdIIlAQEBBC0+HgIBCBEEAQELHQcyFAkIAgQTCId+DLoRjhmBBzcBgx2BAQOFT5NdkEmDJIIq X-IronPort-AV: E=Sophos;i="4.90,992,1371081600"; d="scan'208,217";a="265234908" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 27 Sep 2013 12:00:32 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8RC0Wkm029584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Sep 2013 12:00:32 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 07:00:32 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: Applicability Statements Documents Thread-Index: AQHOurIsuKnIt0Zdg0iHwspwmGFIqpnZefjg Date: Fri, 27 Sep 2013 12:00:31 +0000 Deferred-Delivery: Fri, 27 Sep 2013 12:00:00 +0000 Message-ID: References: <03B78081B371D44390ED6E7BADBB4A77238284EB@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77238284EB@xmb-rcd-x02.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.223.27] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8414A222Exmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [Roll] Applicability Statements Documents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 12:00:47 -0000 --_000_E045AECD98228444A58C61C200AE1BD8414A222Exmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all We publish a refresher in August. Point is until we have more deployments, = we can hardly do better than what we have. In particular we cannot fill: 4.2. Layer-two features . . . . . . . . . . . . . . . . . = . . . 28 4.2.1. Need layer-2 expert here. . . . . . . . . . . . . . . 28 4.2.2. Security functions provided by layer-2. . . . . . . . 28 4.2.3. 6LowPAN options assumed. . . . . . . . . .= . . . . . . 28 4.2.4. MLE and other things . . . . . . . . . . .= . . . . . . 28 My suggestion is to drop that section and publish what we have as an inform= ational RFC. If 6TiSCH is formed, then we will have better information there to make a r= efined applicability statement for RPL over that particular MAC, which is t= oday the industrial LLN of choice. Cheers, Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur (jvasseur) Sent: jeudi 26 septembre 2013 14:16 To: Routing Over Low power and Lossy networks Subject: [Roll] Applicability Statements Documents Dear all (especially to the authors), As you know, we are dramatically lagging behind with regards to our applica= bility statements (AMI, home, industrial, ...). As a reminder: Feb 2013 Submit first draft of RPL applicability statement for Home Automation appli= cations to the IESG to be considered as an Informational RFC Feb 2013 Submit first draft of RPL applicability statement for Building Automation a= pplications to the IESG to be considered as an Informational RFC Feb 2013 Submit first draft of RPL applicability statement for Industrial applicatio= ns to the IESG to be considered as an Informational RFC So we would really appreciate if the authors could give us an update on the= se WG documents, copying the list. Many Thanks ! JP and Michael. --_000_E045AECD98228444A58C61C200AE1BD8414A222Exmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all

 <= /p>

We publish a refresher in= August. Point is until we have more deployments, we can hardly do better t= han what we have.

In particular we cannot f= ill:

 <= /p> 

4.2.  Layer-two features . . . . .=
 . . . . . . . . . . . . . . . 28

       4.2.1.  Need layer-2 expert =
here.  . . . . . . . . . . . . . . 28<=
/o:p>


       4.2.2.  Security functions p=
rovided by layer-2.  . . . . . . . 28<=
/o:p>


       4.2.=
3.  6LowPAN options assumed. . . . . . . . . . . . . . . . 28


       4.2.=
4.  MLE and other things . . . . . . . . . . . . . . . . . 28


 


My suggestion is to drop =
that section and publish what we have as an informational RFC.


If 6TiSCH is formed, then=
 we will have better information there to make a refined applicability stat=
ement for RPL over that particular MAC, which is today the
 industrial LLN of choice.


 <=
/p>

Cheers,=



 <=
/p>



Pascal<=
/p>



 <=
/p>





From: roll-bou=
nces@ietf.org [mailto:roll-bounces@ietf.org]
On Behalf Of JP Vasseur (jvasseur)

Sent: jeudi 26 septembre 2013 14:16

To: Routing Over Low power and Lossy networks

Subject: [Roll] Applicability Statements Documents=







 


Dear all (especially to the authors), 



 






As you know, we are dramatically lagging behind with=
 regards to our applicability statements (AMI, home, industrial, ...). As a=
 reminder:






 






 












Feb 2013




Submit first draft of RPL applicability statement for Home Automation appl=
ications to the IESG to be considered as an Informational
 RFC








Feb 2013




Submit first draft of RPL applicability statement for Building Automation =
applications to the IESG to be considered as an Informational
 RFC








Feb 2013




Submit first draft of RPL applicability statement for Industrial applicati=
ons to the IESG to be considered as an Informational RFC<=
/p>










 








So we would really appreciate if the authors could g=
ive us an update on these WG documents, copying the list.





 






Many Thanks !






 






JP and Michael.
--_000_E045AECD98228444A58C61C200AE1BD8414A222Exmbrcdx01ciscoc_-- From mcr@sandelman.ca Fri Sep 27 06:40:41 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0BA21F9F88 for ; Fri, 27 Sep 2013 06:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfhlZrNcAxUb for ; Fri, 27 Sep 2013 06:40:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 478CF21F8934 for ; Fri, 27 Sep 2013 06:40:36 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6658920267 for ; Fri, 27 Sep 2013 10:49:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8E2B663B18; Fri, 27 Sep 2013 09:40:22 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7CF1063848 for ; Fri, 27 Sep 2013 09:40:22 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <03B78081B371D44390ED6E7BADBB4A77238284EB@xmb-rcd-x02.cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] Applicability Statements Documents -- industrial applications X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 13:40:41 -0000 --=-=-= Pascal Thubert (pthubert) wrote: > We publish a refresher in August. Point is until we have more > deployments, we > can hardly do better than what we have. > In particular we cannot fill: > 4.2. Layer-two features . . . . . . . . . . . . . . . . . . . . 28 > 4.2.1. Need layer-2 expert here. . . . . . . . . . . . . . . 28 > 4.2.2. Security functions provided by layer-2. . . . . . . . 28 > 4.2.3. 6LowPAN options assumed. . . . . . . . . . . . . . . . 28 > 4.2.4. MLE and other things . . . . . . . . . . . . . . . . . 28 Then I don't see how you can have a specification that be implemented. Do you truly have no layer-2 security, or you just don't know what it is? If you are targetting more than one layer-2, then you are approaching the applicability statements wrong... If you say here, "this applies to [WirelessHART] and [ISA100], each of which specifies security mechanisms X and Y", then you've said enough. > My suggestion is to drop that section and publish what we have as an > informational RFC. I don't think that this is going to fly with the IESG. You might as well wait then. > If 6TiSCH is formed, then we will have better information there to make a > refined applicability statement for RPL over that particular MAC, which > is > today the industrial LLN of choice. This is why I asked if 6tisch should adopt this document. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUkWKxIqHRg3pndX9AQL/BgQA0e4V3PSeSxP15DJwHDIrKYu/9Kuk+Zz7 o/Zng5qPvcn3avaWBYbXgZMzkEED/Kx42Q+yDxChzBNvikPxp5Y9LFugtuLWRpfZ 66eu3mDNm+4ckavmwWDwtX+oDY94RAeF9MItDurRDbltgdrCNE/UIjAkM+usjh9v +c5h/PnVmvY= =f66w -----END PGP SIGNATURE----- --=-=-=-- From jvasseur@cisco.com Mon Sep 30 04:13:55 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921D821F9B9F for ; Mon, 30 Sep 2013 04:13:55 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIlG5MGcpjPP for ; Mon, 30 Sep 2013 04:13:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 628FA21F893E for ; Mon, 30 Sep 2013 04:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=557; q=dns/txt; s=iport; t=1380539626; x=1381749226; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=HoPtMV/dTqdxKXztCEJrx7UFEpXv13VoytpQUyE734I=; b=lTw2rk1LMrxSF/AgKFphDn8776BAPfasDoEkjYQ+2VqzF0Q5MHhRLHvp Vid0jCtWAmCGyiprKueF+u+2RUok7Grv4yYCK8ljxuoL+OjZ4xlfnHZv5 bryle1RX3xFfRlPk1V+0CeMKLpEkU2O9dmSAP4TJOOa4yHULe4o1Ebw03 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJxbSVKtJV2Y/2dsb2JhbABagweBCsB9gSkWdIInAQQ6PxIBKhRCJwQODYd+vRGPIDGDJoEDA6l4gySCKg X-IronPort-AV: E=Sophos;i="4.90,1007,1371081600"; d="scan'208";a="266122401" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 30 Sep 2013 11:13:44 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8UBDiaL026975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Sep 2013 11:13:44 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.78]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 30 Sep 2013 06:13:44 -0500 From: "JP Vasseur (jvasseur)" To: Routing Over Low power and Lossy networks Thread-Topic: Meet in Vancouver Thread-Index: AQHOvc4fYgZeHn6BCEO34XtUFWoM7Q== Date: Mon, 30 Sep 2013 11:13:42 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772388902D@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] Content-Type: text/plain; charset="us-ascii" Content-ID: <0ACCB340D95FEE48B371EA46A6A150A1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson Subject: [Roll] Meet in Vancouver X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 11:13:56 -0000 Dear WG, We had quite a bit of discussion about Trickle Multicast on the list, and M= ichael and I are now working on a potential agenda. As you know, IETF meetings are quite busy and we wan= t to make sure to ask=20 for a slot if and only of we do have items requiring to meet as a WG. As of= now, we only have applicability statements, which at this point do not require for the WG to meet. Could yo= u let us know this week if=20 there are discussion items that you would like to discuss, new topics, ... = ? Thanks. JP and Michael.= From yusuke.doi@toshiba.co.jp Mon Sep 30 05:03:42 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5828F21F8E70 for ; Mon, 30 Sep 2013 05:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLdpq7--zSAz for ; Mon, 30 Sep 2013 05:03:36 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7A33F21F898A for ; Mon, 30 Sep 2013 05:03:36 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r8UC3YeJ002785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Sep 2013 21:03:34 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r8UC3Yx3022111 for ; Mon, 30 Sep 2013 21:03:34 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 366 for ; Mon, 30 Sep 2013 21:03:34 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r8UC3Yla022105 for ; Mon, 30 Sep 2013 21:03:34 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r8UC3X1W003865 for roll@ietf.org; Mon, 30 Sep 2013 21:03:33 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id XAA03864; Mon, 30 Sep 2013 21:03:33 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r8UC3XAS002027 for ; Mon, 30 Sep 2013 21:03:33 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id r8UC3XwK009096; Mon, 30 Sep 2013 21:03:33 +0900 (JST) Received: from [10.0.2.15] (ncg-dhcp114.isl.rdc.toshiba.co.jp [133.196.16.114]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 65E7E97D65; Mon, 30 Sep 2013 21:03:33 +0900 (JST) Message-ID: <52496896.8040805@toshiba.co.jp> Date: Mon, 30 Sep 2013 21:03:34 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks References: <03B78081B371D44390ED6E7BADBB4A772388902D@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772388902D@xmb-rcd-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Richardson Subject: Re: [Roll] Meet in Vancouver X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 12:03:42 -0000 Dear Chairs and WG members, I have a new proposal and I appreciate if the WG can discuss on it. (or in general, MPL parameter configuration / update method discussion?) http://tools.ietf.org/html/draft-doi-roll-mpl-parameter-configuration-02 This is joint proposal of Matt and me, and we believe it's beneficial for the community to define a method to configure/reconfigure MPL parameters per MPL domain. As Peter suggested, MPL parameters should be chosen carefully with network and traffic characteristics, and all the nodes should have the same parameters under the Trickle algorithm. Regards, Yusuke (2013-09-30 20:13), JP Vasseur (jvasseur) wrote: > Dear WG, > > We had quite a bit of discussion about Trickle Multicast on the list, and Michael and I are now working > on a potential agenda. As you know, IETF meetings are quite busy and we want to make sure to ask > for a slot if and only of we do have items requiring to meet as a WG. As of now, we only have applicability > statements, which at this point do not require for the WG to meet. Could you let us know this week if > there are discussion items that you would like to discuss, new topics, ... ? > > Thanks. > > JP and Michael. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > -- // Yusuke DOI