From jpv@cisco.com Tue Nov 1 03:19:02 2011 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 422DB21F8D5E for ; Tue, 1 Nov 2011 03:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, 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 DOqDTHFhSsyJ for ; Tue, 1 Nov 2011 03:19:01 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E798A21F8D30 for ; Tue, 1 Nov 2011 03:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2; q=dns/txt; s=iport; t=1320142741; x=1321352341; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=ixkoqgXYjjbpgBOYUqevjqL9L/UA7cHAX4OeG9oGdp6QtNaNoHhoWNgT JCJhY3/gSGgIvI3BK9pmrVTlDqil8udX+w+d4VrvZYAmtOrDVY8Oes0IO INnaHRJm/1O1AW2VPwuBox4/IdYJM5um5R0bP6y4p6U+xMjgbssYnqWoh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANHGr06rRDoG/2dsb2JhbABChzWiBIEFggsBBmCBPjWeDgGeT4gmYQSIBowJhS0JjEk X-IronPort-AV: E=Sophos;i="4.69,437,1315180800"; d="scan'208";a="10338652" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 01 Nov 2011 10:16:59 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA1AGxZF028105; Tue, 1 Nov 2011 10:16:59 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 03:16:58 -0700 Received: from [10.2.63.144] ([10.21.127.230]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 03:16:58 -0700 From: JP Vasseur Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 1 Nov 2011 03:16:58 -0700 Message-Id: <9BE57772-5AA6-4C8E-A350-962757C6A887@cisco.com> To: roll WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 01 Nov 2011 10:16:58.0447 (UTC) FILETIME=[637F7DF0:01CC987F] Cc: David Culler Subject: [Roll] FYI - ROLL WG Meeting - IETF-82 Agenda has been updated X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 10:19:02 -0000 From daniel@olddog.co.uk Tue Nov 1 04:40:49 2011 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 46F0C21F8C6A for ; Tue, 1 Nov 2011 04:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 ZX9wCqDEmY1z for ; Tue, 1 Nov 2011 04:40:48 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 7E65B21F8B86 for ; Tue, 1 Nov 2011 04:40:47 -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 pA1BecVg031365; Tue, 1 Nov 2011 11:40:38 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id pA1Bebc5031325; Tue, 1 Nov 2011 11:40:37 GMT From: "Daniel King" To: "'roll WG'" Date: Tue, 1 Nov 2011 11:40:34 -0000 Message-ID: <017901cc988b$121a6ea0$364f4be0$@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: AcyYii9mY6OsWyexSYuwm3Hy4pSNqg== Content-language: en-gb Cc: 'David Culler' Subject: [Roll] ROLL WG Meeting - IETF-82 Agenda Slides X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 11:40:49 -0000 Hi All, If you are presenting at IETF 82 please send me, CC'ing the Chairs, your ROLL slides no later than Saturday 11th, 2011. These will allow us to upload the slides at least 24hrs before the WG session. This is especially useful for our non-native English speakers to review and print out the slides before the session, and for remote participants (Jabber, et al.) to follow the presentation/discussions during the session. Once uploaded the slides will be available via the agenda page: http://tools.ietf.org/wg/roll/agenda Thanks! Dan From c.chauvenet@watteco.com Wed Nov 2 03:21:14 2011 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 8394C11E814A for ; Wed, 2 Nov 2011 03:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=1.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NxYw4sxraf5f for ; Wed, 2 Nov 2011 03:21:12 -0700 (PDT) Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4907911E8142 for ; Wed, 2 Nov 2011 03:21:11 -0700 (PDT) Received: from mail166-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Nov 2011 10:20:56 +0000 Received: from mail166-tx2 (localhost.localdomain [127.0.0.1]) by mail166-tx2-R.bigfish.com (Postfix) with ESMTP id 9DD06E88329 for ; Wed, 2 Nov 2011 10:21:05 +0000 (UTC) X-SpamScore: -7 X-BigFish: VPS-7(zzc89bhc85dh14ffOzz1202hzz8275bh8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB025.red002.local; RD:none; EFVD:NLI Received: from mail166-tx2 (localhost.localdomain [127.0.0.1]) by mail166-tx2 (MessageSwitch) id 1320229263916753_16172; Wed, 2 Nov 2011 10:21:03 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.235]) by mail166-tx2.bigfish.com (Postfix) with ESMTP id D08961C7004B for ; Wed, 2 Nov 2011 10:21:03 +0000 (UTC) Received: from IE2RD2HUB025.red002.local (213.199.187.153) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 2 Nov 2011 10:21:10 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB025.red002.local ([10.43.198.103]) with mapi; Wed, 2 Nov 2011 03:20:52 -0700 From: C Chauvenet To: "roll@ietf.org" Date: Wed, 2 Nov 2011 03:20:49 -0700 Thread-Topic: RPL behaviour with routing table overflow Thread-Index: AcyZRynreNWmQMr5Sem/uhCgVjJnQA== Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_BDF612E3788C4C4791A1A49AC3CB7C971CE865B739IE2RD2XVS211r_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: [Roll] RPL behaviour with routing table overflow X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 10:21:14 -0000 --_000_BDF612E3788C4C4791A1A49AC3CB7C971CE865B739IE2RD2XVS211r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, A question raised my mind : How is RPL coping with downward routing table = overflow ? I think upward routing cannot lead to memory issues because we just need at= least 1 entry for the best parent. I think it is a strong point of the RPL design. But we may have some memory issues with downward routing. If we are using non storing mode, it is the DAGRoot job's and I assume DAGR= oot of non storing RPL network won't have the memory limitations of LLNs. But if we are using storing mode, what happen if my downward routing table = is full, and I receive a DAO from a new Node ? The first option I see is in the DAO-ACK, where the Status field could indi= cate that the requested node cannot act as a DAO Parent. Then the DAO originator sends out another DAO to its 2nd best parent, and s= o on until its DAO is successfully acklowledged. But then, how could that node know when there will be some space for it in = the routing table of its best parent (Which should be the best route for do= wnward routing) ? Do it need to send periodic DAO to its best parent ? The second option I see is the use of the "O" flag in nthe NSA metric objec= t defined in the RPL routing metric document. This flag is used to advertise an Overflow, without too much precision abou= t the meaning. I guess it is up to the implementor, which is flexible enoug= h to handle various cases. Using this flag, nodes could know that a node ad= vertising DIO with this flag set to 1 has no more space in its routing tabl= e and so prune it from their possible DAO parent list (thus saving useless = DAO sendings). The extreme case is : if I have no alternative DAO parent or No parent has = some space for me, What should I do ?? Let expand this routing overflow issue to global downward routing : If I se= lect a DAO parent which has some space for me in its routing table, what ha= ppen if my grand parent has not ? My grand parent will reject the DAO of my= parent. My parent will follow the previous rules and try an alternative pa= rent, but if it has no alternative parent what happen ? How could I know th= at my DAO has not been successfully delivered until the DAGroot (and so tha= t I won't be reachable from the Root)? If I know it, I may be able to selec= t an alternative DAO parent that could successfully registered my path unti= l the DAGroot. Of course one simple hypothesis could cope with these memory issues : Havin= g a routing table size for each RPL router >=3D Total Number of Nodes in t= he RPL network. But I guess this narrow the scalability to the most memory-= limited router in the network... I would enjoy to know what people do with these routing overflow, and have = some guidelines about the RPL behaviour. Best, C=E9dric. --_000_BDF612E3788C4C4791A1A49AC3CB7C971CE865B739IE2RD2XVS211r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

A quest= ion raised my mind=A0 : How is RPL coping with downward routing table overf= low ?

 

I think upward routing cannot lead to memory issues because we just= need at least 1 entry for the best parent.

I think it is a strong point of the RPL design.

 

But we may have some= memory issues with downward routing.

 

If we are using non storing mode, i= t is the DAGRoot job's and I assume DAGRoot of non storing RPL network won'= t have the memory limitations of LLNs.

<= o:p> 

But if we are using storing mode, = what happen if my downward routing table is full, and I receive a DAO from = a new Node ?

 

The first option I see is in the DAO-ACK, where the Status f= ield could indicate that the requested node cannot act as a DAO Parent.

Then the DAO originator sends out another D= AO to its 2nd best parent, and so on until its DAO is successfully acklowle= dged.

 

But then, how could that node know when there will be some space fo= r it in the routing table of its best parent (Which should be the best rout= e for downward routing) ? Do it need to send periodic DAO to its best paren= t ?

 

The second option I see is the use of the "O" flag in nthe = NSA metric object defined in the RPL routing metric document.

This flag is used to advertise an Overflow, without t= oo much precision about the meaning. I guess it is up to the implementor, w= hich is flexible enough to handle various cases. Using this flag, nodes cou= ld know that a node advertising DIO with this flag set to 1 has no more spa= ce in its routing table and so prune it from their possible DAO parent list= (thus saving useless DAO sendings).

 

The extreme case is : if I have no a= lternative DAO parent or No parent has some space for me, What should I do = ??

 

Let expand this routing overflow issue to global downward routing : If= I select a DAO parent which has some space for me in its routing table, wh= at happen if my grand parent has not ? My grand parent will reject the DAO = of my parent. My parent will follow the previous rules and try an alternati= ve parent, but if it has no alternative parent what happen ? How could I kn= ow that my DAO has not been successfully delivered until the DAGroot (and s= o that I won't be reachable from the Root)? If I know it, I may be able to = select an alternative DAO parent that could successfully registered my path= until the DAGroot.

 

Of course one simple hypothesis could cope with these= memory issues : Having a routing table size for each RPL router >=3D To= tal Number of =A0Nodes in the RPL network. But I guess this narrow the scal= ability to the most memory-limited router in the network…<= /p>

 

I would e= njoy to know what people do with these routing overflow, and have some guid= elines about the RPL behaviour.

&nb= sp;

Best,

= C=E9dric.

= --_000_BDF612E3788C4C4791A1A49AC3CB7C971CE865B739IE2RD2XVS211r_-- From pthubert@cisco.com Wed Nov 2 05:16:08 2011 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 42A9011E8089 for ; Wed, 2 Nov 2011 05:16: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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4EwTbY9HV0Y6 for ; Wed, 2 Nov 2011 05:16:05 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2FECE1F0C8E for ; Wed, 2 Nov 2011 05:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=15293; q=dns/txt; s=iport; t=1320236164; x=1321445764; h=mime-version:subject:date:message-id:from:to; bh=6xGhkpAr53oqfb15aANA0ROMK36iFqbDWrch8wTi4Tg=; b=Ze9jwsn3qvCLGGDVQNcwFMwmTEGLf+RFZvRCOVOxbEMnS6xrgiWZ1Rt9 H1uzoHZpX8rJDvpuT04C83fvnI7M3Bnz8lhbM16wMvkRRmopR9oykKrh8 ncOsHYrFJZy3+jUIWIfbXsNOKfbF4Hp6KPT3M6Dz+ilZf0dO4TlyOFvFV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADQ0sU6Q/khL/2dsb2JhbABDgk2me4EFgXIBAQEEEgEJEQNbAQgRBAEBCwYXAQdFCQkBBAESCBqeJQGeWogvYQSHVpF4jCw X-IronPort-AV: E=Sophos;i="4.69,443,1315180800"; d="scan'208,217";a="2255812" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 02 Nov 2011 12:15:59 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA2CFwDw026528; Wed, 2 Nov 2011 12:15:58 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 13:15:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9959.2D8A5765" Date: Wed, 2 Nov 2011 13:14:13 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL behaviour with routing table overflow Thread-Index: AcyZWO6dWhkGFKTyTLyopi+W/vVzJg== From: "Pascal Thubert (pthubert)" To: "C Chauvenet" , X-OriginalArrivalTime: 02 Nov 2011 12:15:58.0428 (UTC) FILETIME=[2DABE1C0:01CC9959] Subject: Re: [Roll] RPL behaviour with routing table overflow X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 12:16:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9959.2D8A5765 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Cedric: =20 This question was discussed but proposals to actually do something were = rejected. The point was that the devices are supposed to have 'enough' = memory. We can probably dig in the ML archive but my memory tells me = that you already went as far as the discussion ever did. =20 In your thinking you need to remember that RPL is still building a = DODAG. So if all devices are equal and a node has a memory issue, then = its parent's memory is even more of an issue. And the problem goes down = very rapidly has the number of hops augments from the root. IOW, very = generally it is a first hop problem, just as most of the sorts of = congestion that could probably happen. So before we make the protocol = very complex, there's a minimum of deployment best practice to ensure = that as many nodes as possible are one hop away from the root. =20 >From there, one could probably include the residual memory in the = exposed metrics so that the OF accounts for it in the parent = computation. Same goes for residual battery if you look at it, or for = bandwidth for mesh networks where that's the most critical constraints. = But you'll recognize the risk of Arpanet-like oscillations if nodes = blindly move to the least loaded parent, and you'll have to figure ways = to filter/dampen them out. =20 Finally you'll note that if you follow that path, a node might have = children that also injected routes into it. So the node might need a = certain amount of resources (bandwidth, battery, memory...) available = from the parent in order to be able to attach to that parent with all = its own children. If none of the parents have enough resources, what = will the node do? Spread the load, probably? Drop/ push back some = children as well? You see that rapidly, the complexity and potential = instabilities overwhelm the benefits. =20 Cheers, =20 Pascal =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = C Chauvenet Sent: mercredi 2 novembre 2011 11:21 To: roll@ietf.org Subject: [Roll] RPL behaviour with routing table overflow =20 Hi all,=20 =20 A question raised my mind : How is RPL coping with downward routing = table overflow ? =20 I think upward routing cannot lead to memory issues because we just need = at least 1 entry for the best parent. I think it is a strong point of the RPL design. =20 But we may have some memory issues with downward routing. =20 If we are using non storing mode, it is the DAGRoot job's and I assume = DAGRoot of non storing RPL network won't have the memory limitations of = LLNs. =20 But if we are using storing mode, what happen if my downward routing = table is full, and I receive a DAO from a new Node ? =20 The first option I see is in the DAO-ACK, where the Status field could = indicate that the requested node cannot act as a DAO Parent. Then the DAO originator sends out another DAO to its 2nd best parent, = and so on until its DAO is successfully acklowledged. =20 But then, how could that node know when there will be some space for it = in the routing table of its best parent (Which should be the best route = for downward routing) ? Do it need to send periodic DAO to its best = parent ? =20 The second option I see is the use of the "O" flag in nthe NSA metric = object defined in the RPL routing metric document. This flag is used to advertise an Overflow, without too much precision = about the meaning. I guess it is up to the implementor, which is = flexible enough to handle various cases. Using this flag, nodes could = know that a node advertising DIO with this flag set to 1 has no more = space in its routing table and so prune it from their possible DAO = parent list (thus saving useless DAO sendings). =20 The extreme case is : if I have no alternative DAO parent or No parent = has some space for me, What should I do ?? =20 Let expand this routing overflow issue to global downward routing : If I = select a DAO parent which has some space for me in its routing table, = what happen if my grand parent has not ? My grand parent will reject the = DAO of my parent. My parent will follow the previous rules and try an = alternative parent, but if it has no alternative parent what happen ? = How could I know that my DAO has not been successfully delivered until = the DAGroot (and so that I won't be reachable from the Root)? If I know = it, I may be able to select an alternative DAO parent that could = successfully registered my path until the DAGroot. =20 Of course one simple hypothesis could cope with these memory issues : = Having a routing table size for each RPL router >=3D Total Number of = Nodes in the RPL network. But I guess this narrow the scalability to the = most memory-limited router in the network... =20 I would enjoy to know what people do with these routing overflow, and = have some guidelines about the RPL behaviour. =20 Best, C=E9dric. ------_=_NextPart_001_01CC9959.2D8A5765 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello = Cedric:

 

This = question was discussed but proposals to actually do something were = rejected. The point was that the devices are supposed to have = ‘enough’ memory. We can probably dig in the ML archive but = my memory tells me that you already went as far as the discussion ever = did.

 

In your = thinking you need to remember that RPL is still building a DODAG. So if = all devices are equal and a node has a memory issue, then its = parent’s memory is even more of an issue. And the problem goes = down very rapidly has the number of hops augments from the root. IOW, = very generally it is a first hop problem, just as most of the sorts of = congestion that could probably happen. So before we make the protocol = very complex, there’s a minimum of deployment best practice to = ensure that as many nodes as possible are one hop away from the = root.

 

From there, = one could probably include the residual memory in the exposed metrics so = that the OF accounts for it in the parent computation. Same goes for = residual battery if you look at it, or for bandwidth for mesh networks = where that’s the most critical constraints. But you’ll = recognize the risk of Arpanet-like oscillations if nodes blindly move to = the least loaded parent, and you’ll have to figure ways to = filter/dampen them out.

 

Finally = you’ll note that if you follow that path, a node might have = children that also injected routes into it. So the node might need a = certain amount of resources (bandwidth, battery, memory…) = available from the parent in order to be able to attach to that parent = with all its own children. If none of the parents have enough resources, = what will the node do? Spread the load, probably? Drop/ push back some = children as well? You see that rapidly, the complexity and potential = instabilities overwhelm the benefits.

 

Cheers,

 

Pascal

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = Behalf Of C Chauvenet
Sent: mercredi 2 novembre 2011 = 11:21
To: roll@ietf.org
Subject: [Roll] RPL = behaviour with routing table = overflow

 

Hi all, =

 

A question raised my mind  : How is RPL coping = with downward routing table overflow ?

 

I think = upward routing cannot lead to memory issues because we just need at = least 1 entry for the best parent.

I = think it is a strong point of the RPL design.

 

But we may = have some memory issues with downward routing.

 

If we are = using non storing mode, it is the DAGRoot job's and I assume DAGRoot of = non storing RPL network won't have the memory limitations of = LLNs.

 

But if we are using storing mode, what happen if my = downward routing table is full, and I receive a DAO from a new Node = ?

 

The first option I see is in the DAO-ACK, where the = Status field could indicate that the requested node cannot act as a DAO = Parent.

Then the DAO originator sends = out another DAO to its 2nd best parent, and so on until its DAO is = successfully acklowledged.

 

But then, = how could that node know when there will be some space for it in the = routing table of its best parent (Which should be the best route for = downward routing) ? Do it need to send periodic DAO to its best parent = ?

 

The second option I see is the use of the = "O" flag in nthe NSA metric object defined in the RPL routing = metric document.

This flag is used to = advertise an Overflow, without too much precision about the meaning. I = guess it is up to the implementor, which is flexible enough to handle = various cases. Using this flag, nodes could know that a node advertising = DIO with this flag set to 1 has no more space in its routing table and = so prune it from their possible DAO parent list (thus saving useless DAO = sendings).

 

The extreme case is : if I have no alternative DAO = parent or No parent has some space for me, What should I do = ??

 

Let expand this routing overflow issue to global = downward routing : If I select a DAO parent which has some space for me = in its routing table, what happen if my grand parent has not ? My grand = parent will reject the DAO of my parent. My parent will follow the = previous rules and try an alternative parent, but if it has no = alternative parent what happen ? How could I know that my DAO has not = been successfully delivered until the DAGroot (and so that I won't be = reachable from the Root)? If I know it, I may be able to select an = alternative DAO parent that could successfully registered my path until = the DAGroot.

 

Of course one simple hypothesis could cope with these = memory issues : Having a routing table size for each RPL router >=3D = Total Number of  Nodes in the RPL network. But I guess this narrow = the scalability to the most memory-limited router in the = network…

 

I would = enjoy to know what people do with these routing overflow, and have some = guidelines about the RPL behaviour.

 

Best,

C=E9dric.

------_=_NextPart_001_01CC9959.2D8A5765-- From c.chauvenet@watteco.com Wed Nov 2 06:20:32 2011 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 40E411F0C4F for ; Wed, 2 Nov 2011 06:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.223 X-Spam-Level: X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[AWL=-0.625, 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 LSoZLe02v2gL for ; Wed, 2 Nov 2011 06:20:27 -0700 (PDT) Received: from VA3EHSOBE002.bigfish.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id D989121F8CA3 for ; Wed, 2 Nov 2011 06:20:26 -0700 (PDT) Received: from mail75-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Nov 2011 13:20:07 +0000 Received: from mail75-va3 (localhost [127.0.0.1]) by mail75-va3-R.bigfish.com (Postfix) with ESMTP id 657D710027D; Wed, 2 Nov 2011 13:20:10 +0000 (UTC) X-SpamScore: -32 X-BigFish: VPS-32(zzc89bhc85dh14ffO1419Mzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); SRV:BULK; H:IE2RD2HUB015.red002.local; RD:none; EFVD:NLI Received: from mail75-va3 (localhost.localdomain [127.0.0.1]) by mail75-va3 (MessageSwitch) id 1320240007559367_12359; Wed, 2 Nov 2011 13:20:07 +0000 (UTC) Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.243]) by mail75-va3.bigfish.com (Postfix) with ESMTP id D194D20150; Wed, 2 Nov 2011 13:20:01 +0000 (UTC) Received: from IE2RD2HUB015.red002.local (213.199.187.153) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 2 Nov 2011 13:19:56 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB015.red002.local ([10.43.198.13]) with mapi; Wed, 2 Nov 2011 06:19:53 -0700 From: C Chauvenet To: "Pascal Thubert (pthubert)" , "roll@ietf.org" Date: Wed, 2 Nov 2011 06:19:50 -0700 Thread-Topic: [Roll] RPL behaviour with routing table overflow Thread-Index: AcyZWO6dWhkGFKTyTLyopi+W/vVzJgABl4gg Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_BDF612E3788C4C4791A1A49AC3CB7C971CE865B847IE2RD2XVS211r_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: Re: [Roll] RPL behaviour with routing table overflow X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 13:20:32 -0000 --_000_BDF612E3788C4C4791A1A49AC3CB7C971CE865B847IE2RD2XVS211r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal, Thank you for your answer. I think the final decision regarding this issue will be : - Do storing mode if you have enough memory - Do non storing mode if you don't or can't predict the num= ber of Nodes in your network Again, this is related to downward routing only, which is an optional featu= re of RPL. C=E9dric. De : Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Envoy=E9 : mercredi 2 novembre 2011 13:14 =C0 : C Chauvenet; roll@ietf.org Objet : RE: [Roll] RPL behaviour with routing table overflow Hello Cedric: This question was discussed but proposals to actually do something were rej= ected. The point was that the devices are supposed to have 'enough' memory.= We can probably dig in the ML archive but my memory tells me that you alre= ady went as far as the discussion ever did. In your thinking you need to remember that RPL is still building a DODAG. S= o if all devices are equal and a node has a memory issue, then its parent's= memory is even more of an issue. And the problem goes down very rapidly ha= s the number of hops augments from the root. IOW, very generally it is a fi= rst hop problem, just as most of the sorts of congestion that could probabl= y happen. So before we make the protocol very complex, there's a minimum of= deployment best practice to ensure that as many nodes as possible are one = hop away from the root. >From there, one could probably include the residual memory in the exposed m= etrics so that the OF accounts for it in the parent computation. Same goes = for residual battery if you look at it, or for bandwidth for mesh networks = where that's the most critical constraints. But you'll recognize the risk o= f Arpanet-like oscillations if nodes blindly move to the least loaded paren= t, and you'll have to figure ways to filter/dampen them out. Finally you'll note that if you follow that path, a node might have childre= n that also injected routes into it. So the node might need a certain amoun= t of resources (bandwidth, battery, memory...) available from the parent in= order to be able to attach to that parent with all its own children. If no= ne of the parents have enough resources, what will the node do? Spread the = load, probably? Drop/ push back some children as well? You see that rapidly= , the complexity and potential instabilities overwhelm the benefits. Cheers, Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of C C= hauvenet Sent: mercredi 2 novembre 2011 11:21 To: roll@ietf.org Subject: [Roll] RPL behaviour with routing table overflow Hi all, A question raised my mind : How is RPL coping with downward routing table = overflow ? I think upward routing cannot lead to memory issues because we just need at= least 1 entry for the best parent. I think it is a strong point of the RPL design. But we may have some memory issues with downward routing. If we are using non storing mode, it is the DAGRoot job's and I assume DAGR= oot of non storing RPL network won't have the memory limitations of LLNs. But if we are using storing mode, what happen if my downward routing table = is full, and I receive a DAO from a new Node ? The first option I see is in the DAO-ACK, where the Status field could indi= cate that the requested node cannot act as a DAO Parent. Then the DAO originator sends out another DAO to its 2nd best parent, and s= o on until its DAO is successfully acklowledged. But then, how could that node know when there will be some space for it in = the routing table of its best parent (Which should be the best route for do= wnward routing) ? Do it need to send periodic DAO to its best parent ? The second option I see is the use of the "O" flag in nthe NSA metric objec= t defined in the RPL routing metric document. This flag is used to advertise an Overflow, without too much precision abou= t the meaning. I guess it is up to the implementor, which is flexible enoug= h to handle various cases. Using this flag, nodes could know that a node ad= vertising DIO with this flag set to 1 has no more space in its routing tabl= e and so prune it from their possible DAO parent list (thus saving useless = DAO sendings). The extreme case is : if I have no alternative DAO parent or No parent has = some space for me, What should I do ?? Let expand this routing overflow issue to global downward routing : If I se= lect a DAO parent which has some space for me in its routing table, what ha= ppen if my grand parent has not ? My grand parent will reject the DAO of my= parent. My parent will follow the previous rules and try an alternative pa= rent, but if it has no alternative parent what happen ? How could I know th= at my DAO has not been successfully delivered until the DAGroot (and so tha= t I won't be reachable from the Root)? If I know it, I may be able to selec= t an alternative DAO parent that could successfully registered my path unti= l the DAGroot. Of course one simple hypothesis could cope with these memory issues : Havin= g a routing table size for each RPL router >=3D Total Number of Nodes in t= he RPL network. But I guess this narrow the scalability to the most memory-= limited router in the network... I would enjoy to know what people do with these routing overflow, and have = some guidelines about the RPL behaviour. Best, C=E9dric. --_000_BDF612E3788C4C4791A1A49AC3CB7C971CE865B847IE2RD2XVS211r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

Thank you for your answer.

 

I think the final decis= ion regarding this issue will be :

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 - Do storing mode if you have enough memory

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 - Do non storing mode if you don't or can't predict the = number of Nodes in your network

<= span style=3D'color:#1F497D'> 

Again, this is related to downward routing= only, which is an optional feature of RPL.

 

C=E9dric.<= /p>

 

De : Pascal Thubert (pthubert) [mailto:pthubert@cisco.com= ]
Envoy=E9 : mercredi 2 novembre 2011 13:14
=C0 = : C Chauvenet; roll@ietf.org
Objet : RE: [Roll] RPL beha= viour with routing table overflow

 

Hello Cedric:

 

=

This questi= on was discussed but proposals to actually do something were rejected. The = point was that the devices are supposed to have ‘enough’ memory= . We can probably dig in the ML archive but my memory tells me that you alr= eady went as far as the discussion ever did.

 

In= your thinking you need to remember that RPL is still building a DODAG. So = if all devices are equal and a node has a memory issue, then its parentR= 17;s memory is even more of an issue. And the problem goes down very rapidl= y has the number of hops augments from the root. IOW, very generally it is = a first hop problem, just as most of the sorts of congestion that could pro= bably happen. So before we make the protocol very complex, there’s a = minimum of deployment best practice to ensure that as many nodes as possibl= e are one hop away from the root.

 

From there, on= e could probably include the residual memory in the exposed metrics so that= the OF accounts for it in the parent computation. Same goes for residual b= attery if you look at it, or for bandwidth for mesh networks where thatR= 17;s the most critical constraints. But you’ll recognize the risk of = Arpanet-like oscillations if nodes blindly move to the least loaded parent,= and you’ll have to figure ways to filter/dampen them out.=

=  

Finally you’ll note that if you follow that path, = a node might have children that also injected routes into it. So the node m= ight need a certain amount of resources (bandwidth, battery, memory…)= available from the parent in order to be able to attach to that parent wit= h all its own children. If none of the parents have enough resources, what = will the node do? Spread the load, probably? Drop/ push back some children = as well? You see that rapidly, the complexity and potential instabilities o= verwhelm the benefits.

 

Cheers,=

&n= bsp;

Pascal

 

 

From: roll-bounces@ietf.org [mailto:roll-bounc= es@ietf.org] On Behalf Of C Chauvenet
Sent: mercredi 2 nov= embre 2011 11:21
To: roll@ietf.org
Subject: [Roll] RPL = behaviour with routing table overflow

 

Hi all,

 

A que= stion raised my mind  : How is RPL coping with downward routing table = overflow ?

 

I think upward routing cannot lead to memory issues because we= just need at least 1 entry for the best parent.

I think it is a strong point of the RPL design.

 

But we may have = some memory issues with downward routing.

 

If we are using non storing mod= e, it is the DAGRoot job's and I assume DAGRoot of non storing RPL network = won't have the memory limitations of LLNs.

 

But if we are using storing mo= de, what happen if my downward routing table is full, and I receive a DAO f= rom a new Node ?

 

The first option I see is in the DAO-ACK, where the Stat= us field could indicate that the requested node cannot act as a DAO Parent.=

Then the DAO originator sends out anoth= er DAO to its 2nd best parent, and so on until its DAO is successfully ackl= owledged.

 

But then, how could that node know when there will be some spa= ce for it in the routing table of its best parent (Which should be the best= route for downward routing) ? Do it need to send periodic DAO to its best = parent ?

 

The second option I see is the use of the "O" flag i= n nthe NSA metric object defined in the RPL routing metric document.

This flag is used to advertise an Overflow, wi= thout too much precision about the meaning. I guess it is up to the impleme= ntor, which is flexible enough to handle various cases. Using this flag, no= des could know that a node advertising DIO with this flag set to 1 has no m= ore space in its routing table and so prune it from their possible DAO pare= nt list (thus saving useless DAO sendings).

 

The extreme case is : if I ha= ve no alternative DAO parent or No parent has some space for me, What shoul= d I do ??

 

Let expand this routing overflow issue to global downward rout= ing : If I select a DAO parent which has some space for me in its routing t= able, what happen if my grand parent has not ? My grand parent will reject = the DAO of my parent. My parent will follow the previous rules and try an a= lternative parent, but if it has no alternative parent what happen ? How co= uld I know that my DAO has not been successfully delivered until the DAGroo= t (and so that I won't be reachable from the Root)? If I know it, I may be = able to select an alternative DAO parent that could successfully registered= my path until the DAGroot.

 <= /o:p>

Of course one simple hypothesis could cope wi= th these memory issues : Having a routing table size for each RPL router &g= t;=3D Total Number of  Nodes in the RPL network. But I guess this narr= ow the scalability to the most memory-limited router in the network…<= o:p>

 

I would enjoy to know what people do with these routing overflow, and hav= e some guidelines about the RPL behaviour.

 

Best,

C=E9dric.

= --_000_BDF612E3788C4C4791A1A49AC3CB7C971CE865B847IE2RD2XVS211r_-- From pthubert@cisco.com Wed Nov 2 07:03:52 2011 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 C4A7F1F0C52 for ; Wed, 2 Nov 2011 07:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=1.999, 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 iP8Md0bnYlxV for ; Wed, 2 Nov 2011 07:03:47 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 79DC41F0C8B for ; Wed, 2 Nov 2011 07:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=27175; q=dns/txt; s=iport; t=1320242626; x=1321452226; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=NH5a0Q/WsVTk8zjQyzFZy8Bxfg97534dAHMJE6UBHYg=; b=lCw/oViSpplg1GOw1K5CqesQpdYWONoybpzmzUBqegmboCNxgb4f5+Fo ZWsMNkRHLk1MD6OWLKxplxK9E6z9tg4WpF4U/VSRDBbUv5uMcBcro34Ge F3eg+dFqPva3q6WERIfGRuw7vkgf6h086/co+7XRGR+VaKxU7i32vrQI/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACpNsU6Q/khN/2dsb2JhbABDgk2nH4EFgXIBAQEEEgEJEQNZAgEIEQQBAQsGEAcBBgFFCQgBAQQBEgganjABnl6IL2EEh1aReIws X-IronPort-AV: E=Sophos;i="4.69,443,1315180800"; d="scan'208,217";a="59043453" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 02 Nov 2011 14:03:45 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA2E3jKb008603; Wed, 2 Nov 2011 14:03:45 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 15:03:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9968.3BCFF495" Date: Wed, 2 Nov 2011 15:02:53 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL behaviour with routing table overflow Thread-Index: AcyZWO6dWhkGFKTyTLyopi+W/vVzJgABl4ggAAEJ/tA= References: From: "Pascal Thubert (pthubert)" To: "C Chauvenet" , X-OriginalArrivalTime: 02 Nov 2011 14:03:44.0958 (UTC) FILETIME=[3C060DE0:01CC9968] Subject: Re: [Roll] RPL behaviour with routing table overflow X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 14:03:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9968.3BCFF495 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Cedric; =20 That's certainly right for an autonomic network that might take any form = and shape. =20 For a more engineered network and operation, there are several aspects = to the memory utilization, linked to how diversity is handled. =20 - Root diversity creates more and smaller DODAGS, each of which will = require less memory. Can you throw more roots in? Where can they be = placed to optimize distribution and reduce hops? If the distribution is = perfect, the size of the routing table in each first hop router is = divided by the number of roots. =20 - First hop diversity. You want to have enough first hop routers (FHR) = so that the total number of routes gets divided between those. Can you = make it so that the first hop is distributed well-enough that second hop = routers have multiple potential parents and entries are fairly = distributed between the first hop parents? The size of the routing table in each first hop router is probably = divided by a good portion of the number of first hop routers that = depends for one thing on the fan out of the DAO routes. =20 - Time diversity. Do you need all entries all the time? If there's a = sort of schedule by which meters can know when they should be reachable, = then the meters only need to inject DAOs during that period. Again, in a = perfect distribution, the size of the routing table in each first hop = router is divided by the ratio of time that the end devices need to be = reachable. =20 Talking an example to illustrate this; say you have 2400 devices that = expect to be polled within a time window of less than one hour per day. = As a result the address of a device needs only be present in the network = for a 24th of the time. So at a given point of time there are only 100 = routes in the network. Say you have 10 first hop routers and an expected = fan out of 2, which means that there will be 2 first hop routers with a = given DAO route. You can end up with 20 routes per FHR, if the = distribution is perfect, and 10 routes if you add an second root. =20 Finally there are cases where aggregation can work for you. I think that = there is a good opportunity for this group to work on aggregation = schemes that would map existing deployments and would enable to compress = either the RIBs or the advertisements. =20 Cheers, =20 Pascal =20 =20 From: C Chauvenet [mailto:c.chauvenet@watteco.com]=20 Sent: mercredi 2 novembre 2011 14:20 To: Pascal Thubert (pthubert); roll@ietf.org Subject: RE: [Roll] RPL behaviour with routing table overflow =20 Hi Pascal, =20 Thank you for your answer. =20 I think the final decision regarding this issue will be : =20 - Do storing mode if you have enough memory - Do non storing mode if you don't or can't predict the = number of Nodes in your network =20 Again, this is related to downward routing only, which is an optional = feature of RPL. =20 C=E9dric. =20 De : Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Envoy=E9 : mercredi 2 novembre 2011 13:14 =C0 : C Chauvenet; roll@ietf.org Objet : RE: [Roll] RPL behaviour with routing table overflow =20 Hello Cedric: =20 This question was discussed but proposals to actually do something were = rejected. The point was that the devices are supposed to have 'enough' = memory. We can probably dig in the ML archive but my memory tells me = that you already went as far as the discussion ever did. =20 In your thinking you need to remember that RPL is still building a = DODAG. So if all devices are equal and a node has a memory issue, then = its parent's memory is even more of an issue. And the problem goes down = very rapidly has the number of hops augments from the root. IOW, very = generally it is a first hop problem, just as most of the sorts of = congestion that could probably happen. So before we make the protocol = very complex, there's a minimum of deployment best practice to ensure = that as many nodes as possible are one hop away from the root. =20 >From there, one could probably include the residual memory in the = exposed metrics so that the OF accounts for it in the parent = computation. Same goes for residual battery if you look at it, or for = bandwidth for mesh networks where that's the most critical constraints. = But you'll recognize the risk of Arpanet-like oscillations if nodes = blindly move to the least loaded parent, and you'll have to figure ways = to filter/dampen them out. =20 Finally you'll note that if you follow that path, a node might have = children that also injected routes into it. So the node might need a = certain amount of resources (bandwidth, battery, memory...) available = from the parent in order to be able to attach to that parent with all = its own children. If none of the parents have enough resources, what = will the node do? Spread the load, probably? Drop/ push back some = children as well? You see that rapidly, the complexity and potential = instabilities overwhelm the benefits. =20 Cheers, =20 Pascal =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = C Chauvenet Sent: mercredi 2 novembre 2011 11:21 To: roll@ietf.org Subject: [Roll] RPL behaviour with routing table overflow =20 Hi all,=20 =20 A question raised my mind : How is RPL coping with downward routing = table overflow ? =20 I think upward routing cannot lead to memory issues because we just need = at least 1 entry for the best parent. I think it is a strong point of the RPL design. =20 But we may have some memory issues with downward routing. =20 If we are using non storing mode, it is the DAGRoot job's and I assume = DAGRoot of non storing RPL network won't have the memory limitations of = LLNs. =20 But if we are using storing mode, what happen if my downward routing = table is full, and I receive a DAO from a new Node ? =20 The first option I see is in the DAO-ACK, where the Status field could = indicate that the requested node cannot act as a DAO Parent. Then the DAO originator sends out another DAO to its 2nd best parent, = and so on until its DAO is successfully acklowledged. =20 But then, how could that node know when there will be some space for it = in the routing table of its best parent (Which should be the best route = for downward routing) ? Do it need to send periodic DAO to its best = parent ? =20 The second option I see is the use of the "O" flag in nthe NSA metric = object defined in the RPL routing metric document. This flag is used to advertise an Overflow, without too much precision = about the meaning. I guess it is up to the implementor, which is = flexible enough to handle various cases. Using this flag, nodes could = know that a node advertising DIO with this flag set to 1 has no more = space in its routing table and so prune it from their possible DAO = parent list (thus saving useless DAO sendings). =20 The extreme case is : if I have no alternative DAO parent or No parent = has some space for me, What should I do ?? =20 Let expand this routing overflow issue to global downward routing : If I = select a DAO parent which has some space for me in its routing table, = what happen if my grand parent has not ? My grand parent will reject the = DAO of my parent. My parent will follow the previous rules and try an = alternative parent, but if it has no alternative parent what happen ? = How could I know that my DAO has not been successfully delivered until = the DAGroot (and so that I won't be reachable from the Root)? If I know = it, I may be able to select an alternative DAO parent that could = successfully registered my path until the DAGroot. =20 Of course one simple hypothesis could cope with these memory issues : = Having a routing table size for each RPL router >=3D Total Number of = Nodes in the RPL network. But I guess this narrow the scalability to the = most memory-limited router in the network... =20 I would enjoy to know what people do with these routing overflow, and = have some guidelines about the RPL behaviour. =20 Best, C=E9dric. ------_=_NextPart_001_01CC9968.3BCFF495 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Cedric;

 

That’s certainly right for an autonomic = network that might take any form and shape.

 

For a more = engineered network and operation, there are several aspects to the = memory utilization, linked to how diversity is = handled.

 

- Root = diversity creates more and smaller DODAGS, each of which will require = less memory. Can you throw more roots in? Where can they be placed to = optimize distribution and reduce hops? If the distribution is perfect, = the size of the routing table in each first hop router is divided by the = number of roots.

 

- First hop = diversity. You want to have enough first hop routers (FHR) so that the = total number of routes gets divided between those. Can you make it so = that the first hop is distributed well-enough that second hop routers = have multiple potential parents and entries are fairly distributed = between the first hop parents?

The size of = the routing table in each first hop router is probably divided by a good = portion of the number of first hop routers that depends for one thing on = the fan out of the DAO routes.

 

- Time = diversity. Do you need all entries all the time? If there’s a sort = of schedule by which meters can know when they should be reachable, then = the meters only need to inject DAOs during that period. Again, in a = perfect distribution, the size of the routing table in each first hop = router is divided by the ratio of time that the end devices need to be = reachable.

 

Talking an = example to illustrate this; say you have 2400 devices that expect to be = polled within a time window of less than one hour per day. As a result = the address of a device needs only be present in the network for a = 24th of the time. So at a given point of time there are only = 100 routes in the network. Say you have 10 first hop routers and an = expected fan out of 2, which means that there will be 2 first hop = routers with a given DAO route. You can end up with 20 routes per FHR, = if the distribution is perfect, and 10 routes if you add an second = root.

 

Finally = there are cases where aggregation can work for you. I think that there = is a good opportunity for this group to work on aggregation schemes that = would map existing deployments and would enable to compress either the = RIBs or the advertisements.

 

Cheers,

 

Pascal

 

 

From: C Chauvenet [mailto:c.chauvenet@watteco.com] =
Sent: mercredi 2 novembre 2011 14:20
To: Pascal = Thubert (pthubert); roll@ietf.org
Subject: RE: [Roll] RPL = behaviour with routing table = overflow

 

Hi Pascal,

 

Thank you for your = answer.

 

I think the final = decision regarding this issue will be :

 

        &= nbsp;       - Do storing mode if you have = enough memory

        &= nbsp;       - Do non storing mode if you = don't or can't predict the number of Nodes in your = network

 

Again, this is related = to downward routing only, which is an optional feature of = RPL.

 

C=E9dric.

 

De : Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Envoy=E9 : mercredi 2 novembre 2011 = 13:14
=C0 : C Chauvenet; roll@ietf.org
Objet : = RE: [Roll] RPL behaviour with routing table = overflow

 

Hello = Cedric:

 

This = question was discussed but proposals to actually do something were = rejected. The point was that the devices are supposed to have = ‘enough’ memory. We can probably dig in the ML archive but = my memory tells me that you already went as far as the discussion ever = did.

 

In your = thinking you need to remember that RPL is still building a DODAG. So if = all devices are equal and a node has a memory issue, then its = parent’s memory is even more of an issue. And the problem goes = down very rapidly has the number of hops augments from the root. IOW, = very generally it is a first hop problem, just as most of the sorts of = congestion that could probably happen. So before we make the protocol = very complex, there’s a minimum of deployment best practice to = ensure that as many nodes as possible are one hop away from the = root.

 

From there, = one could probably include the residual memory in the exposed metrics so = that the OF accounts for it in the parent computation. Same goes for = residual battery if you look at it, or for bandwidth for mesh networks = where that’s the most critical constraints. But you’ll = recognize the risk of Arpanet-like oscillations if nodes blindly move to = the least loaded parent, and you’ll have to figure ways to = filter/dampen them out.

 

Finally = you’ll note that if you follow that path, a node might have = children that also injected routes into it. So the node might need a = certain amount of resources (bandwidth, battery, memory…) = available from the parent in order to be able to attach to that parent = with all its own children. If none of the parents have enough resources, = what will the node do? Spread the load, probably? Drop/ push back some = children as well? You see that rapidly, the complexity and potential = instabilities overwhelm the benefits.

 

Cheers,

 

Pascal

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.= org] On Behalf Of C Chauvenet
Sent: mercredi 2 = novembre 2011 11:21
To: roll@ietf.org
Subject: = [Roll] RPL behaviour with routing table = overflow

 

Hi all, =

 

A question raised my mind  : How is RPL coping = with downward routing table overflow ?

 

I think = upward routing cannot lead to memory issues because we just need at = least 1 entry for the best parent.

I = think it is a strong point of the RPL design.

 

But we may = have some memory issues with downward routing.

 

If we are = using non storing mode, it is the DAGRoot job's and I assume DAGRoot of = non storing RPL network won't have the memory limitations of = LLNs.

 

But if we are using storing mode, what happen if my = downward routing table is full, and I receive a DAO from a new Node = ?

 

The first option I see is in the DAO-ACK, where the = Status field could indicate that the requested node cannot act as a DAO = Parent.

Then the DAO originator sends = out another DAO to its 2nd best parent, and so on until its DAO is = successfully acklowledged.

 

But then, = how could that node know when there will be some space for it in the = routing table of its best parent (Which should be the best route for = downward routing) ? Do it need to send periodic DAO to its best parent = ?

 

The second option I see is the use of the = "O" flag in nthe NSA metric object defined in the RPL routing = metric document.

This flag is used to = advertise an Overflow, without too much precision about the meaning. I = guess it is up to the implementor, which is flexible enough to handle = various cases. Using this flag, nodes could know that a node advertising = DIO with this flag set to 1 has no more space in its routing table and = so prune it from their possible DAO parent list (thus saving useless DAO = sendings).

 

The extreme case is : if I have no alternative DAO = parent or No parent has some space for me, What should I do = ??

 

Let expand this routing overflow issue to global = downward routing : If I select a DAO parent which has some space for me = in its routing table, what happen if my grand parent has not ? My grand = parent will reject the DAO of my parent. My parent will follow the = previous rules and try an alternative parent, but if it has no = alternative parent what happen ? How could I know that my DAO has not = been successfully delivered until the DAGroot (and so that I won't be = reachable from the Root)? If I know it, I may be able to select an = alternative DAO parent that could successfully registered my path until = the DAGroot.

 

Of course one simple hypothesis could cope with these = memory issues : Having a routing table size for each RPL router >=3D = Total Number of  Nodes in the RPL network. But I guess this narrow = the scalability to the most memory-limited router in the = network…

 

I would = enjoy to know what people do with these routing overflow, and have some = guidelines about the RPL behaviour.

 

Best,

C=E9dric.

------_=_NextPart_001_01CC9968.3BCFF495-- From prvs=2807ed889=Tzeta.Tsao@cooperindustries.com Wed Nov 2 13:22:34 2011 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 A621411E8193 for ; Wed, 2 Nov 2011 13:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, 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 bCI0X5e+oLHy for ; Wed, 2 Nov 2011 13:22:19 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8A05E11E8192 for ; Wed, 2 Nov 2011 13:22:17 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.69,445,1315195200"; d="scan'208,217";a="30663876" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 02 Nov 2011 16:22:16 -0400 Received: from EVS2.NAM.CI.ROOT ([10.132.108.170]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 16:22:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC999D.18915565" Date: Wed, 2 Nov 2011 16:22:07 -0400 Message-ID: In-Reply-To: <4E9F2EE0.4050200@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] notes re AMiKeydraft(draft-alexander-roll-amikey-lln-key-mgmt-02) Thread-Index: AcyOm1K/Ry57WSzxQ+airJBHct5RsQLACCww References: <4E975CA0.4010104@gmail.com> <4E983D47.1020601@gmail.com> <4E9F2EE0.4050200@gmail.com> From: "Tsao, Tzeta" To: "Rene Struik" , "Alexander, Roger" , X-OriginalArrivalTime: 02 Nov 2011 20:22:15.0943 (UTC) FILETIME=[1CD35970:01CC999D] Subject: Re: [Roll] notes re AMiKeydraft(draft-alexander-roll-amikey-lln-key-mgmt-02) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 20:22:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC999D.18915565 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rene, WG, =20 We are updating the AMIKEY draft to include a description on how AMIKEY may be used with RPL. As we are not able to attend IETF82, but would like very much to hear feedback from this WG, I have appended the text in the following. Your comment is most welcome. =20 Thanks, Tzeta =20 ------------------------------------------------------------------------ --------------- Key Assignment for the RPL Join Process =20 The process of a node joining a secured RPL instance is described in Sec. 10.2 of the RPL specification. Where the DODAG operates in "authenticated mode", as indicated by the "A" bit being set in the DODAG Configuration option of the DIO messages, a joining node is required to access a key server to obtain the current key for securing RPL messages. AMIKEY is intended to support the requirements of the key management protocol that allows RPL nodes to be able to obtain (and receive) the dynamic DODAG security key (see Sec. 3.2.3 of the RPL specification). For AMIKEY, the security of the key management protocol exchanges between the nodes and the key server may be based on a pre-shared key (PSK), public key (PKE) or Diffie-Hellman (DH) method as described in the AMIKEY draft, Sec. 3. =20 Fig. 1 illustrates how AMIKEY may be employed to obtain the DODAG security key. The figure depicts how the joining node uses AMIKEY to request the DODAG key when a pre-shared key is used for securing the key management exchange with the key server. =20 =20 Joining Node RPL Router Key Server | | | | 1. RPL: Secure DIS (KI=3D0) | | |----------------------------->| | | | | | 2. RPL: Secure DIO (KI=3D0,"A"bit set) | |<-----------------------------| | | | | | | | 3. AMIKEY: Q_MESSAGE (HDR, T, IDq, V) | |---------------------------------------------------------->| | 4. AMIKEY: I_MESSAGE (HDR, T, RAND, IDi, {SP}, KEMAC) | |<----------------------------------------------------------| | | | | 5. RPL: Secure DIS (KI=3Dn) | |----------------------------->| =20 | | =20 | 6. RPL: Secure DIO (KI=3Dn) | =20 |<-----------------------------| =20 | | =20 Fig. 1: Key Assignment with AMIKEY in the RPL Join Process =20 1. A joining node broadcasts a RPL Secure DIS message to request DIO information for joining the DODAG. The DIS message is secured using the pre-installed key (see RPL, Sec. 3.2.3). The secure DIS message security header includes the Key Index, KI=3D0, that references the pre-installed key used to secure the message. =20 2. An existing DODAG RPL node responds with a secure DIO message that is similarly secured with the pre-installed key, even where that key differs from the DODAG RPL security key being used by nodes that have joined the DODAG (see RPL, Sec. 10.2). This initial DIS/DIO exchange allows the joining node to operate as a leaf node and forward data traffic into the network without being part of the secure routing exchange.=20 =20 3. Based on the A-bit being set within the Secure DIO message, the joining node uses its leaf node network access to initiate the key request to the key server to request the current DODAG security key; the joining node does this by sending an AMIKEY key request (Q_MESSAGE) to the key server (see AMIKEY, Sec. 3). In the example in Fig. 1 the Q_MESSAGE is secured based on the pre-shared key maintained between the joining node and the key server. The verification field (V) authenticates the message sent by the requesting node (see AMIKEY, Sec. 4.2.4). =20 4. The key server responds to the request by assigning the current DODAG key within the I_MESSAGE (see AMIKEY, Sec. 3.1). Like the Q_MESSAGE, the I_MESSAGE is secured based on the pre-shared key maintained between the joining node and the key server. The T field included in the I_MESSAGE is the same as that sent by the key requesting node in the Q_MESSAGE. This field in the form of a timestamp or counter allows for replay protection (and timeliness verification if network-wide time is supported in the DODAG). The KEMAC information element includes the DODAG key material assigned by the key server encrypted using the pre-shared key maintained between the joining node and the key server. =20 5. The assigned DODAG key (given by Key Index=3Dn in the message = security header) is used to secure the subsequent secure DIS message. =20 6. Once the secure DIS message is authenticated by the receiver a secure DIO message (with KI=3Dn) is returned. That message provides current = DODAG routing information and allows the joining node to be a full RPL participant of the secure DODAG.=20 =20 The particular information elements of the AMIKEY Q_MESSAGE include: =20 HDR Header (common AMIKEY header) T Timestamp/counter IDq ID of the requestor (joining node) V Message verification =20 The particular information elements of the AMIKEY I_MESSAGE include: =20 HDR Header T Timestamp/counter RAND a (pseudo-)random bit-string used for generating the DODAG security key (using AMIKEY, the RPL DODAG key is generated from the key assigned by the key server) IDi ID of the assignment initiator (key server) =20 SP Security Policy that defines the policy information of the secure RPL protocol for which the key assignment is being made KEMAC Key data transport payload that includes the assigned key generating key from which the RPL DODAG security key is derived =20 =20 Note: In conjunction with RPL, AMIKEY can also be applied to support proactive key assignment/update by the key server using an I_MESSAGE and R_MESSAGE exchange as discussed in AMIKEY, Section 3. =20 =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Rene Struik Sent: Wednesday, October 19, 2011 4:11 PM To: Alexander, Roger Cc: roll@ietf.org Subject: Re: [Roll] notes re AMiKeydraft(draft-alexander-roll-amikey-lln-key-mgmt-02) =20 Hi Roger: Thanks for your feedback. What would really help here is to showcase a specific instantiation of AMIKey that exemplifies how it can address the key management aspects that have been labelled out of scope with rpl-19. This could then also serve as taking away [resp. identifying] thoughts that interoperability may be sacrificed once one wishes to switch on security. Another benefit of this exercise is that it maeks the AMIKey draft somewhat more concrete for the ROLL WG membership. (It has been written more abstractly than just to serve rpl, which is great, but may also deter some of the audience.) I can imagine this exercise to assume device counters, rather than a notion of time (since, with rpl, this was argued to be "unrealistic" at the time [around June 2010], but perhaps this needs revisiting]). This would allow identifying whether this indeed addresses key management aspects that were out of scope with rpl so far. All - it would be invaluable to have some insight as to whether implementations based on rpl-19 actually use its security provisions and gain some insight into problems/bottlenecks/interop issues, and the-like. So far, not too much information on this has been brought to the foreground, but it would be invaluable to have some. So, please do not be shy and share your experiences and perspectives here. Best regards, Rene On 14/10/2011 4:13 PM, Alexander, Roger wrote:=20 Hi Rene, =20 Thank you very much for the detailed review and comments. Please see responses below. =20 AMIKEY is of course a separate key management application intended to provide the out-of-band key management specification called for to support RPL 'Authenticated' mode security (see RPL, Section 3.2.3). It is thus intended to support the long-term updating/re-keying of the group key used to provide routing security among RPL peers.=20 =20 Thanks again. =20 Best regards, =20 Roger =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Rene Struik Sent: Friday, October 14, 2011 9:47 AM To: roll@ietf.org Subject: [Roll] notes re AMiKey draft(draft-alexander-roll-amikey-lln-key-mgmt-02) =20 [resend] -------- Original Message --------=20 Subject:=20 notes re AMiKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02) Date:=20 Thu, 13 Oct 2011 17:48:16 -0400 From:=20 Rene Struik =20 To:=20 Alexander, Roger , Tsao, Tzeta =20 CC:=20 roll@ietf.org =20 Dear Roger, Tzeta: =20 Please find below some notes on your AMIKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02). =20 I made the assumption that cryptographic protection is based on a nonce-based cryptographic mode of operation and that replay protection would be provided (thus, necessitating each receiving device to keep some nonce state on sending devices).=20 >>[RA] Correct. MIKEY does discuss the state information required (see Section 5.4). The required state maintenance is of course simplified where system-wide time is available though a Counter can also be used and is part of the specification. Note that in the specific case of RPL key management, state information is required only between the RPL node and the key server entity. =20 =20 While AMIKey could have applications that would not require a nonce-based mechanism and replay protection, this seems a fair assumption (and holds for RoLL-based cryptographic protection). >>[RA] Agreed. =20 As suggested previously, some of my notes have more to do with MIKey (RFC 3830), so it seems, than with AMIKey. However, some have to do with implicit assumptions on what basic functionality devices have on board. >>[RA] Understood but useful to clarify since it is the base for AMIKEY. =20 Please feel free to discuss. =20 Best regards, Rene =20 =3D=3D =20 1) Notion of time Some of the MIKey constructs (e.g., CSB Id, Section 1.4) suggest that one assumes devices have a notion of time, e.g., to be used to detect replays/duplicates, and correlate messages with the corresponding acknowledgement. With RoLL, this notion of time is not a given. Moreover, this begs the question as to what to do if time notions between devices are out-of-synch. Does the MIKey specification cater to this? >>[RA] Yes for MIKEY there is a notion of system time but an optional Counter is also defined. The NTP-based Timestamp is mandatory for MIKEY (See Section 4.2.8 and 6.6 of RFC 3830). For AMIKEY however, the Counter is to be made mandatory, while Timestamp is optional (consistent with RPL).=20 See Section 5.4 of RFC3830 for a good discussion of the issue regarding the tradeoff of state maintenance (replay cache) versus degree of time synchronization to be maintained.=20 =20 Additional note: -Section 5.2, first para: this seems to suggest a mandatory timestamp. >>[RA] This should read "Timestamp [payload]" where as specified in RFC3830 the Timestamp payload can be a Timestamp or Counter value. =20 Not sure what the granularity is with MIKey (important, since not to be reused) and how this time stamp would be managed. >>[RA] The granularity as given for NTP (32-bit fractional second). Devices would increment to their degree of supported system time synchronization. =20 -Section 6.14, 2nd para: here, key validity periods are specified (KV), thus requiring a sufficiently accurate shared notion of time (for, if not, any time check may be unreliable or futile). >>[RA] Only applicable where system time is supported. The validity period can be defined by an Interval (Valid From and Valid To) that can be referenced to the Timestamp of the key assignment message. The granularity in the triggering of key updates will depend on the system time accuracy supported. =20 =20 =20 2) Key dependencies It seems that MIKey defines a deterministic mapping between key encryption keys (TGK) and session keys (TEK). As a result, inadvertent key exposure of the TGK key will expose all derived keys as well. This may be undesirable, e.g., if TGK is shared amongst many devices and one of those devices gets compromised. If session keys would be generated at random and transported over a secure per-device-pair channel instead, the impact of compromise of a single node seems more limited. Moreover, it seems to be preferable to have a logical separation between keys (e.g., in the event of ownership transfer of a single node or replacement of a malfunctioning single node). >>[RA] Yes there is a deterministic mapping between the TEK generating key (TGK) and the TEK. However, the use of a TGK to derive multiple TEKs only applies where required for simultaneous assignment or update of related keys, as applicable for example in the multimedia domain for voice video, etc. For RPL the RPL routing group key (TEK) would be the only key derived from the assigned TGK.=20 =20 =20 Additional note: -From Section 2 (AMIKey overview, para below Fig. 2) it is unclear whether the TEK is used directly as cryptographic key with, e.g., RoLL, or whether one derives additional keying material from this. -Section 6.16 (Key Index payload): this may benefit from some more explanation. >>[RA] The TEK is the security key that will be assigned (derived from the TGK) by the RPL Key Server for use in securing the routing exchanges between the RPL peers. Some further clarifications can be made to ensure that this is better understood. As in other sections, the intent will be to use RPL-specific examples throughout while maintaining the protocol's more general application.=20 =20 =20 3) Key identification With RoLL, the pair (key source identifier, key index) indicates both the originator of the key ("key source id") and an index ("key index") of keys issued by this key originator. This does not necessarily imply, though, that keys are correlated, as is suggested in Section 1.4. (It seems that KeySourceId identifies a TGK, while KeyIndex identifies a parameter so as to allow computation of TEK=3Df(TGK,#)). If this interpretation is correct, this leads to key dependencies that may be undesirable, e.g., in the event of key compromise. >>[RA] As part of the 'Authenticated' mode operation, RPL-19, Section 10.1, RPL uses a shared group key assigned by a network Key Server (where pre-shared keys or public keys may be used to secure the key management communications with the key server). The Key Index associated with the assigned RPL group key allows RPL nodes to ensure synchronization to a common shared key. RPL's group key can be changed by the key server at any time and nodes can request the current key when out of sync with a routing peer (that is, when having a lower Key index key). The Key Source ID would refer to the RPL key server entity, again to ensure synchronization among RPL routing peers as to the entity from which the group key was obtained. Since the security of RPL routing exchanges is based on the shared group key it is vulnerable to compromise of a single group member and hence the need for key updates. With a single TGK/TEK assigned there is no difference in the level of vulnerability between the single assigned group TGK or the derived group TEK. =20 =20 =20 4) Challenge response protocol I am somewhat concerned about some of the message flows with MIKey (e.g., Section 3, 3rd para, Fig. 3), since a key request could arise, e.g., if a key or nonce are "out-of-synch" (which, for keys, mens that one does not have the proper key; for nonces, that one has lost this value). With MIKey PSK flows, this would result (in the context of RPL) that one cannot adequately secure the first message Q_MESSAGE, thereby aborting the protocol. Simply put, what does one do if keys are lost or if nonces are out of synch?=20 >>[RA] Keep in mind that the key being requested, the RPL group key that the node may have determined to be out of synch with its routing peers is different from the key being used to secure and authenticate the RPL node client (Q) to the key server (I). If the node is using a PSK for authenticating exchanges to the key server and that key is out of synch, the device needs to be re-provisioned/reconfigured (with Error indication of inability to access key server, for ex.). =20 =20 Moreover, the message flows do not seem to provide for timeliness (in other words: how does entity I know that the request by entity R is "fresh")? >>[RA] Timeliness is supported only where the time-based Timestamp is used. In the case of Q_MESSAGE the Timestamp payload is included in the message set according to the time of origination of the message. When the message is received at the server (I), it can be accepted provided it is within the allowable time window when (including allowance for degree to system time synchronization). In the returned I_MESSAGE the same Timestamp value is included which again must be received at Q within an allowable roundtrip time window (again subject to allowances for degree of system time synchronization).=20 =20 =20 In out-of-synch scenarios, it seems better to employ a proper challenge/response protocol (unilateral entity authentication), where the key requestor sends a random challenge to the key assignment initiator and where the response messsage includes a protected version of the requested key and incorporates this random value. This results in implicit key authentication (only the requestor can recover the key [assuming both entities have a shared key]) and provides logical binding between message flows without dependency on nonces. >>[RA] The Q_MESSAGE is indeed protected and so the Requestor's Timestamp value provides the equivalent of the random value. The logical binding is therefore supported in the defined mechanism. Let us discuss to ensure I fully understand the concern. =20 =20 NOTE RS: with RoLL, this may cause some trouble, since this suggests mixing of unsecured and secured traffic in the network (which, vaguely, seems to be forbidden using the "security mode"). Since with RoLL, the security mode and the security level seems to be unduly tied together, this may result in the security mode toggling between unsecured and secured once such a C/R protocol would get implemented. >>[RA] Keep in mind that the communications with the key server in RPL is distinct from the communications with routing peers. The key server using PSK or PKE methods with each node is able to assign the routing security group key. In the RPL 'Authenticated' mode a node has a key that only allows a leaf join (no routing). That leaf join then allows key management exchanges with the key server to obtain the current routing group key. Until that group key is obtained the node cannot operate as a routing peer. =20 =20 5) Timeliness/ logical binding in protocol flows It is not entirely clear how the MIKey protocol provides for logical binding between protocol flows. As already mentioned, this may be a problem with the protocol flows in Fig. 3 (key request), but also with subsequent detailed protocol flows (such as with Fig. 5, using the PSK method). >>[RA] See above discussion. =20 =20 Additional note: -Section 3.1, 2nd last para: doesn't this impact the resulting properties? >>[RA] This determines when a key assignment confirmation is required for a server-initiated key push. =20 =20 6) Public key usage: The MIKEY protocol seems to use the same public key both for signing and for encryption. It is unclear in abstracto whether this poses problems, but common practice is to separate public keys for different cryptographic purposes. If this practice is heeded to, this requires the use of two public keys per device (including management hereof). >>[RA] Noted. A recommendation that could be made for devices/networks that support additional processing resource capabilities. =20 =20 Additional note: -Section 3.2, forelast para: wouldn't this impact freshness and aliveness properties? >>[RA] Timeliness checks can be supported when the time-based Timestamp payload is used (see discussion above). =20 =20 -Section 3.2 vs. 3.3: What is the rationale for making public key encryption (3.2) mandatory and Diffie-Hellman key exchange (3.3) optional? To me, it seems that use of public key techniques may significantly simplify configuration management (since this now depends on juggling publicly available information, rather than handling of secret keying material). Of those techniques, DH-based protocols seem to be best suited for highly constrained networks, where energy cost and implementation footprint come at a premium. Moreover, these may also be more resistant to side channel attacks (not trivial, esp. for devices that can be expected to be low-cost, consumer-style devices that may not be able to rely on tamper-evidencing techniques). This suggests that public-key based techniques, rather than symmetric-key based techniques (with proper eye for detail, of course) should be mandatory to implement. >>[RA] I think it would be more consistent with RPL to make PSK mandatory and both PKE and DH methods optional. This comment was also made by another reviewer. The intent of AMIKEY is to provide a reasonable lowest-common denominator with the ability to ratchet up the security level based on application environment. =20 =20 7) Hash function The suggested "hash function" (Section 4.1.2 - use of CMAC) may be somewhat unfortunate, since it is invertible if one has access to the key (in contrast to HMAC-SHAx, which is one-way, or block-cipher based hashes, such as AES-MMO, as ZigBee SE1.x used). This may have implications in the event of key compromise. >>[RA] Agreed. A trade-off made to permit lowest common denominator (all AES implementation) devices. SHAx of course remains an option that is available for devices/networks that can support the additional capability. =20 =20 8) Key management fit [as already noted by others] Overarching question may be whether key management functionality best fits with RoLL, CoRE, etc. Of course, this a perennial question. Nevertheless, some of the functionality described seems to suggest layer violation (e.g., Section 6.1.2, Table 6.1.e), since RoLL may not know about application layers, etc. >>[RA] As described in the Section 2, the key management entity logically exists independent of the device protocol layers. The KM entity can thus select the particular protocol for which key management is being performed. As previously discussed, the objective is to be able to handle key management for one or more layers with a single protocol given the constraints of a LLN-type device.=20 =20 =20 9) Other notes -Section 4: RFC 4493 corresponds to NIST SP 800-38B. >>[RA] Noted. =20 =20 -Section 4.1.2: not sure what the AES-CMAC alignment remark is about. BTW - this seems to suggest one can mix usage of CMAC with that of CCM with the same key (cf. also Section 6.2 (Table 6.2.b) and the last para of Section 6.2). In my opinion, this may be highly dangerous. As case in point, with the development of 802.15.4-2003, the same mixing was suggested (CBC-MAC, CTR, CCM) and shown to lead to an unsecure scheme (I can send you my presentation at the time [Nov 2002]). >>[RA] I think this was just loose wording intended to convey replacement. CCM can be mandated. I would still be interested in your reference paper.=20 =20 =20 -Section 4.2.4: CCM mode of operation uses a nonce, rather than IV. With RoLL, this is a 13-byte entry, rather than a 16-byte entry. Moreover, the structure of the nonce matters, since it is aimed at preventing nonce reuse by a single sender/amongst different senders sharing the same key. >>[RA] Understood. The intent was to re-use the "IV" information element given in RFC 3830 as a Nonce. Since that "IV" included the Timestamp (time-based or Counter from the originator) it was guaranteed to be non-repeating. This should be cleaned up to avoid potential confusion. =20 =20 =20 -Section 6.1, bullet #CS (8 bits): shouldn't this entry enumerate, rather than provide a number. >>[RA] No this should be a number. This number will match the number of subsequent occurrences of "CS ID map info" elements in the message. =20 -Section 6.7, 3rd para: the IEEE MAC address is a 64-bit entry (rather than a 48-bit address). Not sure how the reference to RFC 4291 comes into play here. >>[RA] The idea is to allow use of the 48-bit MAC as an ID as well as the IEEE EUI 64-bit MAC where it can be derived from the IP address of packet carrying the key exchange message (the IPv6 address being auto-configured from the MAC address in conformance with RFC4291). =20 =20 -Section 6.10.2: Table 6.10.2c suggests the use of AES-CBC-MAC-x. Why not use CCM instead (it provides various combinations of encryption and authentication, including authentication-only). >>[RA] Yes CCM can be mandated. =20 =20 --=20 email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 =20 =20 --=20 email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 ------_=_NextPart_001_01CC999D.18915565 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rene, WG,

 

We are updating the AMIKEY draft to include a description on how = AMIKEY may be used with RPL. As we are not able to attend IETF82, but = would like very much to hear feedback from this WG, I have appended the = text in the following.  Your comment is most = welcome.

 

Thanks,

Tzeta

 

----------------------------------------------------------------------= -----------------

Key Assignment for the RPL Join = Process

 

The process of a node joining a secured RPL = instance is described in Sec. 10.2 of the RPL specification. Where the = DODAG operates in "authenticated mode", as indicated by the = "A" bit being set in the DODAG Configuration option of the DIO = messages, a joining node is required to access a key server to obtain = the current key for securing RPL messages. AMIKEY is intended to support = the requirements of the key management protocol that allows RPL nodes to = be able to obtain (and receive) the dynamic DODAG security key (see Sec. = 3.2.3 of the RPL specification). For AMIKEY, the security of the key = management protocol exchanges between the nodes and the key server may = be based on a pre-shared key (PSK), public key (PKE) or Diffie-Hellman = (DH) method as described in the AMIKEY draft, Sec. = 3.

 

Fig. 1 illustrates how AMIKEY may be employed to = obtain the DODAG security key. The figure depicts how the joining node = uses AMIKEY to request the DODAG key when a pre-shared key is used for = securing the key management exchange with the key = server.

 

 

Joining = Node           &nb= sp;         RPL = Router           &= nbsp;      Key Server

      = |            =             &= nbsp;     = |            =             &= nbsp;   |

      |   1. = RPL: Secure DIS (KI=3D0)  = |            =             &= nbsp;   |

      = |----------------------------->|      &n= bsp;        =             &= nbsp;|

      = |            =             &= nbsp;     = |            =             &= nbsp;   |

      |   2. = RPL: Secure DIO (KI=3D0,"A"bit = set)           &nb= sp;        |

      = |<-----------------------------|      &n= bsp;           &nb= sp;         = |

      = |            =             &= nbsp;     = |            =             &= nbsp;   |

      = |            =             &= nbsp;           &n= bsp;           &nb= sp;          = |

      |   3. = AMIKEY: Q_MESSAGE (HDR, T, IDq, = V)            = ;       = |            =             &= nbsp;

      |-------------= --------------------------------------------->|

<= p class=3DMsoNormal style=3D'text-autospace:none'>      |   4. = AMIKEY: I_MESSAGE (HDR, T, RAND, IDi, {SP}, KEMAC)   = |

      = |<----------------------------------------------------------|

      = |            =             &= nbsp;           &n= bsp;           &nb= sp;          = |

      = |

      |   5. = RPL: Secure DIS (KI=3Dn)  |

      = |----------------------------->|      &n= bsp;

      |  &= nbsp;           &n= bsp;           &nb= sp;   |       =

      |   = 6. RPL: Secure DIO (KI=3Dn)  |      =

      |<---------= --------------------|      =

      |  &= nbsp;           &n= bsp;           &nb= sp;   |

 

       Fig. 1: Key = Assignment with AMIKEY in the RPL Join Process

 

1. = A joining node broadcasts a RPL Secure DIS message to request DIO = information for joining the DODAG. The DIS message is secured using the = pre-installed key (see RPL, Sec. 3.2.3). The secure DIS message security = header includes the Key Index, KI=3D0, that references the pre-installed = key used to secure the message.

 

2. = An existing DODAG RPL node responds with a secure DIO message that is = similarly secured with the pre-installed key, even where that key = differs from the DODAG RPL security key being used by nodes that have = joined the DODAG (see RPL, Sec. 10.2). This initial DIS/DIO exchange = allows the joining node to operate as a leaf node and forward data = traffic into the network without being part of the secure routing = exchange.

 

3. = Based on the A-bit being set within the Secure DIO message, the joining = node uses its leaf node network access to initiate the key request to = the key server to request the current DODAG security key; the joining = node does this by sending an AMIKEY key request (Q_MESSAGE) to the key = server (see AMIKEY, Sec. 3). In the example in Fig. 1 the Q_MESSAGE is = secured based on the pre-shared key maintained between the joining node = and the key server. The verification field (V) authenticates the message = sent by the requesting node (see AMIKEY, Sec. = 4.2.4).

 

4. = The key server responds to the request by assigning the current DODAG = key within the I_MESSAGE (see AMIKEY, Sec. 3.1). Like the Q_MESSAGE, the = I_MESSAGE is secured based on the pre-shared key maintained between the = joining node and the key server. The T field included in the I_MESSAGE = is the same as that sent by the key requesting node in the Q_MESSAGE. = This field in the form of a timestamp or counter allows for replay = protection (and timeliness verification if network-wide time is = supported in the DODAG). The KEMAC information element includes the = DODAG key material assigned by the key server encrypted using the = pre-shared key maintained between the joining node and the key = server.

 

5. = The assigned DODAG key (given by Key Index=3Dn in the message security = header) is used to secure the subsequent secure DIS = message.

 

6. = Once the secure DIS message is authenticated by the receiver a secure = DIO message (with KI=3Dn) is returned. That message provides current = DODAG routing information and allows the joining node to be a full RPL = participant of the secure DODAG.

 

=

The particular information elements of the AMIKEY = Q_MESSAGE include:

 

   HDR     Header = (common AMIKEY header)

   = T       = Timestamp/counter

   IDq     ID of = the requestor (joining node)

   = V       Message = verification

 

The particular information elements of the AMIKEY = I_MESSAGE include:

 

   HDR     = Header

   = T       = Timestamp/counter

   RAND    a = (pseudo-)random bit-string used for generating the DODAG security key = (using AMIKEY, the RPL DODAG key is generated from the key assigned by = the key server)

   IDi     ID of = the assignment initiator (key server) 

   SP     = Security Policy that defines the policy information of the secure RPL = protocol for which the key assignment is being = made

   KEMAC   Key data transport = payload that includes the assigned key generating key from which the RPL = DODAG security key is derived

 

 

Note: In conjunction with RPL, AMIKEY can also be = applied to support proactive key assignment/update by the key server = using an I_MESSAGE and R_MESSAGE exchange as discussed in AMIKEY, = Section 3.  

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Rene Struik
Sent: Wednesday, October 19, 2011 4:11 = PM
To: Alexander, Roger
Cc: = roll@ietf.org
Subject: Re: [Roll] notes re = AMiKeydraft(draft-alexander-roll-amikey-lln-key-mgmt-02)

 

Hi Roger:

Thanks for your feedback.

What = would really help here is to showcase a specific instantiation of AMIKey = that exemplifies how it can address the key management aspects that have = been labelled out of scope with rpl-19. This could then also serve as = taking away [resp. identifying] thoughts that interoperability may be = sacrificed once one wishes to switch on security.

Another benefit = of this exercise is that it maeks the AMIKey draft somewhat more = concrete for the ROLL WG membership. (It has been written more = abstractly than just to serve rpl, which is great, but may also deter = some of the audience.)

I can imagine this exercise to assume = device counters, rather than a notion of time (since, with rpl, this was = argued to be "unrealistic" at the time [around June 2010], but = perhaps this needs revisiting]). This would allow identifying whether = this indeed addresses key management aspects that were out of scope with = rpl so far.

All - it would be invaluable to have some insight as = to whether implementations based on rpl-19 actually use its security = provisions and gain some insight into problems/bottlenecks/interop = issues, and the-like. So far, not too much information on this has been = brought to the foreground, but it would be invaluable to have = some.
So, please do not be shy and share your experiences and = perspectives here.

Best regards,

Rene



On = 14/10/2011 4:13 PM, Alexander, Roger wrote:

Hi Rene,

 

Thank = you very much for the detailed review and comments. Please see responses = below.

 

AMIKEY is of course a separate key management = application intended to provide the out-of-band key management = specification called for to support RPL ‘Authenticated’ mode = security (see RPL, Section 3.2.3). It is thus intended to support the = long-term updating/re-keying of the group key used to provide routing = security among RPL peers.

 

Thanks = again.

 

Best regards,

 

Roger

 

 

From: roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] = On Behalf Of Rene Struik
Sent: Friday, October 14, 2011 = 9:47 AM
To: roll@ietf.org
Subject: = [Roll] notes re AMiKey = draft(draft-alexander-roll-amikey-lln-key-mgmt-02)

<= /div>

 

[resend]

-------- Original Message -------- =

<= /table>

 

Dear Roger, =
Tzeta:
 
Please find =
below some notes on your AMIKey =
draft
(draft-alexander-roll-amikey-lln-key-mgmt-02).=

 
I made the assumption =
that cryptographic protection is based on =
a
nonce-based cryptographic mode of operation and =
that replay protection
would be provided (thus, =
necessitating each receiving device to keep
some =
nonce state on sending devices).

>>[RA] Correct. MIKEY does discuss the state = information required (see Section 5.4). The required state maintenance = is of course simplified where system-wide time is available though a = Counter can also be used and is part of the specification. Note that in = the specific case of RPL key management, state information is required = only between the RPL node and the key server = entity.

 
 
While AMIKey could =
have
applications that would not require a =
nonce-based mechanism and replay
protection, this =
seems a fair assumption (and holds for =
RoLL-based
cryptographic =
protection).

>>[RA] = Agreed.

 
As suggested =
previously, some of my notes have more to do with =
MIKey
(RFC 3830), so it seems, than with AMIKey. =
However, some have to do with
implicit assumptions =
on what basic functionality devices have on board.

>>[RA] Understood but useful to clarify since = it is the base for = AMIKEY.

 
Please feel free =
to discuss.
 
Best =
regards, =
Rene
 
=3D=3D
 
1) Notion of =
time
Some of the MIKey constructs (e.g., CSB Id, =
Section 1.4) suggest that
one assumes devices have =
a notion of time, e.g., to be used to =
detect
replays/duplicates, and correlate messages =
with the corresponding
acknowledgement. With RoLL, =
this notion of time is not a given.
Moreover, this =
begs the question as to what to do if time =
notions
between devices are out-of-synch. Does the =
MIKey specification cater =
to
this?
>>[RA] Yes for MIKEY there is a notion of =
system time but an optional Counter is also defined. The NTP-based =
Timestamp is mandatory for MIKEY (See Section 4.2.8 and 6.6 of RFC =
3830). For AMIKEY however, the Counter is to be made mandatory, while =
Timestamp is optional (consistent with RPL). 
See Section 5.4 of RFC3830 for a good discussion of =
the issue regarding the tradeoff of state maintenance (replay cache) =
versus degree of time synchronization to be maintained. =

 
Additional =
note:
-Section 5.2, first para: this seems to =
suggest a mandatory timestamp.
>>[RA] This should read "Timestamp =
[payload]" where as specified in RFC3830 the Timestamp payload can =
be a Timestamp or Counter value.
 
Not sure what the granularity is =
with MIKey (important, since not to be
reused) and =
how this time stamp would be managed.
>>[RA] The granularity as given for NTP =
(32-bit fractional second). Devices would increment to their degree of =
supported system time synchronization.
 
-Section 6.14, 2nd para: here, key =
validity periods are specified (KV),
thus requiring =
a sufficiently accurate shared notion of time (for, =
if
not, any time check may be unreliable or =
futile).
>>[RA] Only =
applicable where system time is supported. The validity period can be =
defined by an Interval (Valid From and Valid To) that can be referenced =
to the Timestamp of the key assignment message. The granularity in the =
triggering of key updates will depend on the system time accuracy =
supported.    
 
 
2) Key =
dependencies
It seems that MIKey defines a =
deterministic mapping between key
encryption keys =
(TGK) and session keys (TEK). As a result, =
inadvertent
key exposure of the TGK key will expose =
all derived keys as well. This
may be undesirable, =
e.g., if TGK is shared amongst many devices and =
one
of those devices gets compromised. If session =
keys would be generated at
random and transported =
over a secure per-device-pair channel instead,
the =
impact of compromise of a single node seems more limited. =
Moreover,
it seems to be preferable to have a =
logical separation between keys
(e.g., in the event =
of ownership transfer of a single node =
or
replacement of a malfunctioning single =
node).
>>[RA] Yes there is =
a deterministic mapping between the TEK generating key (TGK) and the =
TEK. However, the use of a TGK to derive multiple TEKs only applies =
where required for simultaneous assignment or update of related keys, as =
applicable for example in the multimedia domain for voice video, etc. =
For RPL the RPL routing group key (TEK) would be the only key derived =
from the assigned TGK. 
 
 
Additio=
nal note:
-From Section 2 (AMIKey overview, para =
below Fig. 2) it is unclear
whether the TEK is used =
directly as cryptographic key with, e.g., RoLL,
or =
whether one derives additional keying material from =
this.
-Section 6.16 (Key Index payload): this may =
benefit from some =
more
explanation.
>>[RA] The TEK is the security key that will =
be assigned (derived from the TGK) by the RPL Key Server for use in =
securing the routing exchanges between the RPL peers. Some further =
clarifications can be made to ensure that this is better understood. As =
in other sections, the intent will be to use RPL-specific examples =
throughout while maintaining the protocol’s more general =
application. 
 
 
3) Key =
identification
With RoLL, the pair (key source =
identifier, key index) indicates both
the =
originator of the key ("key source id") and an index =
("key index")
of keys issued by this key =
originator. This does not necessarily =
imply,
though, that keys are correlated, as is =
suggested in Section 1.4. (It
seems that =
KeySourceId identifies a TGK, while KeyIndex identifies =
a
parameter so as to allow computation of =
TEK=3Df(TGK,#)). If this
interpretation is correct, =
this leads to key dependencies that may =
be
undesirable, e.g., in the event of key =
compromise.
>>[RA] As part =
of the 'Authenticated' mode operation, RPL-19, Section 10.1, RPL uses a =
shared group key assigned by a network Key Server (where pre-shared keys =
or public keys may be used to secure the key management communications =
with the key server). The Key Index associated with the assigned RPL =
group key allows RPL nodes to ensure synchronization to a common shared =
key. RPL's group key can be changed by the key server at any time and =
nodes can request the current key when out of sync with a routing peer =
(that is, when having a lower Key index key). The Key Source ID would =
refer to the RPL key server entity, again to ensure synchronization =
among RPL routing peers as to the entity from which the group key was =
obtained. Since the security of RPL routing exchanges is based on the =
shared group key it is vulnerable to compromise of a single group member =
and hence the need for key updates. With a single TGK/TEK assigned there =
is no difference in the level of vulnerability between the single =
assigned group TGK or the derived group TEK.  =

 
 
4) Challenge response =
protocol
I am somewhat concerned about some of the =
message flows with MIKey
(e.g., Section 3, 3rd =
para, Fig. 3), since a key request could =
arise,
e.g., if a key or nonce are =
"out-of-synch" (which, for keys, mens =
that
one does not have the proper key; for nonces, =
that one has lost this
value). With MIKey PSK =
flows, this would result (in the context of =
RPL)
that one cannot adequately secure the first =
message Q_MESSAGE, thereby
aborting the protocol. =
Simply put, what does one do if keys are lost or
if =
nonces are out of synch? 
>>[RA] Keep in mind that the key being =
requested, the RPL group key that the node may have determined to be out =
of synch with its routing peers is different from the key being used to =
secure and authenticate the RPL node client (Q) to the key server (I). =
If the node is using a PSK for authenticating exchanges to the key =
server and that key is out of synch, the device needs to be =
re-provisioned/reconfigured (with Error indication of inability to =
access key server, for ex.).
 
 
Moreover, the message =
flows do not seem to provide for timeliness (in other words: how does =
entity I know that the request by entity R is =
"fresh")?
>>[RA] =
Timeliness is supported only where the time-based Timestamp is used. In =
the case of Q_MESSAGE the Timestamp payload is included in the message =
set according to the time of origination of the message. When the =
message is received at the server (I), it can be accepted provided it is =
within the allowable time window when (including allowance for degree to =
system time synchronization). In the returned I_MESSAGE the same =
Timestamp value is included which again must be received at Q within an =
allowable roundtrip time window (again subject to allowances for degree =
of system time synchronization). 
 
 
In out-of-synch scenarios, it =
seems better to employ a proper
challenge/response =
protocol (unilateral entity authentication), =
where
the key requestor sends a random challenge to =
the key assignment
initiator and where the response =
messsage includes a protected version
of the =
requested key and incorporates this random value. This results =
in
implicit key authentication (only the requestor =
can recover the key
[assuming both entities have a =
shared key]) and provides logical binding
between =
message flows without dependency on nonces.
>>[RA] The Q_MESSAGE is indeed protected and =
so the Requestor's Timestamp value provides the equivalent of the random =
value. The logical binding is therefore supported in the defined =
mechanism. Let us discuss to ensure I fully understand the =
concern.
 
 
NOTE RS: with RoLL, this may cause =
some trouble, since this suggests
mixing of =
unsecured and secured traffic in the network (which, =
vaguely,
seems to be forbidden using the =
"security mode"). Since with RoLL, =
the
security mode and the security level seems to =
be unduly tied together,
this may result in the =
security mode toggling between unsecured =
and
secured once such a C/R protocol would get =
implemented.
>>[RA] Keep in =
mind that the communications with the key server in RPL is distinct from =
the communications with routing peers. The key server using PSK or PKE =
methods with each node is able to assign the routing security group key. =
In the RPL 'Authenticated' mode a node has a key that only allows a leaf =
join (no routing). That leaf join then allows key management exchanges =
with the key server to obtain the current routing group key. Until that =
group key is obtained the node cannot operate as a routing =
peer.
 
 
5) Timeliness/ logical binding in =
protocol flows
It is not entirely clear how the =
MIKey protocol provides for logical
binding between =
protocol flows. As already mentioned, this may be =
a
problem with the protocol flows in Fig. 3 (key =
request), but also with
subsequent detailed =
protocol flows (such as with Fig. 5, using the =
PSK
method).
>>[RA] See above =
discussion.
 
 
Additio=
nal note:
-Section 3.1, 2nd last para: doesn't this =
impact the resulting properties?
>>[RA] This determines when a key assignment =
confirmation is required for a server-initiated key =
push.
 
 
6) Public key =
usage:
The MIKEY protocol seems to use the same =
public key both for signing and
for encryption. It =
is unclear in abstracto whether this poses =
problems,
but common practice is to separate public =
keys for different
cryptographic purposes. If this =
practice is heeded to, this requires the
use of two =
public keys per device (including management hereof).
>>[RA] Noted. A recommendation that could be =
made for devices/networks that support additional processing resource =
capabilities.
 
 
Additional =
note:
-Section 3.2, forelast para: wouldn't this =
impact freshness and
aliveness =
properties?
>>[RA] =
Timeliness checks can be supported when the time-based Timestamp payload =
is used (see discussion above).
 
 
-Section 3.2 vs. 3.3: What is the =
rationale for making public key
encryption (3.2) =
mandatory and Diffie-Hellman key exchange =
(3.3)
optional? To me, it seems that use of public =
key techniques may
significantly simplify =
configuration management (since this now depends
on =
juggling publicly available information, rather than handling =
of
secret keying material). Of those techniques, =
DH-based protocols seem to
be best suited for =
highly constrained networks, where energy cost =
and
implementation footprint come at a premium. =
Moreover, these may also be
more resistant to side =
channel attacks (not trivial, esp. for devices
that =
can be expected to be low-cost, consumer-style devices that may =
not
be able to rely on tamper-evidencing =
techniques). This suggests that
public-key based =
techniques, rather than symmetric-key based =
techniques
(with proper eye for detail, of course) =
should be mandatory to implement.
>>[RA] I think it would be more consistent =
with RPL to make PSK mandatory and both PKE and DH methods optional. =
This comment was also made by another reviewer. The intent of AMIKEY is =
to provide a reasonable lowest-common denominator with the ability to =
ratchet up the security level based on application =
environment.
 
 
7) Hash =
function
The suggested "hash function" =
(Section 4.1.2 - use of CMAC) may be
somewhat =
unfortunate, since it is invertible if one has access to =
the
key (in contrast to HMAC-SHAx, which is =
one-way, or block-cipher based
hashes, such as =
AES-MMO, as ZigBee SE1.x used). This may =
have
implications in the event of key =
compromise.
>>[RA] Agreed. =
A trade-off made to permit lowest common denominator (all AES =
implementation) devices. SHAx of course remains an option that is =
available for devices/networks that can support the additional =
capability.
 
 
8) Key =
management fit
[as already noted by others] =
Overarching question may be whether key
management =
functionality best fits with RoLL, CoRE, etc. Of course, =
this
a perennial question. Nevertheless, some of =
the functionality described
seems to suggest layer =
violation (e.g., Section 6.1.2, Table 6.1.e),
since =
RoLL may not know about application layers, etc.
>>[RA] As described in the Section 2, the key =
management entity logically exists independent of the device protocol =
layers. The KM entity can thus select the particular protocol for which =
key management is being performed. As previously discussed, the =
objective is to be able to handle key management for one or more layers =
with a single protocol given the constraints of a LLN-type device. =

 
 
9) Other =
notes
-Section 4: RFC 4493 corresponds to NIST SP =
800-38B.
>>[RA] =
Noted.
 
 
-Section =
4.1.2: not sure what the AES-CMAC alignment remark is =
about.
BTW - this seems to suggest one can mix =
usage of CMAC with that of CCM
with the same key =
(cf. also Section 6.2 (Table 6.2.b) and the last =
para
of Section 6.2). In my opinion, this may be =
highly dangerous. As case in
point, with the =
development of 802.15.4-2003, the same mixing =
was
suggested (CBC-MAC, CTR, CCM) and shown to lead =
to an unsecure scheme (I
can send you my =
presentation at the time [Nov 2002]).
>>[RA] I think this was just loose wording =
intended to convey replacement. CCM can be mandated. I would still be =
interested in your reference paper. 
 
 
-Section 4.2.4: CCM mode of =
operation uses a nonce, rather than IV. With
RoLL, =
this is a 13-byte entry, rather than a 16-byte entry. =
Moreover,
the structure of the nonce matters, since =
it is aimed at preventing
nonce reuse by a single =
sender/amongst different senders sharing the
same =
key.
>>[RA] Understood. =
The intent was to re-use the "IV" information element given in =
RFC 3830 as a Nonce. Since that "IV" included the Timestamp =
(time-based or Counter from the originator) it was guaranteed to be =
non-repeating. This should be cleaned up to avoid potential =
confusion.  
 
 
-Section 6.1, bullet #CS (8 bits): =
shouldn't this entry enumerate,
rather than provide =
a number.
>>[RA] No this =
should be a number. This number will match the number of subsequent =
occurrences of "CS ID map info" elements in the =
message.
 
-Section 6.7, 3rd para: the IEEE =
MAC address is a 64-bit entry (rather
than a 48-bit =
address). Not sure how the reference to RFC 4291 =
comes
into play here.
>>[RA] The idea is to allow use of the 48-bit =
MAC as an ID as well as the IEEE EUI 64-bit MAC where it can be derived =
from the IP address of packet carrying the key exchange message (the =
IPv6 address being auto-configured from the MAC address in conformance =
with RFC4291).
 
 
-Section 6.10.2: Table 6.10.2c =
suggests the use of AES-CBC-MAC-x. Why
not use CCM =
instead (it provides various combinations of encryption =
and
authentication, including =
authentication-only).
>>[RA] Yes CCM can be =
mandated.
 
 
-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) =
867-5658
USA Google voice: +1 (415) =
690-7363
 
 



-- =

email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) =
867-5658
USA Google voice: +1 (415) =
690-7363

------_=_NextPart_001_01CC999D.18915565--

From jari.arkko@piuha.net  Tue Nov  8 04:10:13 2011
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 01E8221F8C6E; Tue,  8 Nov 2011 04:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 S5nukf8c7ULc; Tue,  8 Nov 2011 04:10:12 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D2D7821F8B66; Tue,  8 Nov 2011 04:10:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2F7E52CCE0; Tue,  8 Nov 2011 14:10:06 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBBDjaYvJSEC; Tue,  8 Nov 2011 14:10:05 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9AB792CC61; Tue,  8 Nov 2011 14:10:05 +0200 (EET)
Message-ID: <4EB91C1D.5000606@piuha.net>
Date: Tue, 08 Nov 2011 14:10:05 +0200
From: Jari Arkko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: core , 6lowpan@ietf.org, roll@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Hannes Tschofenig 
Subject: [Roll] informal hacking & interop session on Sunday
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Nov 2011 12:10:13 -0000

In the last IETF we organized an informal session to demonstrate & test various smart object related implementations. We are now doing this again for the Taipei IETF. We will meet at 19:00-22:00 on Sunday, November 13th, (room TBD). If you are attending the IETF and have your Internet of Things toys with you (be it 6lowpan, coap, rpl, or anything else) feel free to join. Maybe you'll find someone to test with, or at least get to see other people with interesting implementations.

Jari


From prvs=287ce053d=Roger.Alexander@cooperindustries.com  Wed Nov  9 15:20:54 2011
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 166F811E809C for ; Wed,  9 Nov 2011 15:20:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.068
X-Spam-Level: 
X-Spam-Status: No, score=-5.068 tagged_above=-999 required=5 tests=[AWL=-1.529, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_51=0.6, 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 0ZBo+b7HCUm1 for ; Wed,  9 Nov 2011 15:20:36 -0800 (PST)
Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id 102C711E809A for ; Wed,  9 Nov 2011 15:20:33 -0800 (PST)
Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.69,485,1315195200"; d="scan'208,217";a="31490209"
Received: from cipt0175.nam.ci.root ([10.132.108.175]) by cooperlighting-sw.cooperlighting.com with ESMTP; 09 Nov 2011 18:20:32 -0500
Received: from EVS2.NAM.CI.ROOT ([10.132.108.170]) by cipt0175.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 9 Nov 2011 18:20:32 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9F36.2379AD21"
Date: Wed, 9 Nov 2011 18:20:14 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] notes re AMiKeydraft(draft-alexander-roll-amikey-lln-key-mgmt-02)
Thread-Index: AcyOm1K/Ry57WSzxQ+airJBHct5RsQLACCwwAWL7XXA=
References: <4E975CA0.4010104@gmail.com> <4E983D47.1020601@gmail.com> <4E9F2EE0.4050200@gmail.com> 
From: "Alexander, Roger" 
To: "Tsao, Tzeta" , "Rene Struik" , 
X-OriginalArrivalTime: 09 Nov 2011 23:20:32.0085 (UTC) FILETIME=[2D1D5850:01CC9F36]
Subject: Re: [Roll] notes re AMiKeydraft(draft-alexander-roll-amikey-lln-key-mgmt-02)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Nov 2011 23:20:55 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC9F36.2379AD21
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Rene, WG,

=20

As a further follow-up, the following text provides an overview of the
use of AMIKEY for DODAG key update during the operation of a secured RPL
network.

=20

Comments are welcome.

=20

Thanks,

=20

Roger

=20

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

Key Update for RPL Authenticated Mode

=20

The RPL security key for a DODAG operating in authenticated mode may be
updated one or more times during the lifetime of the DODAG. With AMIKEY,
such updates are initiated by the key server and pushed to individual
RPL nodes.=20

=20

Fig. 2 illustrates how AMIKEY is employed for the key update. The
scenario assumes a pre-shared key (PSK) for securing the key management
exchange between the RPL nodes and the key server. Public key encryption
(PKE) or Diffie-Hellman (DH) methods may also be used as described in
the AMIKEY draft, Section 3.=20

=20

=20

RPL Node i                   RPL Node j                      Key Server

    |                            |                                 |

    | 1. Secure DIO              |                                 |

    |    (KI=3Dn, "A"bit set)      |                                 |

    |--------------------------->|                                 |

    |                            |                                 |

    | 2. Secure DAO (KI=3Dn)       |                                 |

    |<---------------------------|                                 |

    |                            |                                 |

    | 3. Secure DAO ACK (KI=3Dn)   |                                 |

    |--------------------------->|                                 |

    ~                            ~                                 |

    ~                            ~                                 |

    |                                                              |

    |      4a. AMIKEY: I_MESSAGE (HDR,T,RAND,IDi,{SP},KEMAC)       |

    =
|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|

    |                                                              |

    |      5a. AMIKEY: R_MESSAGE (HDR,T,IDr V)                     |

    =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|

    |                                                              |

    |                            | 4b. AMIKEY: I_MESSAGE           |

    |                            |     (HDR,T,RAND,IDi,{SP},KEMAC) |

    |                            =
|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D|

    |                            |     5b. AMIKEY: R_MESSAGE       |

    |                            |         (HDR,T,IDr V)           |

    |                            =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D>|

    ~                            ~

    ~                            ~

    |                            |

    | 6. Secure DIO              |

    |    (KI=3Dn+1,"A"bit set)     |

    |--------------------------->|       =20

    |                            |

    | 7. Secure DAO (KI=3Dn+1)     |     =20

    |<---------------------------|     =20

    |                            |

    | 8. Secure DAO ACK (KI=3Dn+1) |

    |--------------------------->|       =20

    |                            |      =20

=20

        Fig. 2: Key Update during RPL Operation Using AMIKEY

=20

=20

1. An operating RPL node (Node i) transmits a Secure DIO message
providing information on its DODAG routing connectivity. The DIO message
is secured using the current DODAG security key indicated by the
inclusion of the Key Index, KI=3Dn, within the message security header.

=20

2. In response to the DIO message the RPL routing peer (Node j) sends a
Secure DAO message to establish/maintain its routing connectivity. The
DAO message is secured with the current DODAG security key indicated by
the inclusion of KI=3Dn within the message security header.=20

=20

3. The RPL node receiving the DAO message may acknowledge receipt of the
message by sending a Secure DAO ACK message, also secured by the current
DODAG key.

=20

4. The key server can choose at any time to update the current DODAG key
by making a new key assignment to each network node. The new key is
encrypted within the KEMAC information element of the I_MESSAGE (see
AMIKEY, Sec. 3.1). In this example the I_MESSAGE is secured based on the
pre-shared key maintained between each node and the key server. The T
field included in the I_MESSAGE, in the form of a timestamp or counter
allows for replay protection (and timeliness verification if
network-wide time is supported).

=20

5. The key assignment is acknowledged by the receiving node through the
sending of the R_MESSAGE (see AMIKEY, Sec. 3). The requirement for the
sending of the=20

R_MESSAGE is specified through the setting of the V-bit flag in the
I_MESSAGE Header (HDR). For replay protection and timeliness
verification on the part of the key server, the T field included in the
R_MESSAGE, is copied and repeated from the I_MESSAGE. The verification
field (V) authenticates the message sent by the responding node using
the node-key server pre-shared secret.

=20

6. The updated DODAG key, indicated by the Key Index=3Dn+1 in the =
message
security header, is used to secure the subsequent transmitted Secure DIO
messages.

=20

7. Following the key update the Secure DAO messages also use the newly
assigned key (indicated by KI=3Dn+1 in the message security header).=20

=20

8. Any Secure DAO ACK messages are similarly protected using the newly
assigned key.

=20

The particular information elements of the AMIKEY I_MESSAGE include:

=20

   HDR     Header

   T       Timestamp/counter

   RAND    a (pseudo-)random bit-string used for generating the DODAG
security key (using AMIKEY, the RPL DODAG key is generated from the key
assigned by the key server).

   IDi     ID of the assignment initiator (key server) =20

   SP      Security Policy that defines the policy information of the
secure RPL protocol for which the key assignment is being made

   KEMAC   Key data transport payload that includes the assigned key
generating key from which the RPL DODAG security key is derived

=20

The particular information elements of the AMIKEY R_MESSAGE include:

=20

   HDR     Header (common AMIKEY header)

   T       Timestamp/counter

   IDr     ID of the responder (RPL node)

   V       Message verification

=20

Note: In an ad hoc network there is the potential for nodes that have
received a DODAG key update to initiate routing exchanges with nodes
that have not yet received the update. This situation will be detected
by the mis-match between the node's maintained DODAG key index and that
of its corresponding peer. Where a received RPL message is secured by a
key different from that maintained by the recipient node it will not be
possible to verify the authenticity or validity of the message. To avoid
potential denial of service attacks from forged or purported Secure RPL
messages, a RPL node should silently discard such messages if it has not
received an updated key. One consequence is the potential for broken RPL
associations when the key update is not sufficiently synchronized across
the DODAG. A key activation time can be used to limit the potential for
such routing disruptions during the key update. The Key Activation time
in the form of a UTC clock time or future count can be specified through
the AMIKEY Key Validity information element (see MIKEY Key data
sub-payload, Section 6.13).=20

=20

A node recovering from reset and receiving Secure DIO messages with a
key index different from the one currently maintained can revert its
status to a non-routing (leaf) node. The node can then initiate an
AMIKEY key request to the key server to obtain the current DODAG key.

=20

From: Tsao, Tzeta=20
Sent: Wednesday, November 02, 2011 4:22 PM
To: Rene Struik; Alexander, Roger; roll@ietf.org
Cc: Adrian Farrel
Subject: RE: [Roll] notes re
AMiKeydraft(draft-alexander-roll-amikey-lln-key-mgmt-02)

=20

Hi Rene, WG,

=20

We are updating the AMIKEY draft to include a description on how AMIKEY
may be used with RPL. As we are not able to attend IETF82, but would
like very much to hear feedback from this WG, I have appended the text
in the following.  Your comment is most welcome.

=20

Thanks,

Tzeta

=20

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

Key Assignment for the RPL Join Process

=20

The process of a node joining a secured RPL instance is described in
Sec. 10.2 of the RPL specification. Where the DODAG operates in
"authenticated mode", as indicated by the "A" bit being set in the DODAG
Configuration option of the DIO messages, a joining node is required to
access a key server to obtain the current key for securing RPL messages.
AMIKEY is intended to support the requirements of the key management
protocol that allows RPL nodes to be able to obtain (and receive) the
dynamic DODAG security key (see Sec. 3.2.3 of the RPL specification).
For AMIKEY, the security of the key management protocol exchanges
between the nodes and the key server may be based on a pre-shared key
(PSK), public key (PKE) or Diffie-Hellman (DH) method as described in
the AMIKEY draft, Sec. 3.

=20

Fig. 1 illustrates how AMIKEY may be employed to obtain the DODAG
security key. The figure depicts how the joining node uses AMIKEY to
request the DODAG key when a pre-shared key is used for securing the key
management exchange with the key server.

=20

=20

Joining Node                     RPL Router                  Key Server

      |                              |                            |

      |   1. Secure DIS (KI=3D0)       |                            |

      |----------------------------->|                            |

      |                              |                            |

      |   2. Secure DIO (KI=3D0,"A"bit set)                         |

      |<-----------------------------|                            |

      |                              |                            |

      |                                                           |

      |   3. AMIKEY: Q_MESSAGE (HDR, T, IDq, V)                   |


      =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D>|

      |   4. AMIKEY: I_MESSAGE (HDR, T, RAND, IDi, {SP}, KEMAC)   |

      =
|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D|

      |                                                           |

      |

      |   5. Secure DIS (KI=3Dn)       |

      |----------------------------->|       =20

      |                              |      =20

      |   6. Secure DIO (KI=3Dn)       |     =20

      |<-----------------------------|     =20

      |                              |

=20

       Fig. 1: Key Assignment with AMIKEY in the RPL Join Process

=20

1. A joining node broadcasts a RPL Secure DIS message to request DIO
information for joining the DODAG. The DIS message is secured using the
pre-installed key (see RPL, Sec. 3.2.3). The secure DIS message security
header includes the Key Index, KI=3D0, that references the pre-installed
key used to secure the message.

=20

2. An existing DODAG RPL node responds with a secure DIO message that is
similarly secured with the pre-installed key, even where that key
differs from the DODAG RPL security key being used by nodes that have
joined the DODAG (see RPL, Sec. 10.2). This initial DIS/DIO exchange
allows the joining node to operate as a leaf node and forward data
traffic into the network without being part of the secure routing
exchange.=20

=20

3. Based on the A-bit being set within the Secure DIO message, the
joining node uses its leaf node network access to initiate the key
request to the key server to request the current DODAG security key; the
joining node does this by sending an AMIKEY key request (Q_MESSAGE) to
the key server (see AMIKEY, Sec. 3). In the example in Fig. 1 the
Q_MESSAGE is secured based on the pre-shared key maintained between the
joining node and the key server. The verification field (V)
authenticates the message sent by the requesting node (see AMIKEY, Sec.
4.2.4).

=20

4. The key server responds to the request by assigning the current DODAG
key within the I_MESSAGE (see AMIKEY, Sec. 3.1). Like the Q_MESSAGE, the
I_MESSAGE is secured based on the pre-shared key maintained between the
joining node and the key server. The T field included in the I_MESSAGE
is the same as that sent by the key requesting node in the Q_MESSAGE.
This field in the form of a timestamp or counter allows for replay
protection (and timeliness verification if network-wide time is
supported in the DODAG). The KEMAC information element includes the
DODAG key material assigned by the key server encrypted using the
pre-shared key maintained between the joining node and the key server.

=20

5. The assigned DODAG key (given by Key Index=3Dn in the message =
security
header) is used to secure the subsequent secure DIS message.

=20

6. Once the secure DIS message is authenticated by the receiver a secure
DIO message (with KI=3Dn) is returned. That message provides current =
DODAG
routing information and allows the joining node to be a full RPL
participant of the secure DODAG.=20

=20

=20

The particular information elements of the AMIKEY Q_MESSAGE include:

=20

   HDR     Header (common AMIKEY header)

   T       Timestamp/counter

   IDq     ID of the requestor (joining node)

   V       Message verification

=20

The particular information elements of the AMIKEY I_MESSAGE include:

=20

   HDR     Header

   T       Timestamp/counter

   RAND    a (pseudo-)random bit-string used for generating the DODAG
security key (using AMIKEY, the RPL DODAG key is generated from the key
assigned by the key server)

   IDi     ID of the assignment initiator (key server) =20

   SP      Security Policy that defines the policy information of the
secure RPL protocol for which the key assignment is being made

   KEMAC   Key data transport payload that includes the assigned key
generating key from which the RPL DODAG security key is derived

=20

=20

Note: In conjunction with RPL, AMIKEY can also be applied to support
proactive key assignment/update by the key server using an I_MESSAGE and
R_MESSAGE exchange as discussed in AMIKEY, Section 3.  =20

=20

=20

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Rene Struik
Sent: Wednesday, October 19, 2011 4:11 PM
To: Alexander, Roger
Cc: roll@ietf.org
Subject: Re: [Roll] notes re
AMiKeydraft(draft-alexander-roll-amikey-lln-key-mgmt-02)

=20

Hi Roger:

Thanks for your feedback.

What would really help here is to showcase a specific instantiation of
AMIKey that exemplifies how it can address the key management aspects
that have been labelled out of scope with rpl-19. This could then also
serve as taking away [resp. identifying] thoughts that interoperability
may be sacrificed once one wishes to switch on security.

Another benefit of this exercise is that it maeks the AMIKey draft
somewhat more concrete for the ROLL WG membership. (It has been written
more abstractly than just to serve rpl, which is great, but may also
deter some of the audience.)

I can imagine this exercise to assume device counters, rather than a
notion of time (since, with rpl, this was argued to be "unrealistic" at
the time [around June 2010], but perhaps this needs revisiting]). This
would allow identifying whether this indeed addresses key management
aspects that were out of scope with rpl so far.

All - it would be invaluable to have some insight as to whether
implementations based on rpl-19 actually use its security provisions and
gain some insight into problems/bottlenecks/interop issues, and
the-like. So far, not too much information on this has been brought to
the foreground, but it would be invaluable to have some.
So, please do not be shy and share your experiences and perspectives
here.

Best regards,

Rene



On 14/10/2011 4:13 PM, Alexander, Roger wrote:=20

Hi Rene,

=20

Thank you very much for the detailed review and comments. Please see
responses below.

=20

AMIKEY is of course a separate key management application intended to
provide the out-of-band key management specification called for to
support RPL 'Authenticated' mode security (see RPL, Section 3.2.3). It
is thus intended to support the long-term updating/re-keying of the
group key used to provide routing security among RPL peers.=20

=20

Thanks again.

=20

Best regards,

=20

Roger

=20

=20

From: roll-bounces@ietf.org 
[mailto:roll-bounces@ietf.org  ] On Behalf
Of Rene Struik
Sent: Friday, October 14, 2011 9:47 AM
To: roll@ietf.org =20
Subject: [Roll] notes re AMiKey
draft(draft-alexander-roll-amikey-lln-key-mgmt-02)

=20

[resend]

-------- Original Message --------=20

Subject:=20

notes re AMiKey draft (draft-alexander-roll-amikey-lln-key-mgmt-02)

Date:=20

Thu, 13 Oct 2011 17:48:16 -0400

From:=20

Rene Struik  =20

To:=20

Alexander, Roger 
 , Tsao, Tzeta

=20

CC:=20

roll@ietf.org =20

=20

Dear Roger, Tzeta:
=20
Please find below some notes on your AMIKey draft
(draft-alexander-roll-amikey-lln-key-mgmt-02).
=20
I made the assumption that cryptographic protection is based on a
nonce-based cryptographic mode of operation and that replay protection
would be provided (thus, necessitating each receiving device to keep
some nonce state on sending devices).=20

>>[RA] Correct. MIKEY does discuss the state information required (see
Section 5.4). The required state maintenance is of course simplified
where system-wide time is available though a Counter can also be used
and is part of the specification. Note that in the specific case of RPL
key management, state information is required only between the RPL node
and the key server entity.

=20
=20
While AMIKey could have
applications that would not require a nonce-based mechanism and replay
protection, this seems a fair assumption (and holds for RoLL-based
cryptographic protection).

>>[RA] Agreed.

=20
As suggested previously, some of my notes have more to do with MIKey
(RFC 3830), so it seems, than with AMIKey. However, some have to do with
implicit assumptions on what basic functionality devices have on board.

>>[RA] Understood but useful to clarify since it is the base for AMIKEY.

=20
Please feel free to discuss.
=20
Best regards, Rene
=20
=3D=3D
=20
1) Notion of time
Some of the MIKey constructs (e.g., CSB Id, Section 1.4) suggest that
one assumes devices have a notion of time, e.g., to be used to detect
replays/duplicates, and correlate messages with the corresponding
acknowledgement. With RoLL, this notion of time is not a given.
Moreover, this begs the question as to what to do if time notions
between devices are out-of-synch. Does the MIKey specification cater to
this?

>>[RA] Yes for MIKEY there is a notion of system time but an optional
Counter is also defined. The NTP-based Timestamp is mandatory for MIKEY
(See Section 4.2.8 and 6.6 of RFC 3830). For AMIKEY however, the Counter
is to be made mandatory, while Timestamp is optional (consistent with
RPL).=20

See Section 5.4 of RFC3830 for a good discussion of the issue regarding
the tradeoff of state maintenance (replay cache) versus degree of time
synchronization to be maintained.=20

=20
Additional note:
-Section 5.2, first para: this seems to suggest a mandatory timestamp.

>>[RA] This should read "Timestamp [payload]" where as specified in
RFC3830 the Timestamp payload can be a Timestamp or Counter value.

=20
Not sure what the granularity is with MIKey (important, since not to be
reused) and how this time stamp would be managed.

>>[RA] The granularity as given for NTP (32-bit fractional second).
Devices would increment to their degree of supported system time
synchronization.

=20
-Section 6.14, 2nd para: here, key validity periods are specified (KV),
thus requiring a sufficiently accurate shared notion of time (for, if
not, any time check may be unreliable or futile).

>>[RA] Only applicable where system time is supported. The validity
period can be defined by an Interval (Valid From and Valid To) that can
be referenced to the Timestamp of the key assignment message. The
granularity in the triggering of key updates will depend on the system
time accuracy supported.   =20

=20
=20
2) Key dependencies
It seems that MIKey defines a deterministic mapping between key
encryption keys (TGK) and session keys (TEK). As a result, inadvertent
key exposure of the TGK key will expose all derived keys as well. This
may be undesirable, e.g., if TGK is shared amongst many devices and one
of those devices gets compromised. If session keys would be generated at
random and transported over a secure per-device-pair channel instead,
the impact of compromise of a single node seems more limited. Moreover,
it seems to be preferable to have a logical separation between keys
(e.g., in the event of ownership transfer of a single node or
replacement of a malfunctioning single node).

>>[RA] Yes there is a deterministic mapping between the TEK generating
key (TGK) and the TEK. However, the use of a TGK to derive multiple TEKs
only applies where required for simultaneous assignment or update of
related keys, as applicable for example in the multimedia domain for
voice video, etc. For RPL the RPL routing group key (TEK) would be the
only key derived from the assigned TGK.=20

=20
=20
Additional note:
-From Section 2 (AMIKey overview, para below Fig. 2) it is unclear
whether the TEK is used directly as cryptographic key with, e.g., RoLL,
or whether one derives additional keying material from this.
-Section 6.16 (Key Index payload): this may benefit from some more
explanation.

>>[RA] The TEK is the security key that will be assigned (derived from
the TGK) by the RPL Key Server for use in securing the routing exchanges
between the RPL peers. Some further clarifications can be made to ensure
that this is better understood. As in other sections, the intent will be
to use RPL-specific examples throughout while maintaining the protocol's
more general application.=20

=20
=20
3) Key identification
With RoLL, the pair (key source identifier, key index) indicates both
the originator of the key ("key source id") and an index ("key index")
of keys issued by this key originator. This does not necessarily imply,
though, that keys are correlated, as is suggested in Section 1.4. (It
seems that KeySourceId identifies a TGK, while KeyIndex identifies a
parameter so as to allow computation of TEK=3Df(TGK,#)). If this
interpretation is correct, this leads to key dependencies that may be
undesirable, e.g., in the event of key compromise.

>>[RA] As part of the 'Authenticated' mode operation, RPL-19, Section
10.1, RPL uses a shared group key assigned by a network Key Server
(where pre-shared keys or public keys may be used to secure the key
management communications with the key server). The Key Index associated
with the assigned RPL group key allows RPL nodes to ensure
synchronization to a common shared key. RPL's group key can be changed
by the key server at any time and nodes can request the current key when
out of sync with a routing peer (that is, when having a lower Key index
key). The Key Source ID would refer to the RPL key server entity, again
to ensure synchronization among RPL routing peers as to the entity from
which the group key was obtained. Since the security of RPL routing
exchanges is based on the shared group key it is vulnerable to
compromise of a single group member and hence the need for key updates.
With a single TGK/TEK assigned there is no difference in the level of
vulnerability between the single assigned group TGK or the derived group
TEK. =20

=20
=20
4) Challenge response protocol
I am somewhat concerned about some of the message flows with MIKey
(e.g., Section 3, 3rd para, Fig. 3), since a key request could arise,
e.g., if a key or nonce are "out-of-synch" (which, for keys, mens that
one does not have the proper key; for nonces, that one has lost this
value). With MIKey PSK flows, this would result (in the context of RPL)
that one cannot adequately secure the first message Q_MESSAGE, thereby
aborting the protocol. Simply put, what does one do if keys are lost or
if nonces are out of synch?=20

>>[RA] Keep in mind that the key being requested, the RPL group key that
the node may have determined to be out of synch with its routing peers
is different from the key being used to secure and authenticate the RPL
node client (Q) to the key server (I). If the node is using a PSK for
authenticating exchanges to the key server and that key is out of synch,
the device needs to be re-provisioned/reconfigured (with Error
indication of inability to access key server, for ex.).

=20

=20

Moreover, the message flows do not seem to provide for timeliness (in
other words: how does entity I know that the request by entity R is
"fresh")?

>>[RA] Timeliness is supported only where the time-based Timestamp is
used. In the case of Q_MESSAGE the Timestamp payload is included in the
message set according to the time of origination of the message. When
the message is received at the server (I), it can be accepted provided
it is within the allowable time window when (including allowance for
degree to system time synchronization). In the returned I_MESSAGE the
same Timestamp value is included which again must be received at Q
within an allowable roundtrip time window (again subject to allowances
for degree of system time synchronization).=20

=20
=20
In out-of-synch scenarios, it seems better to employ a proper
challenge/response protocol (unilateral entity authentication), where
the key requestor sends a random challenge to the key assignment
initiator and where the response messsage includes a protected version
of the requested key and incorporates this random value. This results in
implicit key authentication (only the requestor can recover the key
[assuming both entities have a shared key]) and provides logical binding
between message flows without dependency on nonces.

>>[RA] The Q_MESSAGE is indeed protected and so the Requestor's
Timestamp value provides the equivalent of the random value. The logical
binding is therefore supported in the defined mechanism. Let us discuss
to ensure I fully understand the concern.

=20
=20
NOTE RS: with RoLL, this may cause some trouble, since this suggests
mixing of unsecured and secured traffic in the network (which, vaguely,
seems to be forbidden using the "security mode"). Since with RoLL, the
security mode and the security level seems to be unduly tied together,
this may result in the security mode toggling between unsecured and
secured once such a C/R protocol would get implemented.
>>[RA] Keep in mind that the communications with the key server in RPL
is distinct from the communications with routing peers. The key server
using PSK or PKE methods with each node is able to assign the routing
security group key. In the RPL 'Authenticated' mode a node has a key
that only allows a leaf join (no routing). That leaf join then allows
key management exchanges with the key server to obtain the current
routing group key. Until that group key is obtained the node cannot
operate as a routing peer.
=20
=20
5) Timeliness/ logical binding in protocol flows
It is not entirely clear how the MIKey protocol provides for logical
binding between protocol flows. As already mentioned, this may be a
problem with the protocol flows in Fig. 3 (key request), but also with
subsequent detailed protocol flows (such as with Fig. 5, using the PSK
method).

>>[RA] See above discussion.

=20
=20
Additional note:
-Section 3.1, 2nd last para: doesn't this impact the resulting
properties?

>>[RA] This determines when a key assignment confirmation is required
for a server-initiated key push.

=20
=20
6) Public key usage:
The MIKEY protocol seems to use the same public key both for signing and
for encryption. It is unclear in abstracto whether this poses problems,
but common practice is to separate public keys for different
cryptographic purposes. If this practice is heeded to, this requires the
use of two public keys per device (including management hereof).

>>[RA] Noted. A recommendation that could be made for devices/networks
that support additional processing resource capabilities.

=20
=20
Additional note:
-Section 3.2, forelast para: wouldn't this impact freshness and
aliveness properties?

>>[RA] Timeliness checks can be supported when the time-based Timestamp
payload is used (see discussion above).

=20
=20
-Section 3.2 vs. 3.3: What is the rationale for making public key
encryption (3.2) mandatory and Diffie-Hellman key exchange (3.3)
optional? To me, it seems that use of public key techniques may
significantly simplify configuration management (since this now depends
on juggling publicly available information, rather than handling of
secret keying material). Of those techniques, DH-based protocols seem to
be best suited for highly constrained networks, where energy cost and
implementation footprint come at a premium. Moreover, these may also be
more resistant to side channel attacks (not trivial, esp. for devices
that can be expected to be low-cost, consumer-style devices that may not
be able to rely on tamper-evidencing techniques). This suggests that
public-key based techniques, rather than symmetric-key based techniques
(with proper eye for detail, of course) should be mandatory to
implement.

>>[RA] I think it would be more consistent with RPL to make PSK
mandatory and both PKE and DH methods optional. This comment was also
made by another reviewer. The intent of AMIKEY is to provide a
reasonable lowest-common denominator with the ability to ratchet up the
security level based on application environment.

=20
=20
7) Hash function
The suggested "hash function" (Section 4.1.2 - use of CMAC) may be
somewhat unfortunate, since it is invertible if one has access to the
key (in contrast to HMAC-SHAx, which is one-way, or block-cipher based
hashes, such as AES-MMO, as ZigBee SE1.x used). This may have
implications in the event of key compromise.

>>[RA] Agreed. A trade-off made to permit lowest common denominator (all
AES implementation) devices. SHAx of course remains an option that is
available for devices/networks that can support the additional
capability.

=20
=20
8) Key management fit
[as already noted by others] Overarching question may be whether key
management functionality best fits with RoLL, CoRE, etc. Of course, this
a perennial question. Nevertheless, some of the functionality described
seems to suggest layer violation (e.g., Section 6.1.2, Table 6.1.e),
since RoLL may not know about application layers, etc.

>>[RA] As described in the Section 2, the key management entity
logically exists independent of the device protocol layers. The KM
entity can thus select the particular protocol for which key management
is being performed. As previously discussed, the objective is to be able
to handle key management for one or more layers with a single protocol
given the constraints of a LLN-type device.=20

=20
=20
9) Other notes
-Section 4: RFC 4493 corresponds to NIST SP 800-38B.

>>[RA] Noted.

=20
=20
-Section 4.1.2: not sure what the AES-CMAC alignment remark is about.
BTW - this seems to suggest one can mix usage of CMAC with that of CCM
with the same key (cf. also Section 6.2 (Table 6.2.b) and the last para
of Section 6.2). In my opinion, this may be highly dangerous. As case in
point, with the development of 802.15.4-2003, the same mixing was
suggested (CBC-MAC, CTR, CCM) and shown to lead to an unsecure scheme (I
can send you my presentation at the time [Nov 2002]).

>>[RA] I think this was just loose wording intended to convey
replacement. CCM can be mandated. I would still be interested in your
reference paper.=20

=20
=20
-Section 4.2.4: CCM mode of operation uses a nonce, rather than IV. With
RoLL, this is a 13-byte entry, rather than a 16-byte entry. Moreover,
the structure of the nonce matters, since it is aimed at preventing
nonce reuse by a single sender/amongst different senders sharing the
same key.

>>[RA] Understood. The intent was to re-use the "IV" information element
given in RFC 3830 as a Nonce. Since that "IV" included the Timestamp
(time-based or Counter from the originator) it was guaranteed to be
non-repeating. This should be cleaned up to avoid potential confusion. =20

=20

=20
-Section 6.1, bullet #CS (8 bits): shouldn't this entry enumerate,
rather than provide a number.

>>[RA] No this should be a number. This number will match the number of
subsequent occurrences of "CS ID map info" elements in the message.

=20
-Section 6.7, 3rd para: the IEEE MAC address is a 64-bit entry (rather
than a 48-bit address). Not sure how the reference to RFC 4291 comes
into play here.

>>[RA] The idea is to allow use of the 48-bit MAC as an ID as well as
the IEEE EUI 64-bit MAC where it can be derived from the IP address of
packet carrying the key exchange message (the IPv6 address being
auto-configured from the MAC address in conformance with RFC4291).

=20
=20
-Section 6.10.2: Table 6.10.2c suggests the use of AES-CBC-MAC-x. Why
not use CCM instead (it provides various combinations of encryption and
authentication, including authentication-only).

>>[RA] Yes CCM can be mandated.

=20
=20
--=20
email: rstruik.ext@gmail.com =20
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
=20
=20





--=20
email: rstruik.ext@gmail.com =20
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

------_=_NextPart_001_01CC9F36.2379AD21
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Rene, WG,
 
As a further follow-up, the following text provides an overview of =
the use of AMIKEY for DODAG key update during the operation of a secured =
RPL network.
 
Comments are welcome.
 
Thanks,
 
Roger
 
-------------------------------------------------------------------=
--------------------
Key Update for RPL Authenticated =
Mode
 
The RPL security key for a DODAG operating in =
authenticated mode may be updated one or more times during the lifetime =
of the DODAG. With AMIKEY, such updates are initiated by the key server =
and pushed to individual RPL nodes. 
 
Fig. 2 illustrates how AMIKEY is employed for the =
key update. The scenario assumes a pre-shared key (PSK) for securing the =
key management exchange between the RPL nodes and the key server. Public =
key encryption (PKE) or Diffie-Hellman (DH) methods may also be used as =
described in the AMIKEY draft, Section 3. 
 
 
RPL Node =
i            =
       RPL Node =
j            =
          Key =
Server
    =
|            =
   =
            &=
nbsp;|           &=
nbsp;           &n=
bsp;         =
|
    | 1. Secure =
DIO           &nbs=
p;  =
|            =
            &=
nbsp;        =
|
    |    (KI=3Dn, =
"A"bit set)    =
  |          =
            &=
nbsp;          =
|
    =
|--------------------------->|      &nbs=
p;            =
;            =
  |
    =
|            =
            &=
nbsp;   =
|            =
            &=
nbsp;        =
|
    | 2. Secure DAO =
(KI=3Dn)       =
|            =
            &=
nbsp;        =
|
    =
|<---------------------------|      &nbs=
p;            =
;            =
  |
    =
|            =
            &=
nbsp;   =
|            =
   =
            &=
nbsp;     |
    | 3. Secure DAO ACK =
(KI=3Dn)   =
|            =
            &=
nbsp;        =
|
    =
|--------------------------->|      &nbs=
p;            =
;            =
  |
    =
~            =
            &=
nbsp;   =
~            =
            &=
nbsp;        =
|
    =
~            =
            =
    ~        =
            &=
nbsp;            =
|
    =
|            =
            &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p; |
    =
|      4a. AMIKEY: I_MESSAGE =
(HDR,T,RAND,IDi,{SP},KEMAC)       =
|
    =
|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|
    |    =
            &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;         |
    =
|      5a. AMIKEY: R_MESSAGE (HDR,T,IDr =
V)            =
;         =
|
    =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
    =
|            =
            &=
nbsp;           &n=
bsp;           &nb=
sp;    =
         |=

    =
|            =
            &=
nbsp;   | 4b. AMIKEY: =
I_MESSAGE           =
|
    =
|            =
            &=
nbsp;   |     (HDR,T,RAND,IDi,{SP},KEMAC) =
|
    =
|            =
            &=
nbsp;   =
|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D|
    =
|            =
            &=
nbsp;   |     5b. AMIKEY: =
R_MESSAGE       |
    =
|            =
            &=
nbsp;   |         =
(HDR,T,IDr =
V)           =
|
    =
|            =
            &=
nbsp;   =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D>|
    =
~            =
            &=
nbsp;   ~
    =
~         =
            &=
nbsp;      ~
    =
|            =
            &=
nbsp;   |
    | 6. Secure =
DIO           &nbs=
p;  |
    |    =
(KI=3Dn+1,"A"bit set)     =
|
    =
|--------------------------->|      &nbs=
p; 
    |    &=
nbsp;           &n=
bsp;           =
|
    | 7. Secure DAO =
(KI=3Dn+1)     |      =

    |<---------------------=
------|      
    |    &=
nbsp;           &n=
bsp;           =
|
    | 8. Secure DAO ACK (KI=3Dn+1) =
|
    =
|--------------------------->|      &nbs=
p; 
    |    &=
nbsp;           &n=
bsp;           =
|       
 
        Fig. =
2: Key Update during RPL Operation Using AMIKEY
 
 
1. An operating RPL node (Node i) transmits a =
Secure DIO message providing information on its DODAG routing =
connectivity. The DIO message is secured using the current DODAG =
security key indicated by the inclusion of the Key Index, KI=3Dn, within =
the message security header.
 
2. In response to the DIO message the RPL routing =
peer (Node j) sends a Secure DAO message to establish/maintain its =
routing connectivity. The DAO message is secured with the current DODAG =
security key indicated by the inclusion of KI=3Dn within the message =
security header. 
 
3. The RPL node receiving the DAO message may =
acknowledge receipt of the message by sending a Secure DAO ACK message, =
also secured by the current DODAG key.
 
4. The key server can choose at any time to =
update the current DODAG key by making a new key assignment to each =
network node. The new key is encrypted within the KEMAC information =
element of the I_MESSAGE (see AMIKEY, Sec. 3.1). In this example the =
I_MESSAGE is secured based on the pre-shared key maintained between each =
node and the key server. The T field included in the I_MESSAGE, in the =
form of a timestamp or counter allows for replay protection (and =
timeliness verification if network-wide time is =
supported).
 
5. The key assignment is acknowledged by the =
receiving node through the sending of the R_MESSAGE (see AMIKEY, Sec. =
3). The requirement for the sending of the 
R_MESSAGE is specified through the setting of the =
V-bit flag in the I_MESSAGE Header (HDR). For replay protection and =
timeliness verification on the part of the key server, the T field =
included in the R_MESSAGE, is copied and repeated from the I_MESSAGE. =
The verification field (V) authenticates the message sent by the =
responding node using the node-key server pre-shared =
secret.
 
6. The updated DODAG key, indicated by the Key =
Index=3Dn+1 in the message security header, is used to secure the =
subsequent transmitted Secure DIO messages.
 
7. Following the key update the Secure DAO =
messages also use the newly assigned key (indicated by KI=3Dn+1 in the =
message security header). 
 
8. Any Secure DAO ACK messages are similarly =
protected using the newly assigned key.
 
The particular information elements of the AMIKEY =
I_MESSAGE include:
 
   HDR     =
Header
   =
T       =
Timestamp/counter
   RAND    a =
(pseudo-)random bit-string used for generating the DODAG security key =
(using AMIKEY, the RPL DODAG key is generated from the key assigned by =
the key server).
   IDi     ID of =
the assignment initiator (key server)  
   SP     =
 Security Policy that defines the policy information of the secure RPL =
protocol for which the key assignment is being =
made
   KEMAC   Key data transport =
payload that includes the assigned key generating key from which the RPL =
DODAG security key is derived
 
The particular information elements of the AMIKEY =
R_MESSAGE include:
 
   HDR     Header =
(common AMIKEY header)
   =
T       =
Timestamp/counter
   IDr     ID of =
the responder (RPL node)
   =
V       Message =
verification
 
Note: In an ad hoc network there is the potential =
for nodes that have received a DODAG key update to initiate routing =
exchanges with nodes that have not yet received the update. This =
situation will be detected by the mis-match between the node's =
maintained DODAG key index and that of its corresponding peer. Where a =
received RPL message is secured by a key different from that maintained =
by the recipient node it will not be possible to verify the authenticity =
or validity of the message. To avoid potential denial of service attacks =
from forged or purported Secure RPL messages, a RPL node should silently =
discard such messages if it has not received an updated key. One =
consequence is the potential for broken RPL associations when the key =
update is not sufficiently synchronized across the DODAG. A key =
activation time can be used to limit the potential for such routing =
disruptions during the key update. The Key Activation time in the form =
of a UTC clock time or future count can be specified through the AMIKEY =
Key Validity information element (see MIKEY Key data sub-payload, =
Section 6.13). 
 
A node recovering from reset and receiving Secure =
DIO messages with a key index different from the one currently =
maintained can revert its status to a non-routing (leaf) node. The node =
can then initiate an AMIKEY key request to the key server to obtain the =
current DODAG key.
 
From: Tsao, Tzeta 
Sent: Wednesday, November 02, 2011 4:22 =
PM
To: Rene Struik; Alexander, Roger; =
roll@ietf.org
Cc: Adrian Farrel
Subject: RE: [Roll] =
notes re =
AMiKeydraft(draft-alexander-roll-amikey-lln-key-mgmt-02)
 
Hi Rene, WG,
 
We are updating the AMIKEY draft to include a description on how =
AMIKEY may be used with RPL. As we are not able to attend IETF82, but =
would like very much to hear feedback from this WG, I have appended the =
text in the following.  Your comment is most =
welcome.
 
Thanks,
Tzeta
 
-------------------------------------------------------------------=
--------------------
Key Assignment for the RPL Join =
Process
 
The process of a node joining a secured RPL =
instance is described in Sec. 10.2 of the RPL specification. Where the =
DODAG operates in "authenticated mode", as indicated by the =
"A" bit being set in the DODAG Configuration option of the DIO =
messages, a joining node is required to access a key server to obtain =
the current key for securing RPL messages. AMIKEY is intended to support =
the requirements of the key management protocol that allows RPL nodes to =
be able to obtain (and receive) the dynamic DODAG security key (see Sec. =
3.2.3 of the RPL specification). For AMIKEY, the security of the key =
management protocol exchanges between the nodes and the key server may =
be based on a pre-shared key (PSK), public key (PKE) or Diffie-Hellman =
(DH) method as described in the AMIKEY draft, Sec. =
3.
 
Fig. 1 illustrates how AMIKEY may be employed to =
obtain the DODAG security key. The figure depicts how the joining node =
uses AMIKEY to request the DODAG key when a pre-shared key is used for =
securing the key management exchange with the key =
server.
 
 
Joining =
Node           &nb=
sp;         RPL =
Router           &=
nbsp;      Key Server
      =
|            =
            &=
nbsp;     =
|            =
            &=
nbsp;   |
      |   1. =
Secure DIS (KI=3D0)      =
 |           =
            &=
nbsp;    |
      =
|----------------------------->|      &n=
bsp;        =
            &=
nbsp;|
      =
|            =
            &=
nbsp;     =
|            =
            &=
nbsp;   |
      |   2. =
Secure DIO (KI=3D0,"A"bit =
set)       =
            &=
nbsp;     |
      =
|<-----------------------------|      &n=
bsp;           &nb=
sp;         =
|
      =
|            =
            &=
nbsp;     =
|            =
            &=
nbsp;   |
      =
|            =
            &=
nbsp;           &n=
bsp;           &nb=
sp;          =
|
      |   3. =
AMIKEY: Q_MESSAGE (HDR, T, IDq, =
V)            =
;       =
|            =
            &=
nbsp; 
      |=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D>|
      |   4. =
AMIKEY: I_MESSAGE (HDR, T, RAND, IDi, {SP}, KEMAC)   =
|
      =
|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|
      =
|            =
            &=
nbsp;           &n=
bsp;           &nb=
sp;          =
|
      =
|
      |   5. =
Secure DIS (KI=3Dn)       =
|
      =
|----------------------------->|      &n=
bsp; 
      |  &=
nbsp;           &n=
bsp;           &nb=
sp;   |       =

      |   =
6. Secure DIO (KI=3Dn)      =
 |      
      |<---------=
--------------------|      =

      |  &=
nbsp;           &n=
bsp;           &nb=
sp;   |
 
       Fig. 1: Key =
Assignment with AMIKEY in the RPL Join Process
 
1. =
A joining node broadcasts a RPL Secure DIS message to request DIO =
information for joining the DODAG. The DIS message is secured using the =
pre-installed key (see RPL, Sec. 3.2.3). The secure DIS message security =
header includes the Key Index, KI=3D0, that references the pre-installed =
key used to secure the message.
 
2. =
An existing DODAG RPL node responds with a secure DIO message that is =
similarly secured with the pre-installed key, even where that key =
differs from the DODAG RPL security key being used by nodes that have =
joined the DODAG (see RPL, Sec. 10.2). This initial DIS/DIO exchange =
allows the joining node to operate as a leaf node and forward data =
traffic into the network without being part of the secure routing =
exchange. 
 
3. =
Based on the A-bit being set within the Secure DIO message, the joining =
node uses its leaf node network access to initiate the key request to =
the key server to request the current DODAG security key; the joining =
node does this by sending an AMIKEY key request (Q_MESSAGE) to the key =
server (see AMIKEY, Sec. 3). In the example in Fig. 1 the Q_MESSAGE is =
secured based on the pre-shared key maintained between the joining node =
and the key server. The verification field (V) authenticates the message =
sent by the requesting node (see AMIKEY, Sec. =
4.2.4).
 
4. =
The key server responds to the request by assigning the current DODAG =
key within the I_MESSAGE (see AMIKEY, Sec. 3.1). Like the Q_MESSAGE, the =
I_MESSAGE is secured based on the pre-shared key maintained between the =
joining node and the key server. The T field included in the I_MESSAGE =
is the same as that sent by the key requesting node in the Q_MESSAGE. =
This field in the form of a timestamp or counter allows for replay =
protection (and timeliness verification if network-wide time is =
supported in the DODAG). The KEMAC information element includes the =
DODAG key material assigned by the key server encrypted using the =
pre-shared key maintained between the joining node and the key =
server.
 
5. =
The assigned DODAG key (given by Key Index=3Dn in the message security =
header) is used to secure the subsequent secure DIS =
message.
 
6. =
Once the secure DIS message is authenticated by the receiver a secure =
DIO message (with KI=3Dn) is returned. That message provides current =
DODAG routing information and allows the joining node to be a full RPL =
participant of the secure DODAG. 
 
 
The particular information elements of the AMIKEY =
Q_MESSAGE include:
 
   HDR     Header =
(common AMIKEY header)
   =
T       =
Timestamp/counter
   IDq     ID of =
the requestor (joining node)
   =
V       Message =
verification
 
The particular information elements of the AMIKEY =
I_MESSAGE include:
 
   HDR     =
Header
   =
T       =
Timestamp/counter
   RAND    a =
(pseudo-)random bit-string used for generating the DODAG security key =
(using AMIKEY, the RPL DODAG key is generated from the key assigned by =
the key server)
   IDi     ID of =
the assignment initiator (key server)  
   SP     =
 Security Policy that defines the policy information of the secure RPL =
protocol for which the key assignment is being =
made
   KEMAC   Key data transport =
payload that includes the assigned key generating key from which the RPL =
DODAG security key is derived
 
 
Note: In conjunction with RPL, AMIKEY can also be =
applied to support proactive key assignment/update by the key server =
using an I_MESSAGE and R_MESSAGE exchange as discussed in AMIKEY, =
Section 3.   
 
 
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =
Of Rene Struik
Sent: Wednesday, October 19, 2011 4:11 =
PM
To: Alexander, Roger
Cc: =
roll@ietf.org
Subject: Re: [Roll] notes re =
AMiKeydraft(draft-alexander-roll-amikey-lln-key-mgmt-02)
 
Hi =
Roger:

Thanks for your feedback.

What would really help =
here is to showcase a specific instantiation of AMIKey that exemplifies =
how it can address the key management aspects that have been labelled =
out of scope with rpl-19. This could then also serve as taking away =
[resp. identifying] thoughts that interoperability may be sacrificed =
once one wishes to switch on security.

Another benefit of this =
exercise is that it maeks the AMIKey draft somewhat more concrete for =
the ROLL WG membership. (It has been written more abstractly than just =
to serve rpl, which is great, but may also deter some of the =
audience.)

I can imagine this exercise to assume device counters, =
rather than a notion of time (since, with rpl, this was argued to be =
"unrealistic" at the time [around June 2010], but perhaps this =
needs revisiting]). This would allow identifying whether this indeed =
addresses key management aspects that were out of scope with rpl so =
far.

All - it would be invaluable to have some insight as to =
whether implementations based on rpl-19 actually use its security =
provisions and gain some insight into problems/bottlenecks/interop =
issues, and the-like. So far, not too much information on this has been =
brought to the foreground, but it would be invaluable to have =
some.
So, please do not be shy and share your experiences and =
perspectives here.

Best regards,

Rene



On =
14/10/2011 4:13 PM, Alexander, Roger wrote: 
Hi =
Rene,
 
Thank you very =
much for the detailed review and comments. Please see responses =
below.
 
AMIKEY is of =
course a separate key management application intended to provide the =
out-of-band key management specification called for to support RPL =
‘Authenticated’ mode security (see RPL, Section 3.2.3). It =
is thus intended to support the long-term updating/re-keying of the =
group key used to provide routing security among RPL peers. =

 
Thanks =
again.
 
Best =
regards,
 
Roger
 
 
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] =
On Behalf Of Rene Struik
Sent: Friday, October 14, 2011 =
9:47 AM
To: roll@ietf.org
Subject: =
[Roll] notes re AMiKey =
draft(draft-alexander-roll-amikey-lln-key-mgmt-02)
 
[resend]

-------- Original Message =
--------

Subject:

notes re AMiKey = draft = (draft-alexander-roll-amikey-lln-key-mgmt-02)

Date: =

Thu, 13 Oct 2011 17:48:16 = -0400

From:

Rene Struik <rstruik.ext@gmail.com>

To:

Alexander, Roger = <Roger.Alexander@= cooperindustries.com>, Tsao, Tzeta <Tzeta.Tsao@cooperindu= stries.com>

CC:

roll@ietf.org

<= /tr>

Subject: =

notes re AMiKey draft = (draft-alexander-roll-amikey-lln-key-mgmt-02)

Date:

Thu, 13 Oct 2011 17:48:16 = -0400

From: =

Rene Struik <rstruik.ext@gmail.com><= /o:p>

To: =

Alexander, Roger <Roger.Alexander@cooperindustries.com>, Tsao, Tzeta <Tzeta.Tsao@cooperindustries.com>=

CC: =

roll@ietf.org

=

 

Dear Roger, =
Tzeta:
 
Please find below some notes on your AMIKey =
draft
(draft-alexander-roll-amikey-lln-key-mgmt-02).=

 
I made the assumption that cryptographic =
protection is based on a
nonce-based cryptographic mode of operation =
and that replay protection
would be provided (thus, necessitating each =
receiving device to keep
some nonce state on sending devices). =

>>[RA] Correct. MIKEY does discuss the = state information required (see Section 5.4). The required state = maintenance is of course simplified where system-wide time is available = though a Counter can also be used and is part of the specification. Note = that in the specific case of RPL key management, state information is = required only between the RPL node and the key server = entity.

 
 
While AMIKey could =
have
applications that would not require a =
nonce-based mechanism and replay
protection, this seems a fair assumption (and =
holds for RoLL-based
cryptographic =
protection).

>>[RA] = Agreed.

 
As suggested previously, some of my notes =
have more to do with MIKey
(RFC 3830), so it seems, than with AMIKey. =
However, some have to do with
implicit assumptions on what basic =
functionality devices have on board.

>>[RA] = Understood but useful to clarify since it is the base for = AMIKEY.

 
Please feel free to =
discuss.
 
Best regards, =
Rene
 
=3D=3D
 
1) Notion of =
time
Some =
of the MIKey constructs (e.g., CSB Id, Section 1.4) suggest =
that
one =
assumes devices have a notion of time, e.g., to be used to =
detect
replays/duplicates, and correlate messages =
with the corresponding
acknowledgement. With RoLL, this notion of =
time is not a given.
Moreover, this begs the question as to what =
to do if time notions
between devices are out-of-synch. Does the =
MIKey specification cater to
this?

>>[RA] Yes = for MIKEY there is a notion of system time but an optional Counter is = also defined. The NTP-based Timestamp is mandatory for MIKEY (See = Section 4.2.8 and 6.6 of RFC 3830). For AMIKEY however, the Counter is = to be made mandatory, while Timestamp is optional (consistent with RPL). =

See Section 5.4 of RFC3830 for a good = discussion of the issue regarding the tradeoff of state maintenance = (replay cache) versus degree of time synchronization to be maintained. = 

 
Additional =
note:
-Section 5.2, first para: this seems to =
suggest a mandatory timestamp.

>>[RA] This = should read "Timestamp [payload]" where as specified in = RFC3830 the Timestamp payload can be a Timestamp or Counter = value.

 
Not sure what the granularity is with MIKey =
(important, since not to be
reused) and how this time stamp would be =
managed.

>>[RA] The granularity as given for NTP = (32-bit fractional second). Devices would increment to their degree of = supported system time synchronization.

 
-Section 6.14, 2nd para: here, key validity =
periods are specified (KV),
thus requiring a sufficiently accurate shared =
notion of time (for, if
not, any time check may be unreliable or =
futile).

>>[RA] Only applicable where system = time is supported. The validity period can be defined by an Interval = (Valid From and Valid To) that can be referenced to the Timestamp of the = key assignment message. The granularity in the triggering of key updates = will depend on the system time accuracy supported.    = 

 
 
2) Key =
dependencies
It seems that MIKey defines a deterministic =
mapping between key
encryption keys (TGK) and session keys (TEK). =
As a result, inadvertent
key exposure of the TGK key will expose all =
derived keys as well. This
may be undesirable, e.g., if TGK is shared =
amongst many devices and one
of those devices gets compromised. If session =
keys would be generated at
random and transported over a secure =
per-device-pair channel instead,
the impact of compromise of a single node =
seems more limited. Moreover,
it seems to be preferable to have a logical =
separation between keys
(e.g., in the event of ownership transfer of =
a single node or
replacement of a malfunctioning single =
node).

>>[RA] Yes there is a deterministic = mapping between the TEK generating key (TGK) and the TEK. However, the = use of a TGK to derive multiple TEKs only applies where required for = simultaneous assignment or update of related keys, as applicable for = example in the multimedia domain for voice video, etc. For RPL the RPL = routing group key (TEK) would be the only key derived from the assigned = TGK. 

 
 
Additional =
note:
-From =
Section 2 (AMIKey overview, para below Fig. 2) it is =
unclear
whether the TEK is used directly as =
cryptographic key with, e.g., RoLL,
or whether one derives additional keying =
material from this.
-Section 6.16 (Key Index payload): this may =
benefit from some more
explanation.

>>[RA] The = TEK is the security key that will be assigned (derived from the TGK) by = the RPL Key Server for use in securing the routing exchanges between the = RPL peers. Some further clarifications can be made to ensure that this = is better understood. As in other sections, the intent will be to use = RPL-specific examples throughout while maintaining the protocol’s = more general application. 

 
 
3) Key =
identification
With RoLL, the pair (key source identifier, =
key index) indicates both
the originator of the key ("key source =
id") and an index ("key =
index")
of keys issued by this key originator. This =
does not necessarily imply,
though, that keys are correlated, as is =
suggested in Section 1.4. (It
seems that KeySourceId identifies a TGK, =
while KeyIndex identifies a
parameter so as to allow computation of =
TEK=3Df(TGK,#)). If this
interpretation is correct, this leads to key =
dependencies that may be
undesirable, e.g., in the event of key =
compromise.

>>[RA] As part of the 'Authenticated' = mode operation, RPL-19, Section 10.1, RPL uses a shared group key = assigned by a network Key Server (where pre-shared keys or public keys = may be used to secure the key management communications with the key = server). The Key Index associated with the assigned RPL group key allows = RPL nodes to ensure synchronization to a common shared key. RPL's group = key can be changed by the key server at any time and nodes can request = the current key when out of sync with a routing peer (that is, when = having a lower Key index key). The Key Source ID would refer to the RPL = key server entity, again to ensure synchronization among RPL routing = peers as to the entity from which the group key was obtained. Since the = security of RPL routing exchanges is based on the shared group key it is = vulnerable to compromise of a single group member and hence the need for = key updates. With a single TGK/TEK assigned there is no difference in = the level of vulnerability between the single assigned group TGK or the = derived group TEK.  

 
 
4) Challenge response =
protocol
I =
am somewhat concerned about some of the message flows with =
MIKey
(e.g., Section 3, 3rd para, Fig. 3), since a =
key request could arise,
e.g., if a key or nonce are =
"out-of-synch" (which, for keys, mens =
that
one =
does not have the proper key; for nonces, that one has lost =
this
value). With MIKey PSK flows, this would =
result (in the context of RPL)
that one cannot adequately secure the first =
message Q_MESSAGE, thereby
aborting the protocol. Simply put, what does =
one do if keys are lost or
if nonces are out of synch? =

>>[RA] Keep in mind that the key being = requested, the RPL group key that the node may have determined to be out = of synch with its routing peers is different from the key being used to = secure and authenticate the RPL node client (Q) to the key server (I). = If the node is using a PSK for authenticating exchanges to the key = server and that key is out of synch, the device needs to be = re-provisioned/reconfigured (with Error indication of inability to = access key server, for ex.).

 

 

Moreover, the message flows do not seem to =
provide for timeliness (in other words: how does entity I know that the =
request by entity R is "fresh")?

>>[RA] = Timeliness is supported only where the time-based Timestamp is used. In = the case of Q_MESSAGE the Timestamp payload is included in the message = set according to the time of origination of the message. When the = message is received at the server (I), it can be accepted provided it is = within the allowable time window when (including allowance for degree to = system time synchronization). In the returned I_MESSAGE the same = Timestamp value is included which again must be received at Q within an = allowable roundtrip time window (again subject to allowances for degree = of system time synchronization). 

 
 
In out-of-synch scenarios, it seems better to =
employ a proper
challenge/response protocol (unilateral =
entity authentication), where
the key requestor sends a random challenge to =
the key assignment
initiator and where the response messsage =
includes a protected version
of the requested key and incorporates this =
random value. This results in
implicit key authentication (only the =
requestor can recover the key
[assuming both entities have a shared key]) =
and provides logical binding
between message flows without dependency on =
nonces.

>>[RA] The Q_MESSAGE is indeed = protected and so the Requestor's Timestamp value provides the equivalent = of the random value. The logical binding is therefore supported in the = defined mechanism. Let us discuss to ensure I fully understand the = concern.

 
 
NOTE RS: with RoLL, this may cause some =
trouble, since this suggests
mixing of unsecured and secured traffic in =
the network (which, vaguely,
seems to be forbidden using the =
"security mode"). Since with RoLL, =
the
security mode and the security level seems to =
be unduly tied together,
this may result in the security mode toggling =
between unsecured and
secured once such a C/R protocol would get =
implemented.
>>=
[RA] Keep in mind that the communications with the key server in RPL is =
distinct from the communications with routing peers. The key server =
using PSK or PKE methods with each node is able to assign the routing =
security group key. In the RPL 'Authenticated' mode a node has a key =
that only allows a leaf join (no routing). That leaf join then allows =
key management exchanges with the key server to obtain the current =
routing group key. Until that group key is obtained the node cannot =
operate as a routing peer.
 
 
5) Timeliness/ logical binding in protocol =
flows
It is =
not entirely clear how the MIKey protocol provides for =
logical
binding between protocol flows. As already =
mentioned, this may be a
problem with the protocol flows in Fig. 3 =
(key request), but also with
subsequent detailed protocol flows (such as =
with Fig. 5, using the PSK
method).

>>[RA] See = above discussion.

 
 
Additional =
note:
-Section 3.1, 2nd last para: doesn't this =
impact the resulting properties?

>>[RA] This = determines when a key assignment confirmation is required for a = server-initiated key push.

 
 
6) Public key =
usage:
The =
MIKEY protocol seems to use the same public key both for signing =
and
for =
encryption. It is unclear in abstracto whether this poses =
problems,
but common practice is to separate public =
keys for different
cryptographic purposes. If this practice is =
heeded to, this requires the
use of two public keys per device (including =
management hereof).

>>[RA] Noted. A recommendation that = could be made for devices/networks that support additional processing = resource capabilities.

 
 
Additional =
note:
-Section 3.2, forelast para: wouldn't this =
impact freshness and
aliveness =
properties?

>>[RA] Timeliness checks can be = supported when the time-based Timestamp payload is used (see discussion = above).

 
 
-Section 3.2 vs. 3.3: What is the rationale =
for making public key
encryption (3.2) mandatory and Diffie-Hellman =
key exchange (3.3)
optional? To me, it seems that use of public =
key techniques may
significantly simplify configuration =
management (since this now depends
on juggling publicly available information, =
rather than handling of
secret keying material). Of those techniques, =
DH-based protocols seem to
be best suited for highly constrained =
networks, where energy cost and
implementation footprint come at a premium. =
Moreover, these may also be
more resistant to side channel attacks (not =
trivial, esp. for devices
that can be expected to be low-cost, =
consumer-style devices that may not
be able to rely on tamper-evidencing =
techniques). This suggests that
public-key based techniques, rather than =
symmetric-key based techniques
(with proper eye for detail, of course) =
should be mandatory to implement.

>>[RA] I = think it would be more consistent with RPL to make PSK mandatory and = both PKE and DH methods optional. This comment was also made by another = reviewer. The intent of AMIKEY is to provide a reasonable lowest-common = denominator with the ability to ratchet up the security level based on = application environment.

 
 
7) Hash =
function
The suggested "hash function" =
(Section 4.1.2 - use of CMAC) may be
somewhat unfortunate, since it is invertible =
if one has access to the
key (in contrast to HMAC-SHAx, which is =
one-way, or block-cipher based
hashes, such as AES-MMO, as ZigBee SE1.x =
used). This may have
implications in the event of key =
compromise.

>>[RA] Agreed. A trade-off made to = permit lowest common denominator (all AES implementation) devices. SHAx = of course remains an option that is available for devices/networks that = can support the additional capability.

 
 
8) Key management =
fit
[as =
already noted by others] Overarching question may be whether =
key
management functionality best fits with RoLL, =
CoRE, etc. Of course, this
a perennial question. Nevertheless, some of =
the functionality described
seems to suggest layer violation (e.g., =
Section 6.1.2, Table 6.1.e),
since RoLL may not know about application =
layers, etc.

>>[RA] As described in the Section 2, = the key management entity logically exists independent of the device = protocol layers. The KM entity can thus select the particular protocol = for which key management is being performed. As previously discussed, = the objective is to be able to handle key management for one or more = layers with a single protocol given the constraints of a LLN-type = device. 

 
 
9) Other =
notes
-Section 4: RFC 4493 corresponds to NIST SP =
800-38B.

>>[RA] = Noted.

 
 
-Section 4.1.2: not sure what the AES-CMAC =
alignment remark is about.
BTW - this seems to suggest one can mix usage =
of CMAC with that of CCM
with the same key (cf. also Section 6.2 =
(Table 6.2.b) and the last para
of Section 6.2). In my opinion, this may be =
highly dangerous. As case in
point, with the development of 802.15.4-2003, =
the same mixing was
suggested (CBC-MAC, CTR, CCM) and shown to =
lead to an unsecure scheme (I
can send you my presentation at the time [Nov =
2002]).

>>[RA] I think this was just loose = wording intended to convey replacement. CCM can be mandated. I would = still be interested in your reference paper. = 

 
 
-Section 4.2.4: CCM mode of operation uses a =
nonce, rather than IV. With
RoLL, this is a 13-byte entry, rather than a =
16-byte entry. Moreover,
the structure of the nonce matters, since it =
is aimed at preventing
nonce reuse by a single sender/amongst =
different senders sharing the
same key.

>>[RA] = Understood. The intent was to re-use the "IV" information = element given in RFC 3830 as a Nonce. Since that "IV" included = the Timestamp (time-based or Counter from the originator) it was = guaranteed to be non-repeating. This should be cleaned up to avoid = potential confusion. 

 

 
-Section 6.1, bullet #CS (8 bits): shouldn't =
this entry enumerate,
rather than provide a =
number.

>>[RA] No this should be a number. This = number will match the number of subsequent occurrences of "CS ID = map info" elements in the message.

 
-Section 6.7, 3rd para: the IEEE MAC address =
is a 64-bit entry (rather
than a 48-bit address). Not sure how the =
reference to RFC 4291 comes
into play here.

>>[RA] The = idea is to allow use of the 48-bit MAC as an ID as well as the IEEE EUI = 64-bit MAC where it can be derived from the IP address of packet = carrying the key exchange message (the IPv6 address being = auto-configured from the MAC address in conformance with = RFC4291).

 
 
-Section 6.10.2: Table 6.10.2c suggests the =
use of AES-CBC-MAC-x. Why
not use CCM instead (it provides various =
combinations of encryption and
authentication, including =
authentication-only).

>>[RA] Yes = CCM can be mandated.

 
 
-- 
email: rstruik.ext@gmail.com
Skype: =
rstruik
cell: +1 (647) =
867-5658
USA Google voice: +1 (415) =
690-7363
 
 



-- 
email: rstruik.ext@gmail.com
Skype: =
rstruik
cell: +1 (647) =
867-5658
USA Google voice: +1 (415) =
690-7363
------_=_NextPart_001_01CC9F36.2379AD21-- From tianlinyi@huawei.com Tue Nov 8 14:26:15 2011 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 271AD1F0C70; Tue, 8 Nov 2011 14:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.708 X-Spam-Level: *** X-Spam-Status: No, score=3.708 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.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 juWL8qp6w0oK; Tue, 8 Nov 2011 14:26:14 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2CF11E80AD; Tue, 8 Nov 2011 14:25:47 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD002SO4YWMZ@szxga03-in.huawei.com>; Wed, 09 Nov 2011 06:25:44 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD000QF4YWA8@szxga03-in.huawei.com>; Wed, 09 Nov 2011 06:25:44 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV44266; Wed, 09 Nov 2011 06:25:25 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 06:25:21 +0800 Received: from SZXEML513-MBX.china.huawei.com ([169.254.8.59]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 06:25:19 +0800 Date: Tue, 08 Nov 2011 22:25:18 +0000 From: TianLinyi In-reply-to: <4EB91C1D.5000606@piuha.net> X-Originating-IP: [172.24.2.40] To: Jari Arkko , core , "6lowpan@ietf.org" <6lowpan@ietf.org>, "roll@ietf.org" Message-id: <3615F3CCD55F054395A882F51C6E5FDA181FD1FC@szxeml513-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [core] informal hacking & interop session on Sunday Thread-index: AQHMng94QsTxRr2OuECfrzamTLX3rJWjjgFO X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EB91C1D.5000606@piuha.net> X-Mailman-Approved-At: Fri, 11 Nov 2011 22:06:15 -0800 Subject: Re: [Roll] [core] informal hacking & interop session on Sunday X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 22:26:15 -0000 SGksIEphcmkNCg0KR29vZCB0byBrbm93IHRoaXMgZXZlbnQuIE15IHRlYW0gaGFzIGltcGxlbWVu dGVkIHRoZSBsYXRlc3QgZHJhZnQgb2YgY29yZSwgbGluayBmb3JtYXQsIGJsb2NrIGFuZCBvYnNl cnZlLiBTaW5jZSB3ZSBoYXZlIGEgY29tcGFueSBtZWV0aW5nIGF0IDE5OjAwIHdlIG1heSBjb21l IGEgbGl0dGxlIGJpdCBsYXRlLg0KDQpDaGVlcnMsDQpMaW55aQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBb Y29yZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEphcmkgQXJra28gW2phcmkuYXJra29AcGl1aGEu bmV0XQ0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI4yNUgMjA6MTANCrW9OiBjb3JlOyA2bG93cGFuQGll dGYub3JnOyByb2xsQGlldGYub3JnDQrW98ziOiBbY29yZV0gaW5mb3JtYWwgaGFja2luZyAmIGlu dGVyb3Agc2Vzc2lvbiBvbiBTdW5kYXkNCg0KSW4gdGhlIGxhc3QgSUVURiB3ZSBvcmdhbml6ZWQg YW4gaW5mb3JtYWwgc2Vzc2lvbiB0byBkZW1vbnN0cmF0ZSAmIHRlc3QgdmFyaW91cyBzbWFydCBv YmplY3QgcmVsYXRlZCBpbXBsZW1lbnRhdGlvbnMuIFdlIGFyZSBub3cgZG9pbmcgdGhpcyBhZ2Fp biBmb3IgdGhlIFRhaXBlaSBJRVRGLiBXZSB3aWxsIG1lZXQgYXQgMTk6MDAtMjI6MDAgb24gU3Vu ZGF5LCBOb3ZlbWJlciAxM3RoLCAocm9vbSBUQkQpLiBJZiB5b3UgYXJlIGF0dGVuZGluZyB0aGUg SUVURiBhbmQgaGF2ZSB5b3VyIEludGVybmV0IG9mIFRoaW5ncyB0b3lzIHdpdGggeW91IChiZSBp dCA2bG93cGFuLCBjb2FwLCBycGwsIG9yIGFueXRoaW5nIGVsc2UpIGZlZWwgZnJlZSB0byBqb2lu LiBNYXliZSB5b3UnbGwgZmluZCBzb21lb25lIHRvIHRlc3Qgd2l0aCwgb3IgYXQgbGVhc3QgZ2V0 IHRvIHNlZSBvdGhlciBwZW9wbGUgd2l0aCBpbnRlcmVzdGluZyBpbXBsZW1lbnRhdGlvbnMuDQoN CkphcmkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NvcmU= From gabriel.chegaray@orange.com Fri Nov 11 06:48:33 2011 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 2D26321F8997 for ; Fri, 11 Nov 2011 06:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 KFMOLNd-eB9G for ; Fri, 11 Nov 2011 06:48:32 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2E18521F8888 for ; Fri, 11 Nov 2011 06:48:32 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C1D12140002 for ; Fri, 11 Nov 2011 15:48:29 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id B4D52140001 for ; Fri, 11 Nov 2011 15:48:29 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 15:48:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA080.F992F0B9" Date: Fri, 11 Nov 2011 15:48:27 +0100 Message-ID: <9ECCF01B52E7AB408A7EB8535264214103767C1B@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPL is a great achievement for the WAVE2M Community Thread-Index: AcyggPhwoQJLYD0XSNiGbF4xhOpS1g== From: To: X-OriginalArrivalTime: 11 Nov 2011 14:48:29.0568 (UTC) FILETIME=[F9E4C800:01CCA080] X-Mailman-Approved-At: Fri, 11 Nov 2011 22:06:15 -0800 Subject: [Roll] RPL is a great achievement for the WAVE2M Community X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 14:48:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA080.F992F0B9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear Working Group, =20 We would like to let you know that the WAVE2M Community (formerly names Wavenis Open Standard Alliance), that is defining very low-powered radio networking solutions for the smart metering market where constrained LLN (e.g. battery operated devices) are operating, has decided to select RPL as their protocol of choice, after careful technical considerations. Since the beginning we have been following the work of this WG and some of our members contributed to the RFC 5548 which was reflecting pretty well our requirements. Thanks to this WG for having specified this routing protocol, a great achievement for the Internet of Things. =20 Gabriel Chegaray Orange Labs, President of the WAVE2M Community www.wave2m.org =20 =20 ------_=_NextPart_001_01CCA080.F992F0B9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear Working Group,

 

We would like to let you know that = the WAVE2M Community (formerly names Wavenis Open Standard Alliance), = that is defining very low-powered radio networking solutions for the = smart metering market where constrained LLN (e.g. battery operated = devices) are operating, has decided to select RPL as their protocol of = choice, after careful technical considerations.

Since the beginning we have been = following the work of this WG and some of our members contributed to the = RFC 5548 which was reflecting pretty well our = requirements.

Thanks to this WG for having specified this routing = protocol, a great achievement for the Internet of = Things.

 

G= abriel Chegaray<= br>Orange Labs,

P= resident of the WAVE2M Community

<= a = href=3D"http://www.wave2m.org">www.wave2m.org

<= o:p> 

 

------_=_NextPart_001_01CCA080.F992F0B9-- From jari.arkko@piuha.net Sat Nov 12 04:13:41 2011 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 A21E521F85FF; Sat, 12 Nov 2011 04:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 xSacoeXQee3Y; Sat, 12 Nov 2011 04:13:41 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 10AB121F8551; Sat, 12 Nov 2011 04:13:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 500112CCE1; Sat, 12 Nov 2011 14:13:26 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL0adqpXQ9-0; Sat, 12 Nov 2011 14:13:25 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id F20672CC61; Sat, 12 Nov 2011 14:13:23 +0200 (EET) Message-ID: <4EBE62E2.8010103@piuha.net> Date: Sat, 12 Nov 2011 20:13:22 +0800 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: core , 6lowpan@ietf.org, roll@ietf.org References: <4EB91C1D.5000606@piuha.net> In-Reply-To: <4EB91C1D.5000606@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hannes Tschofenig Subject: Re: [Roll] informal hacking & interop session on Sunday X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 12:13:41 -0000 The room is 202A. See you there! Jari On 08.11.2011 20:10, Jari Arkko wrote: > In the last IETF we organized an informal session to demonstrate & test various smart object related implementations. We are now doing this again for the Taipei IETF. We will meet at 19:00-22:00 on Sunday, November 13th, (room TBD). If you are attending the IETF and have your Internet of Things toys with you (be it 6lowpan, coap, rpl, or anything else) feel free to join. Maybe you'll find someone to test with, or at least get to see other people with interesting implementations. > > Jari > From yoav@yitran.com Sun Nov 13 08:31:52 2011 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 A85F821F8485 for ; Sun, 13 Nov 2011 08:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 8syw8I++fJry for ; Sun, 13 Nov 2011 08:31:51 -0800 (PST) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with SMTP id 67D0E21F8484 for ; Sun, 13 Nov 2011 08:31:51 -0800 (PST) Received: from mail-wy0-f170.google.com ([74.125.82.170]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTr/w8eR/UfLlS5yMNsbiYN28wpfTMj4J@postini.com; Sun, 13 Nov 2011 08:31:52 PST Received: by wyf19 with SMTP id 19so310408wyf.29 for ; Sun, 13 Nov 2011 08:31:44 -0800 (PST) Received: by 10.227.198.212 with SMTP id ep20mr1679712wbb.9.1321201904099; Sun, 13 Nov 2011 08:31:44 -0800 (PST) From: Yoav Ben-Yehezkel MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyiHwzPKbB6CDMWQqqPwhKILSx/RQ== Date: Sun, 13 Nov 2011 18:29:41 +0200 Message-ID: <9a42333a50c494a76fd72c8714efb307@mail.gmail.com> To: roll@ietf.org Content-Type: multipart/alternative; boundary=00151747b8b62ba05c04b1a04a54 Subject: [Roll] regarding DIS Modifications draft (draft-goyal-roll-dis-modifications-00) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 16:31:52 -0000 --00151747b8b62ba05c04b1a04a54 Content-Type: text/plain; charset=ISO-8859-1 Hi, I went through the draft, it seems interesting. I had one concern regarding the use of the Response Spreading Option specified in 4.2. 8 bits specified in ms can be a too small randomization for some L2 technologies (such as narrowband powerline). Would it be possible to increase the number of bits (although 16 seems like an overkill)? Another option could be to divide the field into two (first part units: ms, 10ms, 100ms, etc. and second part randomization range)? I expect that in order to avoid collisions this randomization is best achieved if the units are at the magnitude of the duration of a frame or so. Best regards, Yoav --00151747b8b62ba05c04b1a04a54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

I went through the draft, it seems interesti= ng.

=A0

I had one concern regarding the use of the Re= sponse Spreading Option specified in 4.2.

=A0

=

8 bits specified in ms can be a too small randomizat= ion for some L2 technologies (such as narrowband powerline).

=A0

Would it be possible t= o increase the number of bits (although 16 seems like an overkill)?

Another option could be to divide the field into two (fi= rst part units: ms, 10ms, 100ms, etc. and second part randomization range)?=

=A0

I expect that in order= to avoid collisions this randomization is best achieved if the units are a= t the magnitude of the duration of a frame or so.

=A0

Best regards,

Yoav

=A0

--00151747b8b62ba05c04b1a04a54-- From emmanuel.baccelli@gmail.com Sun Nov 13 18:08:24 2011 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 8857F11E8128 for ; Sun, 13 Nov 2011 18:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.511 X-Spam-Level: X-Spam-Status: No, score=-4.511 tagged_above=-999 required=5 tests=[AWL=-1.535, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5G0jIqH5fxYB for ; Sun, 13 Nov 2011 18:08:24 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 993FC11E8127 for ; Sun, 13 Nov 2011 18:08:23 -0800 (PST) Received: by qadb40 with SMTP id b40so3938837qad.10 for ; Sun, 13 Nov 2011 18:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=Mjs4/5u6AcAqqrtyQmMlOeEAP43p23jGcX7Fpio/7p4=; b=cpZ07L0lmjPb+Z8ywnLahsGRRs3yKEYR2h1dcUQVE5AjbXFdsZo4UpK9Od0b8+zzrC BZfvCyN4I+eKFjWnxtSQm7NGf5dd2TPGMrrivmMIHVXCytMWowEtZ2NJZYqMRCB2g0Ct b/htTCbnPrzLZqZLwtFmrhg7z/FzMPYEodNHw= Received: by 10.229.86.208 with SMTP id t16mr2817712qcl.189.1321236014244; Sun, 13 Nov 2011 18:00:14 -0800 (PST) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.229.233.136 with HTTP; Sun, 13 Nov 2011 17:59:53 -0800 (PST) In-Reply-To: <1538999065.280078.1321201922021.JavaMail.root@zmbs1.inria.fr> References: <1538999065.280078.1321201922021.JavaMail.root@zmbs1.inria.fr> From: Emmanuel Baccelli Date: Mon, 14 Nov 2011 02:59:53 +0100 X-Google-Sender-Auth: NRDxqPVafGCtUzbGKXHuycHL_KY Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary=001636426e114b24bb04b1a83b37 Subject: Re: [Roll] regarding DIS Modifications draft (draft-goyal-roll-dis-modifications-00) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 02:08:24 -0000 --001636426e114b24bb04b1a83b37 Content-Type: text/plain; charset=ISO-8859-1 Hi Yoav, good call. In fact the current specification interprets the randomization range being from 0 to 2^SpreadingInterval ms. The maximum interval is thus 0 to 2^256 ms, which is quite an astronomic number already! Do you think we need some more fancy way to define the range from the number specified in the SpreadingInterval field? Cheers Emmanuel On Sun, Nov 13, 2011 at 5:32 PM, Yoav Ben-Yehezkel wrote: > Hi, > > > > I went through the draft, it seems interesting. > > > > I had one concern regarding the use of the Response Spreading Option > specified in 4.2. > > > > 8 bits specified in ms can be a too small randomization for some L2 > technologies (such as narrowband powerline). > > > > Would it be possible to increase the number of bits (although 16 seems > like an overkill)? > > Another option could be to divide the field into two (first part units: > ms, 10ms, 100ms, etc. and second part randomization range)? > > > > I expect that in order to avoid collisions this randomization is best > achieved if the units are at the magnitude of the duration of a frame or so. > > > > Best regards, > > Yoav > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001636426e114b24bb04b1a83b37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yoav,
good call. In fact the current specification interprets the ra= ndomization range being from 0 to 2^SpreadingInterval ms. The maximum inter= val is thus =A00 to 2^256 ms,=A0which is quite an astronomic number already= ! Do you think we need some more fancy way to define the range from the num= ber specified in the SpreadingInterval field?
Cheers
Emmanuel


On Sun, Nov 13, 2011 at 5:32 PM, Yoav Ben-Yehezkel <yoav@yitran.= com> wrote:

Hi,

=A0

I went through the draft, it seems interestin= g.

=A0

I had one concern regarding the use of the Re= sponse Spreading Option specified in 4.2.

=A0

=

8 bits specified in ms can be a too small randomizat= ion for some L2 technologies (such as narrowband powerline).

=A0

Would it be possible t= o increase the number of bits (although 16 seems like an overkill)?

Another option could be to divide the field into two (fi= rst part units: ms, 10ms, 100ms, etc. and second part randomization range)?=

=A0

I expect that in order= to avoid collisions this randomization is best achieved if the units are a= t the magnitude of the duration of a frame or so.

=A0

Best regards,

Yoav

=A0


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


--001636426e114b24bb04b1a83b37-- From internet-drafts@ietf.org Sun Nov 13 18:47:30 2011 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 C742F1F0C94; Sun, 13 Nov 2011 18:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 V8VWwpuQvyPk; Sun, 13 Nov 2011 18:47:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5383B1F0C8B; Sun, 13 Nov 2011 18:47:30 -0800 (PST) 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: 3.63 Message-ID: <20111114024730.5825.44858.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2011 18:47:30 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 02:47:31 -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 netw= orks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power= and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-05.txt Pages : 24 Date : 2011-11-13 This document specifies a route discovery mechanism, complementary to the RPL base functionality. This mechanism allows an IPv6 router to discover and establish, on demand, a route to another IPv6 router in the LLN such that the discovered route meets specified metrics constraints, without necessarily going along the DAG links established by basic RPL. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-05.txt From prvs=292873e84=mukul@uwm.edu Sun Nov 13 20:28:21 2011 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 6A88411E809F for ; Sun, 13 Nov 2011 20:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jceP5VsB9LPa for ; Sun, 13 Nov 2011 20:28:20 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id CDDE311E8080 for ; Sun, 13 Nov 2011 20:28:20 -0800 (PST) Received: from localhost (HELO mta01.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 13 Nov 2011 22:28:20 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 44BB6E6A77 for ; Sun, 13 Nov 2011 22:28:20 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LftUFO6f-rIC for ; Sun, 13 Nov 2011 22:28:19 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id EB875E6A74 for ; Sun, 13 Nov 2011 22:28:19 -0600 (CST) Date: Sun, 13 Nov 2011 22:28:19 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <1782793375.276823.1321244899852.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20111114024730.5825.44858.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-p2p-rpl-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 04:28:21 -0000 Hi all Here are the changes from the previous version: 1) Added Security and IANA sections. 2) Leaner initial sections. 3) Corrected typos. 4) Corrected a bug: The Option Length field in the Route Discovery Option now does not cover the Option Type and Option Length fields. 5) Added the secure versions of DRO and DRO-ACK messages. Thanks Mukul ----- Forwarded Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Sunday, November 13, 2011 8:47:30 PM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-05.txt Pages : 24 Date : 2011-11-13 This document specifies a route discovery mechanism, complementary to the RPL base functionality. This mechanism allows an IPv6 router to discover and establish, on demand, a route to another IPv6 router in the LLN such that the discovered route meets specified metrics constraints, without necessarily going along the DAG links established by basic RPL. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-05.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Sun Nov 13 22:11:19 2011 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 4821321F8B79 for ; Sun, 13 Nov 2011 22:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.672 X-Spam-Level: X-Spam-Status: No, score=-0.672 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_20=-0.74, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 nl-GHymo+bXV for ; Sun, 13 Nov 2011 22:11:18 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id C1CC121F8B77 for ; Sun, 13 Nov 2011 22:11:18 -0800 (PST) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 77030343CB; Mon, 14 Nov 2011 01:09:48 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id B880B98CB3; Mon, 14 Nov 2011 01:11:12 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id A955198CB2; Mon, 14 Nov 2011 01:11:12 -0500 (EST) From: Michael Richardson To: Adrian Farrel X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 14 Nov 2011 01:11:12 -0500 Message-ID: <14728.1321251072@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: [Roll] unknown suboption text for rpl-19 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:11:19 -0000 section 6.7.1: change: When processing a RPL message containing an option for which the Option Type value is not recognized by the receiver, the receiver MUST silently ignore the unrecognized option and continue to process the following option, correctly handling any remaining options in the message. To: When processing a RPL message containing an option for which the Option Type value is not recognized by the receiver, the receiver MUST silently skip the unrecognized option. Unrecognized options in DIO messages SHOULD be copied into any subsequent DIO message transmitted. On a per-DODAG basis, unrecognized messages should reset the trickle timers if they are byte different than previous messages, thus causing a DIO to be immediately emitted. ==== -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From ietf@thomasclausen.org Sun Nov 13 23:39:40 2011 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 30E0E11E8198 for ; Sun, 13 Nov 2011 23:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 qW5K1XelNKY4 for ; Sun, 13 Nov 2011 23:39:39 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC3A11E8165 for ; Sun, 13 Nov 2011 23:39:39 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 0C205CD09B for ; Sun, 13 Nov 2011 23:39:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 058981BD5A58; Sun, 13 Nov 2011 23:39:38 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.3] (unknown [203.69.99.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7AC801BD5A30; Sun, 13 Nov 2011 23:39:37 -0800 (PST) From: Thomas Heide Clausen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 08:39:35 +0100 Message-Id: To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [Roll] As promised during today's WG meeting to Pascal on draft-thubert-roll-asymlink X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 07:39:40 -0000 All, (ended up needing to resend this to have it hit the list - so I will = elaborate a bit more than what I did in my first attempt) As I said at the mike, I suggest putting in the Terminology section = proper definitions of: o bi-directional (traffic confirmed possible in both direction) o uni-directional (traffic confirmed possible only in one = direction) o symmetric (bi-directional, with identical link = characteristics in both directions) o asymmetric (bi-directional, with different link = characteristics in both directions) There's potential confusion on this matter (terminology used differently = in different contexts/WGs/documents), so for the sake of clarity it = would be good to call it out - also, to call out what it is this = document addresses (asymmetric, but not uni-directional links). (This without otherwise pronouncing myself on this document, wg adoption = etc, I need to mull over it a bit more....) Best, Thomas From yoav@yitran.com Mon Nov 14 03:11:24 2011 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 D7CB611E8239 for ; Mon, 14 Nov 2011 03:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.676 X-Spam-Level: X-Spam-Status: No, score=-4.676 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 8jvdojxHYfM4 for ; Mon, 14 Nov 2011 03:11:24 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with SMTP id ADB4411E8234 for ; Mon, 14 Nov 2011 03:11:23 -0800 (PST) Received: from mail-ww0-f41.google.com ([74.125.82.41]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTsD3W43UMilDn+DyJHTv4ZktIxLXLqDB@postini.com; Mon, 14 Nov 2011 03:11:23 PST Received: by mail-ww0-f41.google.com with SMTP id 25so4341113wwf.2 for ; Mon, 14 Nov 2011 03:11:23 -0800 (PST) Received: by 10.227.199.132 with SMTP id es4mr14396975wbb.5.1321269081595; Mon, 14 Nov 2011 03:11:21 -0800 (PST) From: Yoav Ben-Yehezkel References: <1538999065.280078.1321201922021.JavaMail.root@zmbs1.inria.fr> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMCtIda5ovyDzivw24Q2cKrjIP3rAHNmOf4kzGljwA= Date: Mon, 14 Nov 2011 13:09:13 +0200 Message-ID: <9da83f41cc0f890394a2d666b4e3a167@mail.gmail.com> To: roll@ietf.org Content-Type: multipart/alternative; boundary=000e0cd574ee42e0e304b1afee18 Subject: Re: [Roll] regarding DIS Modifications draft (draft-goyal-roll-dis-modifications-00) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 11:11:25 -0000 --000e0cd574ee42e0e304b1afee18 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, I didn=92t notice the 2^ J I take my comment back. Best regards, Yoav *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of *Emmanuel Baccelli *Sent:* Monday, November 14, 2011 4:00 AM *To:* roll@ietf.org *Subject:* Re: [Roll] regarding DIS Modifications draft (draft-goyal-roll-dis-modifications-00) Hi Yoav, good call. In fact the current specification interprets the randomization range being from 0 to 2^SpreadingInterval ms. The maximum interval is thus 0 to 2^256 ms, which is quite an astronomic number already! Do you think we need some more fancy way to define the range from the number specified in the SpreadingInterval field? Cheers Emmanuel On Sun, Nov 13, 2011 at 5:32 PM, Yoav Ben-Yehezkel wrote: Hi, I went through the draft, it seems interesting. I had one concern regarding the use of the Response Spreading Option specified in 4.2. 8 bits specified in ms can be a too small randomization for some L2 technologies (such as narrowband powerline). Would it be possible to increase the number of bits (although 16 seems like an overkill)? Another option could be to divide the field into two (first part units: ms, 10ms, 100ms, etc. and second part randomization range)? I expect that in order to avoid collisions this randomization is best achieved if the units are at the magnitude of the duration of a frame or so= . Best regards, Yoav _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --000e0cd574ee42e0e304b1afee18 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Th= anks,

=A0

I didn=92t notice the 2^ J

I take my comment back. <= /span>

=A0

Best regards,

<= p class=3D"MsoNormal">Yoav

=A0

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Emmanu= el Baccelli
Sent: Monday, November 14, 2011 4:00 AM
To: roll@ietf.org
Subject: Re: [Roll] regardin= g DIS Modifications draft (draft-goyal-roll-dis-modifications-00)

=A0

Hi Yoav,

good call. In fact the current specification interprets t= he randomization range being from 0 to 2^SpreadingInterval ms. The maximum = interval is thus =A00 to 2^256 ms,=A0which is quite an astronomic number al= ready! Do you think we need some more fancy way to define the range from th= e number specified in the SpreadingInterval field?

Cheers

Emmanuel

=A0

=A0

On Sun, Nov 13, 2011 at 5= :32 PM, Yoav Ben-Yehezkel <yoav@yitran.com> wrote:

Hi,

=A0

I went through the draft, it seems interesting.

=A0

I had one concern regarding the use of the Response Spreading Option spec= ified in 4.2.

=A0

8 bits specified in ms can be a too small randomiz= ation for some L2 technologies (such as narrowband powerline).

=A0

Would it be possible to increase the number of bit= s (although 16 seems like an overkill)?

Another option could be to divide the field into two (first part u= nits: ms, 10ms, 100ms, etc. and second part randomization range)?

=A0

I expect that in order to avoid collisions this randomizati= on is best achieved if the units are at the magnitude of the duration of a = frame or so.

=A0

Best regards,

Yoav

=A0


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

=A0

--000e0cd574ee42e0e304b1afee18-- From ietf@thomasclausen.org Mon Nov 14 03:36:37 2011 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 B0C6821F8F2E for ; Mon, 14 Nov 2011 03:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 lKXsK17c+RZT for ; Mon, 14 Nov 2011 03:36:37 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0666321F8F2C for ; Mon, 14 Nov 2011 03:36:36 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id B550CCD15B for ; Mon, 14 Nov 2011 03:36:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 1AD891BD9197; Mon, 14 Nov 2011 03:36:34 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.3.103] (unknown [203.69.99.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9E6711BD9196; Mon, 14 Nov 2011 03:36:33 -0800 (PST) References: <1538999065.280078.1321201922021.JavaMail.root@zmbs1.inria.fr> <9da83f41cc0f890394a2d666b4e3a167@mail.gmail.com> In-Reply-To: <9da83f41cc0f890394a2d666b4e3a167@mail.gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-F078C5A2-5512-4951-B8C5-9EC5CA5EB244 Message-Id: X-Mailer: iPad Mail (9A334) From: Thomas Heide Clausen Date: Mon, 14 Nov 2011 19:37:00 +0800 To: Yoav Ben-Yehezkel Cc: "roll@ietf.org" Subject: Re: [Roll] regarding DIS Modifications draft (draft-goyal-roll-dis-modifications-00) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 11:36:37 -0000 --Apple-Mail-F078C5A2-5512-4951-B8C5-9EC5CA5EB244 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Allow me to reiterate the question that I asked at the mike: why is the beha= vior proposed by this draft (i.e., to be not considering receipt of a DIS as= an indication of inconsistency and thus not resetting trickle timers) not d= efault behavior in RPL? That the WG during the meeting did not have a clear answer to this leads me t= o believe that it should be - but I wanted to ask here as there may be a sub= tle reason....(and, if so, the conditions in which it applies or not should b= e called out in any IDs modifying the behavior). Cheers, Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) On 14 Nov 2011, at 19:09, Yoav Ben-Yehezkel wrote: > Thanks, > =20 > I didn=E2=80=99t notice the 2^ J > I take my comment back. > =20 > Best regards, > Yoav > =20 > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Em= manuel Baccelli > Sent: Monday, November 14, 2011 4:00 AM > To: roll@ietf.org > Subject: Re: [Roll] regarding DIS Modifications draft (draft-goyal-roll-di= s-modifications-00) > =20 > Hi Yoav, > good call. In fact the current specification interprets the randomization r= ange being from 0 to 2^SpreadingInterval ms. The maximum interval is thus 0= to 2^256 ms, which is quite an astronomic number already! Do you think we n= eed some more fancy way to define the range from the number specified in the= SpreadingInterval field? > Cheers > Emmanuel > =20 > =20 > On Sun, Nov 13, 2011 at 5:32 PM, Yoav Ben-Yehezkel wrote= : > Hi, > =20 > I went through the draft, it seems interesting. > =20 > I had one concern regarding the use of the Response Spreading Option speci= fied in 4.2. > =20 > 8 bits specified in ms can be a too small randomization for some L2 techno= logies (such as narrowband powerline). > =20 > Would it be possible to increase the number of bits (although 16 seems lik= e an overkill)? > Another option could be to divide the field into two (first part units: ms= , 10ms, 100ms, etc. and second part randomization range)? > =20 > I expect that in order to avoid collisions this randomization is best achi= eved if the units are at the magnitude of the duration of a frame or so. > =20 > Best regards, > Yoav > =20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-F078C5A2-5512-4951-B8C5-9EC5CA5EB244 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Allow me to reiterate the q= uestion that I asked at the mike: why is the behavior proposed by this draft= (i.e., to be not considering receipt of a DIS as an indication of inconsist= ency and thus not resetting trickle timers) not default behavior in RPL?

That the WG during the meeting did not have a clear an= swer to this leads me to believe that it should be - but I wanted to ask her= e as there may be a subtle reason....(and, if so, the conditions in which it= applies or not should be called out in any IDs modifying the behavior).

Cheers,

Thomas

--=  
Thomas Heide Clausen

"<= /div>


On 14 Nov 2011, at 19:09, Yoav Ben-Yehezk= el <yoav@yitran.com> wrote:
=

Thanks,

 

I didn=E2=80=99t notice the 2^ = J

I take my comment back.

 

Best regards,

Yoav

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Emmanuel Ba= ccelli
Sent: Monday, November 14, 2011 4:00 AM
To: roll@ietf.org
Subject: Re: [Roll] regarding D= IS Modifications draft (draft-goyal-roll-dis-modifications-00)

 

Hi Yoav,

good call. In fact the current specification interprets t= he randomization range being from 0 to 2^SpreadingInterval ms. The maximum i= nterval is thus  0 to 2^256 ms, which is quite an astronomic numbe= r already! Do you think we need some more fancy way to define the range from= the number specified in the SpreadingInterval field?

Cheers

Emmanuel

 

 

On Sun, Nov 13, 2011 a= t 5:32 PM, Yoav Ben-Yehezkel <yoav@yitran.com> wrote:

Hi,

 

I went through the draft, it seems interesting.

 

I had one concern regarding the use of the Response Spreading Option speci= fied in 4.2.

 

8 bits specified in ms can be a too small randomiz= ation for some L2 technologies (such as narrowband powerline).

 

Would it be possible to increase the number of bit= s (although 16 seems like an overkill)?

Another option could be to divide the field into two (first part uni= ts: ms, 10ms, 100ms, etc. and second part randomization range)?

 

I expect that in order to avoid collisions this randomizat= ion is best achieved if the units are at the magnitude of the duration of a f= rame or so.

 

Best regards,

Yoav

 


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

 

____________________= ___________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman= /listinfo/roll
= --Apple-Mail-F078C5A2-5512-4951-B8C5-9EC5CA5EB244-- From cabo@tzi.org Mon Nov 14 21:43:00 2011 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 4DF0511E80C4; Mon, 14 Nov 2011 21:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 UiNNimxzSOLL; Mon, 14 Nov 2011 21:42:58 -0800 (PST) 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 66C6A11E8098; Mon, 14 Nov 2011 21:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAF5gmN5015023; Tue, 15 Nov 2011 06:42:48 +0100 (CET) Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 23ADDC8D; Tue, 15 Nov 2011 06:42:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Carsten Bormann Date: Tue, 15 Nov 2011 13:42:39 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> To: 6lowpan <6lowpan@ietf.org>, roll@ietf.org, core WG , lwip@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: [Roll] Cross-layer issues in Constrained Node/Networks: informal get-together X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: 6lowpan <6lowpan@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, 15 Nov 2011 05:43:00 -0000 Our WGs (6LoWPAN/ROLL/CoRE/LWIG) are about making IP work well on constrained node/network environments. A number of issues in this space are cross-layer (or at least cross-WG) in nature. While these are a constant topic in the hallways, maybe we can make more progress by getting a group of people in one room. We are going to have an informal get-together to discuss some of these issues at Thu, 1740-1940, room 102 While the room maybe is not optimal for an informal discussion (and the overlap with TLS is unfortunate for some of us), it does enable use of the projector -- and it was available now that the LISP WG meeting is canceled. I'm going to try to get some structure into the discussion. The following items have been mentioned as possible subjects (drafts are mentioned as potential background material): 0 -- implications of 802.15.4g, 802.15.4e on 6LoWPAN is there anything we need to do/should be doing to make 6LoWPAN more useful with these new/extended link layers in the 802.15.4 space? Anything beyond the adaptation layer? What about security/key management? Also: other links, e.g. 6LoWPAN for Bluetooth-Low-Energy draft-ietf-6lowpan-btle-03.txt (We had a nice lunch discussion in a small group today, so we are already mostly done with the basic work on this topic) e.g., what are the interactions of the Bluetooth security protocols/attribute protocol and the things we are doing on the IP side? 1 -- 6LoWPAN-GHC and its application to ROLL, SenML and other protocols draft-bormann-6lowpan-ghc-03.txt draft-goyal-6lowpan-rpl-compression-00.txt draft-goyal-roll-rpl-compression-00.txt draft-jennings-senml-07.txt Any other protocols that would benefit significantly from 6LoWPAN-GHC? 2 -- Cross-Layer implications of the CoRE discovery discussion Discover of servers, services, and resources sometimes interacts with discovery of network elements like proxies, routers, networks. http://tools.ietf.org/html/draft-brandt-coap-subnet-discovery-00 Is there a useful overlap between application layer discovery and network layer autoconfiguration? Related: 6LoWPAN vs. HOMENET What are the implications of the HOMENET architecture document and technical proposals on the typical deployment of 6LoWPANs for home automation applications? (Implications on discovery?) 3 -- LWIG draft-bormann-lwig-guidance-00.txt what can we do to discuss APIs in a meaningful way here? what else should be in this document? 4 -- extensions for industrial applications of 6LoWPAN draft-wang-6lowpan-scheduling-requirements-00.txt Are there solutions that could be implemented in 6LoWPAN that solve some of these requirements? Is it even useful to discuss industrial applications outside of the system standards ISA100.11a/Wireless-HART/WIA-PA (i.e., is there a "pure IPv6" space waiting to be explored)? 5 -- network management for constrained node/networks What is the best place to bring the various efforts together? Should we be doing the bigger picture in the IETF NMRG? This is a lot of items, and we won't cover all of them in these two hours, but maybe we can at least make interested people known to each other and spin off further hallway discussions. Maybe we can go through the items in this sequence (i.e., =E2=89=A4 10 = minutes per number) in the first hour and then revisit points that merit more discussion. If you want to make a more structured contribution to, or lead, any one of these points, please tell me (and send a slide or two,=20= if useful). Gruesse, Carsten PS.: To be redundantly clear, let me add this Disclaimer: This is not a BOF, not even a Bar-BOF. It is not about drumming up support for some potential work. Just about technical discussion. No intent to forcibly draw in ADs... PPS.: I have attempted to set a reply-to to 6lowpan. Feel free to answer to *one* of the WGs. Please don't spam all four. From angelo.castellani@gmail.com Tue Nov 15 00:44:20 2011 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 D85A721F8FBF; Tue, 15 Nov 2011 00:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 oYFUPwxl913N; Tue, 15 Nov 2011 00:44:20 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 683E921F8FC1; Tue, 15 Nov 2011 00:44:19 -0800 (PST) Received: by wwe5 with SMTP id 5so4069940wwe.13 for ; Tue, 15 Nov 2011 00:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=l/VV90Z3ZVSOjeRfbwdWFjmFD4CIZM9s/KdvMib9URA=; b=XTEJgS8D6qkZNrG9deRG0j4SXt/ddxln6qxdxfk6+q2JIJeQ/8XO+mxTtoe8fpspo8 i5F/rKfbDIMsQyQWOdPKXETL07bfCHQr1rnAcT3+fwmJ+wAzKlALNNMqj2BgSqefayOj 7ZB4UKFa88g2hdzc6hTPUjbaOMdzDuaQ6hof0= Received: by 10.216.14.206 with SMTP id d56mr238784wed.33.1321346657131; Tue, 15 Nov 2011 00:44:17 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.62.8 with HTTP; Tue, 15 Nov 2011 00:43:36 -0800 (PST) In-Reply-To: References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> From: "Angelo P. Castellani" Date: Tue, 15 Nov 2011 09:43:36 +0100 X-Google-Sender-Auth: 0SyBWOqg3ArIZ9AXELR7aYn5iIg Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: lwip@ietf.org, roll WG , 6lowpan@ietf.org, Thomas Fossati , core WG Subject: Re: [Roll] [core] Cross-layer issues in Constrained Node/Networks: informal get-together X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 08:44:21 -0000 I will enjoy hearing to your talk and even send my comments to jabber, if will be possible for you to use the microphone on the vast majority of time (not always as during a formal WG meeting). If using the microphone frequently is a problem, it would be probably better to discuss offline the results of this informal meeting. BTW, do you plan to circulate some notes after this informal talk? Angelo On Tue, Nov 15, 2011 at 09:29, Carsten Bormann wrote: > On Nov 15, 2011, at 15:44, Thomas Fossati wrote: > >> is there any chance to get at least the audio streaming of the meeting ? > > Well, this is more of a brainstorming gathering, and I'm not sure I want = to enforce religious use of the microphone. > > I think the stream from room 102 should work in principle, so if you go t= o http://ietf82streaming.dnsalias.net/ietf/ietf825.m3u you should have a go= od chance of hearing faint voices arguing in the background noise. =C2=A0We= also can try to have a jabber monitor (probably not a "jabber scribe", tho= ugh). > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From Emmanuel.Nataf@loria.fr Tue Nov 15 07:59:57 2011 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 BC64711E808A for ; Tue, 15 Nov 2011 07:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.394 X-Spam-Level: X-Spam-Status: No, score=-7.394 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 RTf2ydNyN8ES for ; Tue, 15 Nov 2011 07:59:53 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBC821F8ADE for ; Tue, 15 Nov 2011 07:59:48 -0800 (PST) From: Emmanuel.Nataf@loria.fr X-IronPort-AV: E=Sophos;i="4.69,515,1315173600"; d="scan'208,217";a="119119193" Received: from leod.loria.fr ([152.81.15.93]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 15 Nov 2011 16:59:46 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-2--531797163 Date: Tue, 15 Nov 2011 16:59:46 +0100 Message-Id: <8FADA460-0444-4A0D-A8AF-7F0154EB0BBC@loria.fr> To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Patrick Olivier Kamgueu Subject: [Roll] =?utf-8?b?IM6jz4fOtc+EOiBTb21lIGNvbW1lbnRzIGFib3V0IGRyYWZ0?= =?utf-8?q?-zahariadis-roll-metrics-composition-01?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 15:59:57 -0000 --Apple-Mail-2--531797163 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, We are in a research team interested by routing metric composition in = sensors network. We agree with the draft but have some comments : Comment 1 In [draft-zahariadis-roll-metrics-composition-01] section 4.9 Composite = metric MUST hold properties of isotonicity and monotonicity=20 (paragraph just before figure 7) you claim: Since the contribution of any path increases the non-negative composite = metric value and one is minimizing along the non-decreasing paths, the = metric satisfies the property of monotonicity. =20 This text can be understood as the composite metric with = =91<=92 as the composite metric order relation satisfies the property of = monotonicity. When we examine figure 7, we can see that w(A,C,D) =3D 13 = and w(A,C,D,E) =3D 13. Since w(A,C,D,E) is not greater than w(A,C,D), = the monotonicity cannot hold. Worst if we change the node (E) Throughput = to 1 (rather than 2), we compute w(A,C,D,E) =3D 12 (and then w(A,C,D,E) = < w(A,C,D)), which decrease the path weight. =20 Comment 2 In [draft-zahariadis-roll-metrics-composition-01] section 2.2 Metric = Operator (First paragraph) you claim: According to [I-D.ietf-roll-routing-metrics], a metric can either be = recorded or aggregated along the path. In the former case, the metric = can be of maximum type (A=3D0x01) or minimum type (A=3D0x02), while in = the latter case, a metric can be of additive type (A=3D0x00) or = multiplicative type (A=3D0x03). =20 The referenced draft rather mention (section 2.1 DAG Metric Container = Format, page 9 paragraph 3) The A field is only relevant for metrics and is used to indicate whether the aggregated routing metric is additive, multiplicative, reports a maximum or a minimum. Reference that contradicts what you say. A field is relevant only when = using aggregated metric, and must take one of the following values = (A=3D0X00 additive, A=3D0x01 maximum A=3D0x02 minimum and A=3D0x00 = multiplicative) > Dear Nicolas, >=20 > Thanks for commenting this draft. > We will soon update the draft taking into consideration your comments. > See our reply below. >=20 > Best Regards, > Panos Trakadas. >=20 > ----- Original Message ----- From: "Nicolas DEJEAN" = > To: ; > Sent: Tuesday, October 04, 2011 6:00 PM > Subject: Some comments about = draft-zahariadis-roll-metrics-composition-01 >=20 >=20 > Hello, >=20 >..... > Example 6 and Figure 7: I do not really understand the figure there. > What are the local values (certainly L and T link properties)? > Whar are the values advertised (i.e. the ones the potential successor > have to take into account for computong their own)? >=20 > ->Panos: Correct. This is the only example that does not show link = values, but node values, confusing the reader. We will modify it = according to your comment. >=20 > I agree that with the 'bad' compound metric used, it seems that > sub-optimal paths are used. However, in this example, practically the > parent choice is the good one as the only available candidate for (E) > is (D). > Maybe a more complex example would show the selection of the wrong = parent ... >=20 > ->Panos: Of course node E selects node D, as its only parent. What we = are highlighting is that since the metric is not isotonic, >when node D = is the source, it selects path (A,B,D), while when node D acts as a = relay node, forwarding traffic of E, then it will >select path (A,C,D) = which is not the optimal one. >=20 This seems to be a source routing mechanism that is not present in RPL = (as our knowledge).=20 Maybe the figure bellow is a better answer that show how non = isotonicity can lead to a sub-optimal path selection. +-------------------------------------------------------------------+ | ------------ (A) <1 , 10> | | / / \ | | / / \ | | / / \ | | / / \ | | / / \ | | / / \ | | / / \ | | <6 , 8> (F) <3 , 2> (B) (C) <1 , 9> | | | \ / | | | \ / | | | \ / | | | \ / | | <4 , 3> (G) \ / | | | \ / | | | \ / | | | <2 , 8> (D) w(A,B,D) =3D <6 , 2> =3D 8 = | | | | w(A,C,D) =3D <4 , 8> =3D 12 = | | \ | | | \ | | | \ <6 , 2> (E) w(A,B,D,E) =3D <12 , 2> =3D 14 = | | \ ----------/ w(A,C,D,E) =3D <10 , 2> =3D 12 = | | \ / | | \ / | | <1 , 1> (H) w(A,F,G,H) =3D <12 , 1> =3D 13 = | | w(A,B,D,E,H) =3D <13 , 1> =3D 14 = | | w(A,C,D,E,H) =3D <11 , 1> =3D 12 = | | | +-------------------------------------------------------------------+ In this case we have modified the C node latency (from 2 to 1) and added = nodes F to H. As in the figure in the draft, first the node D propagates in DIO the = lightest path toward A (A,B,D). Second the node E propagates the path = toward A (A,B,D,E) with a weight of 14. At the other side, the path from = H to A (A,F,G,H) has a weight of 13 and so will be choose by the node H.=20= However the best path according to this metric composition is the one = which pass through E and C (A,C,D,E,H). This example shows that the non = isotonicity of such composition will lead to a non optimal routing.=20 Emmanuel Nataf Patrick Olivier Kamgueu --Apple-Mail-2--531797163 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

We are in a research team interested by = routing metric composition in sensors network. We agree with the draft = but have some comments :

Comment 1

In = [draft-zahariadis-roll-metrics-composition-01] section 4.9 Composite = metric MUST hold properties of isotonicity and = monotonicity 

(paragraph just before figure 7) you = claim:

Since =
the contribution of any path increases the non-negative composite metric =
value and one is minimizing along the non-decreasing paths, the metric =
satisfies the property of monotonicity.
 

This text can be understood as the composite = metric <Latency + T> with =91<=92 as the composite metric order = relation satisfies the property of monotonicity. When we examine figure = 7, we can see that w(A,C,D) =3D 13 and w(A,C,D,E) =3D 13. Since w(A,C,D,E) is not greater than w(A,C,D), the monotonicity = cannot hold. Worst if we change the node (E) Throughput to 1 (rather = than 2), we compute w(A,C,D,E) =3D 12 (and = then ), which decrease = the path weight.

 

Comment = 2

In = [draft-zahariadis-roll-metrics-composition-01] section 2.2 Metric = Operator (First paragraph) you claim:

According to = [I-D.ietf-roll-routing-metrics], a metric can either be recorded or = aggregated along the path. In the former case, the metric can be of = maximum type (A=3D0x01) or minimum type (A=3D0x02), while in the latter = case, a metric can be of additive type (A=3D0x00) or multiplicative type = (A=3D0x03).

 

The referenced draft rather mention (section 2.1 DAG Metric = Container Format, page 9 paragraph 3)


   The A field is only relevant for metrics =
and is
   used to indicate whether the aggregated routing metric is additive,
   multiplicative, reports a maximum or a =
minimum.


Reference that contradicts what you say. A field is = relevant only when using aggregated metric, and must take one of the = following values (A=3D0X00 additive, A=3D0x01 maximum A=3D0x02 minimum = and A=3D0x00 multiplicative)



> Dear Nicolas,
> 
> Thanks for commenting this draft.
> We will soon update the draft = taking into consideration your comments.
> See our reply = below.
> = Best Regards,
> = Panos Trakadas.
> = ----- Original Message ----- From: "Nicolas DEJEAN" <nicolas.dejean.ietf at googlemail.com>
> To: <zahariad at = teihal.gr>; = <trakadasp at = adae.gr> Sent: = Tuesday, October 04, 2011 6:00 PM
> Subject: Some comments about = draft-zahariadis-roll-metrics-composition-01
> 
> 
> Hello,
> 
>.....

> = Example 6 and Figure 7: I do not really understand the figure = there.
> What = are the local values (certainly L and T link = properties)?
> = Whar are the values advertised (i.e. the ones the potential = successor
> have = to take into account for computong their own)?
> 
> ->Panos: Correct. This is the = only example that does not show link values, but node values, confusing = the reader. We will modify it according to your comment.
> 
> I agree that with the 'bad' = compound metric used, it seems that
> sub-optimal paths are used. = However, in this example, practically the
> parent choice is the good one as = the only available candidate for (E)
> is (D).
> Maybe a more complex example = would show the selection of the wrong parent ...
> 
> ->Panos: Of course node E = selects node D, as its only parent. What we are highlighting is that = since the metric is not isotonic, >when node D is the source, it = selects path (A,B,D), while when node D acts as a relay node, forwarding = traffic of E, then it will >select path (A,C,D) which is not the = optimal one.

This seems to be a = source routing mechanism that is not present in RPL (as our = knowledge). 

Maybe the figure = bellow is a better answer  that show how non isotonicity can lead = to a sub-optimal path selection.

   |           =         ------------ (A) <1 , 10>   =                     = |
   |       =           /           =   /   \               =                 |
   |       =         /             = /       \             =                 |
   |       =       /             / =           \           =                 |
   |  <6 , 8> = (F)    <3 , 2> (B)           =   (C) <1 , 9>             =   |
   |           = |              \       =       /              =             |
   |     =       |               = \           /         =                   = |
   |       =     |                 = \       /             =                 |
   |           = |                   \ =   /                   =             |
   |     =       |              =       \ /              =                   = |
   |       =     |                 =     |  w(A,C,D) =3D <4 , 8> =3D 12    =     |
   |          =   \                  =   |                   =               |
   |      =         \         <6 , 2> = (E) w(A,B,D,E) =3D <12 , 2> =3D 14     |
   |          =       \    /           =                     =               |
   |       =   <1 , 1> (H) w(A,F,G,H) =3D <12 , 1> =3D 13  =                   = |
   |     =                 w(A,C,D,E,H) =3D = <11 , 1> =3D 12              =     |
   |           =                     =                     =                 |


In = this case we have modified the C node latency (from 2 to 1) and added = nodes F to H.
As in the figure in the draft, first the node D = propagates in DIO the lightest path toward A (A,B,D). Second the node E = propagates the path toward A (A,B,D,E) with a weight of 14. At the other = side, the path from H to A (A,F,G,H) has a weight of 13 and so will be = choose by the node H. 

However the best path = according to this metric composition is the one which pass through E and = C (A,C,D,E,H). This example shows that the non isotonicity of such = composition will lead to a non optimal = routing. 

Emmanuel = Nataf
Patrick Olivier = Kamgueu






= --Apple-Mail-2--531797163-- From gnawali@cs.uh.edu Tue Nov 15 12:40:24 2011 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 63C9D1F0C92 for ; Tue, 15 Nov 2011 12:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZgw7KvloMnU for ; Tue, 15 Nov 2011 12:40:23 -0800 (PST) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id B485C1F0C76 for ; Tue, 15 Nov 2011 12:40:23 -0800 (PST) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 5DDC023CA89 for ; Tue, 15 Nov 2011 14:40:24 -0600 (CST) 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 vd+mfEsEicuB for ; Tue, 15 Nov 2011 14:40:21 -0600 (CST) Received: from it.cs.uh.edu (it.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 64E2523CA80 for ; Tue, 15 Nov 2011 14:40:21 -0600 (CST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by it.cs.uh.edu (Postfix) with ESMTP id 91AE52A280C8 for ; Tue, 15 Nov 2011 14:58:18 -0600 (CST) Received: by yenq4 with SMTP id q4so5443840yen.31 for ; Tue, 15 Nov 2011 12:40:19 -0800 (PST) Received: by 10.68.74.34 with SMTP id q2mr45693332pbv.13.1321389619108; Tue, 15 Nov 2011 12:40:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.76.12 with HTTP; Tue, 15 Nov 2011 12:39:58 -0800 (PST) In-Reply-To: <09d401cc7d25$ffa16150$fee423f0$@olddog.co.uk> References: <09d401cc7d25$ffa16150$fee423f0$@olddog.co.uk> From: Omprakash Gnawali Date: Tue, 15 Nov 2011 14:39:58 -0600 Message-ID: To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll@ietf.org Subject: Re: [Roll] AD review of draft-ietf-roll-minrank-hysteresis-of-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 20:40:24 -0000 Adrian, thanks for the feedback. I have incorporated some of your comments, but there are some items I wanted to run by you before posting a new version: ... > > In progressing the OG0 draft we learnt that there was no clear > understanding of what an objective function is. I think your draft does > a good job at explaining, but in an attempt to learn from the past, can > you please have a look at the text that got added to the OF0 document to > see whether anything can be added here. I looked through both the drafts and also rpl draft. I could mention the relevant sections of RPL draft in the first sentence of section 1: An objective function specifies how RPL [I-D.ietf-roll-rpl] selects paths. to: An objective function describes how RPL [I-D.ietf-roll-rpl] selects paths within the role defined in Section 3.2.1 and using the guidelines listed in Section 14 of [I-D.ietf-roll-rpl]. Isn't that better than every OF draft describing what an OF is and what it is supposed to do? > --- > > Why is "Minimum Rank Objective Function with Hysteresis" MRHOF not > MROFH? We can change the name to Minimum Rank Hysteresis Objective Function. > > --- > > During the review process for OF0 we ended up adding the following > paragraph. Would you consider adding something similar to make this > point crystal clear? > > =A0 The RPL specification [I-D.ietf-roll-rpl] requires the use of a > =A0 common OF by all nodes in a network. =A0The possible use of multiple > =A0 OFs with a single network is for further study. Do you prefer to repeat this in each OF draft, even though it is already mentioned in rpl draft? ... > Section 5.1 > > Can you add a statement on default values? Here is the current statement on default values: The parameter values are assigned depending on the selected metric. The best values for these parameters should be experimentally determined. The working group has long experience routing with the ETX metric. Based on those experiences, these values are RECOMMENDED: If you think it would be better to clarify some aspect of the above statement or something additional, I am happy to add those statements. I will put the above statem= ent and the table of default values as a separate subsection (5.1) and manageab= ility will become 5.2. > > Can you also have a look at Section 7 of the OF0 draft. This gives a > more substantive approach to describing manageability. How about changing: The parameters MAX_LINK_METRIC, MAX_PATH_COST, MIN_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT should be configurable. to Out of the box, the parameters MAX_LINK_METRIC, MAX_PATH_COST, MIN_PATH_= COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT should be set to the default values. The default value MAY be different from the ones described in Section 5.1. These values may be further modified using guidelines in Section 16 of [I-D.ietf-roll-rpl]. - om_p From jpv@cisco.com Wed Nov 16 02:27:06 2011 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 73DD521F9501 for ; Wed, 16 Nov 2011 02:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Kwj7DFglA+Qn for ; Wed, 16 Nov 2011 02:27:05 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB6221F94C1 for ; Wed, 16 Nov 2011 02:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4228; q=dns/txt; s=iport; t=1321439225; x=1322648825; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=bNVyIdWdvHW5LXYZVzRYp0ubSh6r6JgLSj+vWkLhURc=; b=UaXdF3nOZ+pFE+dwS03RsGA+V1xsSL903CTrEHt1DAW5kRsxn5d0GO2a IqibwLukzRM+ruMG70VftICg5k8TSdGBGf4uO/qTkdofEl/LeezszgifV LgGtutKcP/h+WLm9fRBLN6+4eTh5gwxtVQhhT+2rHHFOSk0XMrfT4zF5P I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkAALqPw06Q/khM/2dsb2JhbABDDplhkAWBBYFyAQEBAwEBAQEPASc0CwULCxEDAQEBLycoCAYTCRmHYAiaaAGeYYk0YwSUNIU7CYwBNw X-IronPort-AV: E=Sophos;i="4.69,520,1315180800"; d="scan'208";a="3203235" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 16 Nov 2011 10:26:49 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAGAQndS019513; Wed, 16 Nov 2011 10:26:49 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 11:26:49 +0100 Received: from [10.61.180.91] ([10.61.82.200]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 11:26:49 +0100 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <736630399.709598.1318899920135.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Wed, 16 Nov 2011 08:33:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <736630399.709598.1318899920135.JavaMail.root@mail05.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1251.1) X-OriginalArrivalTime: 16 Nov 2011 10:26:49.0281 (UTC) FILETIME=[3FDBDB10:01CCA44A] Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 10:27:06 -0000 Hi Mukul, On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: > Hi JP >=20 > I was wondering if the term "RPL Domain" could be defined in the = terminology draft.=20 >=20 How about RPL domain: set of devices using RPL as a routing protocol. Thanks. JP. > Thanks > Mukul=20 >=20 > ----- Forwarded Message ----- > From: "Joseph Reddy" > To: ipv6@ietf.org > Sent: Friday, October 14, 2011 7:15:05 PM > Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >=20 >=20 > Hi Jonathan, >=20 > The draft uses the term "RPL domain" in several places and this is not = clearly defined.=20 >=20 > I would imagine that it includes all nodes that are downstream of the = RPL border router. But can you clarify if Host nodes that are downstream = of the border router but do not implement any part of RPL ( even as RPL = Leaf nodes ) should be considered part of the "RPL domain" ? >=20 > In section 5, the draft now says "..Datagrams destined to nodes = outside the RPL domain are dropped if the outer-most IPv6 header = contains a RPL Option..." >=20 > This text would imply that any RPL node sending packets to nodes = outside should always tunnel to the Root ? Is that the intention really = or am I missing something here..=20 >=20 > Also note that if non-RPL Host is not considered part of the RPL = domain, then I am not sure that a forwarding router can know if the = destination is inside the domain or not.=20 >=20 >=20 > -Regards, Joseph >=20 >=20 > ------------------------------ >=20 > Message: 5 > Date: Tue, 11 Oct 2011 22:23:10 -0700 > From: Jonathan Hui > To: IETF IPv6 Mailing List > Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt > Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> > Content-Type: text/plain; charset=3Dus-ascii >=20 >=20 > This update is intended to address Jari Arkko's AD review. >=20 > Summary of changes: > - Clarify when the RPL Option is used. > - Updated text on recommendations for avoiding fragmentation. > - Specify skip-over-and-continue policy for unrecognized sub-TLVs. > - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. > - Specify RPL Border Router operations in terms of forwarding decision = outcomes. > - Expand security section. >=20 > -- > Jonathan Hui >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: October 11, 2011 10:17:15 PM PDT >> To: i-d-announce@ietf.org >> Cc: ipv6@ietf.org >> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Maintenance Working = Group of the IETF. >>=20 >> Title : RPL Option for Carrying RPL Information in = Data-Plane Datagrams >> Author(s) : Jonathan W. Hui >> JP Vasseur >> Filename : draft-ietf-6man-rpl-option-04.txt >> Pages : 14 >> Date : 2011-10-11 >>=20 >> The RPL protocol requires data-plane datagrams to carry RPL routing >> information that is processed by RPL routers when forwarding those >> datagrams. This document describes the RPL Option for use within a >> RPL domain. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ietf@thomasclausen.org Wed Nov 16 02:40:25 2011 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 D760521F95E5 for ; Wed, 16 Nov 2011 02:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 KdhrKDDUdtI4 for ; Wed, 16 Nov 2011 02:40:25 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 125D621F95DD for ; Wed, 16 Nov 2011 02:40:25 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C4BA1A6555 for ; Wed, 16 Nov 2011 02:40:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 73079C0109; Wed, 16 Nov 2011 02:40:24 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.3.103] (unknown [203.69.99.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 1FC90C0108; Wed, 16 Nov 2011 02:40:22 -0800 (PST) References: <736630399.709598.1318899920135.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3637B756-CB0E-4AD6-8756-0D09D5403D2C@thomasclausen.org> X-Mailer: iPad Mail (9A334) From: Thomas Heide Clausen Date: Wed, 16 Nov 2011 18:40:48 +0800 To: JP Vasseur Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 10:40:25 -0000 Dear Jean-Philippe, That definition doesn't really capture anything interesting or useful.=20 If 40 devices are within communication range of each other, and able to form= a connected graph, are they then in one "RPL domain"? Can you have these 40= devices form two RPL Domains of 20 devices each? What is the frontier betwe= en such two domains like? What impacts does it have? If I have 20 devices running RPL here in Taiwan, and JP, you have 20 devices= running RPL at home in Grenoble, but our low-power-lossy links do not allow= your devices to talk to mine, do our 40 devices then form, together, an "RP= L Domain"? The definition you propose allows for these 40 devices to be cons= idered as one "RPL domain", but I am not sure that I see the usefulness of s= uch a definition. If the answer is "we don't know how to define it" then perhaps the definitio= n isn't useful and the I-D should just talk about "a bunch of devices runnin= g RPL" - or the group should consider carefully formulating a helpful defini= tion? --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) On 16 Nov 2011, at 16:33, JP Vasseur wrote: > Hi Mukul, >=20 > On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >=20 >> Hi JP >>=20 >> I was wondering if the term "RPL Domain" could be defined in the terminol= ogy draft.=20 >>=20 >=20 > How about >=20 > RPL domain: set of devices using RPL as a routing protocol. >=20 > Thanks. >=20 > JP. >=20 >> Thanks >> Mukul=20 >>=20 >> ----- Forwarded Message ----- >> From: "Joseph Reddy" >> To: ipv6@ietf.org >> Sent: Friday, October 14, 2011 7:15:05 PM >> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>=20 >>=20 >> Hi Jonathan, >>=20 >> The draft uses the term "RPL domain" in several places and this is not cl= early defined.=20 >>=20 >> I would imagine that it includes all nodes that are downstream of the RPL= border router. But can you clarify if Host nodes that are downstream of the= border router but do not implement any part of RPL ( even as RPL Leaf nodes= ) should be considered part of the "RPL domain" ? >>=20 >> In section 5, the draft now says "..Datagrams destined to nodes outside t= he RPL domain are dropped if the outer-most IPv6 header contains a RPL Optio= n..." >>=20 >> This text would imply that any RPL node sending packets to nodes outside s= hould always tunnel to the Root ? Is that the intention really or am I missi= ng something here..=20 >>=20 >> Also note that if non-RPL Host is not considered part of the RPL domain, t= hen I am not sure that a forwarding router can know if the destination is in= side the domain or not.=20 >>=20 >>=20 >> -Regards, Joseph >>=20 >>=20 >> ------------------------------ >>=20 >> Message: 5 >> Date: Tue, 11 Oct 2011 22:23:10 -0700 >> From: Jonathan Hui >> To: IETF IPv6 Mailing List >> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >> Content-Type: text/plain; charset=3Dus-ascii >>=20 >>=20 >> This update is intended to address Jari Arkko's AD review. >>=20 >> Summary of changes: >> - Clarify when the RPL Option is used. >> - Updated text on recommendations for avoiding fragmentation. >> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >> - Specify RPL Border Router operations in terms of forwarding decision ou= tcomes. >> - Expand security section. >>=20 >> -- >> Jonathan Hui >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: October 11, 2011 10:17:15 PM PDT >>> To: i-d-announce@ietf.org >>> Cc: ipv6@ietf.org >>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. This draft is a work item of the IPv6 Maintenance Working Group of t= he IETF. >>>=20 >>> Title : RPL Option for Carrying RPL Information in Data-Pla= ne Datagrams >>> Author(s) : Jonathan W. Hui >>> JP Vasseur >>> Filename : draft-ietf-6man-rpl-option-04.txt >>> Pages : 14 >>> Date : 2011-10-11 >>>=20 >>> The RPL protocol requires data-plane datagrams to carry RPL routing >>> information that is processed by RPL routers when forwarding those >>> datagrams. This document describes the RPL Option for use within a >>> RPL domain. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=294de8a4a=mukul@uwm.edu Wed Nov 16 02:46:00 2011 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 27C8321F95FD for ; Wed, 16 Nov 2011 02:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSK6CjkPpY5V for ; Wed, 16 Nov 2011 02:45:59 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 31B8E21F95FA for ; Wed, 16 Nov 2011 02:45:59 -0800 (PST) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 16 Nov 2011 04:45:58 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 6A61212E3B2; Wed, 16 Nov 2011 04:45:58 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3uEQGBrND2I; Wed, 16 Nov 2011 04:45:58 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id F3A5A12E3B1; Wed, 16 Nov 2011 04:45:57 -0600 (CST) Date: Wed, 16 Nov 2011 04:45:57 -0600 (CST) From: Mukul Goyal To: JP Vasseur Message-ID: <687807886.312500.1321440357901.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 10:46:00 -0000 Hi JP >RPL domain: set of devices using RPL as a routing protocol. I think this definition is little too vague. Some of the points that need clarification: 1. It is clear that RPL hosts and routers (as defined towards the end of terminology section in RPL-19) are within an RPL domain but what about the RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagine that such hosts are also within an RPL domain. 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or is it that an RPL domain is same as an LLN using RPL as a routing protocol? Thanks Mukul ----- Original Message ----- From: "JP Vasseur" To: "Mukul Goyal" Cc: "roll" Sent: Wednesday, November 16, 2011 2:33:50 AM Subject: Re: definition of "RPL Domain" Hi Mukul, On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: > Hi JP > > I was wondering if the term "RPL Domain" could be defined in the terminology draft. > How about RPL domain: set of devices using RPL as a routing protocol. Thanks. JP. > Thanks > Mukul > > ----- Forwarded Message ----- > From: "Joseph Reddy" > To: ipv6@ietf.org > Sent: Friday, October 14, 2011 7:15:05 PM > Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt > > > Hi Jonathan, > > The draft uses the term "RPL domain" in several places and this is not clearly defined. > > I would imagine that it includes all nodes that are downstream of the RPL border router. But can you clarify if Host nodes that are downstream of the border router but do not implement any part of RPL ( even as RPL Leaf nodes ) should be considered part of the "RPL domain" ? > > In section 5, the draft now says "..Datagrams destined to nodes outside the RPL domain are dropped if the outer-most IPv6 header contains a RPL Option..." > > This text would imply that any RPL node sending packets to nodes outside should always tunnel to the Root ? Is that the intention really or am I missing something here.. > > Also note that if non-RPL Host is not considered part of the RPL domain, then I am not sure that a forwarding router can know if the destination is inside the domain or not. > > > -Regards, Joseph > > > ------------------------------ > > Message: 5 > Date: Tue, 11 Oct 2011 22:23:10 -0700 > From: Jonathan Hui > To: IETF IPv6 Mailing List > Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt > Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> > Content-Type: text/plain; charset=us-ascii > > > This update is intended to address Jari Arkko's AD review. > > Summary of changes: > - Clarify when the RPL Option is used. > - Updated text on recommendations for avoiding fragmentation. > - Specify skip-over-and-continue policy for unrecognized sub-TLVs. > - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. > - Specify RPL Border Router operations in terms of forwarding decision outcomes. > - Expand security section. > > -- > Jonathan Hui > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Date: October 11, 2011 10:17:15 PM PDT >> To: i-d-announce@ietf.org >> Cc: ipv6@ietf.org >> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. >> >> Title : RPL Option for Carrying RPL Information in Data-Plane Datagrams >> Author(s) : Jonathan W. Hui >> JP Vasseur >> Filename : draft-ietf-6man-rpl-option-04.txt >> Pages : 14 >> Date : 2011-10-11 >> >> The RPL protocol requires data-plane datagrams to carry RPL routing >> information that is processed by RPL routers when forwarding those >> datagrams. This document describes the RPL Option for use within a >> RPL domain. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From thomas@thomasclausen.org Wed Nov 16 04:25:05 2011 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 48B8221F9472 for ; Wed, 16 Nov 2011 04:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Hi3+Kj8tVb3r for ; Wed, 16 Nov 2011 04:25:04 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7595821F9477 for ; Wed, 16 Nov 2011 04:25:04 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 37F72CCFFA for ; Wed, 16 Nov 2011 04:25:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DAC77C129C; Wed, 16 Nov 2011 04:25:02 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.3.103] (unknown [203.69.99.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 3CC68C1287; Wed, 16 Nov 2011 04:25:02 -0800 (PST) References: <687807886.312500.1321440357901.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <687807886.312500.1321440357901.JavaMail.root@mail17.pantherlink.uwm.edu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9A334) From: Thomas Heide Clausen Date: Wed, 16 Nov 2011 20:25:31 +0800 To: Mukul Goyal Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 12:25:05 -0000 Now that we are at it: what is an RPL host? Or rather, why is this even a co= nceivable thing to define? Afaik, RPL is a routing protocol, and as such sho= uld concern only routers - not hosts? I worry if this is inventing an entire ecosystem which "pretends to be just l= ike the Internet, except it is not", as it needs entirely new stacks, protoc= ols, translators/gateways everywhere, and with no real traces of IP as we kn= ow it remaining? --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) On 16 Nov 2011, at 18:45, Mukul Goyal wrote: > Hi JP >=20 >> RPL domain: set of devices using RPL as a routing protocol. >=20 > I think this definition is little too vague. Some of the points that need c= larification: >=20 > 1. It is clear that RPL hosts and routers (as defined towards the end of t= erminology section in RPL-19) are within an RPL domain but what about the RP= L-unaware IPv6 hosts attached to an RPL router/host? I would imagine that su= ch hosts are also within an RPL domain. >=20 > 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of R= PL instances in the LLN? Can multiple RPL domains exist within an LLN? Or is= it that an RPL domain is same as an LLN using RPL as a routing protocol? >=20 > Thanks > Mukul =20 >=20 > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: "roll" > Sent: Wednesday, November 16, 2011 2:33:50 AM > Subject: Re: definition of "RPL Domain" >=20 > Hi Mukul, >=20 > On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >=20 >> Hi JP >>=20 >> I was wondering if the term "RPL Domain" could be defined in the terminol= ogy draft.=20 >>=20 >=20 > How about >=20 > RPL domain: set of devices using RPL as a routing protocol. >=20 > Thanks. >=20 > JP. >=20 >> Thanks >> Mukul=20 >>=20 >> ----- Forwarded Message ----- >> From: "Joseph Reddy" >> To: ipv6@ietf.org >> Sent: Friday, October 14, 2011 7:15:05 PM >> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>=20 >>=20 >> Hi Jonathan, >>=20 >> The draft uses the term "RPL domain" in several places and this is not cl= early defined.=20 >>=20 >> I would imagine that it includes all nodes that are downstream of the RPL= border router. But can you clarify if Host nodes that are downstream of the= border router but do not implement any part of RPL ( even as RPL Leaf nodes= ) should be considered part of the "RPL domain" ? >>=20 >> In section 5, the draft now says "..Datagrams destined to nodes outside t= he RPL domain are dropped if the outer-most IPv6 header contains a RPL Optio= n..." >>=20 >> This text would imply that any RPL node sending packets to nodes outside s= hould always tunnel to the Root ? Is that the intention really or am I missi= ng something here..=20 >>=20 >> Also note that if non-RPL Host is not considered part of the RPL domain, t= hen I am not sure that a forwarding router can know if the destination is in= side the domain or not.=20 >>=20 >>=20 >> -Regards, Joseph >>=20 >>=20 >> ------------------------------ >>=20 >> Message: 5 >> Date: Tue, 11 Oct 2011 22:23:10 -0700 >> From: Jonathan Hui >> To: IETF IPv6 Mailing List >> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >> Content-Type: text/plain; charset=3Dus-ascii >>=20 >>=20 >> This update is intended to address Jari Arkko's AD review. >>=20 >> Summary of changes: >> - Clarify when the RPL Option is used. >> - Updated text on recommendations for avoiding fragmentation. >> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >> - Specify RPL Border Router operations in terms of forwarding decision ou= tcomes. >> - Expand security section. >>=20 >> -- >> Jonathan Hui >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: October 11, 2011 10:17:15 PM PDT >>> To: i-d-announce@ietf.org >>> Cc: ipv6@ietf.org >>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. This draft is a work item of the IPv6 Maintenance Working Group of t= he IETF. >>>=20 >>> Title : RPL Option for Carrying RPL Information in Data-Pla= ne Datagrams >>> Author(s) : Jonathan W. Hui >>> JP Vasseur >>> Filename : draft-ietf-6man-rpl-option-04.txt >>> Pages : 14 >>> Date : 2011-10-11 >>>=20 >>> The RPL protocol requires data-plane datagrams to carry RPL routing >>> information that is processed by RPL routers when forwarding those >>> datagrams. This document describes the RPL Option for use within a >>> RPL domain. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From japcar@cisco.com Wed Nov 16 04:36:27 2011 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 58F9521F94E6 for ; Wed, 16 Nov 2011 04:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 vj3jei1KINlB for ; Wed, 16 Nov 2011 04:36:26 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0183C21F94D8 for ; Wed, 16 Nov 2011 04:36:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=japcar@cisco.com; l=6657; q=dns/txt; s=iport; t=1321446986; x=1322656586; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=97zkPtYGxAXg235qdS4msORpa3BMXPsQgybnxvgZDLw=; b=gM2v8AHW7k4t2SQPBhCo7b8yUX6syKxZkLRMsnpCJQ3HgGxSHE/YB2Qp yvhl4s6luO1O6reVsV1ggOrgt6E6+gNP/6E2GMfMrjbsBFWGuAL3gKV2b QdFAVYOtX7aBtsPvsUCusaaJTIwpsTPBfMHeW2MCm8yV9+CdAic8Q7chf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAPCsw05Io8UR/2dsb2JhbABDmXKPB3wCgQWBcgEBAQMBAQEBDwEnNAsFBwQCAQgRAwEBAQEuJygIAQEEEwkZh2AImkIBnmqJNGMElDSFRIxM X-IronPort-AV: E=Sophos;i="4.69,520,1315180800"; d="scan'208";a="3214332" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-3.cisco.com with ESMTP; 16 Nov 2011 12:36:22 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAGCYOTd013257; Wed, 16 Nov 2011 12:36:21 GMT Received: from xmb-hkg-413.apac.cisco.com ([64.104.123.85]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 20:36:06 +0800 Received: from 72.163.62.136 ([72.163.62.136]) by xmb-hkg-413.apac.cisco.com ([64.104.123.85]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Nov 2011 12:36:05 +0000 References: <687807886.312500.1321440357901.JavaMail.root@mail17.pantherlink.uwm.edu> Content-Transfer-Encoding: quoted-printable From: "Jeff Apcar (japcar)" Content-Type: text/plain; charset="us-ascii" thread-topic: [Roll] definition of "RPL Domain" thread-index: AcykXE7Z9U6BPX51R6ygTXSgVPnNig== In-Reply-To: Message-ID: <6773EB09-3823-457C-A6D4-72B58A26658A@cisco.com> Date: Wed, 16 Nov 2011 23:35:56 +1100 To: "Thomas Heide Clausen" MIME-Version: 1.0 (iPhone Mail 8C148) X-OriginalArrivalTime: 16 Nov 2011 12:36:06.0240 (UTC) FILETIME=[4F5DDE00:01CCA45C] Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 12:36:27 -0000 RPL devices use IPv6, 6LowPan etc. What do you mean no real traces of IP? th= e whole idea is to use IP.=20 Jeff.=20 On 16/11/2011, at 11:25 PM, "Thomas Heide Clausen" wrote: > Now that we are at it: what is an RPL host? Or rather, why is this even a c= onceivable thing to define? Afaik, RPL is a routing protocol, and as such sh= ould concern only routers - not hosts? >=20 > I worry if this is inventing an entire ecosystem which "pretends to be jus= t like the Internet, except it is not", as it needs entirely new stacks, pro= tocols, translators/gateways everywhere, and with no real traces of IP as we= know it remaining? >=20 > --=20 > Thomas Heide Clausen > http://www.thomasclausen.org/ >=20 > "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >=20 >=20 > On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >=20 >> Hi JP >>=20 >>> RPL domain: set of devices using RPL as a routing protocol. >>=20 >> I think this definition is little too vague. Some of the points that need= clarification: >>=20 >> 1. It is clear that RPL hosts and routers (as defined towards the end of t= erminology section in RPL-19) are within an RPL domain but what about the RP= L-unaware IPv6 hosts attached to an RPL router/host? I would imagine that su= ch hosts are also within an RPL domain. >>=20 >> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of= RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or i= s it that an RPL domain is same as an LLN using RPL as a routing protocol? >>=20 >> Thanks >> Mukul =20 >>=20 >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "Mukul Goyal" >> Cc: "roll" >> Sent: Wednesday, November 16, 2011 2:33:50 AM >> Subject: Re: definition of "RPL Domain" >>=20 >> Hi Mukul, >>=20 >> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>=20 >>> Hi JP >>>=20 >>> I was wondering if the term "RPL Domain" could be defined in the termino= logy draft.=20 >>>=20 >>=20 >> How about >>=20 >> RPL domain: set of devices using RPL as a routing protocol. >>=20 >> Thanks. >>=20 >> JP. >>=20 >>> Thanks >>> Mukul=20 >>>=20 >>> ----- Forwarded Message ----- >>> From: "Joseph Reddy" >>> To: ipv6@ietf.org >>> Sent: Friday, October 14, 2011 7:15:05 PM >>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>=20 >>>=20 >>> Hi Jonathan, >>>=20 >>> The draft uses the term "RPL domain" in several places and this is not c= learly defined.=20 >>>=20 >>> I would imagine that it includes all nodes that are downstream of the RP= L border router. But can you clarify if Host nodes that are downstream of th= e border router but do not implement any part of RPL ( even as RPL Leaf node= s ) should be considered part of the "RPL domain" ? >>>=20 >>> In section 5, the draft now says "..Datagrams destined to nodes outside t= he RPL domain are dropped if the outer-most IPv6 header contains a RPL Optio= n..." >>>=20 >>> This text would imply that any RPL node sending packets to nodes outside= should always tunnel to the Root ? Is that the intention really or am I mis= sing something here..=20 >>>=20 >>> Also note that if non-RPL Host is not considered part of the RPL domain,= then I am not sure that a forwarding router can know if the destination is i= nside the domain or not.=20 >>>=20 >>>=20 >>> -Regards, Joseph >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> Message: 5 >>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>> From: Jonathan Hui >>> To: IETF IPv6 Mailing List >>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>> Content-Type: text/plain; charset=3Dus-ascii >>>=20 >>>=20 >>> This update is intended to address Jari Arkko's AD review. >>>=20 >>> Summary of changes: >>> - Clarify when the RPL Option is used. >>> - Updated text on recommendations for avoiding fragmentation. >>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>> - Specify RPL Border Router operations in terms of forwarding decision o= utcomes. >>> - Expand security section. >>>=20 >>> -- >>> Jonathan Hui >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Date: October 11, 2011 10:17:15 PM PDT >>>> To: i-d-announce@ietf.org >>>> Cc: ipv6@ietf.org >>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Maintenance Working Group of t= he IETF. >>>>=20 >>>> Title : RPL Option for Carrying RPL Information in Data-Pla= ne Datagrams >>>> Author(s) : Jonathan W. Hui >>>> JP Vasseur >>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>> Pages : 14 >>>> Date : 2011-10-11 >>>>=20 >>>> The RPL protocol requires data-plane datagrams to carry RPL routing >>>> information that is processed by RPL routers when forwarding those >>>> datagrams. This document describes the RPL Option for use within a >>>> RPL domain. >>>>=20 >>>>=20 >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=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 trakadasp@yahoo.gr Wed Nov 16 04:40:10 2011 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 B95E321F9508 for ; Wed, 16 Nov 2011 04:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.127 X-Spam-Level: *** X-Spam-Status: No, score=3.127 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_20=-0.74, FRT_BELOW2=2.154, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3] 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 PpZoKmWPaCu3 for ; Wed, 16 Nov 2011 04:40:08 -0800 (PST) Received: from nm8.bullet.mail.ird.yahoo.com (nm8.bullet.mail.ird.yahoo.com [77.238.189.23]) by ietfa.amsl.com (Postfix) with SMTP id 1549221F9506 for ; Wed, 16 Nov 2011 04:40:07 -0800 (PST) Received: from [77.238.189.50] by nm8.bullet.mail.ird.yahoo.com with NNFMP; 16 Nov 2011 12:40:03 -0000 Received: from [212.82.108.116] by tm3.bullet.mail.ird.yahoo.com with NNFMP; 16 Nov 2011 12:40:03 -0000 Received: from [127.0.0.1] by omp1025.mail.ird.yahoo.com with NNFMP; 16 Nov 2011 12:40:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 508915.87350.bm@omp1025.mail.ird.yahoo.com Received: (qmail 97424 invoked by uid 60001); 16 Nov 2011 12:40:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s1024; t=1321447203; bh=VCeXRT8eE38Z75qufZKdSl9CRawb2DJjPli3PBUfiLk=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=x3N14fhUaSkNhY6wkhoqAQ3vMHqQNpZzkWuze1hI1XOmtHc8xXCwxwm+aA0KDPvMtgbH1Ps1M1DbeJTnLyYjr0hdys1I6+szoOzS17T139p2BldPJWoWOlU2qpS+g+Zf9BaFrHqgKcAXQKPtcPk0gQTfmll6dUO4gb2gFRlIjhM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.gr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=fyBJMECahVmtLnXzDJt/kP0s2rl79/2NFIxX8Ptm6P8IP38UxZDBC/CES1UgewT1yj+DCEyfaLqfKG3F8ffwFsgfwGRm2bCSCC5efvSrUfHRnv++rY4ndgtVughH8EbuajiUs2uRt+BlP9EDtzM/DJh6zDW5dSXQwoE2w0LDCuk=; X-YMail-OSG: 1MKqlJUVM1n9zYmOXoEaFH_wrMYj0gCivLPXTW9Q.j8Kko4 R2LIAh1p3sbYgAuWwE4hHEigvBecFDQrZGX88m0j2UWJEEDSxbzOPNr3ewQI mq2FgasRP3eXtTFsIzLlkMNbB9l6Ex8ke.4jSzYzajsm1pIur1ROC72tpHMz .0ZrscecLD81bfZ2sgXuPkG.5YyLwldgkIin0oxbPO2P8HfAJMQRf7Cog2qz dMVLKcIWi0wnhvMxPqpd.PzBss5koknQGjhmAd3z9yFkIZhWz9.Jwg5rhFj5 tv200fcL70TmT4Uj._AdOJmZfm.HfJLLED6OEYmEpdLZ_WBIBiz7t5AZI8uO vdnqXWXRtG7bdgA8zH7gmKwfSpMXi2cPBGev9REp_p8Skx8g3o28PxlXkX0V 0JaUYRnh95gjhYoUJEJSjNGs9TW6a33RYi.7kJAxZSxjWjdNfbaCG0UGIKzf YCm0IeOdIDZG5arL8nIEUudM1sBPAzRNyni9sv0K2NgWbTYr3W8eqP7GzH3V VfynS3TKjp7LqMhLf8hUV94Qj Received: from [83.235.46.66] by web29610.mail.ird.yahoo.com via HTTP; Wed, 16 Nov 2011 12:40:03 GMT X-Mailer: YahooMailWebService/0.8.115.325013 References: <8FADA460-0444-4A0D-A8AF-7F0154EB0BBC@loria.fr> Message-ID: <1321447203.93902.YahooMailNeo@web29610.mail.ird.yahoo.com> Date: Wed, 16 Nov 2011 12:40:03 +0000 (GMT) From: Panos Trakadas To: "Emmanuel.Nataf@loria.fr" , "roll@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-839692641-1447193047-1321447203=:93902" Cc: Patrick Olivier Kamgueu Subject: [Roll] =?iso-8859-7?b?0/fl9DogICDT9+X0OiBTb21lIGNvbW1lbnRzIGFi?= =?iso-8859-7?q?out_draft-zahariadis-roll-metrics-composition-01?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Panos Trakadas List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 12:40:10 -0000 ---839692641-1447193047-1321447203=:93902 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable Dear Emmanuel,=0A=0A=0AThanks for your comments.=0ASee our answers in line = (underlined).=0AA new version will be uploaded in the next few days, modify= ing the draft according to your comments.=0A=0A=0ABest Regards,=0APanos.=0A= =0A=0A=0A________________________________=0A=C1=F0=EF: "Emmanuel.Nataf@lori= a.fr" =0A=D0=F1=EF=F2: roll@ietf.org=0A=CA=EF=E9= =ED.: Patrick Olivier Kamgueu =0A=D3=F4=DC=EB=E8=E7=EA= =E5: 5:59 =EC.=EC. =D4=F1=DF=F4=E7, 15 =CD=EF=E5=EC=E2=F1=DF=EF=F5 2011=0A= =C8=E5=EC=E1: [Roll] =D3=F7=E5=F4: Some comments about draft-zahariadis-ro= ll-metrics-composition-01=0A=0A=0AHello,=0A=0AWe are in a research team int= erested by routing metric composition in sensors network. We agree with the= draft but have some comments :=0AComment 1=0AIn [draft-zahariadis-roll-met= rics-composition-01] section 4.9 Composite metric MUST hold properties of i= sotonicity and monotonicity=A0=0A(paragraph just before figure 7) you claim= :=0ASince the contribution of any path increases the non-negative composite= metric value and one is minimizing along the non-decreasing paths, the met= ric satisfies the property of monotonicity.=0A=A0=0AThis text=A0can be=A0un= derstood as the composite metric with =A1<=A2 as the composit= e metric order relation satisfies the property of monotonicity. When we exa= mine figure 7, we can see that=A0w(A,C,D) =3D 13=A0and=A0w(A,C,D,E) =3D 13.= Since=A0w(A,C,D,E)=A0is not greater than w(A,C,D), the monotonicity cannot= hold. Worst if we change the node (E) Throughput to 1 (rather than 2), we = compute=A0w(A,C,D,E) =3D 12=A0(and then=A0w(A,C,D,E) < w(A,C,D)), which dec= rease the path weight.=0APanos: According to section 4.9 of the draft, a ro= uting metric is monotonic if and only if w(a)<=3Dw(a&b) and w(a)<=3Dw(c&a) = (where =A2&=A2 denotes the metric operator) for any paths a,b,c, while a ro= uting metric is defined as strictly monotonicity if both w(a) =0A>= =A0=0A> ----- Original Message ----- From: "Nicolas DEJEAN" =0A> To: ; =0A> Sent: Tuesday, October 04, 2011 6:00 PM=0A> Subject: Some comment= s about draft-zahariadis-roll-metrics-composition-01=0A>=A0=0A>=A0=0A> Hell= o,=0A>=A0=0A>.....=0A=0A> Example 6 and Figure 7: I do not really understan= d the figure there.=0A> What are the local values (certainly L and T link p= roperties)?=0A> Whar are the values advertised (i.e. the ones the potential= successor=0A> have to take into account for computong their own)?=0A>=A0= =0A> ->Panos: Correct. This is the only example that does not show link val= ues, but node values, confusing the reader. We will modify it according to = your comment.=0A>=A0=0A> I agree that with the 'bad' compound metric used, = it seems that=0A> sub-optimal paths are used. However, in this example, pra= ctically the=0A> parent choice is the good one as the only available candid= ate for (E)=0A> is (D).=0A> Maybe a more complex example would show the sel= ection of the wrong parent ...=0A>=A0=0A> ->Panos: Of course node E selects= node D, as its only parent. What we are highlighting is that since the met= ric is not isotonic, >when node D is the source, it selects path (A,B,D), w= hile when node D acts as a relay node, forwarding traffic of E, then it wil= l >select path (A,C,D) which is not the optimal one.=0A>=A0=0A=0AThis seems= to be a source routing mechanism that is not present in RPL (as our knowle= dge). =0A=0A=0APanos: Utilizing recorded metrics is a "sense" of source rou= ting, isn't it?=0A=0A=0AMaybe the figure bellow is a better answer =A0that = show how non isotonicity can lead to a sub-optimal path selection.=0A=0A=A0= =A0+-------------------------------------------------------------------+=0A= =A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ------------ (A) <1 , 10> =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 / \=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 / =A0 =A0 =A0 =A0 =A0 =A0 / =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0 = =A0 =A0 =A0 =A0 =A0 / =A0 =A0 \=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 = =A0 =A0 / =A0 =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=0A=A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 / = =A0 =A0 =A0 =A0 \=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |= =0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0= =A0 =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 |= =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0= \=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 |=A0 <6 , = 8> (F)=A0 =A0 <3 , 2> (B) =A0 =A0 =A0 =A0 =A0 =A0 (C) <1 , 9> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |=0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 = =A0 \ =A0 =A0 =A0 =A0 =A0 =A0 /=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 |=0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ = =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |= =0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 = =A0 =A0 /=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0= | =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 / = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 |=A0 <4 = , 3> (G) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 /=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 | =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ /=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 = =A0 <2 , 8> (D) w(A,B,D) =3D <6 , 2> =3D 8 =A0 =A0 =A0 =A0 |=0A=A0=A0 | =A0= =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 w(A,C,D) = =3D <4 , 8> =3D 12=A0 =A0 =A0 =A0 |=0A=A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 \=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 =A0 = =A0 <6 , 2> (E) w(A,B,D,E) =3D <12 , 2> =3D 14 =A0 =A0 |=0A=A0=A0 | =A0 =A0= =A0 =A0 =A0 =A0 =A0 \=A0 =A0 =A0 ----------/ =A0 w(A,C,D,E) =3D <10 , 2> = =3D 12 =A0 =A0 |=0A=A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \=A0 =A0 / =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 |=0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \=A0 /=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |=0A=A0=A0 | =A0 =A0 =A0 =A0 <1 , 1> (H) w(A,F,G,H) =3D <12 , 1> =3D 13= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 w(A,B,D,E,H) =3D <13 , 1> =3D 14=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 |=0A=A0=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 w(A,C,D,E= ,H) =3D <11 , 1> =3D 12=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 | =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A=A0=A0 +-------= ------------------------------------------------------------+=0A=0A=0AIn th= is case we have modified the C node latency (from 2 to 1) and added nodes F= to H.=0AAs in the figure in the draft, first the node D propagates in DIO = the lightest path toward A (A,B,D). Second the node E propagates the path t= oward A (A,B,D,E) with a weight of 14. At the other side, the path from H t= o A (A,F,G,H) has a weight of 13 and so will be choose by the node H.=A0=0A= =0AHowever the best path according to this metric composition is the one wh= ich pass through E and C (A,C,D,E,H). This example shows that the non isoto= nicity of such composition will lead to a non optimal routing.=A0=0APanos: = A bit more complicated example but, for sure, indicates in a better way the= impact of non-isotonicity property. We will take into account this figure,= although we have to modify the composite metric (L+T) in such a way that m= onotonicity property holds (L+(1/T)). =0A=0A=0AEmmanuel Nataf=0APatrick Oli= vier Kamgueu=0A=0A=0A=0A=0A_______________________________________________= =0ARoll mailing list=0ARoll@ietf.org=0Ahttps://www.ietf.org/mailman/listinf= o/roll ---839692641-1447193047-1321447203=:93902 Content-Type: text/html; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable
=
Dear Emmanuel,
Thanks for your comments.
See our answers in line (underlined).
A new version will be uploaded in the next few days, modifying=0A the= draft according to your comments.

Best Regards,
Panos.

=C1=F0=EF: "Emmanuel.Nataf@loria.fr" <Emmanue= l.Nataf@loria.fr>
=D0=F1=EF=F2:<= /span> roll@ietf.org
=CA=EF=E9=ED.: Patrick Olivier Kamgueu <okamgueu@gmail.com>
=D3=F4=DC=EB=E8=E7=EA=E5: 5:59 =EC.=EC. = =D4=F1=DF=F4=E7, 15 =CD=EF=E5=EC=E2=F1=DF=EF=F5 2011
=C8=E5=EC=E1: [Roll] =D3=F7=E5=F4: Some comme= nts about draft-zahariadis-roll-metrics-composition-01

Hello,

We are in a research team = interested by routing metric composition in sensors network. We agree with = the draft but have some comments :
Comment 1
In [draft-zahariadis-roll-metrics-composition-01] se= ction 4.9 Composite metric MUST hold properties of isotonicity and monotoni= city 
(paragraph just before figure 7) you= claim:
Since the contribution of any path increases the non-negative composite me=
tric value and one is minimizing along the non-decreasing paths, the metric=
 satisfies the property of monotonicity.
 
= This text=  can be understood as the composite metric <Latency + T> wi= th =A1<=A2 as the composite metric order relation satisfies the property= of monotonicity. When we examine figure 7, we can see that w(A,C,D) =3D 13 and w(A,C,D,E) =3D 13.=0A Since = w(A,C,D,E) is not = greater than w(A,C,D), the monotonicity cannot hold. Worst if we change the= node (E) Throughput to 1 (rather than 2), we compute w(A,C,D,E) =3D 12 (and then w(A,C,D,E) < w(A,C,D)), which d= ecrease the path weight.
w(A,C,D) =3D 13 =3D w(A,C,D,E), the metric is monotonic (although not stri= ctly monotonic). The problem appears if we change the node (E) Throughput to 1 (rather than 2). In this case,= monotonicity does not hold.
We have already iden= tified the problem and we are now modifying the composite metric in or4der = to provide an example where monotonicity holds but isotonicity does not. In= this respect, we will make use of your example/figure but modified in orde= r to fulfill monotonicity property=0A requirements. The composite metric is= defined as (L+(1/T)). By doing so, the composite metric is monotonic, but = not always isotonic.

<= b id=3D"yiv135706175yui_3_2_0_17_1321420322721421">Comment 2
In [draft-zahariadis-r= oll-metrics-composition-01] section 2.2 Metric Operator (First paragraph) y= ou claim:
According to [I-D.ietf-roll-routing-metrics], a metric can eit= her be recorded or aggregated along the path. In the former case, the metri= c can be of maximum type (A=3D0x01) or=0A minimum type (A=3D0x02), while in the latter case, a metr= ic can be of additive type (A=3D0x00) or multiplicative=0A type (A=3D0x03).=
=  
The reference= d draft rather mention (section 2.1 DAG Metric Container Format, page 9 par= agraph 3)

Refere= nce that contradicts what you say. A field is relevant only when = using aggregated metric, and must take one of the following values (A=3D0X0= 0 additive, A=3D0x01 maximum A=3D0x02 minimum and A=3D0x00 multiplicative)<= /font>
Panos: This is corre= ct. We have already changed the wording, according to Nicolas comment as we= ll.
>
> 
> ----- Original Message ----- From: "Nicolas= DEJEAN" <= nicolas.dejean.ietf at googlemail.com>
> To: <zahari= ad at teihal.gr>;=0A <trakadasp at adae.gr>
> Sent: Tuesday, October 04, 2011 6:00 PM
> Subject: Some comments about dr= aft-zahariadis-roll-metrics-composition-01
> 
> 
> Hello,
> 
>.....
> Examp= le 6 and Figure 7: I do not really understand the figure there.
<= font class=3D"yiv135706175Apple-style-span" style=3D"font-size:16px;" face= =3D"'times new roman', 'new york', times, serif">> What are the local va= lues (certainly L and T link properties)?
> Whar are the = values advertised (i.e. the ones the potential successor
> have to take into account for= computong their own)?
> 
> 
> sub-optimal pat= hs are used. However, in this example, practically the
> parent choice is the good one a= s the only available candidate for (E)
> is (D).
> Maybe a more complex example would show the select= ion of the wrong parent ...
> 
> ->Panos: Of course node E selects node D, as its only par= ent. What we are highlighting is that since the metric is not isotonic, >= ;when node D is the source, it selects path (A,B,D), while when node D acts= as a relay node, forwarding traffic of E, then it will >select path (A,= C,D) which is not the optimal one.
> 

This seems t= o be a source routing mechanism that is not present in RPL (as our knowledg= e).

Panos:= Utilizing recorded metrics is a "sense" of source routing, isn't it?
Maybe the= figure bellow is a better=0A answer  that show how non isotonicity ca= n lead to a sub-optimal path selection.

  +---------= ----------------------------------------------------------+
   |=0A          =         ------------ (A) <1 , 10>     =                   |
 &n= bsp; |                  / &nbs= p;           / \ =0A       &nb= sp;                     &= nbsp; |
   |               &= nbsp; /             /   \     =                      = ;     |
   |           =     /             /     = \                     =0A         |
  = ; |               /      =       /       \         =                     |
&= nbsp;  |              /   &nbs= p;         /         \   =                     &nbs= p;   |
 &= nbsp; |      =0A       /      =       /           \     =                      = ; |
   |            /   &nbs= p;         /             = \                    &nbs= p;     |
   |  <6 , 8> (F)    &l= t;3 , 2> (B)            =0A (C) <1 , 9>       &nbs= p;       |
   |         &nbs= p; |              \      =       /              &nb= sp;           |
   |     &nb= sp;     |               \ &nbs= p;         /             =              =0A |
   |         &nb= sp; |                \    = ;     /                &n= bsp;           |
   |     &n= bsp;     |                = ; \       /              =               |
&nbs= p;  |  <4 , 3> (G)            = ;     \     /         =0A &nbs= p;                   |
 = ;  |           |         =           \   /         &= nbsp;                    = |
   |           |     = ;               \ /      =                          =0A |
   |         &nb= sp; |            <2 , 8> (D) w(A,B,D) = =3D <6 , 2> =3D 8         |
   | &nbs= p;         |             =         |  w(A,C,D) =3D <4 , 8> =3D 12 =       |
   |   = ;         \            &n= bsp;       |      =0A       &n= bsp;                   |
=
&nb= sp;  |             \      = ;             |         &= nbsp;                    =   |
   |              = \         <6 , 2> (E) w(A,B,D,E) =3D <12 , 2&g= t; =3D 14     |
 &= nbsp; |               \    &nb= sp; ----------/   w(A,C,D,E) =3D <10 , 2> =3D 12     |=
   |                \&= nbsp;   /                 &nbs= p;                     &n= bsp;     |
   |   &nbs= p;             \  /      =                      = ;    =0A               |
=
&nb= sp;  |         <1 , 1> (H) w(A,F,G,H) =3D &l= t;12 , 1> =3D 13                =     |
   |             =         w(A,B,D,E,H) =3D <13 , 1> =3D 14  &n= bsp;               |
   |   &nbs= p;        =0A         w(A,C,D,E,H) = =3D <11 , 1> =3D 12              &= nbsp;   |
   |             &= nbsp;                    =                     &nbs= p;           |
   +------------------= -------------------------------------------------+


In this case= we have modified the C node latency (from 2 to 1) and added nodes F to H.<= /div>

H= owever the best path according to this metric composition is the one which = pass through E and C (A,C,D,E,H). This example shows that the non isotonici= ty of such composition will lead to a non optimal routing. 
Panos: A bit more c= omplicated example but, for sure, indicates in a better=0A way the impact o= f non-isotonicity property. We will take into account this figure, although= we have to modify the composite metric (L+T) in such a way that monotonici= ty property holds (L+(1/T)).

Emmanuel N= ataf
Patrick Olivier Kamgueu




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


---839692641-1447193047-1321447203=:93902-- From thomas@thomasclausen.org Wed Nov 16 04:44:04 2011 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 E8FA221F952E for ; Wed, 16 Nov 2011 04:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 PK2RMxDXjN+2 for ; Wed, 16 Nov 2011 04:44:04 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE8821F9525 for ; Wed, 16 Nov 2011 04:44:02 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 015C3CD06C for ; Wed, 16 Nov 2011 04:44:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 1DE0FC1983; Wed, 16 Nov 2011 04:43:54 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.3.103] (unknown [203.69.99.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7BD2AC1972; Wed, 16 Nov 2011 04:43:53 -0800 (PST) References: <687807886.312500.1321440357901.JavaMail.root@mail17.pantherlink.uwm.edu> <6773EB09-3823-457C-A6D4-72B58A26658A@cisco.com> In-Reply-To: <6773EB09-3823-457C-A6D4-72B58A26658A@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9A334) From: Thomas Heide Clausen Date: Wed, 16 Nov 2011 20:44:23 +0800 To: "Jeff Apcar (japcar)" Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 12:44:05 -0000 Right, I get that. But, if you start requiring that hosts be routing protoco= l aware, then hosts do no longer run "just IP" (albeit compressed/6low), but= their applicability is tied to a specific infrastructure choice. The purpose of the usual dichotomy between hosts and routers is to provide a= layer of abstraction between applications and "connectivity maintenance". A= nd, a layer of independence. Requiring hosts to be aware of the intricacies of the routing protocol isn't= a sound design choice - especially for the scenario that the routing protoc= ol likely/hopefully will evolve. Effectively, in doing so, the IETF is inhib= iting evolution of the routing protocol as independent from hosts and host a= pplications. This just isn't a valid design choice. Would it be a good idea to have all Internet hosts, and applications thereon= , require an update when a new OSPF option is introduced...? --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) On 16 Nov 2011, at 20:35, "Jeff Apcar (japcar)" wrote: > RPL devices use IPv6, 6LowPan etc. What do you mean no real traces of IP? t= he whole idea is to use IP.=20 >=20 > Jeff.=20 >=20 > On 16/11/2011, at 11:25 PM, "Thomas Heide Clausen" wrote: >=20 >> Now that we are at it: what is an RPL host? Or rather, why is this even a= conceivable thing to define? Afaik, RPL is a routing protocol, and as such s= hould concern only routers - not hosts? >>=20 >> I worry if this is inventing an entire ecosystem which "pretends to be ju= st like the Internet, except it is not", as it needs entirely new stacks, pr= otocols, translators/gateways everywhere, and with no real traces of IP as w= e know it remaining? >>=20 >> --=20 >> Thomas Heide Clausen >> http://www.thomasclausen.org/ >>=20 >> "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >>=20 >>=20 >> On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >>=20 >>> Hi JP >>>=20 >>>> RPL domain: set of devices using RPL as a routing protocol. >>>=20 >>> I think this definition is little too vague. Some of the points that nee= d clarification: >>>=20 >>> 1. It is clear that RPL hosts and routers (as defined towards the end of= terminology section in RPL-19) are within an RPL domain but what about the R= PL-unaware IPv6 hosts attached to an RPL router/host? I would imagine that s= uch hosts are also within an RPL domain. >>>=20 >>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set o= f RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or= is it that an RPL domain is same as an LLN using RPL as a routing protocol?= >>>=20 >>> Thanks >>> Mukul =20 >>>=20 >>> ----- Original Message ----- >>> From: "JP Vasseur" >>> To: "Mukul Goyal" >>> Cc: "roll" >>> Sent: Wednesday, November 16, 2011 2:33:50 AM >>> Subject: Re: definition of "RPL Domain" >>>=20 >>> Hi Mukul, >>>=20 >>> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>>=20 >>>> Hi JP >>>>=20 >>>> I was wondering if the term "RPL Domain" could be defined in the termin= ology draft.=20 >>>>=20 >>>=20 >>> How about >>>=20 >>> RPL domain: set of devices using RPL as a routing protocol. >>>=20 >>> Thanks. >>>=20 >>> JP. >>>=20 >>>> Thanks >>>> Mukul=20 >>>>=20 >>>> ----- Forwarded Message ----- >>>> From: "Joseph Reddy" >>>> To: ipv6@ietf.org >>>> Sent: Friday, October 14, 2011 7:15:05 PM >>>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>=20 >>>>=20 >>>> Hi Jonathan, >>>>=20 >>>> The draft uses the term "RPL domain" in several places and this is not c= learly defined.=20 >>>>=20 >>>> I would imagine that it includes all nodes that are downstream of the R= PL border router. But can you clarify if Host nodes that are downstream of t= he border router but do not implement any part of RPL ( even as RPL Leaf nod= es ) should be considered part of the "RPL domain" ? >>>>=20 >>>> In section 5, the draft now says "..Datagrams destined to nodes outside= the RPL domain are dropped if the outer-most IPv6 header contains a RPL Opt= ion..." >>>>=20 >>>> This text would imply that any RPL node sending packets to nodes outsid= e should always tunnel to the Root ? Is that the intention really or am I mi= ssing something here..=20 >>>>=20 >>>> Also note that if non-RPL Host is not considered part of the RPL domain= , then I am not sure that a forwarding router can know if the destination is= inside the domain or not.=20 >>>>=20 >>>>=20 >>>> -Regards, Joseph >>>>=20 >>>>=20 >>>> ------------------------------ >>>>=20 >>>> Message: 5 >>>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>>> From: Jonathan Hui >>>> To: IETF IPv6 Mailing List >>>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>>> Content-Type: text/plain; charset=3Dus-ascii >>>>=20 >>>>=20 >>>> This update is intended to address Jari Arkko's AD review. >>>>=20 >>>> Summary of changes: >>>> - Clarify when the RPL Option is used. >>>> - Updated text on recommendations for avoiding fragmentation. >>>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >>>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>>> - Specify RPL Border Router operations in terms of forwarding decision o= utcomes. >>>> - Expand security section. >>>>=20 >>>> -- >>>> Jonathan Hui >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Date: October 11, 2011 10:17:15 PM PDT >>>>> To: i-d-announce@ietf.org >>>>> Cc: ipv6@ietf.org >>>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. This draft is a work item of the IPv6 Maintenance Working Group of= the IETF. >>>>>=20 >>>>> Title : RPL Option for Carrying RPL Information in Data-Pla= ne Datagrams >>>>> Author(s) : Jonathan W. Hui >>>>> JP Vasseur >>>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>>> Pages : 14 >>>>> Date : 2011-10-11 >>>>>=20 >>>>> The RPL protocol requires data-plane datagrams to carry RPL routing >>>>> information that is processed by RPL routers when forwarding those >>>>> datagrams. This document describes the RPL Option for use within a >>>>> RPL domain. >>>>>=20 >>>>>=20 >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> This Internet-Draft can be retrieved at: >>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>>=20 >>>>=20 >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>=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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=294de8a4a=mukul@uwm.edu Wed Nov 16 05:16:02 2011 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 3156521F9503 for ; Wed, 16 Nov 2011 05:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+ibRyJD4xv1 for ; Wed, 16 Nov 2011 05:16:01 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2B47521F94FC for ; Wed, 16 Nov 2011 05:16:01 -0800 (PST) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 16 Nov 2011 07:16:00 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 91F5912E3B2; Wed, 16 Nov 2011 07:16:00 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUsA9kR8XQtD; Wed, 16 Nov 2011 07:15:59 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 7561412E3B1; Wed, 16 Nov 2011 07:15:59 -0600 (CST) Date: Wed, 16 Nov 2011 07:15:59 -0600 (CST) From: Mukul Goyal To: Thomas Heide Clausen Message-ID: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:16:02 -0000 >Now that we are at it: what is an RPL host? Or rather, why is this even a conceivable thing to define? Afaik, RPL is a routing protocol, and as such should concern only routers - not hosts? My bad. By RPL host, I actually meant an RPL leaf node. I think this term "RPL host" was in use at one point in time but I cant find a reference to it in current spec. THanks Mukul ----- Original Message ----- From: "Thomas Heide Clausen" To: "Mukul Goyal" Cc: "JP Vasseur" , "roll" Sent: Wednesday, November 16, 2011 6:25:31 AM Subject: Re: [Roll] definition of "RPL Domain" Now that we are at it: what is an RPL host? Or rather, why is this even a conceivable thing to define? Afaik, RPL is a routing protocol, and as such should concern only routers - not hosts? I worry if this is inventing an entire ecosystem which "pretends to be just like the Internet, except it is not", as it needs entirely new stacks, protocols, translators/gateways everywhere, and with no real traces of IP as we know it remaining? -- Thomas Heide Clausen http://www.thomasclausen.org/ "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) On 16 Nov 2011, at 18:45, Mukul Goyal wrote: > Hi JP > >> RPL domain: set of devices using RPL as a routing protocol. > > I think this definition is little too vague. Some of the points that need clarification: > > 1. It is clear that RPL hosts and routers (as defined towards the end of terminology section in RPL-19) are within an RPL domain but what about the RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagine that such hosts are also within an RPL domain. > > 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or is it that an RPL domain is same as an LLN using RPL as a routing protocol? > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: "roll" > Sent: Wednesday, November 16, 2011 2:33:50 AM > Subject: Re: definition of "RPL Domain" > > Hi Mukul, > > On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: > >> Hi JP >> >> I was wondering if the term "RPL Domain" could be defined in the terminology draft. >> > > How about > > RPL domain: set of devices using RPL as a routing protocol. > > Thanks. > > JP. > >> Thanks >> Mukul >> >> ----- Forwarded Message ----- >> From: "Joseph Reddy" >> To: ipv6@ietf.org >> Sent: Friday, October 14, 2011 7:15:05 PM >> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> >> >> Hi Jonathan, >> >> The draft uses the term "RPL domain" in several places and this is not clearly defined. >> >> I would imagine that it includes all nodes that are downstream of the RPL border router. But can you clarify if Host nodes that are downstream of the border router but do not implement any part of RPL ( even as RPL Leaf nodes ) should be considered part of the "RPL domain" ? >> >> In section 5, the draft now says "..Datagrams destined to nodes outside the RPL domain are dropped if the outer-most IPv6 header contains a RPL Option..." >> >> This text would imply that any RPL node sending packets to nodes outside should always tunnel to the Root ? Is that the intention really or am I missing something here.. >> >> Also note that if non-RPL Host is not considered part of the RPL domain, then I am not sure that a forwarding router can know if the destination is inside the domain or not. >> >> >> -Regards, Joseph >> >> >> ------------------------------ >> >> Message: 5 >> Date: Tue, 11 Oct 2011 22:23:10 -0700 >> From: Jonathan Hui >> To: IETF IPv6 Mailing List >> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >> Content-Type: text/plain; charset=us-ascii >> >> >> This update is intended to address Jari Arkko's AD review. >> >> Summary of changes: >> - Clarify when the RPL Option is used. >> - Updated text on recommendations for avoiding fragmentation. >> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >> - Specify RPL Border Router operations in terms of forwarding decision outcomes. >> - Expand security section. >> >> -- >> Jonathan Hui >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Date: October 11, 2011 10:17:15 PM PDT >>> To: i-d-announce@ietf.org >>> Cc: ipv6@ietf.org >>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. >>> >>> Title : RPL Option for Carrying RPL Information in Data-Plane Datagrams >>> Author(s) : Jonathan W. Hui >>> JP Vasseur >>> Filename : draft-ietf-6man-rpl-option-04.txt >>> Pages : 14 >>> Date : 2011-10-11 >>> >>> The RPL protocol requires data-plane datagrams to carry RPL routing >>> information that is processed by RPL routers when forwarding those >>> datagrams. This document describes the RPL Option for use within a >>> RPL domain. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=294de8a4a=mukul@uwm.edu Wed Nov 16 05:20:37 2011 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 2872D21F9601 for ; Wed, 16 Nov 2011 05:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q+uwFmg5UC7 for ; Wed, 16 Nov 2011 05:20:36 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id CE28921F95DF for ; Wed, 16 Nov 2011 05:20:35 -0800 (PST) Received: from localhost (HELO mta01.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 16 Nov 2011 07:20:35 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 77400E6A75; Wed, 16 Nov 2011 07:20:35 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3A19kGkLdG4; Wed, 16 Nov 2011 07:20:35 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 0FC9CE6A74; Wed, 16 Nov 2011 07:20:35 -0600 (CST) Date: Wed, 16 Nov 2011 07:20:34 -0600 (CST) From: Mukul Goyal To: Thomas Heide Clausen Message-ID: <1729675193.312896.1321449634927.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:20:37 -0000 So, the revised doubts are as follows: 1. It is clear that RPL routers are within an RPL domain but what about the RPL-unaware IPv6 hosts attached to an RPL router? I would imagine that such hosts are also within an RPL domain. 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or is it that an RPL domain is same as an LLN using RPL as a routing protocol? THanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "Thomas Heide Clausen" Cc: "roll" Sent: Wednesday, November 16, 2011 7:15:59 AM Subject: Re: [Roll] definition of "RPL Domain" >Now that we are at it: what is an RPL host? Or rather, why is this even a conceivable thing to define? Afaik, RPL is a routing protocol, and as such should concern only routers - not hosts? My bad. By RPL host, I actually meant an RPL leaf node. I think this term "RPL host" was in use at one point in time but I cant find a reference to it in current spec. THanks Mukul ----- Original Message ----- From: "Thomas Heide Clausen" To: "Mukul Goyal" Cc: "JP Vasseur" , "roll" Sent: Wednesday, November 16, 2011 6:25:31 AM Subject: Re: [Roll] definition of "RPL Domain" Now that we are at it: what is an RPL host? Or rather, why is this even a conceivable thing to define? Afaik, RPL is a routing protocol, and as such should concern only routers - not hosts? I worry if this is inventing an entire ecosystem which "pretends to be just like the Internet, except it is not", as it needs entirely new stacks, protocols, translators/gateways everywhere, and with no real traces of IP as we know it remaining? -- Thomas Heide Clausen http://www.thomasclausen.org/ "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) On 16 Nov 2011, at 18:45, Mukul Goyal wrote: > Hi JP > >> RPL domain: set of devices using RPL as a routing protocol. > > I think this definition is little too vague. Some of the points that need clarification: > > 1. It is clear that RPL hosts and routers (as defined towards the end of terminology section in RPL-19) are within an RPL domain but what about the RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagine that such hosts are also within an RPL domain. > > 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or is it that an RPL domain is same as an LLN using RPL as a routing protocol? > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: "roll" > Sent: Wednesday, November 16, 2011 2:33:50 AM > Subject: Re: definition of "RPL Domain" > > Hi Mukul, > > On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: > >> Hi JP >> >> I was wondering if the term "RPL Domain" could be defined in the terminology draft. >> > > How about > > RPL domain: set of devices using RPL as a routing protocol. > > Thanks. > > JP. > >> Thanks >> Mukul >> >> ----- Forwarded Message ----- >> From: "Joseph Reddy" >> To: ipv6@ietf.org >> Sent: Friday, October 14, 2011 7:15:05 PM >> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> >> >> Hi Jonathan, >> >> The draft uses the term "RPL domain" in several places and this is not clearly defined. >> >> I would imagine that it includes all nodes that are downstream of the RPL border router. But can you clarify if Host nodes that are downstream of the border router but do not implement any part of RPL ( even as RPL Leaf nodes ) should be considered part of the "RPL domain" ? >> >> In section 5, the draft now says "..Datagrams destined to nodes outside the RPL domain are dropped if the outer-most IPv6 header contains a RPL Option..." >> >> This text would imply that any RPL node sending packets to nodes outside should always tunnel to the Root ? Is that the intention really or am I missing something here.. >> >> Also note that if non-RPL Host is not considered part of the RPL domain, then I am not sure that a forwarding router can know if the destination is inside the domain or not. >> >> >> -Regards, Joseph >> >> >> ------------------------------ >> >> Message: 5 >> Date: Tue, 11 Oct 2011 22:23:10 -0700 >> From: Jonathan Hui >> To: IETF IPv6 Mailing List >> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >> Content-Type: text/plain; charset=us-ascii >> >> >> This update is intended to address Jari Arkko's AD review. >> >> Summary of changes: >> - Clarify when the RPL Option is used. >> - Updated text on recommendations for avoiding fragmentation. >> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >> - Specify RPL Border Router operations in terms of forwarding decision outcomes. >> - Expand security section. >> >> -- >> Jonathan Hui >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Date: October 11, 2011 10:17:15 PM PDT >>> To: i-d-announce@ietf.org >>> Cc: ipv6@ietf.org >>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. >>> >>> Title : RPL Option for Carrying RPL Information in Data-Plane Datagrams >>> Author(s) : Jonathan W. Hui >>> JP Vasseur >>> Filename : draft-ietf-6man-rpl-option-04.txt >>> Pages : 14 >>> Date : 2011-10-11 >>> >>> The RPL protocol requires data-plane datagrams to carry RPL routing >>> information that is processed by RPL routers when forwarding those >>> datagrams. This document describes the RPL Option for use within a >>> RPL domain. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > _______________________________________________ > 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 thomas@thomasclausen.org Wed Nov 16 05:24:52 2011 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 9CC7621F962F for ; Wed, 16 Nov 2011 05:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 zsL4SKotZz-l for ; Wed, 16 Nov 2011 05:24:51 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id BE7C821F9628 for ; Wed, 16 Nov 2011 05:24:51 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 99BA8A39EE for ; Wed, 16 Nov 2011 05:24:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 63A6AC269A; Wed, 16 Nov 2011 05:24:51 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.3.103] (unknown [203.69.99.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id A2F82C269B; Wed, 16 Nov 2011 05:24:50 -0800 (PST) References: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9A334) From: Thomas Heide Clausen Date: Wed, 16 Nov 2011 21:25:20 +0800 To: Mukul Goyal Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:24:52 -0000 On 16 Nov 2011, at 21:15, Mukul Goyal wrote: >> Now that we are at it: what is an RPL host? Or rather, why is this even a= conceivable thing to define? Afaik, RPL is a routing protocol, and as such s= hould concern only routers - not hosts? >=20 > My bad. By RPL host, I actually meant an RPL leaf node. I think this term "= RPL host" was in use at one point in time but I cant find a reference to it i= n current spec. A rose by any other name is *still* a rose.... What is an RPL Leaf Node? What is the difference between a RPL Leaf node and= a RPL Router? Isn't there a thing in the end of the network, inside the LLN, that doesn't= run RPL, aka, a host? Thomas >=20 > THanks > Mukul >=20 >=20 >=20 > ----- Original Message ----- > From: "Thomas Heide Clausen" > To: "Mukul Goyal" > Cc: "JP Vasseur" , "roll" > Sent: Wednesday, November 16, 2011 6:25:31 AM > Subject: Re: [Roll] definition of "RPL Domain" >=20 > Now that we are at it: what is an RPL host? Or rather, why is this even a c= onceivable thing to define? Afaik, RPL is a routing protocol, and as such sh= ould concern only routers - not hosts? >=20 > I worry if this is inventing an entire ecosystem which "pretends to be jus= t like the Internet, except it is not", as it needs entirely new stacks, pro= tocols, translators/gateways everywhere, and with no real traces of IP as we= know it remaining? >=20 > --=20 > Thomas Heide Clausen > http://www.thomasclausen.org/ >=20 > "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >=20 >=20 > On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >=20 >> Hi JP >>=20 >>> RPL domain: set of devices using RPL as a routing protocol. >>=20 >> I think this definition is little too vague. Some of the points that need= clarification: >>=20 >> 1. It is clear that RPL hosts and routers (as defined towards the end of t= erminology section in RPL-19) are within an RPL domain but what about the RP= L-unaware IPv6 hosts attached to an RPL router/host? I would imagine that su= ch hosts are also within an RPL domain. >>=20 >> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of= RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or i= s it that an RPL domain is same as an LLN using RPL as a routing protocol? >>=20 >> Thanks >> Mukul =20 >>=20 >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "Mukul Goyal" >> Cc: "roll" >> Sent: Wednesday, November 16, 2011 2:33:50 AM >> Subject: Re: definition of "RPL Domain" >>=20 >> Hi Mukul, >>=20 >> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>=20 >>> Hi JP >>>=20 >>> I was wondering if the term "RPL Domain" could be defined in the termino= logy draft.=20 >>>=20 >>=20 >> How about >>=20 >> RPL domain: set of devices using RPL as a routing protocol. >>=20 >> Thanks. >>=20 >> JP. >>=20 >>> Thanks >>> Mukul=20 >>>=20 >>> ----- Forwarded Message ----- >>> From: "Joseph Reddy" >>> To: ipv6@ietf.org >>> Sent: Friday, October 14, 2011 7:15:05 PM >>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>=20 >>>=20 >>> Hi Jonathan, >>>=20 >>> The draft uses the term "RPL domain" in several places and this is not c= learly defined.=20 >>>=20 >>> I would imagine that it includes all nodes that are downstream of the RP= L border router. But can you clarify if Host nodes that are downstream of th= e border router but do not implement any part of RPL ( even as RPL Leaf node= s ) should be considered part of the "RPL domain" ? >>>=20 >>> In section 5, the draft now says "..Datagrams destined to nodes outside t= he RPL domain are dropped if the outer-most IPv6 header contains a RPL Optio= n..." >>>=20 >>> This text would imply that any RPL node sending packets to nodes outside= should always tunnel to the Root ? Is that the intention really or am I mis= sing something here..=20 >>>=20 >>> Also note that if non-RPL Host is not considered part of the RPL domain,= then I am not sure that a forwarding router can know if the destination is i= nside the domain or not.=20 >>>=20 >>>=20 >>> -Regards, Joseph >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> Message: 5 >>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>> From: Jonathan Hui >>> To: IETF IPv6 Mailing List >>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>> Content-Type: text/plain; charset=3Dus-ascii >>>=20 >>>=20 >>> This update is intended to address Jari Arkko's AD review. >>>=20 >>> Summary of changes: >>> - Clarify when the RPL Option is used. >>> - Updated text on recommendations for avoiding fragmentation. >>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>> - Specify RPL Border Router operations in terms of forwarding decision o= utcomes. >>> - Expand security section. >>>=20 >>> -- >>> Jonathan Hui >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Date: October 11, 2011 10:17:15 PM PDT >>>> To: i-d-announce@ietf.org >>>> Cc: ipv6@ietf.org >>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Maintenance Working Group of t= he IETF. >>>>=20 >>>> Title : RPL Option for Carrying RPL Information in Data-Pla= ne Datagrams >>>> Author(s) : Jonathan W. Hui >>>> JP Vasseur >>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>> Pages : 14 >>>> Date : 2011-10-11 >>>>=20 >>>> The RPL protocol requires data-plane datagrams to carry RPL routing >>>> information that is processed by RPL routers when forwarding those >>>> datagrams. This document describes the RPL Option for use within a >>>> RPL domain. >>>>=20 >>>>=20 >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From c.chauvenet@watteco.com Wed Nov 16 05:27:18 2011 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 AEC0D21F9642 for ; Wed, 16 Nov 2011 05:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 pKFeGwx1omeS for ; Wed, 16 Nov 2011 05:27:17 -0800 (PST) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8933F21F9641 for ; Wed, 16 Nov 2011 05:27:16 -0800 (PST) Received: from mail53-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Wed, 16 Nov 2011 13:26:44 +0000 Received: from mail53-tx2 (localhost.localdomain [127.0.0.1]) by mail53-tx2-R.bigfish.com (Postfix) with ESMTP id C30F0C50559; Wed, 16 Nov 2011 13:27:01 +0000 (UTC) X-SpamScore: -90 X-BigFish: VPS-90(zz9371Kc89bh936eK542M1432N15caKJ98dKzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB041.red002.local; RD:none; EFVD:NLI Received: from mail53-tx2 (localhost.localdomain [127.0.0.1]) by mail53-tx2 (MessageSwitch) id 1321450020105872_22913; Wed, 16 Nov 2011 13:27:00 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.248]) by mail53-tx2.bigfish.com (Postfix) with ESMTP id 063681690065; Wed, 16 Nov 2011 13:27:00 +0000 (UTC) Received: from IE2RD2HUB041.red002.local (213.199.187.153) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 16 Nov 2011 13:26:40 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB041.red002.local ([10.17.10.80]) with mapi; Wed, 16 Nov 2011 05:26:50 -0800 From: C Chauvenet To: Thomas Heide Clausen , Mukul Goyal Date: Wed, 16 Nov 2011 05:26:54 -0800 Thread-Topic: [Roll] definition of "RPL Domain" Thread-Index: AcykWsoi28qF4hquSJ+NIQq5m/JoMQABsZjg Message-ID: References: <687807886.312500.1321440357901.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:27:18 -0000 Hi Thomas, AFAIK, "Host" is a notion that pops up in LLNs because of their contrained = ressources that historical IP router don't have. For instance, due to power limitation, a LLN device may not want to forward= packets (ie act as a IP router) to save energy and achieve a reasonable li= fetime. My vision is that such Hosts will exist in all LLNs networks, regardless of= the routing protocol use. As RPL has been designed for such networks, a definition of this type of de= vices is needed. If such a definition doesn't exist, then we may not be able to cope with th= e limitations of LLNs. Best, C=E9dric. -----Message d'origine----- De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de T= homas Heide Clausen Envoy=E9=A0: mercredi 16 novembre 2011 13:26 =C0=A0: Mukul Goyal Cc=A0: roll Objet=A0: Re: [Roll] definition of "RPL Domain" Now that we are at it: what is an RPL host? Or rather, why is this even a c= onceivable thing to define? Afaik, RPL is a routing protocol, and as such s= hould concern only routers - not hosts? I worry if this is inventing an entire ecosystem which "pretends to be just= like the Internet, except it is not", as it needs entirely new stacks, pro= tocols, translators/gateways everywhere, and with no real traces of IP as w= e know it remaining? -- Thomas Heide Clausen http://www.thomasclausen.org/ "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) On 16 Nov 2011, at 18:45, Mukul Goyal wrote: > Hi JP >=20 >> RPL domain: set of devices using RPL as a routing protocol. >=20 > I think this definition is little too vague. Some of the points that need= clarification: >=20 > 1. It is clear that RPL hosts and routers (as defined towards the end of = terminology section in RPL-19) are within an RPL domain but what about the = RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagine that= such hosts are also within an RPL domain. >=20 > 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of= RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or= is it that an RPL domain is same as an LLN using RPL as a routing protocol= ? >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: "roll" > Sent: Wednesday, November 16, 2011 2:33:50 AM > Subject: Re: definition of "RPL Domain" >=20 > Hi Mukul, >=20 > On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >=20 >> Hi JP >>=20 >> I was wondering if the term "RPL Domain" could be defined in the termino= logy draft.=20 >>=20 >=20 > How about >=20 > RPL domain: set of devices using RPL as a routing protocol. >=20 > Thanks. >=20 > JP. >=20 >> Thanks >> Mukul >>=20 >> ----- Forwarded Message ----- >> From: "Joseph Reddy" >> To: ipv6@ietf.org >> Sent: Friday, October 14, 2011 7:15:05 PM >> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>=20 >>=20 >> Hi Jonathan, >>=20 >> The draft uses the term "RPL domain" in several places and this is not c= learly defined.=20 >>=20 >> I would imagine that it includes all nodes that are downstream of the RP= L border router. But can you clarify if Host nodes that are downstream of t= he border router but do not implement any part of RPL ( even as RPL Leaf no= des ) should be considered part of the "RPL domain" ? >>=20 >> In section 5, the draft now says "..Datagrams destined to nodes outside = the RPL domain are dropped if the outer-most IPv6 header contains a RPL Opt= ion..." >>=20 >> This text would imply that any RPL node sending packets to nodes outside= should always tunnel to the Root ? Is that the intention really or am I mi= ssing something here..=20 >>=20 >> Also note that if non-RPL Host is not considered part of the RPL domain,= then I am not sure that a forwarding router can know if the destination is= inside the domain or not.=20 >>=20 >>=20 >> -Regards, Joseph >>=20 >>=20 >> ------------------------------ >>=20 >> Message: 5 >> Date: Tue, 11 Oct 2011 22:23:10 -0700 >> From: Jonathan Hui >> To: IETF IPv6 Mailing List >> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >> Content-Type: text/plain; charset=3Dus-ascii >>=20 >>=20 >> This update is intended to address Jari Arkko's AD review. >>=20 >> Summary of changes: >> - Clarify when the RPL Option is used. >> - Updated text on recommendations for avoiding fragmentation. >> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >> - Specify RPL Border Router operations in terms of forwarding decision o= utcomes. >> - Expand security section. >>=20 >> -- >> Jonathan Hui >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: October 11, 2011 10:17:15 PM PDT >>> To: i-d-announce@ietf.org >>> Cc: ipv6@ietf.org >>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Maintenance Working Group of= the IETF. >>>=20 >>> Title : RPL Option for Carrying RPL Information in Data-Pl= ane Datagrams >>> Author(s) : Jonathan W. Hui >>> JP Vasseur >>> Filename : draft-ietf-6man-rpl-option-04.txt >>> Pages : 14 >>> Date : 2011-10-11 >>>=20 >>> The RPL protocol requires data-plane datagrams to carry RPL routing=20 >>> information that is processed by RPL routers when forwarding those=20 >>> datagrams. This document describes the RPL Option for use within a=20 >>> RPL domain. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.tx >>> t >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative=20 >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=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 c.chauvenet@watteco.com Wed Nov 16 05:31:37 2011 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 7058F21F965D for ; Wed, 16 Nov 2011 05:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.265 X-Spam-Level: X-Spam-Status: No, score=-4.265 tagged_above=-999 required=5 tests=[AWL=-0.666, 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 BjJp3lamfkYG for ; Wed, 16 Nov 2011 05:31:36 -0800 (PST) Received: from VA3EHSOBE004.bigfish.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 68E5621F965C for ; Wed, 16 Nov 2011 05:31:36 -0800 (PST) Received: from mail66-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Wed, 16 Nov 2011 13:31:02 +0000 Received: from mail66-va3 (localhost [127.0.0.1]) by mail66-va3-R.bigfish.com (Postfix) with ESMTP id A0D46660106; Wed, 16 Nov 2011 13:30:05 +0000 (UTC) X-SpamScore: -90 X-BigFish: VPS-90(zz9371Kc89bh936eK542M1432N15caKJ98dKzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); SRV:BULK; H:IE2RD2HUB002.red002.local; RD:none; EFVD:NLI Received: from mail66-va3 (localhost.localdomain [127.0.0.1]) by mail66-va3 (MessageSwitch) id 1321450204591399_27933; Wed, 16 Nov 2011 13:30:04 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.246]) by mail66-va3.bigfish.com (Postfix) with ESMTP id 88EBB3A0043; Wed, 16 Nov 2011 13:30:04 +0000 (UTC) Received: from IE2RD2HUB002.red002.local (213.199.187.153) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 16 Nov 2011 13:30:58 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB002.red002.local ([10.33.16.62]) with mapi; Wed, 16 Nov 2011 05:31:31 -0800 From: C Chauvenet To: Mukul Goyal , Thomas Heide Clausen Date: Wed, 16 Nov 2011 05:31:36 -0800 Thread-Topic: [Roll] definition of "RPL Domain" Thread-Index: AcykYehaiiezIWhyQ/GF+lOwJnGhKgAAgJsA Message-ID: References: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:31:37 -0000 Apologize, same mistake for me, I mismatch Host and Leaf. (My previous mail is related to RPL leaf). C=E9dric. -----Message d'origine----- De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de M= ukul Goyal Envoy=E9=A0: mercredi 16 novembre 2011 14:16 =C0=A0: Thomas Heide Clausen Cc=A0: roll Objet=A0: Re: [Roll] definition of "RPL Domain" >Now that we are at it: what is an RPL host? Or rather, why is this even a = conceivable thing to define? Afaik, RPL is a routing protocol, and as such = should concern only routers - not hosts? My bad. By RPL host, I actually meant an RPL leaf node. I think this term "= RPL host" was in use at one point in time but I cant find a reference to it= in current spec. THanks Mukul ----- Original Message ----- From: "Thomas Heide Clausen" To: "Mukul Goyal" Cc: "JP Vasseur" , "roll" Sent: Wednesday, November 16, 2011 6:25:31 AM Subject: Re: [Roll] definition of "RPL Domain" Now that we are at it: what is an RPL host? Or rather, why is this even a c= onceivable thing to define? Afaik, RPL is a routing protocol, and as such s= hould concern only routers - not hosts? I worry if this is inventing an entire ecosystem which "pretends to be just= like the Internet, except it is not", as it needs entirely new stacks, pro= tocols, translators/gateways everywhere, and with no real traces of IP as w= e know it remaining? -- Thomas Heide Clausen http://www.thomasclausen.org/ "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) On 16 Nov 2011, at 18:45, Mukul Goyal wrote: > Hi JP >=20 >> RPL domain: set of devices using RPL as a routing protocol. >=20 > I think this definition is little too vague. Some of the points that need= clarification: >=20 > 1. It is clear that RPL hosts and routers (as defined towards the end of = terminology section in RPL-19) are within an RPL domain but what about the = RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagine that= such hosts are also within an RPL domain. >=20 > 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of= RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or= is it that an RPL domain is same as an LLN using RPL as a routing protocol= ? >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: "roll" > Sent: Wednesday, November 16, 2011 2:33:50 AM > Subject: Re: definition of "RPL Domain" >=20 > Hi Mukul, >=20 > On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >=20 >> Hi JP >>=20 >> I was wondering if the term "RPL Domain" could be defined in the termino= logy draft.=20 >>=20 >=20 > How about >=20 > RPL domain: set of devices using RPL as a routing protocol. >=20 > Thanks. >=20 > JP. >=20 >> Thanks >> Mukul >>=20 >> ----- Forwarded Message ----- >> From: "Joseph Reddy" >> To: ipv6@ietf.org >> Sent: Friday, October 14, 2011 7:15:05 PM >> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>=20 >>=20 >> Hi Jonathan, >>=20 >> The draft uses the term "RPL domain" in several places and this is not c= learly defined.=20 >>=20 >> I would imagine that it includes all nodes that are downstream of the RP= L border router. But can you clarify if Host nodes that are downstream of t= he border router but do not implement any part of RPL ( even as RPL Leaf no= des ) should be considered part of the "RPL domain" ? >>=20 >> In section 5, the draft now says "..Datagrams destined to nodes outside = the RPL domain are dropped if the outer-most IPv6 header contains a RPL Opt= ion..." >>=20 >> This text would imply that any RPL node sending packets to nodes outside= should always tunnel to the Root ? Is that the intention really or am I mi= ssing something here..=20 >>=20 >> Also note that if non-RPL Host is not considered part of the RPL domain,= then I am not sure that a forwarding router can know if the destination is= inside the domain or not.=20 >>=20 >>=20 >> -Regards, Joseph >>=20 >>=20 >> ------------------------------ >>=20 >> Message: 5 >> Date: Tue, 11 Oct 2011 22:23:10 -0700 >> From: Jonathan Hui >> To: IETF IPv6 Mailing List >> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >> Content-Type: text/plain; charset=3Dus-ascii >>=20 >>=20 >> This update is intended to address Jari Arkko's AD review. >>=20 >> Summary of changes: >> - Clarify when the RPL Option is used. >> - Updated text on recommendations for avoiding fragmentation. >> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >> - Specify RPL Border Router operations in terms of forwarding decision o= utcomes. >> - Expand security section. >>=20 >> -- >> Jonathan Hui >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: October 11, 2011 10:17:15 PM PDT >>> To: i-d-announce@ietf.org >>> Cc: ipv6@ietf.org >>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Maintenance Working Group of= the IETF. >>>=20 >>> Title : RPL Option for Carrying RPL Information in Data-Pl= ane Datagrams >>> Author(s) : Jonathan W. Hui >>> JP Vasseur >>> Filename : draft-ietf-6man-rpl-option-04.txt >>> Pages : 14 >>> Date : 2011-10-11 >>>=20 >>> The RPL protocol requires data-plane datagrams to carry RPL routing=20 >>> information that is processed by RPL routers when forwarding those=20 >>> datagrams. This document describes the RPL Option for use within a=20 >>> RPL domain. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.tx >>> t >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative=20 >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=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 sebastien.dawans@cetic.be Wed Nov 16 05:36:52 2011 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 3B72921F9669 for ; Wed, 16 Nov 2011 05:36:52 -0800 (PST) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 719eLXepctF2 for ; Wed, 16 Nov 2011 05:36:51 -0800 (PST) Received: from cronos.cetic.be (cronos.cetic.be [193.190.255.197]) by ietfa.amsl.com (Postfix) with ESMTP id 973C721F95D8 for ; Wed, 16 Nov 2011 05:36:51 -0800 (PST) Received: from [193.10.67.50] (lt-sd.sics.se [193.10.67.50]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sd@cronos.cetic.be) by cronos.cetic.be (Postfix) with ESMTPSA id 7A77710F9A4 for ; Wed, 16 Nov 2011 14:36:50 +0100 (CET) Message-ID: <4EC3BD54.6030403@cetic.be> Date: Wed, 16 Nov 2011 14:40:36 +0100 From: =?ISO-8859-1?Q?S=E9bastien_Dawans?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110506 Icedove/3.0.11 MIME-Version: 1.0 To: roll@ietf.org References: <1729675193.312896.1321449634927.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1729675193.312896.1321449634927.JavaMail.root@mail17.pantherlink.uwm.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:36:52 -0000 Hello Mukul, On what ground would you assume that a non-RPL aware host connected to a RPL-router (in this case I would call it a border router) is in a/the RPL Domain? From what I've seen in the drafts, the term "RPL Domain"'s primary purpose it to differentiate the limits of "RPL-aware" nodes for IP traffic that needs to transit to or from a set of RPL-aware hosts (for example, to define where to add/remove the RPL IPv6 Hop-by-Hop Option if used). To me, this interpretation of RPL Domain is thus only useful in a local context and not to meant to designate one or more bounded set of nodes. That's the role of DODAGs and Instances. Best Regards, Sébastien Dawans On 11/16/2011 02:20 PM, Mukul Goyal wrote: > So, the revised doubts are as follows: > > 1. It is clear that RPL routers are within an RPL domain but what about the RPL-unaware IPv6 hosts attached to an RPL router? I would imagine that such hosts are also within an RPL domain. > > 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or is it that an RPL domain is same as an LLN using RPL as a routing protocol? > > THanks > Mukul > > ----- Original Message ----- > From: "Mukul Goyal" > To: "Thomas Heide Clausen" > Cc: "roll" > Sent: Wednesday, November 16, 2011 7:15:59 AM > Subject: Re: [Roll] definition of "RPL Domain" > > >> Now that we are at it: what is an RPL host? Or rather, why is this even a conceivable thing to define? Afaik, RPL is a routing protocol, and as such should concern only routers - not hosts? >> > My bad. By RPL host, I actually meant an RPL leaf node. I think this term "RPL host" was in use at one point in time but I cant find a reference to it in current spec. > > THanks > Mukul > > > > ----- Original Message ----- > From: "Thomas Heide Clausen" > To: "Mukul Goyal" > Cc: "JP Vasseur", "roll" > Sent: Wednesday, November 16, 2011 6:25:31 AM > Subject: Re: [Roll] definition of "RPL Domain" > > Now that we are at it: what is an RPL host? Or rather, why is this even a conceivable thing to define? Afaik, RPL is a routing protocol, and as such should concern only routers - not hosts? > > I worry if this is inventing an entire ecosystem which "pretends to be just like the Internet, except it is not", as it needs entirely new stacks, protocols, translators/gateways everywhere, and with no real traces of IP as we know it remaining? > > From jonhui@cisco.com Wed Nov 16 05:37:34 2011 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 A78E421F967D for ; Wed, 16 Nov 2011 05:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 DH5ADCJBnRxP for ; Wed, 16 Nov 2011 05:37:33 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id DFD8621F967C for ; Wed, 16 Nov 2011 05:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=6270; q=dns/txt; s=iport; t=1321450653; x=1322660253; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=DJDNcjecRyUANyEim6q8YCLMcfwKvzD1A3gsNcOAD7o=; b=GTZOZVIFRg/TWpr8YL5ut4hXMsuX3KSayYEHuh2vwYFQPaZJ5gfrMNjx 5Uie/K7fYgs0HPPAjXAsntagIkpA+gsOg9/iu4Q/rTNL0Tnz0CQkhaV1S hUaIwDVwkgIgflfylYs8o6Ekrc/bDY4AcQmcCL8UFvUD//ju1axnB35Vs w=; X-IronPort-AV: E=Sophos;i="4.69,521,1315180800"; d="scan'208";a="14616317" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 16 Nov 2011 13:37:33 +0000 Received: from sjc-vpn2-289.cisco.com (sjc-vpn2-289.cisco.com [10.21.113.33]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAGDbWpw029366; Wed, 16 Nov 2011 13:37:32 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <687807886.312500.1321440357901.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 16 Nov 2011 05:37:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <99C9CB3F-6637-456F-AAD0-4C7474219CAE@cisco.com> References: <687807886.312500.1321440357901.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:37:34 -0000 How about a definition derived from RFC 1629: A "RPL domain" is a routing domain, as stated in Section 3.2 of RFC = 1629, where the common routing protocol is RPL. The above definition would unambiguously give the following answers to = your questions: 1) Given the definition above, devices that do not operate RPL are not a = part of the RPL domain. 2) Because RPL devices may support more than one instance, a RPL domain = may contain any number of instances. The term seems to be used most often in draft-ietf-roll-p2p-measurement. = I suggest going through and verifying whether "RPL Instance" or "RPL = domain" was intended. Happy to see any alternative definitions you may have in mind. -- Jonathan Hui On Nov 16, 2011, at 2:45 AM, Mukul Goyal wrote: > Hi JP >=20 >> RPL domain: set of devices using RPL as a routing protocol. >=20 > I think this definition is little too vague. Some of the points that = need clarification: >=20 > 1. It is clear that RPL hosts and routers (as defined towards the end = of terminology section in RPL-19) are within an RPL domain but what = about the RPL-unaware IPv6 hosts attached to an RPL router/host? I would = imagine that such hosts are also within an RPL domain. >=20 > 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set = of RPL instances in the LLN? Can multiple RPL domains exist within an = LLN? Or is it that an RPL domain is same as an LLN using RPL as a = routing protocol? >=20 > Thanks > Mukul =20 >=20 > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: "roll" > Sent: Wednesday, November 16, 2011 2:33:50 AM > Subject: Re: definition of "RPL Domain" >=20 > Hi Mukul, >=20 > On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >=20 >> Hi JP >>=20 >> I was wondering if the term "RPL Domain" could be defined in the = terminology draft.=20 >>=20 >=20 > How about >=20 > RPL domain: set of devices using RPL as a routing protocol. >=20 > Thanks. >=20 > JP. >=20 >> Thanks >> Mukul=20 >>=20 >> ----- Forwarded Message ----- >> From: "Joseph Reddy" >> To: ipv6@ietf.org >> Sent: Friday, October 14, 2011 7:15:05 PM >> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>=20 >>=20 >> Hi Jonathan, >>=20 >> The draft uses the term "RPL domain" in several places and this is = not clearly defined.=20 >>=20 >> I would imagine that it includes all nodes that are downstream of the = RPL border router. But can you clarify if Host nodes that are downstream = of the border router but do not implement any part of RPL ( even as RPL = Leaf nodes ) should be considered part of the "RPL domain" ? >>=20 >> In section 5, the draft now says "..Datagrams destined to nodes = outside the RPL domain are dropped if the outer-most IPv6 header = contains a RPL Option..." >>=20 >> This text would imply that any RPL node sending packets to nodes = outside should always tunnel to the Root ? Is that the intention really = or am I missing something here..=20 >>=20 >> Also note that if non-RPL Host is not considered part of the RPL = domain, then I am not sure that a forwarding router can know if the = destination is inside the domain or not.=20 >>=20 >>=20 >> -Regards, Joseph >>=20 >>=20 >> ------------------------------ >>=20 >> Message: 5 >> Date: Tue, 11 Oct 2011 22:23:10 -0700 >> From: Jonathan Hui >> To: IETF IPv6 Mailing List >> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >> Content-Type: text/plain; charset=3Dus-ascii >>=20 >>=20 >> This update is intended to address Jari Arkko's AD review. >>=20 >> Summary of changes: >> - Clarify when the RPL Option is used. >> - Updated text on recommendations for avoiding fragmentation. >> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >> - Specify RPL Border Router operations in terms of forwarding = decision outcomes. >> - Expand security section. >>=20 >> -- >> Jonathan Hui >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: October 11, 2011 10:17:15 PM PDT >>> To: i-d-announce@ietf.org >>> Cc: ipv6@ietf.org >>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Maintenance Working = Group of the IETF. >>>=20 >>> Title : RPL Option for Carrying RPL Information in = Data-Plane Datagrams >>> Author(s) : Jonathan W. Hui >>> JP Vasseur >>> Filename : draft-ietf-6man-rpl-option-04.txt >>> Pages : 14 >>> Date : 2011-10-11 >>>=20 >>> The RPL protocol requires data-plane datagrams to carry RPL routing >>> information that is processed by RPL routers when forwarding those >>> datagrams. This document describes the RPL Option for use within a >>> RPL domain. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From thomas@thomasclausen.org Wed Nov 16 05:37:44 2011 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 452F321F9683 for ; Wed, 16 Nov 2011 05:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 OZs0xKJOh2Sc for ; Wed, 16 Nov 2011 05:37:43 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6F21E21F968B for ; Wed, 16 Nov 2011 05:37:43 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 4914DA63EA for ; Wed, 16 Nov 2011 05:37:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 04F3CC27C9; Wed, 16 Nov 2011 05:37:43 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.3.103] (unknown [203.69.99.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 6358FC27C7; Wed, 16 Nov 2011 05:37:42 -0800 (PST) References: <687807886.312500.1321440357901.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (9A334) From: Thomas Heide Clausen Date: Wed, 16 Nov 2011 21:38:11 +0800 To: C Chauvenet Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:37:44 -0000 On 16 Nov 2011, at 21:26, C Chauvenet wrote: > Hi Thomas, >=20 > AFAIK, "Host" is a notion that pops up in LLNs because of their contrained= ressources that historical IP router don't have. >=20 > For instance, due to power limitation, a LLN device may not want to forwar= d packets (ie act as a IP router) to save energy and achieve a reasonable li= fetime. So, in that case, it will associate to a router and be a host - routing prot= ocol agnostic, just like my iPad I'd unaware of whatever routing the hotel n= etwork is using. No need to invent a new terminology for this concept. >=20 > My vision is that such Hosts will exist in all LLNs networks, regardless o= f the routing protocol use. > As RPL has been designed for such networks, a definition of this type of d= evices is needed. > If such a definition doesn't exist, then we may not be able to cope with t= he limitations of LLNs. I don't understand. A device that doesn't route isn't a router is therefore a= host. Requiring hosts to be "routing protocol aware" is a significant change to th= e Internet architecture, of which I would doubt that the Internet Architectu= re Board would approve. I assert that a RPL host remains routing protocol unaware, and so is no diff= erent from a host - yes? Thomas >=20 > Best, > C=C3=A9dric. >=20 > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Th= omas Heide Clausen > Envoy=C3=A9 : mercredi 16 novembre 2011 13:26 > =C3=80 : Mukul Goyal > Cc : roll > Objet : Re: [Roll] definition of "RPL Domain" >=20 > Now that we are at it: what is an RPL host? Or rather, why is this even a c= onceivable thing to define? Afaik, RPL is a routing protocol, and as such sh= ould concern only routers - not hosts? >=20 > I worry if this is inventing an entire ecosystem which "pretends to be jus= t like the Internet, except it is not", as it needs entirely new stacks, pro= tocols, translators/gateways everywhere, and with no real traces of IP as we= know it remaining? >=20 > -- > Thomas Heide Clausen > http://www.thomasclausen.org/ >=20 > "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >=20 >=20 > On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >=20 >> Hi JP >>=20 >>> RPL domain: set of devices using RPL as a routing protocol. >>=20 >> I think this definition is little too vague. Some of the points that need= clarification: >>=20 >> 1. It is clear that RPL hosts and routers (as defined towards the end of t= erminology section in RPL-19) are within an RPL domain but what about the RP= L-unaware IPv6 hosts attached to an RPL router/host? I would imagine that su= ch hosts are also within an RPL domain. >>=20 >> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of= RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or i= s it that an RPL domain is same as an LLN using RPL as a routing protocol? >>=20 >> Thanks >> Mukul >>=20 >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "Mukul Goyal" >> Cc: "roll" >> Sent: Wednesday, November 16, 2011 2:33:50 AM >> Subject: Re: definition of "RPL Domain" >>=20 >> Hi Mukul, >>=20 >> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>=20 >>> Hi JP >>>=20 >>> I was wondering if the term "RPL Domain" could be defined in the termino= logy draft.=20 >>>=20 >>=20 >> How about >>=20 >> RPL domain: set of devices using RPL as a routing protocol. >>=20 >> Thanks. >>=20 >> JP. >>=20 >>> Thanks >>> Mukul >>>=20 >>> ----- Forwarded Message ----- >>> From: "Joseph Reddy" >>> To: ipv6@ietf.org >>> Sent: Friday, October 14, 2011 7:15:05 PM >>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>=20 >>>=20 >>> Hi Jonathan, >>>=20 >>> The draft uses the term "RPL domain" in several places and this is not c= learly defined.=20 >>>=20 >>> I would imagine that it includes all nodes that are downstream of the RP= L border router. But can you clarify if Host nodes that are downstream of th= e border router but do not implement any part of RPL ( even as RPL Leaf node= s ) should be considered part of the "RPL domain" ? >>>=20 >>> In section 5, the draft now says "..Datagrams destined to nodes outside t= he RPL domain are dropped if the outer-most IPv6 header contains a RPL Optio= n..." >>>=20 >>> This text would imply that any RPL node sending packets to nodes outside= should always tunnel to the Root ? Is that the intention really or am I mis= sing something here..=20 >>>=20 >>> Also note that if non-RPL Host is not considered part of the RPL domain,= then I am not sure that a forwarding router can know if the destination is i= nside the domain or not.=20 >>>=20 >>>=20 >>> -Regards, Joseph >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> Message: 5 >>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>> From: Jonathan Hui >>> To: IETF IPv6 Mailing List >>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>> Content-Type: text/plain; charset=3Dus-ascii >>>=20 >>>=20 >>> This update is intended to address Jari Arkko's AD review. >>>=20 >>> Summary of changes: >>> - Clarify when the RPL Option is used. >>> - Updated text on recommendations for avoiding fragmentation. >>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>> - Specify RPL Border Router operations in terms of forwarding decision o= utcomes. >>> - Expand security section. >>>=20 >>> -- >>> Jonathan Hui >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Date: October 11, 2011 10:17:15 PM PDT >>>> To: i-d-announce@ietf.org >>>> Cc: ipv6@ietf.org >>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Maintenance Working Group of t= he IETF. >>>>=20 >>>> Title : RPL Option for Carrying RPL Information in Data-Pla= ne Datagrams >>>> Author(s) : Jonathan W. Hui >>>> JP Vasseur >>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>> Pages : 14 >>>> Date : 2011-10-11 >>>>=20 >>>> The RPL protocol requires data-plane datagrams to carry RPL routing=20 >>>> information that is processed by RPL routers when forwarding those=20 >>>> datagrams. This document describes the RPL Option for use within a=20 >>>> RPL domain. >>>>=20 >>>>=20 >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.tx >>>> t >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative=20 >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=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 >=20 >=20 From thomas@thomasclausen.org Wed Nov 16 05:38:43 2011 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 6C8231F0C36 for ; Wed, 16 Nov 2011 05:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 BaYEYAsXXHwP for ; Wed, 16 Nov 2011 05:38:42 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3C81F0C35 for ; Wed, 16 Nov 2011 05:38:42 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 64827A63EA for ; Wed, 16 Nov 2011 05:38:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 379EBC27D2; Wed, 16 Nov 2011 05:38:42 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.3.103] (unknown [203.69.99.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8F18FC27D1; Wed, 16 Nov 2011 05:38:41 -0800 (PST) References: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (9A334) From: Thomas Heide Clausen Date: Wed, 16 Nov 2011 21:39:12 +0800 To: C Chauvenet Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:38:43 -0000 RPL host or RPL leaf - the argument is the same. A host is a device that wou= ld never want to or care about routing. That I exactly what you describe as a= RPL leaf. --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) On 16 Nov 2011, at 21:31, C Chauvenet wrote: > Apologize, same mistake for me, I mismatch Host and Leaf. >=20 > (My previous mail is related to RPL leaf). >=20 > C=C3=A9dric. > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Mu= kul Goyal > Envoy=C3=A9 : mercredi 16 novembre 2011 14:16 > =C3=80 : Thomas Heide Clausen > Cc : roll > Objet : Re: [Roll] definition of "RPL Domain" >=20 >> Now that we are at it: what is an RPL host? Or rather, why is this even a= conceivable thing to define? Afaik, RPL is a routing protocol, and as such s= hould concern only routers - not hosts? >=20 > My bad. By RPL host, I actually meant an RPL leaf node. I think this term "= RPL host" was in use at one point in time but I cant find a reference to it i= n current spec. >=20 > THanks > Mukul >=20 >=20 >=20 > ----- Original Message ----- > From: "Thomas Heide Clausen" > To: "Mukul Goyal" > Cc: "JP Vasseur" , "roll" > Sent: Wednesday, November 16, 2011 6:25:31 AM > Subject: Re: [Roll] definition of "RPL Domain" >=20 > Now that we are at it: what is an RPL host? Or rather, why is this even a c= onceivable thing to define? Afaik, RPL is a routing protocol, and as such sh= ould concern only routers - not hosts? >=20 > I worry if this is inventing an entire ecosystem which "pretends to be jus= t like the Internet, except it is not", as it needs entirely new stacks, pro= tocols, translators/gateways everywhere, and with no real traces of IP as we= know it remaining? >=20 > -- > Thomas Heide Clausen > http://www.thomasclausen.org/ >=20 > "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >=20 >=20 > On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >=20 >> Hi JP >>=20 >>> RPL domain: set of devices using RPL as a routing protocol. >>=20 >> I think this definition is little too vague. Some of the points that need= clarification: >>=20 >> 1. It is clear that RPL hosts and routers (as defined towards the end of t= erminology section in RPL-19) are within an RPL domain but what about the RP= L-unaware IPv6 hosts attached to an RPL router/host? I would imagine that su= ch hosts are also within an RPL domain. >>=20 >> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of= RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or i= s it that an RPL domain is same as an LLN using RPL as a routing protocol? >>=20 >> Thanks >> Mukul >>=20 >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "Mukul Goyal" >> Cc: "roll" >> Sent: Wednesday, November 16, 2011 2:33:50 AM >> Subject: Re: definition of "RPL Domain" >>=20 >> Hi Mukul, >>=20 >> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>=20 >>> Hi JP >>>=20 >>> I was wondering if the term "RPL Domain" could be defined in the termino= logy draft.=20 >>>=20 >>=20 >> How about >>=20 >> RPL domain: set of devices using RPL as a routing protocol. >>=20 >> Thanks. >>=20 >> JP. >>=20 >>> Thanks >>> Mukul >>>=20 >>> ----- Forwarded Message ----- >>> From: "Joseph Reddy" >>> To: ipv6@ietf.org >>> Sent: Friday, October 14, 2011 7:15:05 PM >>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>=20 >>>=20 >>> Hi Jonathan, >>>=20 >>> The draft uses the term "RPL domain" in several places and this is not c= learly defined.=20 >>>=20 >>> I would imagine that it includes all nodes that are downstream of the RP= L border router. But can you clarify if Host nodes that are downstream of th= e border router but do not implement any part of RPL ( even as RPL Leaf node= s ) should be considered part of the "RPL domain" ? >>>=20 >>> In section 5, the draft now says "..Datagrams destined to nodes outside t= he RPL domain are dropped if the outer-most IPv6 header contains a RPL Optio= n..." >>>=20 >>> This text would imply that any RPL node sending packets to nodes outside= should always tunnel to the Root ? Is that the intention really or am I mis= sing something here..=20 >>>=20 >>> Also note that if non-RPL Host is not considered part of the RPL domain,= then I am not sure that a forwarding router can know if the destination is i= nside the domain or not.=20 >>>=20 >>>=20 >>> -Regards, Joseph >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> Message: 5 >>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>> From: Jonathan Hui >>> To: IETF IPv6 Mailing List >>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>> Content-Type: text/plain; charset=3Dus-ascii >>>=20 >>>=20 >>> This update is intended to address Jari Arkko's AD review. >>>=20 >>> Summary of changes: >>> - Clarify when the RPL Option is used. >>> - Updated text on recommendations for avoiding fragmentation. >>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>> - Specify RPL Border Router operations in terms of forwarding decision o= utcomes. >>> - Expand security section. >>>=20 >>> -- >>> Jonathan Hui >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Date: October 11, 2011 10:17:15 PM PDT >>>> To: i-d-announce@ietf.org >>>> Cc: ipv6@ietf.org >>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Maintenance Working Group of t= he IETF. >>>>=20 >>>> Title : RPL Option for Carrying RPL Information in Data-Pla= ne Datagrams >>>> Author(s) : Jonathan W. Hui >>>> JP Vasseur >>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>> Pages : 14 >>>> Date : 2011-10-11 >>>>=20 >>>> The RPL protocol requires data-plane datagrams to carry RPL routing=20 >>>> information that is processed by RPL routers when forwarding those=20 >>>> datagrams. This document describes the RPL Option for use within a=20 >>>> RPL domain. >>>>=20 >>>>=20 >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.tx >>>> t >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative=20 >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=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 >=20 >=20 From jonhui@cisco.com Wed Nov 16 05:40:36 2011 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 ACA261F0C4A for ; Wed, 16 Nov 2011 05:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, 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 IjqVkQ2w5Qek for ; Wed, 16 Nov 2011 05:40:35 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C7F8A1F0C4B for ; Wed, 16 Nov 2011 05:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=7981; q=dns/txt; s=iport; t=1321450835; x=1322660435; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ZzndhNhinW4rBk+/E8l0dKHsI9GpmpnfndEZ/erAqVs=; b=UMkKCX+5wRv0ASU7PkOLjr/FzQSpEBkuhVnmNMBt4HPsN3ZWVNGAGacW gTS1O45QhwFgQp09PK9sGvQcjTdTHKak6ryQurNJ5JmobiifyMAxHGf5i gUShNFu1bWG7zrccmstdmiYEjLnyukYXWH6Bls3OmmODUcpUmbINTjbyw Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkAAD68w06rRDoG/2dsb2JhbABDmXKQBYEFgXIBAQEDAQEBAQ8BJzQLBQcECxEDAQEBAS4nKAgGEwkZh2AImisBnmaJNGMEiBSMIJId X-IronPort-AV: E=Sophos;i="4.69,521,1315180800"; d="scan'208";a="14547180" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 16 Nov 2011 13:40:35 +0000 Received: from sjc-vpn2-289.cisco.com (sjc-vpn2-289.cisco.com [10.21.113.33]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAGDeYH8030529; Wed, 16 Nov 2011 13:40:34 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: Date: Wed, 16 Nov 2011 05:40:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2CD3ADFF-DE10-440C-895B-8527190395F9@cisco.com> References: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1084) Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:40:36 -0000 With my proposed definition, a RPL Leaf is a RPL Router. A RPL Leaf = still operates and participates in the RPL routing protocol - it just = happens not to have any children. -- Jonathan Hui On Nov 16, 2011, at 5:25 AM, Thomas Heide Clausen wrote: > On 16 Nov 2011, at 21:15, Mukul Goyal wrote: >=20 >>> Now that we are at it: what is an RPL host? Or rather, why is this = even a conceivable thing to define? Afaik, RPL is a routing protocol, = and as such should concern only routers - not hosts? >>=20 >> My bad. By RPL host, I actually meant an RPL leaf node. I think this = term "RPL host" was in use at one point in time but I cant find a = reference to it in current spec. >=20 > A rose by any other name is *still* a rose.... >=20 > What is an RPL Leaf Node? What is the difference between a RPL Leaf = node and a RPL Router? >=20 > Isn't there a thing in the end of the network, inside the LLN, that = doesn't run RPL, aka, a host? >=20 > Thomas >=20 >=20 >>=20 >> THanks >> Mukul >>=20 >>=20 >>=20 >> ----- Original Message ----- >> From: "Thomas Heide Clausen" >> To: "Mukul Goyal" >> Cc: "JP Vasseur" , "roll" >> Sent: Wednesday, November 16, 2011 6:25:31 AM >> Subject: Re: [Roll] definition of "RPL Domain" >>=20 >> Now that we are at it: what is an RPL host? Or rather, why is this = even a conceivable thing to define? Afaik, RPL is a routing protocol, = and as such should concern only routers - not hosts? >>=20 >> I worry if this is inventing an entire ecosystem which "pretends to = be just like the Internet, except it is not", as it needs entirely new = stacks, protocols, translators/gateways everywhere, and with no real = traces of IP as we know it remaining? >>=20 >> --=20 >> Thomas Heide Clausen >> http://www.thomasclausen.org/ >>=20 >> "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >>=20 >>=20 >> On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >>=20 >>> Hi JP >>>=20 >>>> RPL domain: set of devices using RPL as a routing protocol. >>>=20 >>> I think this definition is little too vague. Some of the points that = need clarification: >>>=20 >>> 1. It is clear that RPL hosts and routers (as defined towards the = end of terminology section in RPL-19) are within an RPL domain but what = about the RPL-unaware IPv6 hosts attached to an RPL router/host? I would = imagine that such hosts are also within an RPL domain. >>>=20 >>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a = set of RPL instances in the LLN? Can multiple RPL domains exist within = an LLN? Or is it that an RPL domain is same as an LLN using RPL as a = routing protocol? >>>=20 >>> Thanks >>> Mukul =20 >>>=20 >>> ----- Original Message ----- >>> From: "JP Vasseur" >>> To: "Mukul Goyal" >>> Cc: "roll" >>> Sent: Wednesday, November 16, 2011 2:33:50 AM >>> Subject: Re: definition of "RPL Domain" >>>=20 >>> Hi Mukul, >>>=20 >>> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>>=20 >>>> Hi JP >>>>=20 >>>> I was wondering if the term "RPL Domain" could be defined in the = terminology draft.=20 >>>>=20 >>>=20 >>> How about >>>=20 >>> RPL domain: set of devices using RPL as a routing protocol. >>>=20 >>> Thanks. >>>=20 >>> JP. >>>=20 >>>> Thanks >>>> Mukul=20 >>>>=20 >>>> ----- Forwarded Message ----- >>>> From: "Joseph Reddy" >>>> To: ipv6@ietf.org >>>> Sent: Friday, October 14, 2011 7:15:05 PM >>>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>=20 >>>>=20 >>>> Hi Jonathan, >>>>=20 >>>> The draft uses the term "RPL domain" in several places and this is = not clearly defined.=20 >>>>=20 >>>> I would imagine that it includes all nodes that are downstream of = the RPL border router. But can you clarify if Host nodes that are = downstream of the border router but do not implement any part of RPL ( = even as RPL Leaf nodes ) should be considered part of the "RPL domain" ? >>>>=20 >>>> In section 5, the draft now says "..Datagrams destined to nodes = outside the RPL domain are dropped if the outer-most IPv6 header = contains a RPL Option..." >>>>=20 >>>> This text would imply that any RPL node sending packets to nodes = outside should always tunnel to the Root ? Is that the intention really = or am I missing something here..=20 >>>>=20 >>>> Also note that if non-RPL Host is not considered part of the RPL = domain, then I am not sure that a forwarding router can know if the = destination is inside the domain or not.=20 >>>>=20 >>>>=20 >>>> -Regards, Joseph >>>>=20 >>>>=20 >>>> ------------------------------ >>>>=20 >>>> Message: 5 >>>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>>> From: Jonathan Hui >>>> To: IETF IPv6 Mailing List >>>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>>> Content-Type: text/plain; charset=3Dus-ascii >>>>=20 >>>>=20 >>>> This update is intended to address Jari Arkko's AD review. >>>>=20 >>>> Summary of changes: >>>> - Clarify when the RPL Option is used. >>>> - Updated text on recommendations for avoiding fragmentation. >>>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >>>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>>> - Specify RPL Border Router operations in terms of forwarding = decision outcomes. >>>> - Expand security section. >>>>=20 >>>> -- >>>> Jonathan Hui >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Date: October 11, 2011 10:17:15 PM PDT >>>>> To: i-d-announce@ietf.org >>>>> Cc: ipv6@ietf.org >>>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Maintenance Working = Group of the IETF. >>>>>=20 >>>>> Title : RPL Option for Carrying RPL Information in = Data-Plane Datagrams >>>>> Author(s) : Jonathan W. Hui >>>>> JP Vasseur >>>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>>> Pages : 14 >>>>> Date : 2011-10-11 >>>>>=20 >>>>> The RPL protocol requires data-plane datagrams to carry RPL = routing >>>>> information that is processed by RPL routers when forwarding those >>>>> datagrams. This document describes the RPL Option for use within = a >>>>> RPL domain. >>>>>=20 >>>>>=20 >>>>> A URL for this Internet-Draft is: >>>>> = http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> This Internet-Draft can be retrieved at: >>>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>> = -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 >>>>> = -------------------------------------------------------------------- >>>>=20 >>>>=20 >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>>=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 thomas@thomasclausen.org Wed Nov 16 05:48:49 2011 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 9033711E80E2 for ; Wed, 16 Nov 2011 05:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 7+tkNBUjGNkD for ; Wed, 16 Nov 2011 05:48:48 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7CE21F953A for ; Wed, 16 Nov 2011 05:48:48 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 679BFA6A17 for ; Wed, 16 Nov 2011 05:48:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C5ACAC27E7; Wed, 16 Nov 2011 05:48:45 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.3.103] (unknown [203.69.99.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C19FEC27DD; Wed, 16 Nov 2011 05:48:44 -0800 (PST) References: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> <2CD3ADFF-DE10-440C-895B-8527190395F9@cisco.com> In-Reply-To: <2CD3ADFF-DE10-440C-895B-8527190395F9@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <92C241B0-33A1-41A2-8C64-16E5602971D5@thomasclausen.org> X-Mailer: iPad Mail (9A334) From: Thomas Heide Clausen Date: Wed, 16 Nov 2011 21:49:14 +0800 To: Jonathan Hui Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:48:49 -0000 On 16 Nov 2011, at 21:40, Jonathan Hui wrote: >=20 > With my proposed definition, a RPL Leaf is a RPL Router. A RPL Leaf still= operates and participates in the RPL routing protocol - it just happens not= to have any children. So it just happens to be a particular "accidental" topological position of a= router, but entails no different state, transitions or parameters than any o= ther RPL router. Therefore, there is absolutely no need for another term, it is just an RPL r= outer. I therefore strongly suggest that there is no reason to invent yet another p= iece of confusing terminology (and, in general, that ROLL would do well by t= rying to adhere to standard Internet terminology) Thomas >=20 > -- > Jonathan Hui >=20 > On Nov 16, 2011, at 5:25 AM, Thomas Heide Clausen wrote: >=20 >> On 16 Nov 2011, at 21:15, Mukul Goyal wrote: >>=20 >>>> Now that we are at it: what is an RPL host? Or rather, why is this even= a conceivable thing to define? Afaik, RPL is a routing protocol, and as suc= h should concern only routers - not hosts? >>>=20 >>> My bad. By RPL host, I actually meant an RPL leaf node. I think this ter= m "RPL host" was in use at one point in time but I cant find a reference to i= t in current spec. >>=20 >> A rose by any other name is *still* a rose.... >>=20 >> What is an RPL Leaf Node? What is the difference between a RPL Leaf node a= nd a RPL Router? >>=20 >> Isn't there a thing in the end of the network, inside the LLN, that does= n't run RPL, aka, a host? >>=20 >> Thomas >>=20 >>=20 >>>=20 >>> THanks >>> Mukul >>>=20 >>>=20 >>>=20 >>> ----- Original Message ----- >>> From: "Thomas Heide Clausen" >>> To: "Mukul Goyal" >>> Cc: "JP Vasseur" , "roll" >>> Sent: Wednesday, November 16, 2011 6:25:31 AM >>> Subject: Re: [Roll] definition of "RPL Domain" >>>=20 >>> Now that we are at it: what is an RPL host? Or rather, why is this even a= conceivable thing to define? Afaik, RPL is a routing protocol, and as such s= hould concern only routers - not hosts? >>>=20 >>> I worry if this is inventing an entire ecosystem which "pretends to be j= ust like the Internet, except it is not", as it needs entirely new stacks, p= rotocols, translators/gateways everywhere, and with no real traces of IP as w= e know it remaining? >>>=20 >>> --=20 >>> Thomas Heide Clausen >>> http://www.thomasclausen.org/ >>>=20 >>> "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >>>=20 >>>=20 >>> On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >>>=20 >>>> Hi JP >>>>=20 >>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>=20 >>>> I think this definition is little too vague. Some of the points that ne= ed clarification: >>>>=20 >>>> 1. It is clear that RPL hosts and routers (as defined towards the end o= f terminology section in RPL-19) are within an RPL domain but what about the= RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagine that= such hosts are also within an RPL domain. >>>>=20 >>>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set o= f RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or= is it that an RPL domain is same as an LLN using RPL as a routing protocol?= >>>>=20 >>>> Thanks >>>> Mukul =20 >>>>=20 >>>> ----- Original Message ----- >>>> From: "JP Vasseur" >>>> To: "Mukul Goyal" >>>> Cc: "roll" >>>> Sent: Wednesday, November 16, 2011 2:33:50 AM >>>> Subject: Re: definition of "RPL Domain" >>>>=20 >>>> Hi Mukul, >>>>=20 >>>> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>>>=20 >>>>> Hi JP >>>>>=20 >>>>> I was wondering if the term "RPL Domain" could be defined in the termi= nology draft.=20 >>>>>=20 >>>>=20 >>>> How about >>>>=20 >>>> RPL domain: set of devices using RPL as a routing protocol. >>>>=20 >>>> Thanks. >>>>=20 >>>> JP. >>>>=20 >>>>> Thanks >>>>> Mukul=20 >>>>>=20 >>>>> ----- Forwarded Message ----- >>>>> From: "Joseph Reddy" >>>>> To: ipv6@ietf.org >>>>> Sent: Friday, October 14, 2011 7:15:05 PM >>>>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>=20 >>>>>=20 >>>>> Hi Jonathan, >>>>>=20 >>>>> The draft uses the term "RPL domain" in several places and this is not= clearly defined.=20 >>>>>=20 >>>>> I would imagine that it includes all nodes that are downstream of the R= PL border router. But can you clarify if Host nodes that are downstream of t= he border router but do not implement any part of RPL ( even as RPL Leaf nod= es ) should be considered part of the "RPL domain" ? >>>>>=20 >>>>> In section 5, the draft now says "..Datagrams destined to nodes outsid= e the RPL domain are dropped if the outer-most IPv6 header contains a RPL Op= tion..." >>>>>=20 >>>>> This text would imply that any RPL node sending packets to nodes outsi= de should always tunnel to the Root ? Is that the intention really or am I m= issing something here..=20 >>>>>=20 >>>>> Also note that if non-RPL Host is not considered part of the RPL domai= n, then I am not sure that a forwarding router can know if the destination i= s inside the domain or not.=20 >>>>>=20 >>>>>=20 >>>>> -Regards, Joseph >>>>>=20 >>>>>=20 >>>>> ------------------------------ >>>>>=20 >>>>> Message: 5 >>>>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>>>> From: Jonathan Hui >>>>> To: IETF IPv6 Mailing List >>>>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>>>> Content-Type: text/plain; charset=3Dus-ascii >>>>>=20 >>>>>=20 >>>>> This update is intended to address Jari Arkko's AD review. >>>>>=20 >>>>> Summary of changes: >>>>> - Clarify when the RPL Option is used. >>>>> - Updated text on recommendations for avoiding fragmentation. >>>>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >>>>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>>>> - Specify RPL Border Router operations in terms of forwarding decision= outcomes. >>>>> - Expand security section. >>>>>=20 >>>>> -- >>>>> Jonathan Hui >>>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>>> From: internet-drafts@ietf.org >>>>>> Date: October 11, 2011 10:17:15 PM PDT >>>>>> To: i-d-announce@ietf.org >>>>>> Cc: ipv6@ietf.org >>>>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. This draft is a work item of the IPv6 Maintenance Working Group o= f the IETF. >>>>>>=20 >>>>>> Title : RPL Option for Carrying RPL Information in Data-Pla= ne Datagrams >>>>>> Author(s) : Jonathan W. Hui >>>>>> JP Vasseur >>>>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>>>> Pages : 14 >>>>>> Date : 2011-10-11 >>>>>>=20 >>>>>> The RPL protocol requires data-plane datagrams to carry RPL routing >>>>>> information that is processed by RPL routers when forwarding those >>>>>> datagrams. This document describes the RPL Option for use within a >>>>>> RPL domain. >>>>>>=20 >>>>>>=20 >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt= >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> This Internet-Draft can be retrieved at: >>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>>> -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> -------------------------------------------------------------------- >>>>>=20 >>>>>=20 >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>>=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 >=20 From prvs=294de8a4a=mukul@uwm.edu Wed Nov 16 05:49:27 2011 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 C510121F9636 for ; Wed, 16 Nov 2011 05:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5+vgxtppCAG for ; Wed, 16 Nov 2011 05:49:26 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 96FD921F957D for ; Wed, 16 Nov 2011 05:49:26 -0800 (PST) Received: from localhost (HELO mta03.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 16 Nov 2011 07:49:26 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 16ACC1FD010; Wed, 16 Nov 2011 07:49:26 -0600 (CST) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+dDWUyqzhtx; Wed, 16 Nov 2011 07:49:25 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id AADCF1FD00F; Wed, 16 Nov 2011 07:49:25 -0600 (CST) Date: Wed, 16 Nov 2011 07:49:25 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <553275216.313071.1321451365573.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <2CD3ADFF-DE10-440C-895B-8527190395F9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll , Thomas Heide Clausen Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:49:27 -0000 I agree. Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Thomas Heide Clausen" Cc: "Mukul Goyal" , "roll" Sent: Wednesday, November 16, 2011 7:40:34 AM Subject: Re: [Roll] definition of "RPL Domain" With my proposed definition, a RPL Leaf is a RPL Router. A RPL Leaf still operates and participates in the RPL routing protocol - it just happens not to have any children. -- Jonathan Hui On Nov 16, 2011, at 5:25 AM, Thomas Heide Clausen wrote: > On 16 Nov 2011, at 21:15, Mukul Goyal wrote: > >>> Now that we are at it: what is an RPL host? Or rather, why is this even a conceivable thing to define? Afaik, RPL is a routing protocol, and as such should concern only routers - not hosts? >> >> My bad. By RPL host, I actually meant an RPL leaf node. I think this term "RPL host" was in use at one point in time but I cant find a reference to it in current spec. > > A rose by any other name is *still* a rose.... > > What is an RPL Leaf Node? What is the difference between a RPL Leaf node and a RPL Router? > > Isn't there a thing in the end of the network, inside the LLN, that doesn't run RPL, aka, a host? > > Thomas > > >> >> THanks >> Mukul >> >> >> >> ----- Original Message ----- >> From: "Thomas Heide Clausen" >> To: "Mukul Goyal" >> Cc: "JP Vasseur" , "roll" >> Sent: Wednesday, November 16, 2011 6:25:31 AM >> Subject: Re: [Roll] definition of "RPL Domain" >> >> Now that we are at it: what is an RPL host? Or rather, why is this even a conceivable thing to define? Afaik, RPL is a routing protocol, and as such should concern only routers - not hosts? >> >> I worry if this is inventing an entire ecosystem which "pretends to be just like the Internet, except it is not", as it needs entirely new stacks, protocols, translators/gateways everywhere, and with no real traces of IP as we know it remaining? >> >> -- >> Thomas Heide Clausen >> http://www.thomasclausen.org/ >> >> "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >> >> >> On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >> >>> Hi JP >>> >>>> RPL domain: set of devices using RPL as a routing protocol. >>> >>> I think this definition is little too vague. Some of the points that need clarification: >>> >>> 1. It is clear that RPL hosts and routers (as defined towards the end of terminology section in RPL-19) are within an RPL domain but what about the RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagine that such hosts are also within an RPL domain. >>> >>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or is it that an RPL domain is same as an LLN using RPL as a routing protocol? >>> >>> Thanks >>> Mukul >>> >>> ----- Original Message ----- >>> From: "JP Vasseur" >>> To: "Mukul Goyal" >>> Cc: "roll" >>> Sent: Wednesday, November 16, 2011 2:33:50 AM >>> Subject: Re: definition of "RPL Domain" >>> >>> Hi Mukul, >>> >>> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>> >>>> Hi JP >>>> >>>> I was wondering if the term "RPL Domain" could be defined in the terminology draft. >>>> >>> >>> How about >>> >>> RPL domain: set of devices using RPL as a routing protocol. >>> >>> Thanks. >>> >>> JP. >>> >>>> Thanks >>>> Mukul >>>> >>>> ----- Forwarded Message ----- >>>> From: "Joseph Reddy" >>>> To: ipv6@ietf.org >>>> Sent: Friday, October 14, 2011 7:15:05 PM >>>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>> >>>> >>>> Hi Jonathan, >>>> >>>> The draft uses the term "RPL domain" in several places and this is not clearly defined. >>>> >>>> I would imagine that it includes all nodes that are downstream of the RPL border router. But can you clarify if Host nodes that are downstream of the border router but do not implement any part of RPL ( even as RPL Leaf nodes ) should be considered part of the "RPL domain" ? >>>> >>>> In section 5, the draft now says "..Datagrams destined to nodes outside the RPL domain are dropped if the outer-most IPv6 header contains a RPL Option..." >>>> >>>> This text would imply that any RPL node sending packets to nodes outside should always tunnel to the Root ? Is that the intention really or am I missing something here.. >>>> >>>> Also note that if non-RPL Host is not considered part of the RPL domain, then I am not sure that a forwarding router can know if the destination is inside the domain or not. >>>> >>>> >>>> -Regards, Joseph >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 5 >>>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>>> From: Jonathan Hui >>>> To: IETF IPv6 Mailing List >>>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>>> Content-Type: text/plain; charset=us-ascii >>>> >>>> >>>> This update is intended to address Jari Arkko's AD review. >>>> >>>> Summary of changes: >>>> - Clarify when the RPL Option is used. >>>> - Updated text on recommendations for avoiding fragmentation. >>>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >>>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>>> - Specify RPL Border Router operations in terms of forwarding decision outcomes. >>>> - Expand security section. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> Begin forwarded message: >>>> >>>>> From: internet-drafts@ietf.org >>>>> Date: October 11, 2011 10:17:15 PM PDT >>>>> To: i-d-announce@ietf.org >>>>> Cc: ipv6@ietf.org >>>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. >>>>> >>>>> Title : RPL Option for Carrying RPL Information in Data-Plane Datagrams >>>>> Author(s) : Jonathan W. Hui >>>>> JP Vasseur >>>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>>> Pages : 14 >>>>> Date : 2011-10-11 >>>>> >>>>> The RPL protocol requires data-plane datagrams to carry RPL routing >>>>> information that is processed by RPL routers when forwarding those >>>>> datagrams. This document describes the RPL Option for use within a >>>>> RPL domain. >>>>> >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> This Internet-Draft can be retrieved at: >>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> _______________________________________________ >>> 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 jonhui@cisco.com Wed Nov 16 05:53:30 2011 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 6C8CE21F968A for ; Wed, 16 Nov 2011 05:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 2DvnC0gRocOy for ; Wed, 16 Nov 2011 05:53:29 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6802A21F9689 for ; Wed, 16 Nov 2011 05:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=9242; q=dns/txt; s=iport; t=1321451609; x=1322661209; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Pae7X7SFy5zvUF2SIoHTUw92VyFD36KjpZJieEjl3Dc=; b=aGzTgj4zHjh5X7v4lsmxUIScjXqNLdssgoHuhTHMPZQhBAMh4SQP6ouS qGtUTspL3fh5lZJdU+WBBXlszi2k0gVStN3ucplqdQ+zhbvX5q9ropm7a Fx/Uhn9MPWqwFCi1nGh2uOOXhXAEB9Cq0DvE1Mjv4KgOF3kryuixSpYW0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkAABjAw06rRDoJ/2dsb2JhbABDmXKQBYEFgXIBAQEDAQEBAQ8BJzQLBQcECxEDAQEBAS4nKAgGEwkZh2AImi0BnmGJNGMEiBSMIJId X-IronPort-AV: E=Sophos;i="4.69,521,1315180800"; d="scan'208";a="12849616" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 16 Nov 2011 13:53:29 +0000 Received: from sjc-vpn2-289.cisco.com (sjc-vpn2-289.cisco.com [10.21.113.33]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAGDrRio006163; Wed, 16 Nov 2011 13:53:28 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <92C241B0-33A1-41A2-8C64-16E5602971D5@thomasclausen.org> Date: Wed, 16 Nov 2011 05:53:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8688B01C-F255-4868-AF16-0A8AD6B27BE9@cisco.com> References: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> <2CD3ADFF-DE10-440C-895B-8527190395F9@cisco.com> <92C241B0-33A1-41A2-8C64-16E5602971D5@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1084) Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:53:30 -0000 It may or may not be accidental. It is perfectly acceptable for a = device operating RPL not to advertise routes for destinations other than = itself. Either way, the node still operates RPL. -- Jonathan Hui On Nov 16, 2011, at 5:49 AM, Thomas Heide Clausen wrote: > On 16 Nov 2011, at 21:40, Jonathan Hui wrote: >=20 >> With my proposed definition, a RPL Leaf is a RPL Router. A RPL Leaf = still operates and participates in the RPL routing protocol - it just = happens not to have any children. >=20 > So it just happens to be a particular "accidental" topological = position of a router, but entails no different state, transitions or = parameters than any other RPL router. >=20 > Therefore, there is absolutely no need for another term, it is just an = RPL router. >=20 > I therefore strongly suggest that there is no reason to invent yet = another piece of confusing terminology (and, in general, that ROLL would = do well by trying to adhere to standard Internet terminology) >=20 > Thomas >=20 >> -- >> Jonathan Hui >>=20 >> On Nov 16, 2011, at 5:25 AM, Thomas Heide Clausen wrote: >>=20 >>> On 16 Nov 2011, at 21:15, Mukul Goyal wrote: >>>=20 >>>>> Now that we are at it: what is an RPL host? Or rather, why is this = even a conceivable thing to define? Afaik, RPL is a routing protocol, = and as such should concern only routers - not hosts? >>>>=20 >>>> My bad. By RPL host, I actually meant an RPL leaf node. I think = this term "RPL host" was in use at one point in time but I cant find a = reference to it in current spec. >>>=20 >>> A rose by any other name is *still* a rose.... >>>=20 >>> What is an RPL Leaf Node? What is the difference between a RPL Leaf = node and a RPL Router? >>>=20 >>> Isn't there a thing in the end of the network, inside the LLN, that = doesn't run RPL, aka, a host? >>>=20 >>> Thomas >>>=20 >>>=20 >>>>=20 >>>> THanks >>>> Mukul >>>>=20 >>>>=20 >>>>=20 >>>> ----- Original Message ----- >>>> From: "Thomas Heide Clausen" >>>> To: "Mukul Goyal" >>>> Cc: "JP Vasseur" , "roll" >>>> Sent: Wednesday, November 16, 2011 6:25:31 AM >>>> Subject: Re: [Roll] definition of "RPL Domain" >>>>=20 >>>> Now that we are at it: what is an RPL host? Or rather, why is this = even a conceivable thing to define? Afaik, RPL is a routing protocol, = and as such should concern only routers - not hosts? >>>>=20 >>>> I worry if this is inventing an entire ecosystem which "pretends to = be just like the Internet, except it is not", as it needs entirely new = stacks, protocols, translators/gateways everywhere, and with no real = traces of IP as we know it remaining? >>>>=20 >>>> --=20 >>>> Thomas Heide Clausen >>>> http://www.thomasclausen.org/ >>>>=20 >>>> "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >>>>=20 >>>>=20 >>>> On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >>>>=20 >>>>> Hi JP >>>>>=20 >>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>=20 >>>>> I think this definition is little too vague. Some of the points = that need clarification: >>>>>=20 >>>>> 1. It is clear that RPL hosts and routers (as defined towards the = end of terminology section in RPL-19) are within an RPL domain but what = about the RPL-unaware IPv6 hosts attached to an RPL router/host? I would = imagine that such hosts are also within an RPL domain. >>>>>=20 >>>>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a = set of RPL instances in the LLN? Can multiple RPL domains exist within = an LLN? Or is it that an RPL domain is same as an LLN using RPL as a = routing protocol? >>>>>=20 >>>>> Thanks >>>>> Mukul =20 >>>>>=20 >>>>> ----- Original Message ----- >>>>> From: "JP Vasseur" >>>>> To: "Mukul Goyal" >>>>> Cc: "roll" >>>>> Sent: Wednesday, November 16, 2011 2:33:50 AM >>>>> Subject: Re: definition of "RPL Domain" >>>>>=20 >>>>> Hi Mukul, >>>>>=20 >>>>> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>>>>=20 >>>>>> Hi JP >>>>>>=20 >>>>>> I was wondering if the term "RPL Domain" could be defined in the = terminology draft.=20 >>>>>>=20 >>>>>=20 >>>>> How about >>>>>=20 >>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> JP. >>>>>=20 >>>>>> Thanks >>>>>> Mukul=20 >>>>>>=20 >>>>>> ----- Forwarded Message ----- >>>>>> From: "Joseph Reddy" >>>>>> To: ipv6@ietf.org >>>>>> Sent: Friday, October 14, 2011 7:15:05 PM >>>>>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>=20 >>>>>>=20 >>>>>> Hi Jonathan, >>>>>>=20 >>>>>> The draft uses the term "RPL domain" in several places and this = is not clearly defined.=20 >>>>>>=20 >>>>>> I would imagine that it includes all nodes that are downstream of = the RPL border router. But can you clarify if Host nodes that are = downstream of the border router but do not implement any part of RPL ( = even as RPL Leaf nodes ) should be considered part of the "RPL domain" ? >>>>>>=20 >>>>>> In section 5, the draft now says "..Datagrams destined to nodes = outside the RPL domain are dropped if the outer-most IPv6 header = contains a RPL Option..." >>>>>>=20 >>>>>> This text would imply that any RPL node sending packets to nodes = outside should always tunnel to the Root ? Is that the intention really = or am I missing something here..=20 >>>>>>=20 >>>>>> Also note that if non-RPL Host is not considered part of the RPL = domain, then I am not sure that a forwarding router can know if the = destination is inside the domain or not.=20 >>>>>>=20 >>>>>>=20 >>>>>> -Regards, Joseph >>>>>>=20 >>>>>>=20 >>>>>> ------------------------------ >>>>>>=20 >>>>>> Message: 5 >>>>>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>>>>> From: Jonathan Hui >>>>>> To: IETF IPv6 Mailing List >>>>>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>>>>> Content-Type: text/plain; charset=3Dus-ascii >>>>>>=20 >>>>>>=20 >>>>>> This update is intended to address Jari Arkko's AD review. >>>>>>=20 >>>>>> Summary of changes: >>>>>> - Clarify when the RPL Option is used. >>>>>> - Updated text on recommendations for avoiding fragmentation. >>>>>> - Specify skip-over-and-continue policy for unrecognized = sub-TLVs. >>>>>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>>>>> - Specify RPL Border Router operations in terms of forwarding = decision outcomes. >>>>>> - Expand security section. >>>>>>=20 >>>>>> -- >>>>>> Jonathan Hui >>>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>>> From: internet-drafts@ietf.org >>>>>>> Date: October 11, 2011 10:17:15 PM PDT >>>>>>> To: i-d-announce@ietf.org >>>>>>> Cc: ipv6@ietf.org >>>>>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>=20 >>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. This draft is a work item of the IPv6 = Maintenance Working Group of the IETF. >>>>>>>=20 >>>>>>> Title : RPL Option for Carrying RPL Information in = Data-Plane Datagrams >>>>>>> Author(s) : Jonathan W. Hui >>>>>>> JP Vasseur >>>>>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>>>>> Pages : 14 >>>>>>> Date : 2011-10-11 >>>>>>>=20 >>>>>>> The RPL protocol requires data-plane datagrams to carry RPL = routing >>>>>>> information that is processed by RPL routers when forwarding = those >>>>>>> datagrams. This document describes the RPL Option for use = within a >>>>>>> RPL domain. >>>>>>>=20 >>>>>>>=20 >>>>>>> A URL for this Internet-Draft is: >>>>>>> = http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>>>>=20 >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>=20 >>>>>>> This Internet-Draft can be retrieved at: >>>>>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>>>> = -------------------------------------------------------------------- >>>>>>> IETF IPv6 working group mailing list >>>>>>> ipv6@ietf.org >>>>>>> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> = -------------------------------------------------------------------- >>>>>>=20 >>>>>>=20 >>>>>> = -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> = -------------------------------------------------------------------- >>>>>=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 >>=20 From thomas@thomasclausen.org Wed Nov 16 05:56:49 2011 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 3DFE821F96A2 for ; Wed, 16 Nov 2011 05:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 GfSgdV0J8uFZ for ; Wed, 16 Nov 2011 05:56:48 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4333F21F96A1 for ; Wed, 16 Nov 2011 05:56:48 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 1E38FCD13B for ; Wed, 16 Nov 2011 05:56:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D76A7C27F7; Wed, 16 Nov 2011 05:56:47 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.3.103] (unknown [203.69.99.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 3A829C27F6; Wed, 16 Nov 2011 05:56:47 -0800 (PST) References: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> <2CD3ADFF-DE10-440C-895B-8527190395F9@cisco.com> <92C241B0-33A1-41A2-8C64-16E5602971D5@thomasclausen.org> <8688B01C-F255-4868-AF16-0A8AD6B27BE9@cisco.com> In-Reply-To: <8688B01C-F255-4868-AF16-0A8AD6B27BE9@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <164D1B8C-1326-430B-8E16-F961029BEC59@thomasclausen.org> X-Mailer: iPad Mail (9A334) From: Thomas Heide Clausen Date: Wed, 16 Nov 2011 21:57:17 +0800 To: Jonathan Hui Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:56:49 -0000 Yes, but is there a node, connected to and in an RPL deployment, that doesn'= t run RPL? In other words, is there a host in a RPL network? --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) On 16 Nov 2011, at 21:53, Jonathan Hui wrote: >=20 > It may or may not be accidental. It is perfectly acceptable for a device o= perating RPL not to advertise routes for destinations other than itself. Ei= ther way, the node still operates RPL. >=20 > -- > Jonathan Hui >=20 > On Nov 16, 2011, at 5:49 AM, Thomas Heide Clausen wrote: >=20 >> On 16 Nov 2011, at 21:40, Jonathan Hui wrote: >>=20 >>> With my proposed definition, a RPL Leaf is a RPL Router. A RPL Leaf sti= ll operates and participates in the RPL routing protocol - it just happens n= ot to have any children. >>=20 >> So it just happens to be a particular "accidental" topological position o= f a router, but entails no different state, transitions or parameters than a= ny other RPL router. >>=20 >> Therefore, there is absolutely no need for another term, it is just an RP= L router. >>=20 >> I therefore strongly suggest that there is no reason to invent yet anothe= r piece of confusing terminology (and, in general, that ROLL would do well b= y trying to adhere to standard Internet terminology) >>=20 >> Thomas >>=20 >>> -- >>> Jonathan Hui >>>=20 >>> On Nov 16, 2011, at 5:25 AM, Thomas Heide Clausen wrote: >>>=20 >>>> On 16 Nov 2011, at 21:15, Mukul Goyal wrote: >>>>=20 >>>>>> Now that we are at it: what is an RPL host? Or rather, why is this ev= en a conceivable thing to define? Afaik, RPL is a routing protocol, and as s= uch should concern only routers - not hosts? >>>>>=20 >>>>> My bad. By RPL host, I actually meant an RPL leaf node. I think this t= erm "RPL host" was in use at one point in time but I cant find a reference t= o it in current spec. >>>>=20 >>>> A rose by any other name is *still* a rose.... >>>>=20 >>>> What is an RPL Leaf Node? What is the difference between a RPL Leaf nod= e and a RPL Router? >>>>=20 >>>> Isn't there a thing in the end of the network, inside the LLN, that do= esn't run RPL, aka, a host? >>>>=20 >>>> Thomas >>>>=20 >>>>=20 >>>>>=20 >>>>> THanks >>>>> Mukul >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ----- Original Message ----- >>>>> From: "Thomas Heide Clausen" >>>>> To: "Mukul Goyal" >>>>> Cc: "JP Vasseur" , "roll" >>>>> Sent: Wednesday, November 16, 2011 6:25:31 AM >>>>> Subject: Re: [Roll] definition of "RPL Domain" >>>>>=20 >>>>> Now that we are at it: what is an RPL host? Or rather, why is this eve= n a conceivable thing to define? Afaik, RPL is a routing protocol, and as su= ch should concern only routers - not hosts? >>>>>=20 >>>>> I worry if this is inventing an entire ecosystem which "pretends to be= just like the Internet, except it is not", as it needs entirely new stacks,= protocols, translators/gateways everywhere, and with no real traces of IP a= s we know it remaining? >>>>>=20 >>>>> --=20 >>>>> Thomas Heide Clausen >>>>> http://www.thomasclausen.org/ >>>>>=20 >>>>> "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >>>>>=20 >>>>>=20 >>>>> On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >>>>>=20 >>>>>> Hi JP >>>>>>=20 >>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>=20 >>>>>> I think this definition is little too vague. Some of the points that n= eed clarification: >>>>>>=20 >>>>>> 1. It is clear that RPL hosts and routers (as defined towards the end= of terminology section in RPL-19) are within an RPL domain but what about t= he RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagine th= at such hosts are also within an RPL domain. >>>>>>=20 >>>>>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a se= t of RPL instances in the LLN? Can multiple RPL domains exist within an LLN?= Or is it that an RPL domain is same as an LLN using RPL as a routing protoc= ol? >>>>>>=20 >>>>>> Thanks >>>>>> Mukul =20 >>>>>>=20 >>>>>> ----- Original Message ----- >>>>>> From: "JP Vasseur" >>>>>> To: "Mukul Goyal" >>>>>> Cc: "roll" >>>>>> Sent: Wednesday, November 16, 2011 2:33:50 AM >>>>>> Subject: Re: definition of "RPL Domain" >>>>>>=20 >>>>>> Hi Mukul, >>>>>>=20 >>>>>> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>>>>>=20 >>>>>>> Hi JP >>>>>>>=20 >>>>>>> I was wondering if the term "RPL Domain" could be defined in the ter= minology draft.=20 >>>>>>>=20 >>>>>>=20 >>>>>> How about >>>>>>=20 >>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> JP. >>>>>>=20 >>>>>>> Thanks >>>>>>> Mukul=20 >>>>>>>=20 >>>>>>> ----- Forwarded Message ----- >>>>>>> From: "Joseph Reddy" >>>>>>> To: ipv6@ietf.org >>>>>>> Sent: Friday, October 14, 2011 7:15:05 PM >>>>>>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>=20 >>>>>>>=20 >>>>>>> Hi Jonathan, >>>>>>>=20 >>>>>>> The draft uses the term "RPL domain" in several places and this is n= ot clearly defined.=20 >>>>>>>=20 >>>>>>> I would imagine that it includes all nodes that are downstream of th= e RPL border router. But can you clarify if Host nodes that are downstream o= f the border router but do not implement any part of RPL ( even as RPL Leaf n= odes ) should be considered part of the "RPL domain" ? >>>>>>>=20 >>>>>>> In section 5, the draft now says "..Datagrams destined to nodes outs= ide the RPL domain are dropped if the outer-most IPv6 header contains a RPL O= ption..." >>>>>>>=20 >>>>>>> This text would imply that any RPL node sending packets to nodes out= side should always tunnel to the Root ? Is that the intention really or am I= missing something here..=20 >>>>>>>=20 >>>>>>> Also note that if non-RPL Host is not considered part of the RPL dom= ain, then I am not sure that a forwarding router can know if the destination= is inside the domain or not.=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -Regards, Joseph >>>>>>>=20 >>>>>>>=20 >>>>>>> ------------------------------ >>>>>>>=20 >>>>>>> Message: 5 >>>>>>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>>>>>> From: Jonathan Hui >>>>>>> To: IETF IPv6 Mailing List >>>>>>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>>>>>> Content-Type: text/plain; charset=3Dus-ascii >>>>>>>=20 >>>>>>>=20 >>>>>>> This update is intended to address Jari Arkko's AD review. >>>>>>>=20 >>>>>>> Summary of changes: >>>>>>> - Clarify when the RPL Option is used. >>>>>>> - Updated text on recommendations for avoiding fragmentation. >>>>>>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >>>>>>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>>>>>> - Specify RPL Border Router operations in terms of forwarding decisi= on outcomes. >>>>>>> - Expand security section. >>>>>>>=20 >>>>>>> -- >>>>>>> Jonathan Hui >>>>>>>=20 >>>>>>> Begin forwarded message: >>>>>>>=20 >>>>>>>> From: internet-drafts@ietf.org >>>>>>>> Date: October 11, 2011 10:17:15 PM PDT >>>>>>>> To: i-d-announce@ietf.org >>>>>>>> Cc: ipv6@ietf.org >>>>>>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>=20 >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. This draft is a work item of the IPv6 Maintenance Working Group o= f the IETF. >>>>>>>>=20 >>>>>>>> Title : RPL Option for Carrying RPL Information in Data-P= lane Datagrams >>>>>>>> Author(s) : Jonathan W. Hui >>>>>>>> JP Vasseur >>>>>>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>>>>>> Pages : 14 >>>>>>>> Date : 2011-10-11 >>>>>>>>=20 >>>>>>>> The RPL protocol requires data-plane datagrams to carry RPL routing= >>>>>>>> information that is processed by RPL routers when forwarding those >>>>>>>> datagrams. This document describes the RPL Option for use within a= >>>>>>>> RPL domain. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> A URL for this Internet-Draft is: >>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.t= xt >>>>>>>>=20 >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>=20 >>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.tx= t >>>>>>>> -------------------------------------------------------------------= - >>>>>>>> IETF IPv6 working group mailing list >>>>>>>> ipv6@ietf.org >>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6= >>>>>>>> -------------------------------------------------------------------= - >>>>>>>=20 >>>>>>>=20 >>>>>>> --------------------------------------------------------------------= >>>>>>> IETF IPv6 working group mailing list >>>>>>> ipv6@ietf.org >>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> --------------------------------------------------------------------= >>>>>>=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 >>>=20 >=20 From angelo.castellani@gmail.com Wed Nov 16 05:57:51 2011 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 8714D21F958D for ; Wed, 16 Nov 2011 05:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Q1qx8d70Or0R for ; Wed, 16 Nov 2011 05:57:51 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE7FD21F954F for ; Wed, 16 Nov 2011 05:57:50 -0800 (PST) Received: by wyf28 with SMTP id 28so606690wyf.31 for ; Wed, 16 Nov 2011 05:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=MjWTBsoXSBYKdth5ghrYH5+EpXnF2MDjDmEBNl01vIM=; b=CtNk3wh/MJBD2QUo7rnRZY0qTV2Vp2aDN9DjGuYRzkWDnsgtAM+DoR6pahMe4RkOrg mVCeNO7nrhhZx3U18Mjim7XZTmGHbugekn0ELNOvPv3hfzVirH0A09jQ2V5MYKDUeo0n OQSiLuDClG5QCmE42do0x/AluB0JLKr1ixq58= Received: by 10.216.14.206 with SMTP id d56mr802407wed.33.1321451803129; Wed, 16 Nov 2011 05:56:43 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.62.8 with HTTP; Wed, 16 Nov 2011 05:56:01 -0800 (PST) In-Reply-To: References: <736630399.709598.1318899920135.JavaMail.root@mail05.pantherlink.uwm.edu> From: "Angelo P. Castellani" Date: Wed, 16 Nov 2011 14:56:01 +0100 X-Google-Sender-Auth: F5QZkEc4R1tCi3asbf6VipcbyDU Message-ID: To: JP Vasseur Content-Type: text/plain; charset=UTF-8 Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 13:57:51 -0000 On Wed, Nov 16, 2011 at 09:33, JP Vasseur wrote: > RPL domain: set of devices using RPL as a routing protocol. and something like: -- set of router devices in a local area network belonging to the same administrative domain. multiple RPL domains can be formed inside a single administrative domain for different purposes. Best, Angelo From jonhui@cisco.com Wed Nov 16 06:02:59 2011 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 08FC621F9474 for ; Wed, 16 Nov 2011 06:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 N233E-94lPbg for ; Wed, 16 Nov 2011 06:02:52 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1A53A21F943D for ; Wed, 16 Nov 2011 06:02:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=10334; q=dns/txt; s=iport; t=1321452172; x=1322661772; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=gsR2nHx/YACd4JM+VS2YtQz5WEXTytS0uhyouRpvg3w=; b=CEJFE/8myoAPRL8zf/juNP+wpia6FOtFBhOxJ7G4rwtJmzb9IwlipeeF NS9XXBiyko5+MxUdRSPp081BnJcDuKOBgShlfD9qPASuQ8smR2y7udWLT JvacD474fON2ixBRuMgqgzrwtddqkOj7p9OLr+j4LZaRjUPXSN3XyxhaA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkAAADCw06rRDoJ/2dsb2JhbABDmXKQBYEFgXIBAQEDAQEBAQ8BJzQLBQcECxEDAQEBAS4nKAgGEwkZh2AImicBnmGJNGMEiBSMIJId X-IronPort-AV: E=Sophos;i="4.69,521,1315180800"; d="scan'208";a="14621411" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 16 Nov 2011 14:02:51 +0000 Received: from sjc-vpn2-289.cisco.com (sjc-vpn2-289.cisco.com [10.21.113.33]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAGE2oU8011431; Wed, 16 Nov 2011 14:02:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <164D1B8C-1326-430B-8E16-F961029BEC59@thomasclausen.org> Date: Wed, 16 Nov 2011 06:02:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1E9DE872-6511-4F8C-B985-B94EB0635D3F@cisco.com> References: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> <2CD3ADFF-DE10-440C-895B-8527190395F9@cisco.com> <92C241B0-33A1-41A2-8C64-16E5602971D5@thomasclausen.org> <8688B01C-F255-4868-AF16-0A8AD6B27BE9@cisco.com> <164D1B8C-1326-430B-8E16-F961029BEC59@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1084) Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 14:02:59 -0000 There may be. If so, those hosts do not operate any routing protocols = (unless you consider ND to be a routing protocol) and are not a part of = a RPL domain (under my proposed definition). -- Jonathan Hui On Nov 16, 2011, at 5:57 AM, Thomas Heide Clausen wrote: > Yes, but is there a node, connected to and in an RPL deployment, that = doesn't run RPL? In other words, is there a host in a RPL network? >=20 > --=20 > Thomas Heide Clausen > http://www.thomasclausen.org/ >=20 > "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >=20 >=20 > On 16 Nov 2011, at 21:53, Jonathan Hui wrote: >=20 >>=20 >> It may or may not be accidental. It is perfectly acceptable for a = device operating RPL not to advertise routes for destinations other than = itself. Either way, the node still operates RPL. >>=20 >> -- >> Jonathan Hui >>=20 >> On Nov 16, 2011, at 5:49 AM, Thomas Heide Clausen wrote: >>=20 >>> On 16 Nov 2011, at 21:40, Jonathan Hui wrote: >>>=20 >>>> With my proposed definition, a RPL Leaf is a RPL Router. A RPL = Leaf still operates and participates in the RPL routing protocol - it = just happens not to have any children. >>>=20 >>> So it just happens to be a particular "accidental" topological = position of a router, but entails no different state, transitions or = parameters than any other RPL router. >>>=20 >>> Therefore, there is absolutely no need for another term, it is just = an RPL router. >>>=20 >>> I therefore strongly suggest that there is no reason to invent yet = another piece of confusing terminology (and, in general, that ROLL would = do well by trying to adhere to standard Internet terminology) >>>=20 >>> Thomas >>>=20 >>>> -- >>>> Jonathan Hui >>>>=20 >>>> On Nov 16, 2011, at 5:25 AM, Thomas Heide Clausen wrote: >>>>=20 >>>>> On 16 Nov 2011, at 21:15, Mukul Goyal wrote: >>>>>=20 >>>>>>> Now that we are at it: what is an RPL host? Or rather, why is = this even a conceivable thing to define? Afaik, RPL is a routing = protocol, and as such should concern only routers - not hosts? >>>>>>=20 >>>>>> My bad. By RPL host, I actually meant an RPL leaf node. I think = this term "RPL host" was in use at one point in time but I cant find a = reference to it in current spec. >>>>>=20 >>>>> A rose by any other name is *still* a rose.... >>>>>=20 >>>>> What is an RPL Leaf Node? What is the difference between a RPL = Leaf node and a RPL Router? >>>>>=20 >>>>> Isn't there a thing in the end of the network, inside the LLN, = that doesn't run RPL, aka, a host? >>>>>=20 >>>>> Thomas >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> THanks >>>>>> Mukul >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> ----- Original Message ----- >>>>>> From: "Thomas Heide Clausen" >>>>>> To: "Mukul Goyal" >>>>>> Cc: "JP Vasseur" , "roll" >>>>>> Sent: Wednesday, November 16, 2011 6:25:31 AM >>>>>> Subject: Re: [Roll] definition of "RPL Domain" >>>>>>=20 >>>>>> Now that we are at it: what is an RPL host? Or rather, why is = this even a conceivable thing to define? Afaik, RPL is a routing = protocol, and as such should concern only routers - not hosts? >>>>>>=20 >>>>>> I worry if this is inventing an entire ecosystem which "pretends = to be just like the Internet, except it is not", as it needs entirely = new stacks, protocols, translators/gateways everywhere, and with no real = traces of IP as we know it remaining? >>>>>>=20 >>>>>> --=20 >>>>>> Thomas Heide Clausen >>>>>> http://www.thomasclausen.org/ >>>>>>=20 >>>>>> "Payload (noun): wasted bandwidth between headers" (C.Lavenu = 2011) >>>>>>=20 >>>>>>=20 >>>>>> On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >>>>>>=20 >>>>>>> Hi JP >>>>>>>=20 >>>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>>=20 >>>>>>> I think this definition is little too vague. Some of the points = that need clarification: >>>>>>>=20 >>>>>>> 1. It is clear that RPL hosts and routers (as defined towards = the end of terminology section in RPL-19) are within an RPL domain but = what about the RPL-unaware IPv6 hosts attached to an RPL router/host? I = would imagine that such hosts are also within an RPL domain. >>>>>>>=20 >>>>>>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain = a set of RPL instances in the LLN? Can multiple RPL domains exist within = an LLN? Or is it that an RPL domain is same as an LLN using RPL as a = routing protocol? >>>>>>>=20 >>>>>>> Thanks >>>>>>> Mukul =20 >>>>>>>=20 >>>>>>> ----- Original Message ----- >>>>>>> From: "JP Vasseur" >>>>>>> To: "Mukul Goyal" >>>>>>> Cc: "roll" >>>>>>> Sent: Wednesday, November 16, 2011 2:33:50 AM >>>>>>> Subject: Re: definition of "RPL Domain" >>>>>>>=20 >>>>>>> Hi Mukul, >>>>>>>=20 >>>>>>> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>>>>>>=20 >>>>>>>> Hi JP >>>>>>>>=20 >>>>>>>> I was wondering if the term "RPL Domain" could be defined in = the terminology draft.=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> How about >>>>>>>=20 >>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>>=20 >>>>>>> Thanks. >>>>>>>=20 >>>>>>> JP. >>>>>>>=20 >>>>>>>> Thanks >>>>>>>> Mukul=20 >>>>>>>>=20 >>>>>>>> ----- Forwarded Message ----- >>>>>>>> From: "Joseph Reddy" >>>>>>>> To: ipv6@ietf.org >>>>>>>> Sent: Friday, October 14, 2011 7:15:05 PM >>>>>>>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi Jonathan, >>>>>>>>=20 >>>>>>>> The draft uses the term "RPL domain" in several places and this = is not clearly defined.=20 >>>>>>>>=20 >>>>>>>> I would imagine that it includes all nodes that are downstream = of the RPL border router. But can you clarify if Host nodes that are = downstream of the border router but do not implement any part of RPL ( = even as RPL Leaf nodes ) should be considered part of the "RPL domain" ? >>>>>>>>=20 >>>>>>>> In section 5, the draft now says "..Datagrams destined to nodes = outside the RPL domain are dropped if the outer-most IPv6 header = contains a RPL Option..." >>>>>>>>=20 >>>>>>>> This text would imply that any RPL node sending packets to = nodes outside should always tunnel to the Root ? Is that the intention = really or am I missing something here..=20 >>>>>>>>=20 >>>>>>>> Also note that if non-RPL Host is not considered part of the = RPL domain, then I am not sure that a forwarding router can know if the = destination is inside the domain or not.=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -Regards, Joseph >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> ------------------------------ >>>>>>>>=20 >>>>>>>> Message: 5 >>>>>>>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>>>>>>> From: Jonathan Hui >>>>>>>> To: IETF IPv6 Mailing List >>>>>>>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>>>>>>> Content-Type: text/plain; charset=3Dus-ascii >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> This update is intended to address Jari Arkko's AD review. >>>>>>>>=20 >>>>>>>> Summary of changes: >>>>>>>> - Clarify when the RPL Option is used. >>>>>>>> - Updated text on recommendations for avoiding fragmentation. >>>>>>>> - Specify skip-over-and-continue policy for unrecognized = sub-TLVs. >>>>>>>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>>>>>>> - Specify RPL Border Router operations in terms of forwarding = decision outcomes. >>>>>>>> - Expand security section. >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Jonathan Hui >>>>>>>>=20 >>>>>>>> Begin forwarded message: >>>>>>>>=20 >>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>> Date: October 11, 2011 10:17:15 PM PDT >>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>> Cc: ipv6@ietf.org >>>>>>>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>>=20 >>>>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. This draft is a work item of the IPv6 = Maintenance Working Group of the IETF. >>>>>>>>>=20 >>>>>>>>> Title : RPL Option for Carrying RPL Information in = Data-Plane Datagrams >>>>>>>>> Author(s) : Jonathan W. Hui >>>>>>>>> JP Vasseur >>>>>>>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>>>>>>> Pages : 14 >>>>>>>>> Date : 2011-10-11 >>>>>>>>>=20 >>>>>>>>> The RPL protocol requires data-plane datagrams to carry RPL = routing >>>>>>>>> information that is processed by RPL routers when forwarding = those >>>>>>>>> datagrams. This document describes the RPL Option for use = within a >>>>>>>>> RPL domain. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>> = http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>>>>>>=20 >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>=20 >>>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>>>>>> = -------------------------------------------------------------------- >>>>>>>>> IETF IPv6 working group mailing list >>>>>>>>> ipv6@ietf.org >>>>>>>>> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>> = -------------------------------------------------------------------- >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> = -------------------------------------------------------------------- >>>>>>>> IETF IPv6 working group mailing list >>>>>>>> ipv6@ietf.org >>>>>>>> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>> = -------------------------------------------------------------------- >>>>>>>=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 >>>>=20 >>=20 From c.chauvenet@watteco.com Wed Nov 16 06:14:21 2011 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 E6C3421F96B5 for ; Wed, 16 Nov 2011 06:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, 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 g+LEUWSnHyr9 for ; Wed, 16 Nov 2011 06:14:20 -0800 (PST) Received: from TX2EHSOBE008.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 827DB21F9671 for ; Wed, 16 Nov 2011 06:14:20 -0800 (PST) Received: from mail140-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Wed, 16 Nov 2011 14:13:48 +0000 Received: from mail140-tx2 (localhost.localdomain [127.0.0.1]) by mail140-tx2-R.bigfish.com (Postfix) with ESMTP id 6880812F84FC; Wed, 16 Nov 2011 14:14:06 +0000 (UTC) X-SpamScore: -90 X-BigFish: VPS-90(zz9371Kc89bh936eK542M1432N15caKJ98dKzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB019.red002.local; RD:none; EFVD:NLI Received: from mail140-tx2 (localhost.localdomain [127.0.0.1]) by mail140-tx2 (MessageSwitch) id 1321452844615972_30543; Wed, 16 Nov 2011 14:14:04 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.252]) by mail140-tx2.bigfish.com (Postfix) with ESMTP id 87C481880054; Wed, 16 Nov 2011 14:14:04 +0000 (UTC) Received: from IE2RD2HUB019.red002.local (213.199.187.153) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 16 Nov 2011 14:13:43 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB019.red002.local ([10.43.198.97]) with mapi; Wed, 16 Nov 2011 06:14:07 -0800 From: C Chauvenet To: Jonathan Hui , Thomas Heide Clausen Date: Wed, 16 Nov 2011 06:14:11 -0800 Thread-Topic: [Roll] definition of "RPL Domain" Thread-Index: AcykaIG+qdBKaOsIR4m6Hh9/b6tIRAAAL+Tg Message-ID: References: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> <2CD3ADFF-DE10-440C-895B-8527190395F9@cisco.com> <92C241B0-33A1-41A2-8C64-16E5602971D5@thomasclausen.org> <8688B01C-F255-4868-AF16-0A8AD6B27BE9@cisco.com> <164D1B8C-1326-430B-8E16-F961029BEC59@thomasclausen.org> <1E9DE872-6511-4F8C-B985-B94EB0635D3F@cisco.com> In-Reply-To: <1E9DE872-6511-4F8C-B985-B94EB0635D3F@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 14:14:22 -0000 I agree with Jonathan definition. I think it is quite clear. Thomas, could you point us to the document where "RPL Host" is used or defi= ned ? C=E9dric. -----Message d'origine----- De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de J= onathan Hui Envoy=E9=A0: mercredi 16 novembre 2011 15:03 =C0=A0: Thomas Heide Clausen Cc=A0: roll Objet=A0: Re: [Roll] definition of "RPL Domain" There may be. If so, those hosts do not operate any routing protocols (unl= ess you consider ND to be a routing protocol) and are not a part of a RPL d= omain (under my proposed definition). -- Jonathan Hui On Nov 16, 2011, at 5:57 AM, Thomas Heide Clausen wrote: > Yes, but is there a node, connected to and in an RPL deployment, that doe= sn't run RPL? In other words, is there a host in a RPL network? >=20 > -- > Thomas Heide Clausen > http://www.thomasclausen.org/ >=20 > "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >=20 >=20 > On 16 Nov 2011, at 21:53, Jonathan Hui wrote: >=20 >>=20 >> It may or may not be accidental. It is perfectly acceptable for a devic= e operating RPL not to advertise routes for destinations other than itself.= Either way, the node still operates RPL. >>=20 >> -- >> Jonathan Hui >>=20 >> On Nov 16, 2011, at 5:49 AM, Thomas Heide Clausen wrote: >>=20 >>> On 16 Nov 2011, at 21:40, Jonathan Hui wrote: >>>=20 >>>> With my proposed definition, a RPL Leaf is a RPL Router. A RPL Leaf s= till operates and participates in the RPL routing protocol - it just happen= s not to have any children. >>>=20 >>> So it just happens to be a particular "accidental" topological position= of a router, but entails no different state, transitions or parameters tha= n any other RPL router. >>>=20 >>> Therefore, there is absolutely no need for another term, it is just an = RPL router. >>>=20 >>> I therefore strongly suggest that there is no reason to invent yet=20 >>> another piece of confusing terminology (and, in general, that ROLL=20 >>> would do well by trying to adhere to standard Internet terminology) >>>=20 >>> Thomas >>>=20 >>>> -- >>>> Jonathan Hui >>>>=20 >>>> On Nov 16, 2011, at 5:25 AM, Thomas Heide Clausen wrote: >>>>=20 >>>>> On 16 Nov 2011, at 21:15, Mukul Goyal wrote: >>>>>=20 >>>>>>> Now that we are at it: what is an RPL host? Or rather, why is this = even a conceivable thing to define? Afaik, RPL is a routing protocol, and a= s such should concern only routers - not hosts? >>>>>>=20 >>>>>> My bad. By RPL host, I actually meant an RPL leaf node. I think this= term "RPL host" was in use at one point in time but I cant find a referenc= e to it in current spec. >>>>>=20 >>>>> A rose by any other name is *still* a rose.... >>>>>=20 >>>>> What is an RPL Leaf Node? What is the difference between a RPL Leaf n= ode and a RPL Router? >>>>>=20 >>>>> Isn't there a thing in the end of the network, inside the LLN, that = doesn't run RPL, aka, a host? >>>>>=20 >>>>> Thomas >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> THanks >>>>>> Mukul >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> ----- Original Message ----- >>>>>> From: "Thomas Heide Clausen" >>>>>> To: "Mukul Goyal" >>>>>> Cc: "JP Vasseur" , "roll" >>>>>> Sent: Wednesday, November 16, 2011 6:25:31 AM >>>>>> Subject: Re: [Roll] definition of "RPL Domain" >>>>>>=20 >>>>>> Now that we are at it: what is an RPL host? Or rather, why is this e= ven a conceivable thing to define? Afaik, RPL is a routing protocol, and as= such should concern only routers - not hosts? >>>>>>=20 >>>>>> I worry if this is inventing an entire ecosystem which "pretends to = be just like the Internet, except it is not", as it needs entirely new stac= ks, protocols, translators/gateways everywhere, and with no real traces of = IP as we know it remaining? >>>>>>=20 >>>>>> -- >>>>>> Thomas Heide Clausen >>>>>> http://www.thomasclausen.org/ >>>>>>=20 >>>>>> "Payload (noun): wasted bandwidth between headers" (C.Lavenu=20 >>>>>> 2011) >>>>>>=20 >>>>>>=20 >>>>>> On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >>>>>>=20 >>>>>>> Hi JP >>>>>>>=20 >>>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>>=20 >>>>>>> I think this definition is little too vague. Some of the points tha= t need clarification: >>>>>>>=20 >>>>>>> 1. It is clear that RPL hosts and routers (as defined towards the e= nd of terminology section in RPL-19) are within an RPL domain but what abou= t the RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagin= e that such hosts are also within an RPL domain. >>>>>>>=20 >>>>>>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a = set of RPL instances in the LLN? Can multiple RPL domains exist within an L= LN? Or is it that an RPL domain is same as an LLN using RPL as a routing pr= otocol? >>>>>>>=20 >>>>>>> Thanks >>>>>>> Mukul >>>>>>>=20 >>>>>>> ----- Original Message ----- >>>>>>> From: "JP Vasseur" >>>>>>> To: "Mukul Goyal" >>>>>>> Cc: "roll" >>>>>>> Sent: Wednesday, November 16, 2011 2:33:50 AM >>>>>>> Subject: Re: definition of "RPL Domain" >>>>>>>=20 >>>>>>> Hi Mukul, >>>>>>>=20 >>>>>>> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>>>>>>=20 >>>>>>>> Hi JP >>>>>>>>=20 >>>>>>>> I was wondering if the term "RPL Domain" could be defined in the t= erminology draft.=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> How about >>>>>>>=20 >>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>>=20 >>>>>>> Thanks. >>>>>>>=20 >>>>>>> JP. >>>>>>>=20 >>>>>>>> Thanks >>>>>>>> Mukul >>>>>>>>=20 >>>>>>>> ----- Forwarded Message ----- >>>>>>>> From: "Joseph Reddy" >>>>>>>> To: ipv6@ietf.org >>>>>>>> Sent: Friday, October 14, 2011 7:15:05 PM >>>>>>>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi Jonathan, >>>>>>>>=20 >>>>>>>> The draft uses the term "RPL domain" in several places and this is= not clearly defined.=20 >>>>>>>>=20 >>>>>>>> I would imagine that it includes all nodes that are downstream of = the RPL border router. But can you clarify if Host nodes that are downstrea= m of the border router but do not implement any part of RPL ( even as RPL L= eaf nodes ) should be considered part of the "RPL domain" ? >>>>>>>>=20 >>>>>>>> In section 5, the draft now says "..Datagrams destined to nodes ou= tside the RPL domain are dropped if the outer-most IPv6 header contains a R= PL Option..." >>>>>>>>=20 >>>>>>>> This text would imply that any RPL node sending packets to nodes o= utside should always tunnel to the Root ? Is that the intention really or a= m I missing something here..=20 >>>>>>>>=20 >>>>>>>> Also note that if non-RPL Host is not considered part of the RPL d= omain, then I am not sure that a forwarding router can know if the destinat= ion is inside the domain or not.=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -Regards, Joseph >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> ------------------------------ >>>>>>>>=20 >>>>>>>> Message: 5 >>>>>>>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>>>>>>> From: Jonathan Hui >>>>>>>> To: IETF IPv6 Mailing List >>>>>>>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>>>>>>> Content-Type: text/plain; charset=3Dus-ascii >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> This update is intended to address Jari Arkko's AD review. >>>>>>>>=20 >>>>>>>> Summary of changes: >>>>>>>> - Clarify when the RPL Option is used. >>>>>>>> - Updated text on recommendations for avoiding fragmentation. >>>>>>>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >>>>>>>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>>>>>>> - Specify RPL Border Router operations in terms of forwarding deci= sion outcomes. >>>>>>>> - Expand security section. >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Jonathan Hui >>>>>>>>=20 >>>>>>>> Begin forwarded message: >>>>>>>>=20 >>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>> Date: October 11, 2011 10:17:15 PM PDT >>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>> Cc: ipv6@ietf.org >>>>>>>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>>=20 >>>>>>>>> A New Internet-Draft is available from the on-line Internet-Draft= s directories. This draft is a work item of the IPv6 Maintenance Working Gr= oup of the IETF. >>>>>>>>>=20 >>>>>>>>> Title : RPL Option for Carrying RPL Information in Data= -Plane Datagrams >>>>>>>>> Author(s) : Jonathan W. Hui >>>>>>>>> JP Vasseur >>>>>>>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>>>>>>> Pages : 14 >>>>>>>>> Date : 2011-10-11 >>>>>>>>>=20 >>>>>>>>> The RPL protocol requires data-plane datagrams to carry RPL=20 >>>>>>>>> routing information that is processed by RPL routers when=20 >>>>>>>>> forwarding those datagrams. This document describes the RPL=20 >>>>>>>>> Option for use within a RPL domain. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option >>>>>>>>> -04.txt >>>>>>>>>=20 >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>=20 >>>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option- >>>>>>>>> 04.txt >>>>>>>>> -------------------------------------------------------------- >>>>>>>>> ------ IETF IPv6 working group mailing list ipv6@ietf.org=20 >>>>>>>>> Administrative Requests:=20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>> -------------------------------------------------------------- >>>>>>>>> ------ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> --------------------------------------------------------------- >>>>>>>> ----- IETF IPv6 working group mailing list ipv6@ietf.org=20 >>>>>>>> Administrative Requests:=20 >>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>> --------------------------------------------------------------- >>>>>>>> ----- >>>>>>>=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 >>>>=20 >>=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From thomas@thomasclausen.org Wed Nov 16 06:18:41 2011 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 0063E21F93F5 for ; Wed, 16 Nov 2011 06:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 UKcYS5WciZ2m for ; Wed, 16 Nov 2011 06:18:39 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D246E21F938E for ; Wed, 16 Nov 2011 06:18:39 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 9B8B31039CE for ; Wed, 16 Nov 2011 06:18:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 6D45880873; Wed, 16 Nov 2011 06:18:39 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.3.103] (unknown [203.69.99.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B35538087C; Wed, 16 Nov 2011 06:18:38 -0800 (PST) References: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> <2CD3ADFF-DE10-440C-895B-8527190395F9@cisco.com> <92C241B0-33A1-41A2-8C64-16E5602971D5@thomasclausen.org> <8688B01C-F255-4868-AF16-0A8AD6B27BE9@cisco.com> <164D1B8C-1326-430B-8E16-F961029BEC59@thomasclausen.org> <1E9DE872-6511-4F8C-B985-B94EB0635D3F@cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (9A334) From: Thomas Heide Clausen Date: Wed, 16 Nov 2011 22:19:08 +0800 To: C Chauvenet Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 14:18:41 -0000 On 16 Nov 2011, at 22:14, C Chauvenet wrote: > I agree with Jonathan definition. > I think it is quite clear. >=20 > Thomas, could you point us to the document where "RPL Host" is used or def= ined ? No, I can't, i didn't bring up the term on the list, I reacted to somebody e= lse bringing it up. I am trying to understand: o why there is a need to invent RPL leaf and RPL router as different term= s,=20 what the difference between those two is. o if a RPL routed LLN contains hosts, i.e., respects the usual host/route= r dichotomy. Thomas=20 >=20 > C=C3=A9dric. >=20 > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Jo= nathan Hui > Envoy=C3=A9 : mercredi 16 novembre 2011 15:03 > =C3=80 : Thomas Heide Clausen > Cc : roll > Objet : Re: [Roll] definition of "RPL Domain" >=20 >=20 > There may be. If so, those hosts do not operate any routing protocols (un= less you consider ND to be a routing protocol) and are not a part of a RPL d= omain (under my proposed definition). >=20 > -- > Jonathan Hui >=20 > On Nov 16, 2011, at 5:57 AM, Thomas Heide Clausen wrote: >=20 >> Yes, but is there a node, connected to and in an RPL deployment, that doe= sn't run RPL? In other words, is there a host in a RPL network? >>=20 >> -- >> Thomas Heide Clausen >> http://www.thomasclausen.org/ >>=20 >> "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >>=20 >>=20 >> On 16 Nov 2011, at 21:53, Jonathan Hui wrote: >>=20 >>>=20 >>> It may or may not be accidental. It is perfectly acceptable for a devic= e operating RPL not to advertise routes for destinations other than itself. = Either way, the node still operates RPL. >>>=20 >>> -- >>> Jonathan Hui >>>=20 >>> On Nov 16, 2011, at 5:49 AM, Thomas Heide Clausen wrote: >>>=20 >>>> On 16 Nov 2011, at 21:40, Jonathan Hui wrote: >>>>=20 >>>>> With my proposed definition, a RPL Leaf is a RPL Router. A RPL Leaf s= till operates and participates in the RPL routing protocol - it just happens= not to have any children. >>>>=20 >>>> So it just happens to be a particular "accidental" topological position= of a router, but entails no different state, transitions or parameters than= any other RPL router. >>>>=20 >>>> Therefore, there is absolutely no need for another term, it is just an R= PL router. >>>>=20 >>>> I therefore strongly suggest that there is no reason to invent yet=20 >>>> another piece of confusing terminology (and, in general, that ROLL=20 >>>> would do well by trying to adhere to standard Internet terminology) >>>>=20 >>>> Thomas >>>>=20 >>>>> -- >>>>> Jonathan Hui >>>>>=20 >>>>> On Nov 16, 2011, at 5:25 AM, Thomas Heide Clausen wrote: >>>>>=20 >>>>>> On 16 Nov 2011, at 21:15, Mukul Goyal wrote: >>>>>>=20 >>>>>>>> Now that we are at it: what is an RPL host? Or rather, why is this e= ven a conceivable thing to define? Afaik, RPL is a routing protocol, and as s= uch should concern only routers - not hosts? >>>>>>>=20 >>>>>>> My bad. By RPL host, I actually meant an RPL leaf node. I think this= term "RPL host" was in use at one point in time but I cant find a reference= to it in current spec. >>>>>>=20 >>>>>> A rose by any other name is *still* a rose.... >>>>>>=20 >>>>>> What is an RPL Leaf Node? What is the difference between a RPL Leaf n= ode and a RPL Router? >>>>>>=20 >>>>>> Isn't there a thing in the end of the network, inside the LLN, that d= oesn't run RPL, aka, a host? >>>>>>=20 >>>>>> Thomas >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> THanks >>>>>>> Mukul >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> ----- Original Message ----- >>>>>>> From: "Thomas Heide Clausen" >>>>>>> To: "Mukul Goyal" >>>>>>> Cc: "JP Vasseur" , "roll" >>>>>>> Sent: Wednesday, November 16, 2011 6:25:31 AM >>>>>>> Subject: Re: [Roll] definition of "RPL Domain" >>>>>>>=20 >>>>>>> Now that we are at it: what is an RPL host? Or rather, why is this e= ven a conceivable thing to define? Afaik, RPL is a routing protocol, and as s= uch should concern only routers - not hosts? >>>>>>>=20 >>>>>>> I worry if this is inventing an entire ecosystem which "pretends to b= e just like the Internet, except it is not", as it needs entirely new stacks= , protocols, translators/gateways everywhere, and with no real traces of IP a= s we know it remaining? >>>>>>>=20 >>>>>>> -- >>>>>>> Thomas Heide Clausen >>>>>>> http://www.thomasclausen.org/ >>>>>>>=20 >>>>>>> "Payload (noun): wasted bandwidth between headers" (C.Lavenu=20 >>>>>>> 2011) >>>>>>>=20 >>>>>>>=20 >>>>>>> On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >>>>>>>=20 >>>>>>>> Hi JP >>>>>>>>=20 >>>>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>>>=20 >>>>>>>> I think this definition is little too vague. Some of the points tha= t need clarification: >>>>>>>>=20 >>>>>>>> 1. It is clear that RPL hosts and routers (as defined towards the e= nd of terminology section in RPL-19) are within an RPL domain but what about= the RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagine t= hat such hosts are also within an RPL domain. >>>>>>>>=20 >>>>>>>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a s= et of RPL instances in the LLN? Can multiple RPL domains exist within an LLN= ? Or is it that an RPL domain is same as an LLN using RPL as a routing proto= col? >>>>>>>>=20 >>>>>>>> Thanks >>>>>>>> Mukul >>>>>>>>=20 >>>>>>>> ----- Original Message ----- >>>>>>>> From: "JP Vasseur" >>>>>>>> To: "Mukul Goyal" >>>>>>>> Cc: "roll" >>>>>>>> Sent: Wednesday, November 16, 2011 2:33:50 AM >>>>>>>> Subject: Re: definition of "RPL Domain" >>>>>>>>=20 >>>>>>>> Hi Mukul, >>>>>>>>=20 >>>>>>>> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>>>>>>>=20 >>>>>>>>> Hi JP >>>>>>>>>=20 >>>>>>>>> I was wondering if the term "RPL Domain" could be defined in the t= erminology draft.=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> How about >>>>>>>>=20 >>>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>>>=20 >>>>>>>> Thanks. >>>>>>>>=20 >>>>>>>> JP. >>>>>>>>=20 >>>>>>>>> Thanks >>>>>>>>> Mukul >>>>>>>>>=20 >>>>>>>>> ----- Forwarded Message ----- >>>>>>>>> From: "Joseph Reddy" >>>>>>>>> To: ipv6@ietf.org >>>>>>>>> Sent: Friday, October 14, 2011 7:15:05 PM >>>>>>>>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hi Jonathan, >>>>>>>>>=20 >>>>>>>>> The draft uses the term "RPL domain" in several places and this is= not clearly defined.=20 >>>>>>>>>=20 >>>>>>>>> I would imagine that it includes all nodes that are downstream of t= he RPL border router. But can you clarify if Host nodes that are downstream o= f the border router but do not implement any part of RPL ( even as RPL Leaf n= odes ) should be considered part of the "RPL domain" ? >>>>>>>>>=20 >>>>>>>>> In section 5, the draft now says "..Datagrams destined to nodes ou= tside the RPL domain are dropped if the outer-most IPv6 header contains a RP= L Option..." >>>>>>>>>=20 >>>>>>>>> This text would imply that any RPL node sending packets to nodes o= utside should always tunnel to the Root ? Is that the intention really or am= I missing something here..=20 >>>>>>>>>=20 >>>>>>>>> Also note that if non-RPL Host is not considered part of the RPL d= omain, then I am not sure that a forwarding router can know if the destinati= on is inside the domain or not.=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -Regards, Joseph >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ------------------------------ >>>>>>>>>=20 >>>>>>>>> Message: 5 >>>>>>>>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>>>>>>>> From: Jonathan Hui >>>>>>>>> To: IETF IPv6 Mailing List >>>>>>>>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>>>>>>>> Content-Type: text/plain; charset=3Dus-ascii >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This update is intended to address Jari Arkko's AD review. >>>>>>>>>=20 >>>>>>>>> Summary of changes: >>>>>>>>> - Clarify when the RPL Option is used. >>>>>>>>> - Updated text on recommendations for avoiding fragmentation. >>>>>>>>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs.= >>>>>>>>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>>>>>>>> - Specify RPL Border Router operations in terms of forwarding deci= sion outcomes. >>>>>>>>> - Expand security section. >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Jonathan Hui >>>>>>>>>=20 >>>>>>>>> Begin forwarded message: >>>>>>>>>=20 >>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>> Date: October 11, 2011 10:17:15 PM PDT >>>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>>> Cc: ipv6@ietf.org >>>>>>>>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>>>=20 >>>>>>>>>> A New Internet-Draft is available from the on-line Internet-Draft= s directories. This draft is a work item of the IPv6 Maintenance Working Gro= up of the IETF. >>>>>>>>>>=20 >>>>>>>>>> Title : RPL Option for Carrying RPL Information in Data= -Plane Datagrams >>>>>>>>>> Author(s) : Jonathan W. Hui >>>>>>>>>> JP Vasseur >>>>>>>>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>>>>>>>> Pages : 14 >>>>>>>>>> Date : 2011-10-11 >>>>>>>>>>=20 >>>>>>>>>> The RPL protocol requires data-plane datagrams to carry RPL=20 >>>>>>>>>> routing information that is processed by RPL routers when=20 >>>>>>>>>> forwarding those datagrams. This document describes the RPL=20 >>>>>>>>>> Option for use within a RPL domain. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option >>>>>>>>>> -04.txt >>>>>>>>>>=20 >>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>=20 >>>>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option- >>>>>>>>>> 04.txt >>>>>>>>>> -------------------------------------------------------------- >>>>>>>>>> ------ IETF IPv6 working group mailing list ipv6@ietf.org=20 >>>>>>>>>> Administrative Requests:=20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>>> -------------------------------------------------------------- >>>>>>>>>> ------ >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --------------------------------------------------------------- >>>>>>>>> ----- IETF IPv6 working group mailing list ipv6@ietf.org=20 >>>>>>>>> Administrative Requests:=20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>> --------------------------------------------------------------- >>>>>>>>> ----- >>>>>>>>=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 >>>>>=20 >>>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From esko.dijk@philips.com Wed Nov 16 07:31:58 2011 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 12BDF11E8087 for ; Wed, 16 Nov 2011 07:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 DwxItCJNpN+V for ; Wed, 16 Nov 2011 07:31:56 -0800 (PST) Received: from DB3EHSOBE004.bigfish.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3F86711E8086 for ; Wed, 16 Nov 2011 07:31:56 -0800 (PST) Received: from mail71-db3-R.bigfish.com (10.3.81.247) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.22; Wed, 16 Nov 2011 15:31:23 +0000 Received: from mail71-db3 (localhost.localdomain [127.0.0.1]) by mail71-db3-R.bigfish.com (Postfix) with ESMTP id 7A9DB5A042F for ; Wed, 16 Nov 2011 15:31:42 +0000 (UTC) X-SpamScore: -103 X-BigFish: VPS-103(zz217bL15d6O9371K9251Jc89bh936eK542M1432N15caKJ98dKzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPVD:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-FB-SS: 13, Received: from mail71-db3 (localhost.localdomain [127.0.0.1]) by mail71-db3 (MessageSwitch) id 1321457501385719_13350; Wed, 16 Nov 2011 15:31:41 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.253]) by mail71-db3.bigfish.com (Postfix) with ESMTP id 57FD917B0051; Wed, 16 Nov 2011 15:31:41 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 16 Nov 2011 15:31:53 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.171]) by 011-DB3MMR1-006.MGDPHG.emi.philips.com ([10.128.28.56]) with mapi id 14.01.0355.003; Wed, 16 Nov 2011 15:31:52 +0000 From: "Dijk, Esko" To: C Chauvenet Thread-Topic: [Roll] definition of "RPL Domain" Thread-Index: AcyNMWZPunDRPQNoTCauijaxSS+1OwXCRDIAAASdN4AAA3oygAABwzWAAABTmAAAAIgzAAAATXwAAAAl2QAAACIggAAAMZ8AAABleoAAAb7UgA== Date: Wed, 16 Nov 2011 15:31:52 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618010235@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> <2CD3ADFF-DE10-440C-895B-8527190395F9@cisco.com> <92C241B0-33A1-41A2-8C64-16E5602971D5@thomasclausen.org> <8688B01C-F255-4868-AF16-0A8AD6B27BE9@cisco.com> <164D1B8C-1326-430B-8E16-F961029BEC59@thomasclausen.org> <1E9DE872-6511-4F8C-B985-B94EB0635D3F@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 15:31:58 -0000 For information, roll-rpl-19 does define the term "host": an LLN device tha= t can generate but does not forward RPL traffic. "RPL traffic" is not explicitly defined but should be interpreted as any tr= affic routed by means of the RPL protocol over a RPL Instance. regards, Esko -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of C C= hauvenet Sent: Wednesday 16 November 2011 15:14 To: Jonathan Hui; Thomas Heide Clausen Cc: roll Subject: Re: [Roll] definition of "RPL Domain" I agree with Jonathan definition. I think it is quite clear. Thomas, could you point us to the document where "RPL Host" is used or defi= ned ? C=E9dric. -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Jon= athan Hui Envoy=E9 : mercredi 16 novembre 2011 15:03 =C0 : Thomas Heide Clausen Cc : roll Objet : Re: [Roll] definition of "RPL Domain" There may be. If so, those hosts do not operate any routing protocols (unl= ess you consider ND to be a routing protocol) and are not a part of a RPL d= omain (under my proposed definition). -- Jonathan Hui On Nov 16, 2011, at 5:57 AM, Thomas Heide Clausen wrote: > Yes, but is there a node, connected to and in an RPL deployment, that doe= sn't run RPL? In other words, is there a host in a RPL network? > > -- > Thomas Heide Clausen > http://www.thomasclausen.org/ > > "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) > > > On 16 Nov 2011, at 21:53, Jonathan Hui wrote: > >> >> It may or may not be accidental. It is perfectly acceptable for a devic= e operating RPL not to advertise routes for destinations other than itself.= Either way, the node still operates RPL. >> >> -- >> Jonathan Hui >> >> On Nov 16, 2011, at 5:49 AM, Thomas Heide Clausen wrote: >> >>> On 16 Nov 2011, at 21:40, Jonathan Hui wrote: >>> >>>> With my proposed definition, a RPL Leaf is a RPL Router. A RPL Leaf s= till operates and participates in the RPL routing protocol - it just happen= s not to have any children. >>> >>> So it just happens to be a particular "accidental" topological position= of a router, but entails no different state, transitions or parameters tha= n any other RPL router. >>> >>> Therefore, there is absolutely no need for another term, it is just an = RPL router. >>> >>> I therefore strongly suggest that there is no reason to invent yet >>> another piece of confusing terminology (and, in general, that ROLL >>> would do well by trying to adhere to standard Internet terminology) >>> >>> Thomas >>> >>>> -- >>>> Jonathan Hui >>>> >>>> On Nov 16, 2011, at 5:25 AM, Thomas Heide Clausen wrote: >>>> >>>>> On 16 Nov 2011, at 21:15, Mukul Goyal wrote: >>>>> >>>>>>> Now that we are at it: what is an RPL host? Or rather, why is this = even a conceivable thing to define? Afaik, RPL is a routing protocol, and a= s such should concern only routers - not hosts? >>>>>> >>>>>> My bad. By RPL host, I actually meant an RPL leaf node. I think this= term "RPL host" was in use at one point in time but I cant find a referenc= e to it in current spec. >>>>> >>>>> A rose by any other name is *still* a rose.... >>>>> >>>>> What is an RPL Leaf Node? What is the difference between a RPL Leaf n= ode and a RPL Router? >>>>> >>>>> Isn't there a thing in the end of the network, inside the LLN, that = doesn't run RPL, aka, a host? >>>>> >>>>> Thomas >>>>> >>>>> >>>>>> >>>>>> THanks >>>>>> Mukul >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Thomas Heide Clausen" >>>>>> To: "Mukul Goyal" >>>>>> Cc: "JP Vasseur" , "roll" >>>>>> Sent: Wednesday, November 16, 2011 6:25:31 AM >>>>>> Subject: Re: [Roll] definition of "RPL Domain" >>>>>> >>>>>> Now that we are at it: what is an RPL host? Or rather, why is this e= ven a conceivable thing to define? Afaik, RPL is a routing protocol, and as= such should concern only routers - not hosts? >>>>>> >>>>>> I worry if this is inventing an entire ecosystem which "pretends to = be just like the Internet, except it is not", as it needs entirely new stac= ks, protocols, translators/gateways everywhere, and with no real traces of = IP as we know it remaining? >>>>>> >>>>>> -- >>>>>> Thomas Heide Clausen >>>>>> http://www.thomasclausen.org/ >>>>>> >>>>>> "Payload (noun): wasted bandwidth between headers" (C.Lavenu >>>>>> 2011) >>>>>> >>>>>> >>>>>> On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >>>>>> >>>>>>> Hi JP >>>>>>> >>>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>> >>>>>>> I think this definition is little too vague. Some of the points tha= t need clarification: >>>>>>> >>>>>>> 1. It is clear that RPL hosts and routers (as defined towards the e= nd of terminology section in RPL-19) are within an RPL domain but what abou= t the RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagin= e that such hosts are also within an RPL domain. >>>>>>> >>>>>>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a = set of RPL instances in the LLN? Can multiple RPL domains exist within an L= LN? Or is it that an RPL domain is same as an LLN using RPL as a routing pr= otocol? >>>>>>> >>>>>>> Thanks >>>>>>> Mukul >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "JP Vasseur" >>>>>>> To: "Mukul Goyal" >>>>>>> Cc: "roll" >>>>>>> Sent: Wednesday, November 16, 2011 2:33:50 AM >>>>>>> Subject: Re: definition of "RPL Domain" >>>>>>> >>>>>>> Hi Mukul, >>>>>>> >>>>>>> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>>>>>> >>>>>>>> Hi JP >>>>>>>> >>>>>>>> I was wondering if the term "RPL Domain" could be defined in the t= erminology draft. >>>>>>>> >>>>>>> >>>>>>> How about >>>>>>> >>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> JP. >>>>>>> >>>>>>>> Thanks >>>>>>>> Mukul >>>>>>>> >>>>>>>> ----- Forwarded Message ----- >>>>>>>> From: "Joseph Reddy" >>>>>>>> To: ipv6@ietf.org >>>>>>>> Sent: Friday, October 14, 2011 7:15:05 PM >>>>>>>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>> >>>>>>>> >>>>>>>> Hi Jonathan, >>>>>>>> >>>>>>>> The draft uses the term "RPL domain" in several places and this is= not clearly defined. >>>>>>>> >>>>>>>> I would imagine that it includes all nodes that are downstream of = the RPL border router. But can you clarify if Host nodes that are downstrea= m of the border router but do not implement any part of RPL ( even as RPL L= eaf nodes ) should be considered part of the "RPL domain" ? >>>>>>>> >>>>>>>> In section 5, the draft now says "..Datagrams destined to nodes ou= tside the RPL domain are dropped if the outer-most IPv6 header contains a R= PL Option..." >>>>>>>> >>>>>>>> This text would imply that any RPL node sending packets to nodes o= utside should always tunnel to the Root ? Is that the intention really or a= m I missing something here.. >>>>>>>> >>>>>>>> Also note that if non-RPL Host is not considered part of the RPL d= omain, then I am not sure that a forwarding router can know if the destinat= ion is inside the domain or not. >>>>>>>> >>>>>>>> >>>>>>>> -Regards, Joseph >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> Message: 5 >>>>>>>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>>>>>>> From: Jonathan Hui >>>>>>>> To: IETF IPv6 Mailing List >>>>>>>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>>>>>>> Content-Type: text/plain; charset=3Dus-ascii >>>>>>>> >>>>>>>> >>>>>>>> This update is intended to address Jari Arkko's AD review. >>>>>>>> >>>>>>>> Summary of changes: >>>>>>>> - Clarify when the RPL Option is used. >>>>>>>> - Updated text on recommendations for avoiding fragmentation. >>>>>>>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >>>>>>>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>>>>>>> - Specify RPL Border Router operations in terms of forwarding deci= sion outcomes. >>>>>>>> - Expand security section. >>>>>>>> >>>>>>>> -- >>>>>>>> Jonathan Hui >>>>>>>> >>>>>>>> Begin forwarded message: >>>>>>>> >>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>> Date: October 11, 2011 10:17:15 PM PDT >>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>> Cc: ipv6@ietf.org >>>>>>>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>> >>>>>>>>> A New Internet-Draft is available from the on-line Internet-Draft= s directories. This draft is a work item of the IPv6 Maintenance Working Gr= oup of the IETF. >>>>>>>>> >>>>>>>>> Title : RPL Option for Carrying RPL Information in Data= -Plane Datagrams >>>>>>>>> Author(s) : Jonathan W. Hui >>>>>>>>> JP Vasseur >>>>>>>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>>>>>>> Pages : 14 >>>>>>>>> Date : 2011-10-11 >>>>>>>>> >>>>>>>>> The RPL protocol requires data-plane datagrams to carry RPL >>>>>>>>> routing information that is processed by RPL routers when >>>>>>>>> forwarding those datagrams. This document describes the RPL >>>>>>>>> Option for use within a RPL domain. >>>>>>>>> >>>>>>>>> >>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option >>>>>>>>> -04.txt >>>>>>>>> >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>> >>>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option- >>>>>>>>> 04.txt >>>>>>>>> -------------------------------------------------------------- >>>>>>>>> ------ IETF IPv6 working group mailing list ipv6@ietf.org >>>>>>>>> Administrative Requests: >>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>> -------------------------------------------------------------- >>>>>>>>> ------ >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> ----- IETF IPv6 working group mailing list ipv6@ietf.org >>>>>>>> Administrative Requests: >>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>> --------------------------------------------------------------- >>>>>>>> ----- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 ________________________________ 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 d.sturek@att.net Wed Nov 16 07:41:47 2011 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 41CA61F0C38 for ; Wed, 16 Nov 2011 07:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIZ7pk-xohvb for ; Wed, 16 Nov 2011 07:41:46 -0800 (PST) Received: from nm3-vm0.access.bullet.mail.mud.yahoo.com (nm3-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.136]) by ietfa.amsl.com (Postfix) with SMTP id CFC521F0C35 for ; Wed, 16 Nov 2011 07:41:45 -0800 (PST) Received: from [66.94.237.199] by nm3.access.bullet.mail.mud.yahoo.com with NNFMP; 16 Nov 2011 15:41:41 -0000 Received: from [66.94.237.116] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 16 Nov 2011 15:41:41 -0000 Received: from [127.0.0.1] by omp1021.access.mail.mud.yahoo.com with NNFMP; 16 Nov 2011 15:41:41 -0000 X-Yahoo-Newman-Id: 606674.24152.bm@omp1021.access.mail.mud.yahoo.com Received: (qmail 44992 invoked from network); 16 Nov 2011 15:41:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1321458101; bh=daunDUxkzeq4Pu0ChntZXSinynwl1WI/CS4HrenPihg=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=tcpAmpgo5LvCcRg6hHdnb5tAs0J9HnkLyDw4tnasWyF9mYLAB416q2+6KWXtfSRY8bVuXu4U9nItSUlBJEYnuOXMxy8YqHkZk29THo+PCzAJN1yz/vt8VKOPguDH2TFB78fagQVVLXiRHUmkdx8G9c5lYHxF5+oD+wHGFH3E6tw= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vJyCzzgVM1mxZzZ_bxxZsfr3YljcStgWa5iJc.F8Zvs3wc4 cAb7nVN_.ENr1Pmwok4vJirl2TupHTrYqNyOICLZektBY9O_DrwN6xOoc5Rh vo1Ru94P61TrbTB3uWnQAndugJdKP_BS_LiiRHI2u5u_nfafbTWy2A93wKIB cmglPw8wG7EOcF9CPXNA2wun7mMD7uGoCMJAxqmxMgYoTpdu69Dpcr8uHvB3 fWXmgegc4_6hVEWdg41WPiC7ZAPoYUgVVn1a0dxhSPZZxaNOp94eskKHUPtG 9eLGAfb81elrrZZuHi650jOQ9tBsN4nvIEHlOm.0hYCcX5ZMGnmvk3tpEbLp yC2_z.dH1g6al9iLQoaV8dCWr2g2MtAY8aqxr.FJRB5lwUk4iZzhtTIPzbTL r_oJ0RPnYhSQGi5Za1aRVClVl4Aqa0TEwzMWYggqlW9d1cpCfiVWOzP4tOfc BlOe7BLP_TSG0brvQtwun68xq4QUnag1YUpzaPiivYG42spfTGMFJsgw- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.196] (d.sturek@67.124.202.58 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 16 Nov 2011 07:41:40 -0800 PST User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 16 Nov 2011 07:39:10 -0800 From: Don Sturek To: "Dijk, Esko" , C Chauvenet Message-ID: Thread-Topic: [Roll] definition of "RPL Domain" In-Reply-To: <031DD135F9160444ABBE3B0C36CED618010235@011-DB3MPN1-013.MGDPHG.emi.philips.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 15:41:47 -0000 Hi Esko, I would certainly hope that a "host" need not be defined as "an LLN device that can generate but does not forward RPL traffic". The definition from Jonathan Hui earlier in this thread makes more sense. A RPL domain ends with a RPL leaf node which is by definition a router. A host only device (one would hope) would not need to know anything about RPL and would not be considered part of the RPL domain (but would be able to use a nearby device in the RPL domain to route its packets). Don On 11/16/11 7:31 AM, "Dijk, Esko" wrote: >For information, roll-rpl-19 does define the term "host": an LLN device >that can generate but does not forward RPL traffic. > >"RPL traffic" is not explicitly defined but should be interpreted as any >traffic routed by means of the RPL protocol over a RPL Instance. > >regards, >Esko > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of C >Chauvenet >Sent: Wednesday 16 November 2011 15:14 >To: Jonathan Hui; Thomas Heide Clausen >Cc: roll >Subject: Re: [Roll] definition of "RPL Domain" > >I agree with Jonathan definition. >I think it is quite clear. > >Thomas, could you point us to the document where "RPL Host" is used or >defined ? > >C=E9dric. > >-----Message d'origine----- >De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de >Jonathan Hui >Envoy=E9 : mercredi 16 novembre 2011 15:03 >=C0 : Thomas Heide Clausen >Cc : roll >Objet : Re: [Roll] definition of "RPL Domain" > > >There may be. If so, those hosts do not operate any routing protocols >(unless you consider ND to be a routing protocol) and are not a part of a >RPL domain (under my proposed definition). > >-- >Jonathan Hui > >On Nov 16, 2011, at 5:57 AM, Thomas Heide Clausen wrote: > >> Yes, but is there a node, connected to and in an RPL deployment, that >>doesn't run RPL? In other words, is there a host in a RPL network? >> >> -- >> Thomas Heide Clausen >> http://www.thomasclausen.org/ >> >> "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >> >> >> On 16 Nov 2011, at 21:53, Jonathan Hui wrote: >> >>> >>> It may or may not be accidental. It is perfectly acceptable for a >>>device operating RPL not to advertise routes for destinations other >>>than itself. Either way, the node still operates RPL. >>> >>> -- >>> Jonathan Hui >>> >>> On Nov 16, 2011, at 5:49 AM, Thomas Heide Clausen wrote: >>> >>>> On 16 Nov 2011, at 21:40, Jonathan Hui wrote: >>>> >>>>> With my proposed definition, a RPL Leaf is a RPL Router. A RPL Leaf >>>>>still operates and participates in the RPL routing protocol - it just >>>>>happens not to have any children. >>>> >>>> So it just happens to be a particular "accidental" topological >>>>position of a router, but entails no different state, transitions or >>>>parameters than any other RPL router. >>>> >>>> Therefore, there is absolutely no need for another term, it is just >>>>an RPL router. >>>> >>>> I therefore strongly suggest that there is no reason to invent yet >>>> another piece of confusing terminology (and, in general, that ROLL >>>> would do well by trying to adhere to standard Internet terminology) >>>> >>>> Thomas >>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> On Nov 16, 2011, at 5:25 AM, Thomas Heide Clausen wrote: >>>>> >>>>>> On 16 Nov 2011, at 21:15, Mukul Goyal wrote: >>>>>> >>>>>>>> Now that we are at it: what is an RPL host? Or rather, why is >>>>>>>>this even a conceivable thing to define? Afaik, RPL is a routing >>>>>>>>protocol, and as such should concern only routers - not hosts? >>>>>>> >>>>>>> My bad. By RPL host, I actually meant an RPL leaf node. I think >>>>>>>this term "RPL host" was in use at one point in time but I cant >>>>>>>find a reference to it in current spec. >>>>>> >>>>>> A rose by any other name is *still* a rose.... >>>>>> >>>>>> What is an RPL Leaf Node? What is the difference between a RPL Leaf >>>>>>node and a RPL Router? >>>>>> >>>>>> Isn't there a thing in the end of the network, inside the LLN, >>>>>>that doesn't run RPL, aka, a host? >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>>> >>>>>>> THanks >>>>>>> Mukul >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Thomas Heide Clausen" >>>>>>> To: "Mukul Goyal" >>>>>>> Cc: "JP Vasseur" , "roll" >>>>>>> Sent: Wednesday, November 16, 2011 6:25:31 AM >>>>>>> Subject: Re: [Roll] definition of "RPL Domain" >>>>>>> >>>>>>> Now that we are at it: what is an RPL host? Or rather, why is this >>>>>>>even a conceivable thing to define? Afaik, RPL is a routing >>>>>>>protocol, and as such should concern only routers - not hosts? >>>>>>> >>>>>>> I worry if this is inventing an entire ecosystem which "pretends >>>>>>>to be just like the Internet, except it is not", as it needs >>>>>>>entirely new stacks, protocols, translators/gateways everywhere, >>>>>>>and with no real traces of IP as we know it remaining? >>>>>>> >>>>>>> -- >>>>>>> Thomas Heide Clausen >>>>>>> http://www.thomasclausen.org/ >>>>>>> >>>>>>> "Payload (noun): wasted bandwidth between headers" (C.Lavenu >>>>>>> 2011) >>>>>>> >>>>>>> >>>>>>> On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >>>>>>> >>>>>>>> Hi JP >>>>>>>> >>>>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>>> >>>>>>>> I think this definition is little too vague. Some of the points >>>>>>>>that need clarification: >>>>>>>> >>>>>>>> 1. It is clear that RPL hosts and routers (as defined towards the >>>>>>>>end of terminology section in RPL-19) are within an RPL domain but >>>>>>>>what about the RPL-unaware IPv6 hosts attached to an RPL >>>>>>>>router/host? I would imagine that such hosts are also within an >>>>>>>>RPL domain. >>>>>>>> >>>>>>>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain >>>>>>>>a set of RPL instances in the LLN? Can multiple RPL domains exist >>>>>>>>within an LLN? Or is it that an RPL domain is same as an LLN using >>>>>>>>RPL as a routing protocol? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Mukul >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "JP Vasseur" >>>>>>>> To: "Mukul Goyal" >>>>>>>> Cc: "roll" >>>>>>>> Sent: Wednesday, November 16, 2011 2:33:50 AM >>>>>>>> Subject: Re: definition of "RPL Domain" >>>>>>>> >>>>>>>> Hi Mukul, >>>>>>>> >>>>>>>> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>>>>>>> >>>>>>>>> Hi JP >>>>>>>>> >>>>>>>>> I was wondering if the term "RPL Domain" could be defined in the >>>>>>>>>terminology draft. >>>>>>>>> >>>>>>>> >>>>>>>> How about >>>>>>>> >>>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> JP. >>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Mukul >>>>>>>>> >>>>>>>>> ----- Forwarded Message ----- >>>>>>>>> From: "Joseph Reddy" >>>>>>>>> To: ipv6@ietf.org >>>>>>>>> Sent: Friday, October 14, 2011 7:15:05 PM >>>>>>>>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Jonathan, >>>>>>>>> >>>>>>>>> The draft uses the term "RPL domain" in several places and this >>>>>>>>>is not clearly defined. >>>>>>>>> >>>>>>>>> I would imagine that it includes all nodes that are downstream >>>>>>>>>of the RPL border router. But can you clarify if Host nodes that >>>>>>>>>are downstream of the border router but do not implement any part >>>>>>>>>of RPL ( even as RPL Leaf nodes ) should be considered part of >>>>>>>>>the "RPL domain" ? >>>>>>>>> >>>>>>>>> In section 5, the draft now says "..Datagrams destined to nodes >>>>>>>>>outside the RPL domain are dropped if the outer-most IPv6 header >>>>>>>>>contains a RPL Option..." >>>>>>>>> >>>>>>>>> This text would imply that any RPL node sending packets to nodes >>>>>>>>>outside should always tunnel to the Root ? Is that the intention >>>>>>>>>really or am I missing something here.. >>>>>>>>> >>>>>>>>> Also note that if non-RPL Host is not considered part of the RPL >>>>>>>>>domain, then I am not sure that a forwarding router can know if >>>>>>>>>the destination is inside the domain or not. >>>>>>>>> >>>>>>>>> >>>>>>>>> -Regards, Joseph >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------ >>>>>>>>> >>>>>>>>> Message: 5 >>>>>>>>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>>>>>>>> From: Jonathan Hui >>>>>>>>> To: IETF IPv6 Mailing List >>>>>>>>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>>>>>>>> Content-Type: text/plain; charset=3Dus-ascii >>>>>>>>> >>>>>>>>> >>>>>>>>> This update is intended to address Jari Arkko's AD review. >>>>>>>>> >>>>>>>>> Summary of changes: >>>>>>>>> - Clarify when the RPL Option is used. >>>>>>>>> - Updated text on recommendations for avoiding fragmentation. >>>>>>>>> - Specify skip-over-and-continue policy for unrecognized >>>>>>>>>sub-TLVs. >>>>>>>>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>>>>>>>> - Specify RPL Border Router operations in terms of forwarding >>>>>>>>>decision outcomes. >>>>>>>>> - Expand security section. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jonathan Hui >>>>>>>>> >>>>>>>>> Begin forwarded message: >>>>>>>>> >>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>> Date: October 11, 2011 10:17:15 PM PDT >>>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>>> Cc: ipv6@ietf.org >>>>>>>>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>>> >>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>>Internet-Drafts directories. This draft is a work item of the >>>>>>>>>>IPv6 Maintenance Working Group of the IETF. >>>>>>>>>> >>>>>>>>>> Title : RPL Option for Carrying RPL Information in >>>>>>>>>>Data-Plane Datagrams >>>>>>>>>> Author(s) : Jonathan W. Hui >>>>>>>>>> JP Vasseur >>>>>>>>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>>>>>>>> Pages : 14 >>>>>>>>>> Date : 2011-10-11 >>>>>>>>>> >>>>>>>>>> The RPL protocol requires data-plane datagrams to carry RPL >>>>>>>>>> routing information that is processed by RPL routers when >>>>>>>>>> forwarding those datagrams. This document describes the RPL >>>>>>>>>> Option for use within a RPL domain. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option >>>>>>>>>> -04.txt >>>>>>>>>> >>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>> >>>>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option- >>>>>>>>>> 04.txt >>>>>>>>>> -------------------------------------------------------------- >>>>>>>>>> ------ IETF IPv6 working group mailing list ipv6@ietf.org >>>>>>>>>> Administrative Requests: >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>>> -------------------------------------------------------------- >>>>>>>>>> ------ >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------- >>>>>>>>> ----- IETF IPv6 working group mailing list ipv6@ietf.org >>>>>>>>> Administrative Requests: >>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>> --------------------------------------------------------------- >>>>>>>>> ----- >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 > >________________________________ >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 From j.schoenwaelder@jacobs-university.de Wed Nov 16 07:57:08 2011 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 8971821F951B for ; Wed, 16 Nov 2011 07:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 6Rs7+wx2Tmhx for ; Wed, 16 Nov 2011 07:57:08 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CCA8821F951D for ; Wed, 16 Nov 2011 07:57:07 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A4CD20DCE; Wed, 16 Nov 2011 16:57:07 +0100 (CET) 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 CygEmkM_VZx3; Wed, 16 Nov 2011 16:57:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9327220DB4; Wed, 16 Nov 2011 16:57:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 462A31BB7479; Wed, 16 Nov 2011 16:56:47 +0100 (CET) Date: Wed, 16 Nov 2011 16:56:47 +0100 From: Juergen Schoenwaelder To: "Dijk, Esko" Message-ID: <20111116155646.GA24208@elstar.local> Mail-Followup-To: "Dijk, Esko" , C Chauvenet , roll References: <538899391.312842.1321449359380.JavaMail.root@mail17.pantherlink.uwm.edu> <2CD3ADFF-DE10-440C-895B-8527190395F9@cisco.com> <92C241B0-33A1-41A2-8C64-16E5602971D5@thomasclausen.org> <8688B01C-F255-4868-AF16-0A8AD6B27BE9@cisco.com> <164D1B8C-1326-430B-8E16-F961029BEC59@thomasclausen.org> <1E9DE872-6511-4F8C-B985-B94EB0635D3F@cisco.com> <031DD135F9160444ABBE3B0C36CED618010235@011-DB3MPN1-013.MGDPHG.emi.philips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <031DD135F9160444ABBE3B0C36CED618010235@011-DB3MPN1-013.MGDPHG.emi.philips.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 15:57:08 -0000 On Wed, Nov 16, 2011 at 03:31:52PM +0000, Dijk, Esko wrote: > For information, roll-rpl-19 does define the term "host": an LLN device that can generate but does not forward RPL traffic. > > "RPL traffic" is not explicitly defined but should be interpreted as any traffic routed by means of the RPL protocol over a RPL Instance. So does a host that does not talk RPL and simply sends an IPv6 packet to a default router, which happens to be an RPL router, generate "RPL traffic"? This is how I read this. If so, is the host aware in any way of the fact that it is generating RPL traffic, that is, there there is RPL used to construct some portions of the path? I would have naively interpreted "RPL traffic" as the RPL control traffic, that is the DIO etc. messages being exchanged between RPL router. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@thomasclausen.org Wed Nov 16 08:12:10 2011 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 1910B21F94C1 for ; Wed, 16 Nov 2011 08:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 R84Q+21YN-ZZ for ; Wed, 16 Nov 2011 08:12:08 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id C7DE021F94C2 for ; Wed, 16 Nov 2011 08:12:08 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 8AD15CD1D0 for ; Wed, 16 Nov 2011 08:12:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 4F5341C1A1F; Wed, 16 Nov 2011 08:12:08 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (unknown [203.69.99.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 4C2051C1A1D; Wed, 16 Nov 2011 08:12:07 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <0F08C3FC-D56B-4D02-9614-C2C2E110B321@thomasclausen.org> X-Mailer: iPhone Mail (9A334) From: Thomas Heide Clausen Date: Thu, 17 Nov 2011 00:11:42 +0800 To: Don Sturek Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 16:12:10 -0000 +1 to what Don says here.=20 I would very much like to know if this is the case (and, then, get rid of th= e invented terms "host" and "RPL leaf" as they seem useless).=20 I also would like to know what exactly "RPL Traffic" is? Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 On 16 nov. 2011, at 23:39, Don Sturek wrote: > Hi Esko, >=20 > I would certainly hope that a "host" need not be defined as "an LLN device= > that can generate but does not forward RPL traffic". >=20 > The definition from Jonathan Hui earlier in this thread makes more sense. > A RPL domain ends with a RPL leaf node which is by definition a router. > A host only device (one would hope) would not need to know anything about > RPL and would not be considered part of the RPL domain (but would be able > to use a nearby device in the RPL domain to route its packets). >=20 > Don >=20 >=20 >=20 >=20 > On 11/16/11 7:31 AM, "Dijk, Esko" wrote: >=20 >> For information, roll-rpl-19 does define the term "host": an LLN device >> that can generate but does not forward RPL traffic. >>=20 >> "RPL traffic" is not explicitly defined but should be interpreted as any >> traffic routed by means of the RPL protocol over a RPL Instance. >>=20 >> regards, >> Esko >>=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of C= >> Chauvenet >> Sent: Wednesday 16 November 2011 15:14 >> To: Jonathan Hui; Thomas Heide Clausen >> Cc: roll >> Subject: Re: [Roll] definition of "RPL Domain" >>=20 >> I agree with Jonathan definition. >> I think it is quite clear. >>=20 >> Thomas, could you point us to the document where "RPL Host" is used or >> defined ? >>=20 >> C=C3=A9dric. >>=20 >> -----Message d'origine----- >> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de >> Jonathan Hui >> Envoy=C3=A9 : mercredi 16 novembre 2011 15:03 >> =C3=80 : Thomas Heide Clausen >> Cc : roll >> Objet : Re: [Roll] definition of "RPL Domain" >>=20 >>=20 >> There may be. If so, those hosts do not operate any routing protocols >> (unless you consider ND to be a routing protocol) and are not a part of a= >> RPL domain (under my proposed definition). >>=20 >> -- >> Jonathan Hui >>=20 >> On Nov 16, 2011, at 5:57 AM, Thomas Heide Clausen wrote: >>=20 >>> Yes, but is there a node, connected to and in an RPL deployment, that >>> doesn't run RPL? In other words, is there a host in a RPL network? >>>=20 >>> -- >>> Thomas Heide Clausen >>> http://www.thomasclausen.org/ >>>=20 >>> "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) >>>=20 >>>=20 >>> On 16 Nov 2011, at 21:53, Jonathan Hui wrote: >>>=20 >>>>=20 >>>> It may or may not be accidental. It is perfectly acceptable for a >>>> device operating RPL not to advertise routes for destinations other >>>> than itself. Either way, the node still operates RPL. >>>>=20 >>>> -- >>>> Jonathan Hui >>>>=20 >>>> On Nov 16, 2011, at 5:49 AM, Thomas Heide Clausen wrote: >>>>=20 >>>>> On 16 Nov 2011, at 21:40, Jonathan Hui wrote: >>>>>=20 >>>>>> With my proposed definition, a RPL Leaf is a RPL Router. A RPL Leaf >>>>>> still operates and participates in the RPL routing protocol - it just= >>>>>> happens not to have any children. >>>>>=20 >>>>> So it just happens to be a particular "accidental" topological >>>>> position of a router, but entails no different state, transitions or >>>>> parameters than any other RPL router. >>>>>=20 >>>>> Therefore, there is absolutely no need for another term, it is just >>>>> an RPL router. >>>>>=20 >>>>> I therefore strongly suggest that there is no reason to invent yet >>>>> another piece of confusing terminology (and, in general, that ROLL >>>>> would do well by trying to adhere to standard Internet terminology) >>>>>=20 >>>>> Thomas >>>>>=20 >>>>>> -- >>>>>> Jonathan Hui >>>>>>=20 >>>>>> On Nov 16, 2011, at 5:25 AM, Thomas Heide Clausen wrote: >>>>>>=20 >>>>>>> On 16 Nov 2011, at 21:15, Mukul Goyal wrote: >>>>>>>=20 >>>>>>>>> Now that we are at it: what is an RPL host? Or rather, why is >>>>>>>>> this even a conceivable thing to define? Afaik, RPL is a routing >>>>>>>>> protocol, and as such should concern only routers - not hosts? >>>>>>>>=20 >>>>>>>> My bad. By RPL host, I actually meant an RPL leaf node. I think >>>>>>>> this term "RPL host" was in use at one point in time but I cant >>>>>>>> find a reference to it in current spec. >>>>>>>=20 >>>>>>> A rose by any other name is *still* a rose.... >>>>>>>=20 >>>>>>> What is an RPL Leaf Node? What is the difference between a RPL Leaf >>>>>>> node and a RPL Router? >>>>>>>=20 >>>>>>> Isn't there a thing in the end of the network, inside the LLN, >>>>>>> that doesn't run RPL, aka, a host? >>>>>>>=20 >>>>>>> Thomas >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> THanks >>>>>>>> Mukul >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Thomas Heide Clausen" >>>>>>>> To: "Mukul Goyal" >>>>>>>> Cc: "JP Vasseur" , "roll" >>>>>>>> Sent: Wednesday, November 16, 2011 6:25:31 AM >>>>>>>> Subject: Re: [Roll] definition of "RPL Domain" >>>>>>>>=20 >>>>>>>> Now that we are at it: what is an RPL host? Or rather, why is this >>>>>>>> even a conceivable thing to define? Afaik, RPL is a routing >>>>>>>> protocol, and as such should concern only routers - not hosts? >>>>>>>>=20 >>>>>>>> I worry if this is inventing an entire ecosystem which "pretends >>>>>>>> to be just like the Internet, except it is not", as it needs >>>>>>>> entirely new stacks, protocols, translators/gateways everywhere, >>>>>>>> and with no real traces of IP as we know it remaining? >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Thomas Heide Clausen >>>>>>>> http://www.thomasclausen.org/ >>>>>>>>=20 >>>>>>>> "Payload (noun): wasted bandwidth between headers" (C.Lavenu >>>>>>>> 2011) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 16 Nov 2011, at 18:45, Mukul Goyal wrote: >>>>>>>>=20 >>>>>>>>> Hi JP >>>>>>>>>=20 >>>>>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>>>>=20 >>>>>>>>> I think this definition is little too vague. Some of the points >>>>>>>>> that need clarification: >>>>>>>>>=20 >>>>>>>>> 1. It is clear that RPL hosts and routers (as defined towards the >>>>>>>>> end of terminology section in RPL-19) are within an RPL domain but= >>>>>>>>> what about the RPL-unaware IPv6 hosts attached to an RPL >>>>>>>>> router/host? I would imagine that such hosts are also within an >>>>>>>>> RPL domain. >>>>>>>>>=20 >>>>>>>>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain >>>>>>>>> a set of RPL instances in the LLN? Can multiple RPL domains exist >>>>>>>>> within an LLN? Or is it that an RPL domain is same as an LLN using= >>>>>>>>> RPL as a routing protocol? >>>>>>>>>=20 >>>>>>>>> Thanks >>>>>>>>> Mukul >>>>>>>>>=20 >>>>>>>>> ----- Original Message ----- >>>>>>>>> From: "JP Vasseur" >>>>>>>>> To: "Mukul Goyal" >>>>>>>>> Cc: "roll" >>>>>>>>> Sent: Wednesday, November 16, 2011 2:33:50 AM >>>>>>>>> Subject: Re: definition of "RPL Domain" >>>>>>>>>=20 >>>>>>>>> Hi Mukul, >>>>>>>>>=20 >>>>>>>>> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>>>>>>>>=20 >>>>>>>>>> Hi JP >>>>>>>>>>=20 >>>>>>>>>> I was wondering if the term "RPL Domain" could be defined in the >>>>>>>>>> terminology draft. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> How about >>>>>>>>>=20 >>>>>>>>> RPL domain: set of devices using RPL as a routing protocol. >>>>>>>>>=20 >>>>>>>>> Thanks. >>>>>>>>>=20 >>>>>>>>> JP. >>>>>>>>>=20 >>>>>>>>>> Thanks >>>>>>>>>> Mukul >>>>>>>>>>=20 >>>>>>>>>> ----- Forwarded Message ----- >>>>>>>>>> From: "Joseph Reddy" >>>>>>>>>> To: ipv6@ietf.org >>>>>>>>>> Sent: Friday, October 14, 2011 7:15:05 PM >>>>>>>>>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Hi Jonathan, >>>>>>>>>>=20 >>>>>>>>>> The draft uses the term "RPL domain" in several places and this >>>>>>>>>> is not clearly defined. >>>>>>>>>>=20 >>>>>>>>>> I would imagine that it includes all nodes that are downstream >>>>>>>>>> of the RPL border router. But can you clarify if Host nodes that >>>>>>>>>> are downstream of the border router but do not implement any part= >>>>>>>>>> of RPL ( even as RPL Leaf nodes ) should be considered part of >>>>>>>>>> the "RPL domain" ? >>>>>>>>>>=20 >>>>>>>>>> In section 5, the draft now says "..Datagrams destined to nodes >>>>>>>>>> outside the RPL domain are dropped if the outer-most IPv6 header >>>>>>>>>> contains a RPL Option..." >>>>>>>>>>=20 >>>>>>>>>> This text would imply that any RPL node sending packets to nodes >>>>>>>>>> outside should always tunnel to the Root ? Is that the intention >>>>>>>>>> really or am I missing something here.. >>>>>>>>>>=20 >>>>>>>>>> Also note that if non-RPL Host is not considered part of the RPL >>>>>>>>>> domain, then I am not sure that a forwarding router can know if >>>>>>>>>> the destination is inside the domain or not. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -Regards, Joseph >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> ------------------------------ >>>>>>>>>>=20 >>>>>>>>>> Message: 5 >>>>>>>>>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>>>>>>>>> From: Jonathan Hui >>>>>>>>>> To: IETF IPv6 Mailing List >>>>>>>>>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>>>>>>>>> Content-Type: text/plain; charset=3Dus-ascii >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> This update is intended to address Jari Arkko's AD review. >>>>>>>>>>=20 >>>>>>>>>> Summary of changes: >>>>>>>>>> - Clarify when the RPL Option is used. >>>>>>>>>> - Updated text on recommendations for avoiding fragmentation. >>>>>>>>>> - Specify skip-over-and-continue policy for unrecognized >>>>>>>>>> sub-TLVs. >>>>>>>>>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>>>>>>>>> - Specify RPL Border Router operations in terms of forwarding >>>>>>>>>> decision outcomes. >>>>>>>>>> - Expand security section. >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Jonathan Hui >>>>>>>>>>=20 >>>>>>>>>> Begin forwarded message: >>>>>>>>>>=20 >>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>>> Date: October 11, 2011 10:17:15 PM PDT >>>>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>>>> Cc: ipv6@ietf.org >>>>>>>>>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>>>>>>>>=20 >>>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>>> Internet-Drafts directories. This draft is a work item of the >>>>>>>>>>> IPv6 Maintenance Working Group of the IETF. >>>>>>>>>>>=20 >>>>>>>>>>> Title : RPL Option for Carrying RPL Information in >>>>>>>>>>> Data-Plane Datagrams >>>>>>>>>>> Author(s) : Jonathan W. Hui >>>>>>>>>>> JP Vasseur >>>>>>>>>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>>>>>>>>> Pages : 14 >>>>>>>>>>> Date : 2011-10-11 >>>>>>>>>>>=20 >>>>>>>>>>> The RPL protocol requires data-plane datagrams to carry RPL >>>>>>>>>>> routing information that is processed by RPL routers when >>>>>>>>>>> forwarding those datagrams. This document describes the RPL >>>>>>>>>>> Option for use within a RPL domain. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option >>>>>>>>>>> -04.txt >>>>>>>>>>>=20 >>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>=20 >>>>>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option- >>>>>>>>>>> 04.txt >>>>>>>>>>> -------------------------------------------------------------- >>>>>>>>>>> ------ IETF IPv6 working group mailing list ipv6@ietf.org >>>>>>>>>>> Administrative Requests: >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>>>> -------------------------------------------------------------- >>>>>>>>>>> ------ >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> --------------------------------------------------------------- >>>>>>>>>> ----- IETF IPv6 working group mailing list ipv6@ietf.org >>>>>>>>>> Administrative Requests: >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>>> --------------------------------------------------------------- >>>>>>>>>> ----- >>>>>>>>>=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 >>>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >> ________________________________ >> 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. >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=294de8a4a=mukul@uwm.edu Wed Nov 16 08:36:49 2011 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 3E84921F94B5 for ; Wed, 16 Nov 2011 08:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gO2grjNrlfzW for ; Wed, 16 Nov 2011 08:36:44 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9143A21F94B1 for ; Wed, 16 Nov 2011 08:36:44 -0800 (PST) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 16 Nov 2011 10:36:44 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id A3DEF2B3ED8; Wed, 16 Nov 2011 10:35:20 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sc-LJR66BnRF; Wed, 16 Nov 2011 10:35:20 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 13BF32B3ED4; Wed, 16 Nov 2011 10:35:20 -0600 (CST) Date: Wed, 16 Nov 2011 10:36:43 -0600 (CST) From: Mukul Goyal To: Juergen Schoenwaelder Message-ID: <756698293.316555.1321461403485.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20111116155646.GA24208@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: [Roll] RPL traffic Re: definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 16:36:49 -0000 I think the term "RPL traffic" actually means just "data traffic". If that is so, the term "RPL traffic" should be replaced by "data traffic". >I would have naively interpreted "RPL traffic" as the RPL control traffic, that is the DIO etc. messages being exchanged between RPL router. RPL control traffic does not need forwarding. All RPL control messages (except DAO, DAO-ACK) are 1-hop. DAO/DAO-ACK messages, even though they may travel multiple hops, travel by unicast. So, RPL routers, when forwarding these messages, are not aware that these messages are actually RPL control messages. Thanks Mukul ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Esko Dijk" Cc: "roll" Sent: Wednesday, November 16, 2011 9:56:47 AM Subject: Re: [Roll] definition of "RPL Domain" On Wed, Nov 16, 2011 at 03:31:52PM +0000, Dijk, Esko wrote: > For information, roll-rpl-19 does define the term "host": an LLN device that can generate but does not forward RPL traffic. > > "RPL traffic" is not explicitly defined but should be interpreted as any traffic routed by means of the RPL protocol over a RPL Instance. So does a host that does not talk RPL and simply sends an IPv6 packet to a default router, which happens to be an RPL router, generate "RPL traffic"? This is how I read this. If so, is the host aware in any way of the fact that it is generating RPL traffic, that is, there there is RPL used to construct some portions of the path? I would have naively interpreted "RPL traffic" as the RPL control traffic, that is the DIO etc. messages being exchanged between RPL router. /js -- 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 pal@cs.stanford.edu Wed Nov 16 09:29:44 2011 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 ECDA821F944E for ; Wed, 16 Nov 2011 09:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 SE4+DGAsHe1V for ; Wed, 16 Nov 2011 09:29:44 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8A13E21F9441 for ; Wed, 16 Nov 2011 09:29:44 -0800 (PST) Received: from dn0a210211.sunet ([10.33.2.17]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1RQjIt-00086u-Vd; Wed, 16 Nov 2011 09:29:44 -0800 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <0F08C3FC-D56B-4D02-9614-C2C2E110B321@thomasclausen.org> Date: Wed, 16 Nov 2011 09:29:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1F4C8B60-D76F-4820-A84E-EB61A392B3A0@cs.stanford.edu> References: <0F08C3FC-D56B-4D02-9614-C2C2E110B321@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 17:29:45 -0000 On Nov 16, 2011, at 8:11 AM, Thomas Heide Clausen wrote: > +1 to what Don says here.=20 >=20 > I would very much like to know if this is the case (and, then, get rid = of the invented terms "host" and "RPL leaf" as they seem useless).=20 >=20 > I also would like to know what exactly "RPL Traffic" is? >=20 > Thomas Thomas -- what do you think of Jonathan's suggestion (Don supports it)? I'm wondering if this discussion can be a little more constructive: = rather than shoot down every suggestion that comes up, perhaps you could = suggest what you think RPL Traffic is? Phil= From thomas@thomasclausen.org Wed Nov 16 09:43:08 2011 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 84F8521F9436 for ; Wed, 16 Nov 2011 09:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 9jmCEn5J8jvQ for ; Wed, 16 Nov 2011 09:43:08 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id F271A21F9434 for ; Wed, 16 Nov 2011 09:43:07 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C40DDAB1D0 for ; Wed, 16 Nov 2011 09:43:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8726C1E0261; Wed, 16 Nov 2011 09:43:06 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (unknown [203.69.99.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 113A61E024F; Wed, 16 Nov 2011 09:43:06 -0800 (PST) References: <0F08C3FC-D56B-4D02-9614-C2C2E110B321@thomasclausen.org> <1F4C8B60-D76F-4820-A84E-EB61A392B3A0@cs.stanford.edu> In-Reply-To: <1F4C8B60-D76F-4820-A84E-EB61A392B3A0@cs.stanford.edu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7DA09D07-935A-4058-B888-A7C8F73416A3@thomasclausen.org> X-Mailer: iPhone Mail (9A334) From: Thomas Heide Clausen Date: Thu, 17 Nov 2011 01:42:45 +0800 To: Philip Levis Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 17:43:08 -0000 Phil, I have actually no idea what "RPL Traffic" is, hence my question. =20 I don't think that a random guess from me would be particularly constructive= , would it? Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 On 17 nov. 2011, at 01:29, Philip Levis wrote: >=20 > On Nov 16, 2011, at 8:11 AM, Thomas Heide Clausen wrote: >=20 >> +1 to what Don says here.=20 >>=20 >> I would very much like to know if this is the case (and, then, get rid of= the invented terms "host" and "RPL leaf" as they seem useless).=20 >>=20 >> I also would like to know what exactly "RPL Traffic" is? >>=20 >> Thomas >=20 > Thomas -- what do you think of Jonathan's suggestion (Don supports it)? >=20 > I'm wondering if this discussion can be a little more constructive: rather= than shoot down every suggestion that comes up, perhaps you could suggest w= hat you think RPL Traffic is? >=20 > Phil From d.sturek@att.net Wed Nov 16 09:47:04 2011 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 8491411E80A4 for ; Wed, 16 Nov 2011 09:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.617, 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 XYsUOsbaTYOD for ; Wed, 16 Nov 2011 09:47:04 -0800 (PST) Received: from nm30.access.bullet.mail.sp2.yahoo.com (nm30.access.bullet.mail.sp2.yahoo.com [98.139.44.157]) by ietfa.amsl.com (Postfix) with SMTP id 0BD9A11E8085 for ; Wed, 16 Nov 2011 09:47:04 -0800 (PST) Received: from [98.139.44.99] by nm30.access.bullet.mail.sp2.yahoo.com with NNFMP; 16 Nov 2011 17:47:04 -0000 Received: from [98.139.44.64] by tm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 16 Nov 2011 17:47:03 -0000 Received: from [127.0.0.1] by omp1001.access.mail.sp2.yahoo.com with NNFMP; 16 Nov 2011 17:47:03 -0000 X-Yahoo-Newman-Id: 976978.54323.bm@omp1001.access.mail.sp2.yahoo.com Received: (qmail 6152 invoked from network); 16 Nov 2011 17:47:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1321465623; bh=KUeKk61qPTdpJ8d74Rl9PBcwQXYDpQjA8XFjoWPMCPg=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=rv/GoIi4S1HHfYZYKbRdB7INv7CUFZl8Wi2R8TzpI+Z3RYIwvikcUdk9oTIUKo8+q+IooeuCBTeCExnxLGIDuh7xJi8kGdGgdXu7jwCEbn2KwNB8OqOeftNau+1/zD8WuXMgmNYddB2PUdE5wEsik4Zc0d3VDQwvF5h1xRWtkmI= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8QYpoTUVM1meFTEb5YML5BQlaCpI0jC7ITpaXviIoXv0Iae DB8v7GoYT9eXaOTLYFSJu7YE6Biw8MYoO7bdVuKbbGFHlR6dnE9O_zcC9gAY FS_7BAx7NK7.DslNftZ0SQHw4Y1iz21gl52Z10Mg3bOCU1z.kpog7e2r8Ara 9Jz4HBxt2.Ft9cTVfqpg288V8gGv5gvIvKZ_2xHLwFEfmkeEjN.crLtujAw6 20KoCRqmAC3cyad6Ttf3FBGOh.I_CEUFJp88N5WLJFuL3xS8kRfWvw0eJzj1 SIzXGMX_Nhr9_EwIoeFdHTVKT6uBocPQhWp3xp.5Vn83tMhH3Sp7Ogh74.n4 kOjFwDfKbbYR0umQjInd3oDC4ukc9QSbUyENt4MFeg_Fx9GYEC5eQZOXtRXo B5fH_eXSV9DW2MR0uSzI- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.118] (d.sturek@174.78.56.227 with login) by smtp114.sbc.mail.ne1.yahoo.com with SMTP; 16 Nov 2011 09:47:03 -0800 PST User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 16 Nov 2011 09:46:51 -0800 From: Don Sturek To: Philip Levis , Thomas Heide Clausen Message-ID: Thread-Topic: [Roll] definition of "RPL Domain" In-Reply-To: <1F4C8B60-D76F-4820-A84E-EB61A392B3A0@cs.stanford.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 17:47:04 -0000 Here is my suggestion for "RPL traffic" (if indeed we find we even need the term in the RFC/draft): RPL traffic == Data traffic which transits routers that determined the routing path via RPL control messages. Don On 11/16/11 9:29 AM, "Philip Levis" wrote: > >On Nov 16, 2011, at 8:11 AM, Thomas Heide Clausen wrote: > >> +1 to what Don says here. >> >> I would very much like to know if this is the case (and, then, get rid >>of the invented terms "host" and "RPL leaf" as they seem useless). >> >> I also would like to know what exactly "RPL Traffic" is? >> >> Thomas > >Thomas -- what do you think of Jonathan's suggestion (Don supports it)? > >I'm wondering if this discussion can be a little more constructive: >rather than shoot down every suggestion that comes up, perhaps you could >suggest what you think RPL Traffic is? > >Phil From prvs=294de8a4a=mukul@uwm.edu Wed Nov 16 10:07:02 2011 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 BD0CE21F94F9 for ; Wed, 16 Nov 2011 10:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 QrQwBprVmpDn for ; Wed, 16 Nov 2011 10:07:02 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id E257921F94F0 for ; Wed, 16 Nov 2011 10:07:01 -0800 (PST) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 16 Nov 2011 12:07:01 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id EB6052B3EDB; Wed, 16 Nov 2011 12:05:37 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhEj4x2EChxl; Wed, 16 Nov 2011 12:05:37 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 427E52B3EE5; Wed, 16 Nov 2011 12:05:37 -0600 (CST) Date: Wed, 16 Nov 2011 12:07:00 -0600 (CST) From: Mukul Goyal To: =?utf-8?Q?S=C3=A9bastien_Dawans?= Message-ID: <1651973633.318584.1321466820655.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <4EC3BD54.6030403@cetic.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:07:02 -0000 Hi Sebastien First, I would like to clarify that the need to define "RPL domain" arose b= ecause draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header we= re using the term. Now, these drafts use the term "RPL instance" and hence = there is no real need to define the term "RPL domain" any more. I will chan= ge draft-ietf-roll-p2p-measurement so that all references to "RPL domain" a= re changed to "RPL Instance". Now returning to the question whether hosts should be considered part of th= e RPL Instance, the benefit of doing so is that there is no need to use IP-= in-IP tunneling when a host sends out some data. If a host is not considere= d part of the RPL Instance, its default RPL router is obliged to use IP-in-= IP tunneling to forward the packet further. IP-in-IP tunneling means an ext= ra IPv6 header and thus less space for payload if you want to avoid fragmen= tation. Also, if the packet is traveling along a DAG, the encapsulation/dec= apsulation needs to be done at every hop, which sounds fairly heavy duty pr= ocessing to me. So, I would like to explore if there is a way we could consider hosts to be= a part of the RPL Instance. Regards, Mukul >On what ground would you assume that a non-RPL aware host connected to a= =20 >RPL-router (in this case I would call it a border router) is in a/the=20 >RPL Domain? > From what I've seen in the drafts, the term "RPL Domain"'s primary=20 >purpose it to differentiate the limits of "RPL-aware" nodes for IP=20 >traffic that needs to transit to or from a set of RPL-aware hosts (for=20 >example, to define where to add/remove the RPL IPv6 Hop-by-Hop Option if= =20 >used). >To me, this interpretation of RPL Domain is thus only useful in a local=20 >context and not to meant to designate one or more bounded set of nodes.=20 >That's the role of DODAGs and Instances. >Best Regards, >S=C3=A9bastien Dawans On 11/16/2011 02:20 PM, Mukul Goyal wrote: > So, the revised doubts are as follows: > > 1. It is clear that RPL routers are within an RPL domain but what about t= he RPL-unaware IPv6 hosts attached to an RPL router? I would imagine that s= uch hosts are also within an RPL domain. > > 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of= RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or= is it that an RPL domain is same as an LLN using RPL as a routing protocol= ? > > THanks > Mukul > > ----- Original Message ----- > From: "Mukul Goyal" > To: "Thomas Heide Clausen" > Cc: "roll" > Sent: Wednesday, November 16, 2011 7:15:59 AM > Subject: Re: [Roll] definition of "RPL Domain" > > =20 >> Now that we are at it: what is an RPL host? Or rather, why is this even = a conceivable thing to define? Afaik, RPL is a routing protocol, and as suc= h should concern only routers - not hosts? >> =20 > My bad. By RPL host, I actually meant an RPL leaf node. I think this term= "RPL host" was in use at one point in time but I cant find a reference to = it in current spec. > > THanks > Mukul > > > > ----- Original Message ----- > From: "Thomas Heide Clausen" > To: "Mukul Goyal" > Cc: "JP Vasseur", "roll" > Sent: Wednesday, November 16, 2011 6:25:31 AM > Subject: Re: [Roll] definition of "RPL Domain" > > Now that we are at it: what is an RPL host? Or rather, why is this even a= conceivable thing to define? Afaik, RPL is a routing protocol, and as such= should concern only routers - not hosts? > > I worry if this is inventing an entire ecosystem which "pretends to be ju= st like the Internet, except it is not", as it needs entirely new stacks, p= rotocols, translators/gateways everywhere, and with no real traces of IP as= we know it remaining? > > =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=294de8a4a=mukul@uwm.edu Wed Nov 16 10:30:01 2011 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 1577921F94A2 for ; Wed, 16 Nov 2011 10:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 R0aBefH5nKLa for ; Wed, 16 Nov 2011 10:30:00 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 10CF421F900D for ; Wed, 16 Nov 2011 10:29:59 -0800 (PST) Received: from localhost (HELO mta01.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 16 Nov 2011 12:29:59 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 944E5E6A77; Wed, 16 Nov 2011 12:29:59 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjpUWokARrll; Wed, 16 Nov 2011 12:29:59 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 21DECE6A7A; Wed, 16 Nov 2011 12:29:59 -0600 (CST) Date: Wed, 16 Nov 2011 12:29:59 -0600 (CST) From: Mukul Goyal To: Don Sturek Message-ID: <1185890389.319215.1321468199033.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:30:01 -0000 Hi Don I dont want hosts to know about RPL. I just want the RPL routers to conside= r the hosts as part of the RPL instance so that the RPL router does not hav= e to do IP-in-IP tunneling to forward packets generated by a host. Thanks Mukul ----- Original Message ----- From: "Don Sturek" To: "Mukul Goyal" , "S=C3=A9bastien Dawans" Cc: roll@ietf.org Sent: Wednesday, November 16, 2011 12:22:55 PM Subject: Re: [Roll] definition of "RPL Domain" Hi Mukul, I guess my view on this is the opposite of yours. I would like to see host-only devices not need to know anything about RPL. Here is why: 1) Code savings. Removing RPL from these host only devices would allow for deployment on smaller footprint devices 2) Battery operated devices. Some host only devices are deployed on non-mains powered devices. It would be nice for these devices to not have to listen for any RPL control messages yet still support transmission into a RPL routing domain. Don On 11/16/11 10:07 AM, "Mukul Goyal" wrote: >Hi Sebastien > >First, I would like to clarify that the need to define "RPL domain" arose >because draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header >were using the term. Now, these drafts use the term "RPL instance" and >hence there is no real need to define the term "RPL domain" any more. I >will change draft-ietf-roll-p2p-measurement so that all references to >"RPL domain" are changed to "RPL Instance". > >Now returning to the question whether hosts should be considered part of >the RPL Instance, the benefit of doing so is that there is no need to use >IP-in-IP tunneling when a host sends out some data. If a host is not >considered part of the RPL Instance, its default RPL router is obliged to >use IP-in-IP tunneling to forward the packet further. IP-in-IP tunneling >means an extra IPv6 header and thus less space for payload if you want to >avoid fragmentation. Also, if the packet is traveling along a DAG, the >encapsulation/decapsulation needs to be done at every hop, which sounds >fairly heavy duty processing to me. > >So, I would like to explore if there is a way we could consider hosts to >be a part of the RPL Instance. > >Regards, >Mukul > >>On what ground would you assume that a non-RPL aware host connected to a >>RPL-router (in this case I would call it a border router) is in a/the >>RPL Domain? > >> From what I've seen in the drafts, the term "RPL Domain"'s primary >>purpose it to differentiate the limits of "RPL-aware" nodes for IP >>traffic that needs to transit to or from a set of RPL-aware hosts (for >>example, to define where to add/remove the RPL IPv6 Hop-by-Hop Option if >>used). > >>To me, this interpretation of RPL Domain is thus only useful in a local >>context and not to meant to designate one or more bounded set of nodes. >>That's the role of DODAGs and Instances. > >>Best Regards, > >>S=C3=A9bastien Dawans > >On 11/16/2011 02:20 PM, Mukul Goyal wrote: >> So, the revised doubts are as follows: >> >> 1. It is clear that RPL routers are within an RPL domain but what about >>the RPL-unaware IPv6 hosts attached to an RPL router? I would imagine >>that such hosts are also within an RPL domain. >> >> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set >>of RPL instances in the LLN? Can multiple RPL domains exist within an >>LLN? Or is it that an RPL domain is same as an LLN using RPL as a >>routing protocol? >> >> THanks >> Mukul >> >> ----- Original Message ----- >> From: "Mukul Goyal" >> To: "Thomas Heide Clausen" >> Cc: "roll" >> Sent: Wednesday, November 16, 2011 7:15:59 AM >> Subject: Re: [Roll] definition of "RPL Domain" >> >> =20 >>> Now that we are at it: what is an RPL host? Or rather, why is this >>>even a conceivable thing to define? Afaik, RPL is a routing protocol, >>>and as such should concern only routers - not hosts? >>> =20 >> My bad. By RPL host, I actually meant an RPL leaf node. I think this >>term "RPL host" was in use at one point in time but I cant find a >>reference to it in current spec. >> >> THanks >> Mukul >> >> >> >> ----- Original Message ----- >> From: "Thomas Heide Clausen" >> To: "Mukul Goyal" >> Cc: "JP Vasseur", "roll" >> Sent: Wednesday, November 16, 2011 6:25:31 AM >> Subject: Re: [Roll] definition of "RPL Domain" >> >> Now that we are at it: what is an RPL host? Or rather, why is this even >>a conceivable thing to define? Afaik, RPL is a routing protocol, and as >>such should concern only routers - not hosts? >> >> I worry if this is inventing an entire ecosystem which "pretends to be >>just like the Internet, except it is not", as it needs entirely new >>stacks, protocols, translators/gateways everywhere, and with no real >>traces of IP as we know it remaining? >> >> =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 d.sturek@att.net Wed Nov 16 10:32:48 2011 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 BC75621F8C92 for ; Wed, 16 Nov 2011 10:32:48 -0800 (PST) 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, MIME_8BIT_HEADER=0.3] 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 1DETQRGY6JgP for ; Wed, 16 Nov 2011 10:32:48 -0800 (PST) Received: from nm16.access.bullet.mail.mud.yahoo.com (nm16.access.bullet.mail.mud.yahoo.com [66.94.237.217]) by ietfa.amsl.com (Postfix) with SMTP id 0055621F93AF for ; Wed, 16 Nov 2011 10:32:47 -0800 (PST) Received: from [66.94.237.127] by nm16.access.bullet.mail.mud.yahoo.com with NNFMP; 16 Nov 2011 18:23:14 -0000 Received: from [66.94.237.96] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 16 Nov 2011 18:23:14 -0000 Received: from [127.0.0.1] by omp1001.access.mail.mud.yahoo.com with NNFMP; 16 Nov 2011 18:23:14 -0000 X-Yahoo-Newman-Id: 939283.76065.bm@omp1001.access.mail.mud.yahoo.com Received: (qmail 61754 invoked from network); 16 Nov 2011 18:23:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1321467794; bh=md4yC42ElTbLKtb6nOorKZ3ueOdgCUu9hYpC0AmO7po=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=oJgdzXhiEzt8a2eOSVPjiIY+uYgV9ZjRCJgsHAyOLYnX/x5V0cPTya6cwWWxspUzXCcVCkv3RDEeTCClYWctgynDeeAlG8xbyt3W01InufY6UU09zMo8MvIiSE0h/+Uoih2RlykTZXwt8V4OVxQ8Dx6NgjKc7tcJCHLk4Np0c5Y= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1zzeTacVM1mXbgz.rBgUPmNsU91PevtbFhvcqoZNUEsYIpz 20T6iEvvfBgIySv7Nq.TQJxJqu8WgGq3agl5ua4L7ffGVLfhX.2212g9WT49 K7T3x.eC.3TcHifwd6yVZa8loheDsp_.u_bnsR2nkqQZGGQTB4ZF3Fh3x4jU u2BWEf_QTzEKLncVI3bynD9NR4ySVPSUtmnJtEU1Jz567uqLs3nZSNOhG.2i TsdMjmwtb3uo3MzceAceMX8DHCYf85al9nSwLwMDEKQLIFkwexV5IviVTVd. Jnqb_lOVMgnpGCGpK5S2GbYKzD_z1TKOiFQ7uERgSDVHQk7Xfr59E_h.B7O6 fbE3NlSIy7HYVTkjzgwAru_wqEyP2hZS5.6jYcKI_9aeoqVMjb9x2mZ0X3nI bk2nAcoiUc7.MEv6v_BU- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.118] (d.sturek@174.78.56.227 with login) by smtp104.sbc.mail.ne1.yahoo.com with SMTP; 16 Nov 2011 10:23:13 -0800 PST User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 16 Nov 2011 10:22:55 -0800 From: Don Sturek To: Mukul Goyal , =?ISO-8859-1?B?U+liYXN0aWVu?= Dawans Message-ID: Thread-Topic: [Roll] definition of "RPL Domain" In-Reply-To: <1651973633.318584.1321466820655.JavaMail.root@mail17.pantherlink.uwm.edu> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:32:48 -0000 Hi Mukul, I guess my view on this is the opposite of yours. I would like to see host-only devices not need to know anything about RPL. Here is why: 1) Code savings. Removing RPL from these host only devices would allow for deployment on smaller footprint devices 2) Battery operated devices. Some host only devices are deployed on non-mains powered devices. It would be nice for these devices to not have to listen for any RPL control messages yet still support transmission into a RPL routing domain. Don On 11/16/11 10:07 AM, "Mukul Goyal" wrote: >Hi Sebastien > >First, I would like to clarify that the need to define "RPL domain" arose >because draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header >were using the term. Now, these drafts use the term "RPL instance" and >hence there is no real need to define the term "RPL domain" any more. I >will change draft-ietf-roll-p2p-measurement so that all references to >"RPL domain" are changed to "RPL Instance". > >Now returning to the question whether hosts should be considered part of >the RPL Instance, the benefit of doing so is that there is no need to use >IP-in-IP tunneling when a host sends out some data. If a host is not >considered part of the RPL Instance, its default RPL router is obliged to >use IP-in-IP tunneling to forward the packet further. IP-in-IP tunneling >means an extra IPv6 header and thus less space for payload if you want to >avoid fragmentation. Also, if the packet is traveling along a DAG, the >encapsulation/decapsulation needs to be done at every hop, which sounds >fairly heavy duty processing to me. > >So, I would like to explore if there is a way we could consider hosts to >be a part of the RPL Instance. > >Regards, >Mukul > >>On what ground would you assume that a non-RPL aware host connected to a >>RPL-router (in this case I would call it a border router) is in a/the >>RPL Domain? > >> From what I've seen in the drafts, the term "RPL Domain"'s primary >>purpose it to differentiate the limits of "RPL-aware" nodes for IP >>traffic that needs to transit to or from a set of RPL-aware hosts (for >>example, to define where to add/remove the RPL IPv6 Hop-by-Hop Option if >>used). > >>To me, this interpretation of RPL Domain is thus only useful in a local >>context and not to meant to designate one or more bounded set of nodes. >>That's the role of DODAGs and Instances. > >>Best Regards, > >>S=E9bastien Dawans > >On 11/16/2011 02:20 PM, Mukul Goyal wrote: >> So, the revised doubts are as follows: >> >> 1. It is clear that RPL routers are within an RPL domain but what about >>the RPL-unaware IPv6 hosts attached to an RPL router? I would imagine >>that such hosts are also within an RPL domain. >> >> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set >>of RPL instances in the LLN? Can multiple RPL domains exist within an >>LLN? Or is it that an RPL domain is same as an LLN using RPL as a >>routing protocol? >> >> THanks >> Mukul >> >> ----- Original Message ----- >> From: "Mukul Goyal" >> To: "Thomas Heide Clausen" >> Cc: "roll" >> Sent: Wednesday, November 16, 2011 7:15:59 AM >> Subject: Re: [Roll] definition of "RPL Domain" >> >> =20 >>> Now that we are at it: what is an RPL host? Or rather, why is this >>>even a conceivable thing to define? Afaik, RPL is a routing protocol, >>>and as such should concern only routers - not hosts? >>> =20 >> My bad. By RPL host, I actually meant an RPL leaf node. I think this >>term "RPL host" was in use at one point in time but I cant find a >>reference to it in current spec. >> >> THanks >> Mukul >> >> >> >> ----- Original Message ----- >> From: "Thomas Heide Clausen" >> To: "Mukul Goyal" >> Cc: "JP Vasseur", "roll" >> Sent: Wednesday, November 16, 2011 6:25:31 AM >> Subject: Re: [Roll] definition of "RPL Domain" >> >> Now that we are at it: what is an RPL host? Or rather, why is this even >>a conceivable thing to define? Afaik, RPL is a routing protocol, and as >>such should concern only routers - not hosts? >> >> I worry if this is inventing an entire ecosystem which "pretends to be >>just like the Internet, except it is not", as it needs entirely new >>stacks, protocols, translators/gateways everywhere, and with no real >>traces of IP as we know it remaining? >> >> =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 prvs=294de8a4a=mukul@uwm.edu Wed Nov 16 10:38:17 2011 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 DDCF021F93A8 for ; Wed, 16 Nov 2011 10:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3vF0oCbVbMJ for ; Wed, 16 Nov 2011 10:38:17 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id B433721F93A9 for ; Wed, 16 Nov 2011 10:38:16 -0800 (PST) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 16 Nov 2011 12:38:16 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 0B40412E3BC; Wed, 16 Nov 2011 12:38:16 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly1u3dGm2ceR; Wed, 16 Nov 2011 12:38:15 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 84E3D12E3B1; Wed, 16 Nov 2011 12:38:15 -0600 (CST) Date: Wed, 16 Nov 2011 12:38:15 -0600 (CST) From: Mukul Goyal To: Don Sturek Message-ID: <1373977554.319419.1321468695445.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1185890389.319215.1321468199033.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: [Roll] Hosts part of the RPL instance? Re: definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:38:18 -0000 I guess the desired behavior would be: A host sends out a message to its RPL router. The router adds RPL SRH or RP= L option to the IPv6 header and forwards the message further. No need for I= P-in-IP tunneling. Any error message comes back to the router and the route= r handles the message. The host just sends and receives messages. Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "Don Sturek" Cc: roll@ietf.org Sent: Wednesday, November 16, 2011 12:29:59 PM Subject: Re: [Roll] definition of "RPL Domain" Hi Don I dont want hosts to know about RPL. I just want the RPL routers to conside= r the hosts as part of the RPL instance so that the RPL router does not hav= e to do IP-in-IP tunneling to forward packets generated by a host. Thanks Mukul ----- Original Message ----- From: "Don Sturek" To: "Mukul Goyal" , "S=C3=A9bastien Dawans" Cc: roll@ietf.org Sent: Wednesday, November 16, 2011 12:22:55 PM Subject: Re: [Roll] definition of "RPL Domain" Hi Mukul, I guess my view on this is the opposite of yours. I would like to see host-only devices not need to know anything about RPL. Here is why: 1) Code savings. Removing RPL from these host only devices would allow for deployment on smaller footprint devices 2) Battery operated devices. Some host only devices are deployed on non-mains powered devices. It would be nice for these devices to not have to listen for any RPL control messages yet still support transmission into a RPL routing domain. Don On 11/16/11 10:07 AM, "Mukul Goyal" wrote: >Hi Sebastien > >First, I would like to clarify that the need to define "RPL domain" arose >because draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header >were using the term. Now, these drafts use the term "RPL instance" and >hence there is no real need to define the term "RPL domain" any more. I >will change draft-ietf-roll-p2p-measurement so that all references to >"RPL domain" are changed to "RPL Instance". > >Now returning to the question whether hosts should be considered part of >the RPL Instance, the benefit of doing so is that there is no need to use >IP-in-IP tunneling when a host sends out some data. If a host is not >considered part of the RPL Instance, its default RPL router is obliged to >use IP-in-IP tunneling to forward the packet further. IP-in-IP tunneling >means an extra IPv6 header and thus less space for payload if you want to >avoid fragmentation. Also, if the packet is traveling along a DAG, the >encapsulation/decapsulation needs to be done at every hop, which sounds >fairly heavy duty processing to me. > >So, I would like to explore if there is a way we could consider hosts to >be a part of the RPL Instance. > >Regards, >Mukul > >>On what ground would you assume that a non-RPL aware host connected to a >>RPL-router (in this case I would call it a border router) is in a/the >>RPL Domain? > >> From what I've seen in the drafts, the term "RPL Domain"'s primary >>purpose it to differentiate the limits of "RPL-aware" nodes for IP >>traffic that needs to transit to or from a set of RPL-aware hosts (for >>example, to define where to add/remove the RPL IPv6 Hop-by-Hop Option if >>used). > >>To me, this interpretation of RPL Domain is thus only useful in a local >>context and not to meant to designate one or more bounded set of nodes. >>That's the role of DODAGs and Instances. > >>Best Regards, > >>S=C3=A9bastien Dawans > >On 11/16/2011 02:20 PM, Mukul Goyal wrote: >> So, the revised doubts are as follows: >> >> 1. It is clear that RPL routers are within an RPL domain but what about >>the RPL-unaware IPv6 hosts attached to an RPL router? I would imagine >>that such hosts are also within an RPL domain. >> >> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set >>of RPL instances in the LLN? Can multiple RPL domains exist within an >>LLN? Or is it that an RPL domain is same as an LLN using RPL as a >>routing protocol? >> >> THanks >> Mukul >> >> ----- Original Message ----- >> From: "Mukul Goyal" >> To: "Thomas Heide Clausen" >> Cc: "roll" >> Sent: Wednesday, November 16, 2011 7:15:59 AM >> Subject: Re: [Roll] definition of "RPL Domain" >> >> =20 >>> Now that we are at it: what is an RPL host? Or rather, why is this >>>even a conceivable thing to define? Afaik, RPL is a routing protocol, >>>and as such should concern only routers - not hosts? >>> =20 >> My bad. By RPL host, I actually meant an RPL leaf node. I think this >>term "RPL host" was in use at one point in time but I cant find a >>reference to it in current spec. >> >> THanks >> Mukul >> >> >> >> ----- Original Message ----- >> From: "Thomas Heide Clausen" >> To: "Mukul Goyal" >> Cc: "JP Vasseur", "roll" >> Sent: Wednesday, November 16, 2011 6:25:31 AM >> Subject: Re: [Roll] definition of "RPL Domain" >> >> Now that we are at it: what is an RPL host? Or rather, why is this even >>a conceivable thing to define? Afaik, RPL is a routing protocol, and as >>such should concern only routers - not hosts? >> >> I worry if this is inventing an entire ecosystem which "pretends to be >>just like the Internet, except it is not", as it needs entirely new >>stacks, protocols, translators/gateways everywhere, and with no real >>traces of IP as we know it remaining? >> >> =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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jreddy@ti.com Wed Nov 16 11:15:35 2011 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 89BF711E809D for ; Wed, 16 Nov 2011 11:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oQ1ufaw2V8L for ; Wed, 16 Nov 2011 11:15:34 -0800 (PST) Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8626E11E80C6 for ; Wed, 16 Nov 2011 11:15:34 -0800 (PST) Received: from dlep33.itg.ti.com ([157.170.170.112]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id pAGJFV2a001737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Nov 2011 13:15:33 -0600 Received: from dlep26.itg.ti.com (smtp-le.itg.ti.com [157.170.170.27]) by dlep33.itg.ti.com (8.13.7/8.13.8) with ESMTP id pAGJFVLW014022 for ; Wed, 16 Nov 2011 13:15:31 -0600 (CST) Received: from DFLE71.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id pAGJFVWh019090 for ; Wed, 16 Nov 2011 13:15:31 -0600 (CST) Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DFLE71.ent.ti.com ([fe80::29f6:72ad:a62e:2025%21]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 13:15:31 -0600 From: "Reddy, Joseph" To: "roll@ietf.org" Thread-Topic: Roll Digest, Vol 46, Issue 21 Thread-Index: AQHMpI7zYxXZ68oTQ0iFqu8So/WihZWv2eZQ Date: Wed, 16 Nov 2011 19:15:30 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DBEEF48A@DLEE10.ent.ti.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.170.170.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] Roll Digest, Vol 46, Issue 21 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 19:15:35 -0000 Hi Mukul, Note that IP-in-IP tunnelling may be necessary even for data packets orgina= ted on the RPL router itself. This is because the destination may be a non-= RPL Host and so the RPL Option header has to be removed before sending the = packet on the final hop.=20 Essentially, a standard IPv6 Host would not necessarily be able to send/re= ceive IPv6 packets through a RPL router unless the RPL router has the addit= ional logic to add the necessary headers ( and also remove the same for pac= kets destinted to the Host ) and perform tunnelling. This behaviour on part= of the RPL router is not mandatory per the RPL spec. I think it should be. -Regards, Joseph ----- Original Message ----- From: "Mukul Goyal" I guess the desired behavior would be: A host sends out a message to its RPL router. The router adds RPL SRH or RP= L option to the IPv6 header and forwards the message further. No need for I= P-in-IP tunneling. Any error message comes back to the router and the route= r handles the message. The host just sends and receives messages. Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "Don Sturek" Cc: roll at ietf.org Sent: Wednesday, November 16, 2011 12:29:59 PM Subject: Re: [Roll] definition of "RPL Domain" Hi Don I dont want hosts to know about RPL. I just want the RPL routers to conside= r the hosts as part of the RPL instance so that the RPL router does not hav= e to do IP-in-IP tunneling to forward packets generated by a host. Thanks Mukul ----- Original Message ----- From: "Don Sturek" To: "Mukul Goyal" , "S=C3bastien Dawans" Cc: roll at ietf.org Sent: Wednesday, November 16, 2011 12:22:55 PM Subject: Re: [Roll] definition of "RPL Domain" Hi Mukul, I guess my view on this is the opposite of yours. I would like to see host-only devices not need to know anything about RPL. Here is why: 1) Code savings. Removing RPL from these host only devices would allow for deployment on smaller footprint devices 2) Battery operated devices. Some host only devices are deployed on non-mains powered devices. It would be nice for these devices to not have to listen for any RPL control messages yet still support transmission into a RPL routing domain. Don From prvs=294de8a4a=mukul@uwm.edu Wed Nov 16 11:58:39 2011 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 5D4D621F8F9D for ; Wed, 16 Nov 2011 11:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 c8YLNU0J3JkD for ; Wed, 16 Nov 2011 11:58:38 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 60D2121F8F97 for ; Wed, 16 Nov 2011 11:58:38 -0800 (PST) Received: from localhost (HELO mta03.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 16 Nov 2011 13:58:37 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E16471FD010; Wed, 16 Nov 2011 13:58:37 -0600 (CST) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbg-L6ExgErR; Wed, 16 Nov 2011 13:58:35 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id C2CF31FD00F; Wed, 16 Nov 2011 13:58:35 -0600 (CST) Date: Wed, 16 Nov 2011 13:58:35 -0600 (CST) From: Mukul Goyal To: Joseph Reddy Message-ID: <940281896.321332.1321473515680.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DBEEF48A@DLEE10.ent.ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] Roll Digest, Vol 46, Issue 21 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 19:58:39 -0000 Hi Joseph I was wondering if you know the overhead (in terms of bytes) for the extra = IPv6 header required for IP-in-IP tunneling? Also, what would be the proces= sing overhead of encapsulation/decapsulation at every hop as a packet (orig= inated by a host) travels to its destination (another host; hence outside t= he RPL instance) I would like two hosts in an LLN to be able to communicate without requirin= g IP-in-IP tunneling. To achieve this goal, it seems that both hosts need t= o be considered part of the RPL instance of their RPL routers. Also, it sho= uld be possible for the routers to add/remove SRH and RPL options on behalf= of their hosts. I understand that IP-in-IP tunneling is required when source/destination is= not in RPL instance. Thanks Mukul ----- Original Message ----- From: "Joseph Reddy" To: roll@ietf.org Sent: Wednesday, November 16, 2011 1:15:30 PM Subject: Re: [Roll] Roll Digest, Vol 46, Issue 21 Hi Mukul, Note that IP-in-IP tunnelling may be necessary even for data packets orgina= ted on the RPL router itself. This is because the destination may be a non-= RPL Host and so the RPL Option header has to be removed before sending the = packet on the final hop.=20 Essentially, a standard IPv6 Host would not necessarily be able to send/re= ceive IPv6 packets through a RPL router unless the RPL router has the addit= ional logic to add the necessary headers ( and also remove the same for pac= kets destinted to the Host ) and perform tunnelling. This behaviour on part= of the RPL router is not mandatory per the RPL spec. I think it should be. -Regards, Joseph ----- Original Message ----- From: "Mukul Goyal" I guess the desired behavior would be: A host sends out a message to its RPL router. The router adds RPL SRH or RP= L option to the IPv6 header and forwards the message further. No need for I= P-in-IP tunneling. Any error message comes back to the router and the route= r handles the message. The host just sends and receives messages. Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "Don Sturek" Cc: roll at ietf.org Sent: Wednesday, November 16, 2011 12:29:59 PM Subject: Re: [Roll] definition of "RPL Domain" Hi Don I dont want hosts to know about RPL. I just want the RPL routers to conside= r the hosts as part of the RPL instance so that the RPL router does not hav= e to do IP-in-IP tunneling to forward packets generated by a host. Thanks Mukul ----- Original Message ----- From: "Don Sturek" To: "Mukul Goyal" , "S=C3=83bastien Dawans" Cc: roll at ietf.org Sent: Wednesday, November 16, 2011 12:22:55 PM Subject: Re: [Roll] definition of "RPL Domain" Hi Mukul, I guess my view on this is the opposite of yours. I would like to see host-only devices not need to know anything about RPL. Here is why: 1) Code savings. Removing RPL from these host only devices would allow for deployment on smaller footprint devices 2) Battery operated devices. Some host only devices are deployed on non-mains powered devices. It would be nice for these devices to not have to listen for any RPL control messages yet still support transmission into a RPL routing domain. Don _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Wed Nov 16 13:38:55 2011 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 11E6B21F8B10 for ; Wed, 16 Nov 2011 13:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReurzSitTXfN for ; Wed, 16 Nov 2011 13:38:49 -0800 (PST) Received: from p01c12o142.mxlogic.net (p01c12o142.mxlogic.net [208.65.145.65]) by ietfa.amsl.com (Postfix) with ESMTP id 229D821F849E for ; Wed, 16 Nov 2011 13:38:49 -0800 (PST) Received: from unknown [216.236.254.3] (EHLO p01c12o142.mxlogic.net) by p01c12o142.mxlogic.net(mxl_mta-6.12.0-1) with ESMTP id 96d24ce4.68b90940.185638.00-525.403344.p01c12o142.mxlogic.net (envelope-from ); Wed, 16 Nov 2011 14:38:49 -0700 (MST) X-MXL-Hash: 4ec42d69174ad68a-4a61d2a5fb7953dff9a15769e8e1f7b7724bc8ed Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c12o142.mxlogic.net(mxl_mta-6.12.0-1) over TLS secured channel with ESMTP id 95d24ce4.0.185571.00-351.403187.p01c12o142.mxlogic.net (envelope-from ); Wed, 16 Nov 2011 14:38:40 -0700 (MST) X-MXL-Hash: 4ec42d6033f15ec0-a02b22a35fb37f18cbae5144f25f3f2d09263612 Received: from kelsey-ws.hq.ember.com (192.168.81.75) by usmail.ember.com (192.168.80.105) with Microsoft SMTP Server id 14.1.339.1; Wed, 16 Nov 2011 16:38:31 -0500 Date: Wed, 16 Nov 2011 16:40:39 -0500 Message-ID: <87d3cr925k.fsf@kelsey-ws.hq.ember.com> To: Mukul Goyal In-Reply-To: <940281896.321332.1321473515680.JavaMail.root@mail17.pantherlink.uwm.edu> (message from Mukul Goyal on Wed, 16 Nov 2011 13:58:35 -0600) From: Richard Kelsey X-Auto-Response-Suppress: DR, OOF, AutoReply References: <940281896.321332.1321473515680.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [192.168.81.75] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=u0NvnAFnSA0A:10 a=Hbe3rpA4rTAA:10 a=saA6nF2ZJa] X-AnalysisOut: [AA:10 a=BLceEmwcHowA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=zW] X-AnalysisOut: [q7x96kCFZls9bLQ2wA:9 a=fZtrXU9g9x9ZFoFYYmcA:7 a=FhKWNwQuJU] X-AnalysisOut: [ON2PoV:21 a=KnVhLg4qz0F3nJfF:21] Cc: roll@ietf.org, jreddy@ti.com Subject: Re: [Roll] definition of "RPL Domain" (was: Re: Roll Digest, Vol 46, Issue 21) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 21:38:55 -0000 > Date: Wed, 16 Nov 2011 13:58:35 -0600 > From: Mukul Goyal > > I was wondering if you know the overhead (in terms of bytes) for the > extra IPv6 header required for IP-in-IP tunneling? The added header is 40 bytes uncompressed. For a one-hop tunnel, 6LoWPAN HC compression squishes the added header down to 2 bytes. In other cases the compressed length depends on how well the source and destination addresses can be compressed. > Also, what would be > the processing overhead of encapsulation/decapsulation at every hop as > a packet (originated by a host) travels to its destination (another > host; hence outside the RPL instance) That depends entirely on how it is implemented. Using 6LoWPAN HC compression the tunnel header always compresses to the same two bytes. The overhead for adding or removing two fixed bytes from the head of a packet can be quite small. > I would like two hosts in an LLN to be able to communicate without > requiring IP-in-IP tunneling. To achieve this goal, it seems that both > hosts need to be considered part of the RPL instance of their RPL > routers. Also, it should be possible for the routers to add/remove SRH > and RPL options on behalf of their hosts. There were strong objections in the 6man group to having a router add or remove option headers from a packet being forwarded. From their point of view, the only way to avoid tunnelling is if the source adds the RPL option and it travels intact to the destination. This requires that the sender, destination, and all intermediate routers implement RPL. -Richard Kelsey From jpv@cisco.com Wed Nov 16 14:01:14 2011 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 E76CA21F90F2 for ; Wed, 16 Nov 2011 14:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.243 X-Spam-Level: X-Spam-Status: No, score=-106.243 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, 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 80z0yDVDog3K for ; Wed, 16 Nov 2011 14:01:08 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B480221F9101 for ; Wed, 16 Nov 2011 14:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=7115; q=dns/txt; s=iport; t=1321480868; x=1322690468; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=NQ5rUlSMShX4DPzsQtH8XSR6Nfh5E6Clh2SjOQzk/pg=; b=f7rZWYGIKkA0DqgqPNYtJlImWctcszJxMuIcuMGqHCcFdteJHNLFv9QX tkO3GSzyafINJU2/seygtdqSPibBmKNQPkFlzxAzql7nxLezb20bsiaHx tcf9/ITVDDm4L9yf350u2BBJZ6FXRimYHMDxoI+kBQM/igV8tKSAZiwEE I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMHAN8xxE6rRDoG/2dsb2JhbABDJoInpzaBBYFyAQEBAwEBAQEPATYlCwULC0YnMAYTFAYBB4dgCJo9AZ5hiTRjBJQ0hTsJjDg X-IronPort-AV: E=Sophos;i="4.69,523,1315180800"; d="scan'208,217";a="12943983" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 16 Nov 2011 22:01:00 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAGM10wL028943; Wed, 16 Nov 2011 22:01:00 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 14:01:00 -0800 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 14:00:59 -0800 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D451C1D-4F02-4ADC-8675-FB68D61B42C5" From: JP Vasseur In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214103767C1B@ftrdmel0.rd.francetelecom.fr> Date: Wed, 16 Nov 2011 17:14:43 +0000 Message-Id: <7C3B5C63-24B3-4532-9B04-4FFECCCE6351@cisco.com> References: <9ECCF01B52E7AB408A7EB8535264214103767C1B@ftrdmel0.rd.francetelecom.fr> To: "" X-Mailer: Apple Mail (2.1251.1) X-OriginalArrivalTime: 16 Nov 2011 22:00:59.0423 (UTC) FILETIME=[39472AF0:01CCA4AB] Cc: roll@ietf.org Subject: Re: [Roll] RPL is a great achievement for the WAVE2M Community X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 22:01:15 -0000 --Apple-Mail=_1D451C1D-4F02-4ADC-8675-FB68D61B42C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks, knowing that IETF protocols have been selected by other = Standardization Bodies / Alliances is always very much appreciated.=20 This WG has been working hard to deliver RPL over the past 2+ years, do = not hesitate to share any feed-back on this mailing list. Thanks again for the great news. JP. On Nov 11, 2011, at 2:48 PM, = wrote: > Dear Working Group, > =20 > We would like to let you know that the WAVE2M Community (formerly = names Wavenis Open Standard Alliance), that is defining very low-powered = radio networking solutions for the smart metering market where = constrained LLN (e.g. battery operated devices) are operating, has = decided to select RPL as their protocol of choice, after careful = technical considerations. > Since the beginning we have been following the work of this WG and = some of our members contributed to the RFC 5548 which was reflecting = pretty well our requirements. > Thanks to this WG for having specified this routing protocol, a great = achievement for the Internet of Things. > =20 > Gabriel Chegaray > Orange Labs, > President of the WAVE2M Community > www.wave2m.org > =20 > =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_1D451C1D-4F02-4ADC-8675-FB68D61B42C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks, knowing that IETF protocols have been = selected by other Standardization Bodies / Alliances is always very = much appreciated. 
This WG has been working hard to deliver RPL = over the past 2+ years, do not hesitate to share any feed-back on = this mailing list.

Thanks again for the great = news.

JP.


Dear = Working Group,
 
We would like to let you know that the WAVE2M Community = (formerly names Wavenis Open Standard Alliance), that is defining very = low-powered radio networking solutions for the smart metering market = where constrained LLN (e.g. battery operated devices) are operating, has = decided to select RPL as their protocol of choice, after careful = technical considerations.
Since the beginning we have been following the work of = this WG and some of our members contributed to the RFC 5548 which was = reflecting pretty well our requirements.
Thanks to this WG for having = specified this routing protocol, a great achievement for the Internet of = Things.
 
Gabriel Chegaray Subject: Re: [Roll] Hosts part of the RPL instance? Re: definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 00:59:05 -0000 My 2cts on the various terminology discussions: - An "RPL host" seems contradictory to me. Either it is a host, in which cas= e it does not know anything about RPL, or it is an RPL router (leaf node or n= ot, it still remains a router). We should allow for hosts (or be prepared to= fight with the IAB for the next years why we think that we should break the= IP architecture). - A question that comes to my mind: Is it specified anywhere how to add the R= PL IP headers for the traffic direction to a data packet from a host receive= d by an RPL router? - "RPL domain"; We should just stick to official terminology, i.e, "Routing D= omain" in this case. I think it has been specified in RFC1136. - RPL traffic: I don't like the term. I would stick to either control traffi= c or data traffic. Everyone understands these terms. No need to invent new t= erms. Regards Ulrich On Nov 17, 2011, at 2:38, Mukul Goyal wrote: > I guess the desired behavior would be: >=20 > A host sends out a message to its RPL router. The router adds RPL SRH or R= PL option to the IPv6 header and forwards the message further. No need for I= P-in-IP tunneling. Any error message comes back to the router and the router= handles the message. The host just sends and receives messages. >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Mukul Goyal" > To: "Don Sturek" > Cc: roll@ietf.org > Sent: Wednesday, November 16, 2011 12:29:59 PM > Subject: Re: [Roll] definition of "RPL Domain" >=20 > Hi Don >=20 > I dont want hosts to know about RPL. I just want the RPL routers to consid= er the hosts as part of the RPL instance so that the RPL router does not hav= e to do IP-in-IP tunneling to forward packets generated by a host. >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Don Sturek" > To: "Mukul Goyal" , "S=C3=A9bastien Dawans" > Cc: roll@ietf.org > Sent: Wednesday, November 16, 2011 12:22:55 PM > Subject: Re: [Roll] definition of "RPL Domain" >=20 > Hi Mukul, >=20 > I guess my view on this is the opposite of yours. I would like to see > host-only devices not need to know anything about RPL. Here is why: > 1) Code savings. Removing RPL from these host only devices would allow > for deployment on smaller footprint devices > 2) Battery operated devices. Some host only devices are deployed on > non-mains powered devices. It would be nice for these devices to not have= > to listen for any RPL control messages yet still support transmission into= > a RPL routing domain. >=20 > Don >=20 >=20 >=20 > On 11/16/11 10:07 AM, "Mukul Goyal" wrote: >=20 >> Hi Sebastien >>=20 >> First, I would like to clarify that the need to define "RPL domain" arose= >> because draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header= >> were using the term. Now, these drafts use the term "RPL instance" and >> hence there is no real need to define the term "RPL domain" any more. I >> will change draft-ietf-roll-p2p-measurement so that all references to >> "RPL domain" are changed to "RPL Instance". >>=20 >> Now returning to the question whether hosts should be considered part of >> the RPL Instance, the benefit of doing so is that there is no need to use= >> IP-in-IP tunneling when a host sends out some data. If a host is not >> considered part of the RPL Instance, its default RPL router is obliged to= >> use IP-in-IP tunneling to forward the packet further. IP-in-IP tunneling >> means an extra IPv6 header and thus less space for payload if you want to= >> avoid fragmentation. Also, if the packet is traveling along a DAG, the >> encapsulation/decapsulation needs to be done at every hop, which sounds >> fairly heavy duty processing to me. >>=20 >> So, I would like to explore if there is a way we could consider hosts to >> be a part of the RPL Instance. >>=20 >> Regards, >> Mukul >>=20 >>> On what ground would you assume that a non-RPL aware host connected to a= >>> RPL-router (in this case I would call it a border router) is in a/the >>> RPL Domain? >>=20 >>> =46rom what I've seen in the drafts, the term "RPL Domain"'s primary >>> purpose it to differentiate the limits of "RPL-aware" nodes for IP >>> traffic that needs to transit to or from a set of RPL-aware hosts (for >>> example, to define where to add/remove the RPL IPv6 Hop-by-Hop Option if= >>> used). >>=20 >>> To me, this interpretation of RPL Domain is thus only useful in a local >>> context and not to meant to designate one or more bounded set of nodes. >>> That's the role of DODAGs and Instances. >>=20 >>> Best Regards, >>=20 >>> S=C3=A9bastien Dawans >>=20 >> On 11/16/2011 02:20 PM, Mukul Goyal wrote: >>> So, the revised doubts are as follows: >>>=20 >>> 1. It is clear that RPL routers are within an RPL domain but what about >>> the RPL-unaware IPv6 hosts attached to an RPL router? I would imagine >>> that such hosts are also within an RPL domain. >>>=20 >>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set >>> of RPL instances in the LLN? Can multiple RPL domains exist within an >>> LLN? Or is it that an RPL domain is same as an LLN using RPL as a >>> routing protocol? >>>=20 >>> THanks >>> Mukul >>>=20 >>> ----- Original Message ----- >>> From: "Mukul Goyal" >>> To: "Thomas Heide Clausen" >>> Cc: "roll" >>> Sent: Wednesday, November 16, 2011 7:15:59 AM >>> Subject: Re: [Roll] definition of "RPL Domain" >>>=20 >>>=20 >>>> Now that we are at it: what is an RPL host? Or rather, why is this >>>> even a conceivable thing to define? Afaik, RPL is a routing protocol, >>>> and as such should concern only routers - not hosts? >>>>=20 >>> My bad. By RPL host, I actually meant an RPL leaf node. I think this >>> term "RPL host" was in use at one point in time but I cant find a >>> reference to it in current spec. >>>=20 >>> THanks >>> Mukul >>>=20 >>>=20 >>>=20 >>> ----- Original Message ----- >>> From: "Thomas Heide Clausen" >>> To: "Mukul Goyal" >>> Cc: "JP Vasseur", "roll" >>> Sent: Wednesday, November 16, 2011 6:25:31 AM >>> Subject: Re: [Roll] definition of "RPL Domain" >>>=20 >>> Now that we are at it: what is an RPL host? Or rather, why is this even >>> a conceivable thing to define? Afaik, RPL is a routing protocol, and as >>> such should concern only routers - not hosts? >>>=20 >>> I worry if this is inventing an entire ecosystem which "pretends to be >>> just like the Internet, except it is not", as it needs entirely new >>> stacks, protocols, translators/gateways everywhere, and with no real >>> traces of IP as we know it remaining? >>>=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 >=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 cabo@tzi.org Wed Nov 16 18:56:20 2011 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 2660B1F0CA1; Wed, 16 Nov 2011 18:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAYmV0ND6fQI; Wed, 16 Nov 2011 18:56:19 -0800 (PST) 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 14AC51F0C8D; Wed, 16 Nov 2011 18:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pAH2u990017121; Thu, 17 Nov 2011 03:56:09 +0100 (CET) Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 46DBC999; Thu, 17 Nov 2011 03:56:06 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> Date: Thu, 17 Nov 2011 10:56:02 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <49940D6A-23D5-4EF9-A328-E4C5F81F3A36@tzi.org> References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> To: 6lowpan <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1251.1) Cc: lwip@ietf.org, roll@ietf.org, core WG Subject: Re: [Roll] [6lowpan] Cross-layer issues in Constrained Node/Networks: informal get-together X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: 6lowpan <6lowpan@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, 17 Nov 2011 02:56:20 -0000 On Nov 15, 2011, at 13:42, Carsten Bormann wrote: > We are going to have an informal get-together to discuss some of these > issues at >=20 > Thu, 1740-1940, room 102 I have started collecting slides for this event. We don't need slides to discuss something, but where they help, I would = like to have them before the meeting. Observe*) the current set of slides at http://www.tzi.org/~cabo/cross-layer.pdf Gr=FC=DFe, Carsten *) Sorry, no CoAP server there yet=85 Manual repeated HTTP GET = required. From prvs=29562bbfa=mukul@uwm.edu Wed Nov 16 19:47:21 2011 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 D216D11E80D1 for ; Wed, 16 Nov 2011 19:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 Lhy-wYGiImME for ; Wed, 16 Nov 2011 19:47:21 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6A811E80B3 for ; Wed, 16 Nov 2011 19:47:21 -0800 (PST) Received: from localhost (HELO mta03.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 16 Nov 2011 21:47:09 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 7FBF81FD010; Wed, 16 Nov 2011 21:47:09 -0600 (CST) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aknoEiD-PazF; Wed, 16 Nov 2011 21:47:09 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 2B1C31FD00F; Wed, 16 Nov 2011 21:47:09 -0600 (CST) Date: Wed, 16 Nov 2011 21:47:09 -0600 (CST) From: Mukul Goyal To: Richard Kelsey Message-ID: <1168571116.328560.1321501629065.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <87d3cr925k.fsf@kelsey-ws.hq.ember.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org, jreddy@ti.com Subject: Re: [Roll] definition of "RPL Domain" (was: Re: Roll Digest, Vol 46, Issue 21) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 03:47:22 -0000 Hi Richard I was wondering if you could summarize what were the main objections to having a router add/remove optional headers in a packet generated by a host attached to the router. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: "Mukul Goyal" Cc: jreddy@ti.com, roll@ietf.org Sent: Wednesday, November 16, 2011 3:40:39 PM Subject: Re: [Roll] definition of "RPL Domain" (was: Re: [Roll] Roll Digest, Vol 46, Issue 21) > Date: Wed, 16 Nov 2011 13:58:35 -0600 > From: Mukul Goyal > > I was wondering if you know the overhead (in terms of bytes) for the > extra IPv6 header required for IP-in-IP tunneling? The added header is 40 bytes uncompressed. For a one-hop tunnel, 6LoWPAN HC compression squishes the added header down to 2 bytes. In other cases the compressed length depends on how well the source and destination addresses can be compressed. > Also, what would be > the processing overhead of encapsulation/decapsulation at every hop as > a packet (originated by a host) travels to its destination (another > host; hence outside the RPL instance) That depends entirely on how it is implemented. Using 6LoWPAN HC compression the tunnel header always compresses to the same two bytes. The overhead for adding or removing two fixed bytes from the head of a packet can be quite small. > I would like two hosts in an LLN to be able to communicate without > requiring IP-in-IP tunneling. To achieve this goal, it seems that both > hosts need to be considered part of the RPL instance of their RPL > routers. Also, it should be possible for the routers to add/remove SRH > and RPL options on behalf of their hosts. There were strong objections in the 6man group to having a router add or remove option headers from a packet being forwarded. From their point of view, the only way to avoid tunnelling is if the source adds the RPL option and it travels intact to the destination. This requires that the sender, destination, and all intermediate routers implement RPL. -Richard Kelsey From ietf@thomasclausen.org Wed Nov 16 23:38:08 2011 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 9836E11E8117 for ; Wed, 16 Nov 2011 23:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 e-r2qQcPFIPX for ; Wed, 16 Nov 2011 23:38:08 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 22D2311E8114 for ; Wed, 16 Nov 2011 23:38:08 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 896BACCFE1 for ; Wed, 16 Nov 2011 23:38:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D7FF92017DC; Wed, 16 Nov 2011 23:38:05 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.1.240] (unknown [203.69.99.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 6BE8B2017D7; Wed, 16 Nov 2011 23:38:05 -0800 (PST) References: <1168571116.328560.1321501629065.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1168571116.328560.1321501629065.JavaMail.root@mail17.pantherlink.uwm.edu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9054DD86-0957-4A58-B978-D253A7FAD239@thomasclausen.org> X-Mailer: iPhone Mail (9A334) From: Thomas Heide Clausen Date: Thu, 17 Nov 2011 15:37:45 +0800 To: Mukul Goyal Cc: "roll@ietf.org" , "jreddy@ti.com" Subject: Re: [Roll] definition of "RPL Domain" (was: Re: Roll Digest, Vol 46, Issue 21) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 07:38:08 -0000 Mukul, +1 to your question.=20 The crux for me here is, that a non-routing-protocol-aware, non-LLN-aware ho= st can be "hung off an LLN router", and be reachable and reach across the LL= N. If there's a need for "LLN magic" headers etc., then only the LLN routers= should need to be aware of and do that, while the hosts and host apps shoul= d be able to remain ignorant.=20 If we agree on the above, and if that becomes true, then I think we reached a= position on getting rid of "RPL leaf router" and "RPL Host" and "RPL Traffi= c" as concepts and terms, also? Best, Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 On 17 nov. 2011, at 11:47, Mukul Goyal wrote: > Hi Richard >=20 > I was wondering if you could summarize what were the main objections to ha= ving a router add/remove optional headers in a packet generated by a host at= tached to the router. >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Richard Kelsey" > To: "Mukul Goyal" > Cc: jreddy@ti.com, roll@ietf.org > Sent: Wednesday, November 16, 2011 3:40:39 PM > Subject: Re: [Roll] definition of "RPL Domain" (was: Re: [Roll] Roll Diges= t, Vol 46, Issue 21) >=20 >> Date: Wed, 16 Nov 2011 13:58:35 -0600 >> From: Mukul Goyal >>=20 >> I was wondering if you know the overhead (in terms of bytes) for the >> extra IPv6 header required for IP-in-IP tunneling? >=20 > The added header is 40 bytes uncompressed. For a one-hop > tunnel, 6LoWPAN HC compression squishes the added header > down to 2 bytes. In other cases the compressed length > depends on how well the source and destination addresses > can be compressed. >=20 >> Also, what would be >> the processing overhead of encapsulation/decapsulation at every hop as >> a packet (originated by a host) travels to its destination (another >> host; hence outside the RPL instance) >=20 > That depends entirely on how it is implemented. Using > 6LoWPAN HC compression the tunnel header always compresses > to the same two bytes. The overhead for adding or removing > two fixed bytes from the head of a packet can be quite > small. >=20 >> I would like two hosts in an LLN to be able to communicate without >> requiring IP-in-IP tunneling. To achieve this goal, it seems that both >> hosts need to be considered part of the RPL instance of their RPL >> routers. Also, it should be possible for the routers to add/remove SRH >> and RPL options on behalf of their hosts. >=20 > There were strong objections in the 6man group to having a > router add or remove option headers from a packet being > forwarded. =46rom their point of view, the only way to avoid > tunnelling is if the source adds the RPL option and it > travels intact to the destination. This requires that the > sender, destination, and all intermediate routers implement > RPL. > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Thu Nov 17 06:54:28 2011 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 0D8AA21F9A1F for ; Thu, 17 Nov 2011 06:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L89of1utf62L for ; Thu, 17 Nov 2011 06:54:27 -0800 (PST) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAC621F9A1A for ; Thu, 17 Nov 2011 06:54:27 -0800 (PST) Received: from unknown [216.236.254.3] (EHLO p01c11o149.mxlogic.net) by p01c11o149.mxlogic.net(mxl_mta-6.12.0-1) with ESMTP id 32025ce4.7292a940.63576.00-577.133867.p01c11o149.mxlogic.net (envelope-from ); Thu, 17 Nov 2011 07:54:27 -0700 (MST) X-MXL-Hash: 4ec520235a674e6d-e2fa0646fc4b7d4dd90adce466adc833a9882adb Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c11o149.mxlogic.net(mxl_mta-6.12.0-1) over TLS secured channel with ESMTP id c1025ce4.0.63527.00-310.133746.p01c11o149.mxlogic.net (envelope-from ); Thu, 17 Nov 2011 07:54:26 -0700 (MST) X-MXL-Hash: 4ec5202218caaac8-b79119f505aca8c2f54ea580ce8e9c1f0309bf0a Received: from kelsey-ws.hq.ember.com (192.168.81.75) by usmail.ember.com (192.168.80.105) with Microsoft SMTP Server id 14.1.339.1; Thu, 17 Nov 2011 09:54:17 -0500 Date: Thu, 17 Nov 2011 09:56:27 -0500 Message-ID: <8762iivlus.fsf@kelsey-ws.hq.ember.com> To: Mukul Goyal In-Reply-To: <1168571116.328560.1321501629065.JavaMail.root@mail17.pantherlink.uwm.edu> (message from Mukul Goyal on Wed, 16 Nov 2011 21:47:09 -0600) From: Richard Kelsey X-Auto-Response-Suppress: DR, OOF, AutoReply References: <1168571116.328560.1321501629065.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [192.168.81.75] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=u0NvnAFnSA0A:10 a=1ni4KNbD3OAA:10 a=saA6nF2ZJa] X-AnalysisOut: [AA:10 a=BLceEmwcHowA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=kJMgbaQVJ4rLu7h7XQUA:9 a=MbCiOnaYwjix-ENAs6] X-AnalysisOut: [4A:7 a=P-82xo5BOEAA:10 a=kL_PztIh1bUA:10] Cc: roll@ietf.org, jreddy@ti.com Subject: Re: [Roll] definition of "RPL Domain" (was: Re: Roll Digest, Vol 46, Issue 21) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 14:54:28 -0000 > Date: Wed, 16 Nov 2011 21:47:09 -0600 > From: Mukul Goyal > > I was wondering if you could summarize what were the main objections > to having a router add/remove optional headers in a packet generated > by a host attached to the router. Mukul, Disclaimer: I am not an expert on this stuff and did not participate in the discussion within the 6man group. The main concern is MTU issues. If the source sends a message that fits within the path MTU, but an intermediate router adds an optional header that makes the packet too large to fit, things may fall apart. This message: http://www.ietf.org/mail-archive/web/ipv6/current/msg14805.html contains the discussion on this between Jari Arkko, the AD who reviewed the RPL option and routing header drafts, and Jonathan Hui, one of the authors. Jari Arkko did acknowledge that there may be circumstances where the tunnelling is not needed and the RPL option could be added by a forwarding router, but that would require a another draft that explained in detail how it would all work. Personally, I am happy with the one-hop tunnels. They introduce no new routing complications, only some packet overhead. When using 6LoWPAN HC compression they add just two bytes to the packet. Even those two bytes could be removed by getting a new 6LoWPAN dispatch byte that indicated that the packet began with a one-hop tunnel header followed by a RPL option. I believe that would make the compressed packet the same size as if the router had added the RPL option after the existing header. -Richard Kelsey From yvonne-anne.pignolet@ch.abb.com Thu Nov 17 08:13:45 2011 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 0C3C911E80D3 for ; Thu, 17 Nov 2011 08:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHLjkWx3hoxI for ; Thu, 17 Nov 2011 08:13:43 -0800 (PST) Received: from nse3.abb.com (nse3.abb.com [129.35.204.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0805E21F99BB for ; Thu, 17 Nov 2011 08:13:42 -0800 (PST) Received: from mail04.ch.abb.com (ch-s-0001322.ch.abb.com [138.223.3.121]) by nse3.abb.com (8.13.8/8.13.8) with ESMTP id pAHGDdKJ016988; Thu, 17 Nov 2011 17:13:39 +0100 In-Reply-To: References: <1373977554.319419.1321468695445.JavaMail.root@mail17.pantherlink.uwm.edu> To: Ulrich Herberg MIME-Version: 1.0 X-KeepSent: 59E01DF3:39B7D452-C125794B:0058F5AB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 FP1 January 06, 2010 From: Yvonne-Anne Pignolet Message-ID: Date: Thu, 17 Nov 2011 17:13:38 +0100 X-MIMETrack: Serialize by Router on MAIL04.CH.ABB.COM/SRV/ABB(Release 8.5.2FP3 HF8|July 20, 2011) at 17.11.2011 17:13:40, Serialize complete at 17.11.2011 17:13:40 Content-Type: multipart/related; boundary="=_related 0059222EC125794B_=" Cc: roll@ietf.org Subject: Re: [Roll] Hosts part of the RPL instance? Re: definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 16:13:45 -0000 This is a multipart message in MIME format. --=_related 0059222EC125794B_= Content-Type: multipart/alternative; boundary="=_alternative 0059222EC125794B_=" --=_alternative 0059222EC125794B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I fully agree with Ulrich Yvonne-Anne Pignolet Dr. Sc. ETH ABB Schweiz AG Segelhofstrasse 1K 5400 Baden-D=E4ttwil, Switzerland Phone: +41 58 586 86 56 Mobile: +41 79 766 10 54 email: yvonne-anne.pignolet@ch.abb.com roll-bounces@ietf.org wrote on 17.11.2011 02:00:06: > From: Ulrich Herberg > To: Mukul Goyal > Cc: "roll@ietf.org" > Date: 17.11.2011 01:59 > Subject: Re: [Roll] Hosts part of the RPL instance? Re: definition=20 > of "RPL Domain" > Sent by: roll-bounces@ietf.org >=20 > My 2cts on the various terminology discussions: >=20 > - An "RPL host" seems contradictory to me. Either it is a host, in=20 > which case it does not know anything about RPL, or it is an RPL=20 > router (leaf node or not, it still remains a router). We should=20 > allow for hosts (or be prepared to fight with the IAB for the next=20 > years why we think that we should break the IP architecture). >=20 > - A question that comes to my mind: Is it specified anywhere how to=20 > add the RPL IP headers for the traffic direction to a data packet=20 > from a host received by an RPL router? >=20 > - "RPL domain"; We should just stick to official terminology, i.e,=20 > "Routing Domain" in this case. I think it has been specified in RFC1136. >=20 > - RPL traffic: I don't like the term. I would stick to either=20 > control traffic or data traffic. Everyone understands these terms.=20 > No need to invent new terms. >=20 > Regards > Ulrich >=20 > On Nov 17, 2011, at 2:38, Mukul Goyal wrote: >=20 > > I guess the desired behavior would be: > >=20 > > A host sends out a message to its RPL router. The router adds RPL=20 > SRH or RPL option to the IPv6 header and forwards the message=20 > further. No need for IP-in-IP tunneling. Any error message comes=20 > back to the router and the router handles the message. The host just > sends and receives messages. > >=20 > > Thanks > > Mukul > >=20 > > ----- Original Message ----- > > From: "Mukul Goyal" > > To: "Don Sturek" > > Cc: roll@ietf.org > > Sent: Wednesday, November 16, 2011 12:29:59 PM > > Subject: Re: [Roll] definition of "RPL Domain" > >=20 > > Hi Don > >=20 > > I dont want hosts to know about RPL. I just want the RPL routers=20 > to consider the hosts as part of the RPL instance so that the RPL=20 > router does not have to do IP-in-IP tunneling to forward packets=20 > generated by a host. > >=20 > > Thanks > > Mukul > >=20 > > ----- Original Message ----- > > From: "Don Sturek" > > To: "Mukul Goyal" , "S=E9bastien Dawans"=20 > > > Cc: roll@ietf.org > > Sent: Wednesday, November 16, 2011 12:22:55 PM > > Subject: Re: [Roll] definition of "RPL Domain" > >=20 > > Hi Mukul, > >=20 > > I guess my view on this is the opposite of yours. I would like to see > > host-only devices not need to know anything about RPL. Here is why: > > 1) Code savings. Removing RPL from these host only devices would=20 allow > > for deployment on smaller footprint devices > > 2) Battery operated devices. Some host only devices are deployed on > > non-mains powered devices. It would be nice for these devices to not=20 have > > to listen for any RPL control messages yet still support transmission=20 into > > a RPL routing domain. > >=20 > > Don > >=20 > >=20 > >=20 > > On 11/16/11 10:07 AM, "Mukul Goyal" wrote: > >=20 > >> Hi Sebastien > >>=20 > >> First, I would like to clarify that the need to define "RPL domain"=20 arose > >> because draft-ietf-6man-rpl-option and=20 draft-ietf-6man-rpl-routing-header > >> were using the term. Now, these drafts use the term "RPL instance"=20 and > >> hence there is no real need to define the term "RPL domain" any more. = I > >> will change draft-ietf-roll-p2p-measurement so that all references to > >> "RPL domain" are changed to "RPL Instance". > >>=20 > >> Now returning to the question whether hosts should be considered part = of > >> the RPL Instance, the benefit of doing so is that there is no need to = use > >> IP-in-IP tunneling when a host sends out some data. If a host is not > >> considered part of the RPL Instance, its default RPL router is=20 obliged to > >> use IP-in-IP tunneling to forward the packet further. IP-in-IP=20 tunneling > >> means an extra IPv6 header and thus less space for payload if you=20 want to > >> avoid fragmentation. Also, if the packet is traveling along a DAG,=20 the > >> encapsulation/decapsulation needs to be done at every hop, which=20 sounds > >> fairly heavy duty processing to me. > >>=20 > >> So, I would like to explore if there is a way we could consider hosts = to > >> be a part of the RPL Instance. > >>=20 > >> Regards, > >> Mukul > >>=20 > >>> On what ground would you assume that a non-RPL aware host connected=20 to a > >>> RPL-router (in this case I would call it a border router) is in=20 a/the > >>> RPL Domain? > >>=20 > >>> From what I've seen in the drafts, the term "RPL Domain"'s primary > >>> purpose it to differentiate the limits of "RPL-aware" nodes for IP > >>> traffic that needs to transit to or from a set of RPL-aware hosts=20 (for > >>> example, to define where to add/remove the RPL IPv6 Hop-by-Hop=20 Option if > >>> used). > >>=20 > >>> To me, this interpretation of RPL Domain is thus only useful in a=20 local > >>> context and not to meant to designate one or more bounded set of=20 nodes. > >>> That's the role of DODAGs and Instances. > >>=20 > >>> Best Regards, > >>=20 > >>> S=E9bastien Dawans > >>=20 > >> On 11/16/2011 02:20 PM, Mukul Goyal wrote: > >>> So, the revised doubts are as follows: > >>>=20 > >>> 1. It is clear that RPL routers are within an RPL domain but what=20 about > >>> the RPL-unaware IPv6 hosts attached to an RPL router? I would=20 imagine > >>> that such hosts are also within an RPL domain. > >>>=20 > >>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a=20 set > >>> of RPL instances in the LLN? Can multiple RPL domains exist within=20 an > >>> LLN? Or is it that an RPL domain is same as an LLN using RPL as a > >>> routing protocol? > >>>=20 > >>> THanks > >>> Mukul > >>>=20 > >>> ----- Original Message ----- > >>> From: "Mukul Goyal" > >>> To: "Thomas Heide Clausen" > >>> Cc: "roll" > >>> Sent: Wednesday, November 16, 2011 7:15:59 AM > >>> Subject: Re: [Roll] definition of "RPL Domain" > >>>=20 > >>>=20 > >>>> Now that we are at it: what is an RPL host? Or rather, why is this > >>>> even a conceivable thing to define? Afaik, RPL is a routing=20 protocol, > >>>> and as such should concern only routers - not hosts? > >>>>=20 > >>> My bad. By RPL host, I actually meant an RPL leaf node. I think this > >>> term "RPL host" was in use at one point in time but I cant find a > >>> reference to it in current spec. > >>>=20 > >>> THanks > >>> Mukul > >>>=20 > >>>=20 > >>>=20 > >>> ----- Original Message ----- > >>> From: "Thomas Heide Clausen" > >>> To: "Mukul Goyal" > >>> Cc: "JP Vasseur", "roll" > >>> Sent: Wednesday, November 16, 2011 6:25:31 AM > >>> Subject: Re: [Roll] definition of "RPL Domain" > >>>=20 > >>> Now that we are at it: what is an RPL host? Or rather, why is this=20 even > >>> a conceivable thing to define? Afaik, RPL is a routing protocol, and = as > >>> such should concern only routers - not hosts? > >>>=20 > >>> I worry if this is inventing an entire ecosystem which "pretends to=20 be > >>> just like the Internet, except it is not", as it needs entirely new > >>> stacks, protocols, translators/gateways everywhere, and with no real > >>> traces of IP as we know it remaining? > >>>=20 > >>>=20 > >>=20 > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > >=20 > >=20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=_alternative 0059222EC125794B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I fully agree with Ulrich
Yvonne-Anne Pignolet
Dr. Sc. ETH
ABB Schweiz AG
Segelhofstrasse 1K
5400 Baden-D=E4ttwil, Switzerland
Phone: +41 58 586 86 56
Mobile: +41 79 766 10 54
email: yvonne-anne.pignolet@ch.abb.com



roll-bounces@ietf.org wrote on 17.11.2011 02:00:06:<= br>
> From: Ulrich Herberg <ulrich@herberg.name>
> To: Mukul Goyal <mukul@uwm.edu>
> Cc: "roll@ietf.org" <roll@ietf.org= >
> Date: 17.11.2011 01:59
> Subject: Re: [Roll] Hosts part of the RPL insta= nce? Re: definition
> of "RPL Domain"
> Sent by: roll-bounces@ietf.org
>
> My 2cts on the various terminology discussions:
>
> - An "RPL host" seems contradictory to me. Either it is a host, in
> which case it does not know anything about RPL, or it is an RPL
> router (leaf node or not, it still remains a router). We should
> allow for hosts (or be prepared to fight with the IAB for the next
> years why we think that we should break the IP architecture).
>
> - A question that comes to my mind: Is it specified anywhere how to
> add the RPL IP headers for the traffic direction to a data packet
> from a host received by an RPL router?
>
> - "RPL domain"; We should just stick to official terminology, i.e,
> "Routing Domain" in this case. I think it has been specified in RFC1136.
>
> - RPL traffic: I don't like the term. I would stick to either
> control traffic or data traffic. Everyone understands these terms.
> No need to invent new terms.
>
> Regards
> Ulrich
>
> On Nov 17, 2011, at 2:38, Mukul Goyal <mukul@uwm.edu> wrote:
>
> > I guess the desired behavior would be:
> >
> > A host sends out a message to its RPL router. The router adds RPL
> SRH or RPL option to the IPv6 header and forwards the message
> further. No need for IP-in-IP tunneling. Any error message comes
> back to the router and the router handles the message. The host just > sends and receives messages.
> >
> > Thanks
> > Mukul
> >
> > ----- Original Message -----
> > From: "Mukul Goyal" <mukul@uwm.edu>
> > To: "Don Sturek" <d.sturek@att.net>
> > Cc: roll@ietf.org
> > Sent: Wednesday, November 16, 2011 12:29:59 PM
> > Subject: Re: [Roll] definition of "RPL Domain"
> >
> > Hi Don
> >
> > I dont want hosts to know about RPL. I just want the RPL routers
> to consider the hosts as part of the RPL instance so that the RPL
> router does not have to do IP-in-IP tunneling to forward packets
> generated by a host.
> >
> > Thanks
> > Mukul
> >
> > ----- Original Message -----
> > From: "Don Sturek" <d.sturek@att.net>
> > To: "Mukul Goyal" <mukul@uwm.edu>, "S=E9bast= ien Dawans"
> <sebastien.dawans@cetic.be>
> > Cc: roll@ietf.org
> > Sent: Wednesday, November 16, 2011 12:22:55 PM
> > Subject: Re: [Roll] definition of "RPL Domain"
> >
> > Hi Mukul,
> >
> > I guess my view on this is the opposite of yours.  I would like to see
> > host-only devices not need to know anything about RPL.  Here is why:
> > 1)  Code savings.   Removing RPL from these host only devices would allow
> > for deployment on smaller footprint devices
> > 2)  Battery operated devices.   Some host only devices are deployed on
> > non-mains powered devices.  It would be nice for these devic= es to not have
> > to listen for any RPL control messages yet still support transmis= sion into
> > a RPL routing domain.
> >
> > Don
> >
> >
> >
> > On 11/16/11 10:07 AM, "Mukul Goyal" <mukul@uwm.edu&g= t; wrote:
> >
> >> Hi Sebastien
> >>
> >> First, I would like to clarify that the need to define "= RPL domain" arose
> >> because draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-ro= uting-header
> >> were using the term. Now, these drafts use the term "RPL instance" and
> >> hence there is no real need to define the term "RPL domain" any more. I
> >> will change draft-ietf-roll-p2p-measurement so that all refer= ences to
> >> "RPL domain" are changed to "RPL Instance"= ;.
> >>
> >> Now returning to the question whether hosts should be conside= red part of
> >> the RPL Instance, the benefit of doing so is that there is no need to use
> >> IP-in-IP tunneling when a host sends out some data. If a host is not
> >> considered part of the RPL Instance, its default RPL router is obliged to
> >> use IP-in-IP tunneling to forward the packet further. IP-in-IP tunneling
> >> means an extra IPv6 header and thus less space for payload if you want to
> >> avoid fragmentation. Also, if the packet is traveling along a DAG, the
> >> encapsulation/decapsulation needs to be done at every hop, which sounds
> >> fairly heavy duty processing to me.
> >>
> >> So, I would like to explore if there is a way we could consid= er hosts to
> >> be a part of the RPL Instance.
> >>
> >> Regards,
> >> Mukul
> >>
> >>> On what ground would you assume that a non-RPL aware host connected to a
> >>> RPL-router (in this case I would call it a border router) is in a/the
> >>> RPL Domain?
> >>
> >>> From what I've seen in the drafts, the term "RPL Domain"'s primary
> >>> purpose it to differentiate the limits of "RPL-aware= " nodes for IP
> >>> traffic that needs to transit to or from a set of RPL-awa= re hosts (for
> >>> example, to define where to add/remove the RPL IPv6 Hop-b= y-Hop Option if
> >>> used).
> >>
> >>> To me, this interpretation of RPL Domain is thus only useful in a local
> >>> context and not to meant to designate one or more bounded set of nodes.
> >>> That's the role of DODAGs and Instances.
> >>
> >>> Best Regards,
> >>
> >>> S=E9bastien Dawans
> >>
> >> On 11/16/2011 02:20 PM, Mukul Goyal wrote:
> >>> So, the revised doubts are as follows:
> >>>
> >>> 1. It is clear that RPL routers are within an RPL domain but what about
> >>> the RPL-unaware IPv6 hosts attached to an RPL router? I would imagine
> >>> that such hosts are also within an RPL domain.
> >>>
> >>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set
> >>> of RPL instances in the LLN? Can multiple RPL domains exist within an
> >>> LLN? Or is it that an RPL domain is same as an LLN using RPL as a
> >>> routing protocol?
> >>>
> >>> THanks
> >>> Mukul
> >>>
> >>> ----- Original Message -----
> >>> From: "Mukul Goyal"<mukul@uwm.edu>
> >>> To: "Thomas Heide Clausen"<thomas@thomasclau= sen.org>
> >>> Cc: "roll"<roll@ietf.org>
> >>> Sent: Wednesday, November 16, 2011 7:15:59 AM
> >>> Subject: Re: [Roll] definition of "RPL Domain"<= br> > >>>
> >>>
> >>>> Now that we are at it: what is an RPL host? Or rather, why is this
> >>>> even a conceivable thing to define? Afaik, RPL is a routing protocol,
> >>>> and as such should concern only routers - not hosts?<= br> > >>>>
> >>> My bad. By RPL host, I actually meant an RPL leaf node. I think this
> >>> term "RPL host" was in use at one point in time but I cant find a
> >>> reference to it in current spec.
> >>>
> >>> THanks
> >>> Mukul
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>> From: "Thomas Heide Clausen"<thomas@thomascl= ausen.org>
> >>> To: "Mukul Goyal"<mukul@uwm.edu>
> >>> Cc: "JP Vasseur"<jpv@cisco.com>, "ro= ll"<roll@ietf.org>
> >>> Sent: Wednesday, November 16, 2011 6:25:31 AM
> >>> Subject: Re: [Roll] definition of "RPL Domain"<= br> > >>>
> >>> Now that we are at it: what is an RPL host? Or rather, why is this even
> >>> a conceivable thing to define? Afaik, RPL is a routing protocol, and as
> >>> such should concern only routers - not hosts?
> >>>
> >>> I worry if this is inventing an entire ecosystem which "pretends to be
> >>> just like the Internet, except it is not", as it needs entirely new
> >>> stacks, protocols, translators/gateways everywhere, and with no real
> >>> traces of IP as we know it remaining?
> >>>
> >>>
> >>
> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> >
> >
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
> > Roll mailing list
> > Roll@ietf.org
> > = https://www.ietf.org/mailman/listinfo/roll
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
> > Roll mailing list
> > Roll@ietf.org
> > = https://www.ietf.org/mailman/listinfo/roll
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Roll mailing list
> Roll@ietf.org
> <= font size=3D2>https://www.ietf.org/mailman/listinfo/roll
 --=_alternative 0059222EC125794B_=-- --=_related 0059222EC125794B_= Content-Type: image/gif Content-ID: <_1_13A4F47413A4F0740059222EC125794B> Content-Transfer-Encoding: base64 R0lGODlhSgAdALMNAPiusf8AD/q/wfaZm/BTVfWNkPSAg/NvcfvNze9ARO80N/3i4/7+/v///wAA AAAAACH5BAHoAw0ALAAAAABKAB0AAAT/sMk5Qbih4SCob8O2aRgBfKCIkZeJosW4Ga8Uqpl6fLfK YrvaRPTL1HpEHI2ClKmWNYsT03k1V7gAgpktYrY1Q3J27GaDNjMOjfL5rGpVgovzXuYv6RRzQl0v doATfzldLwduImx0iXKMY44vdXV+cYqPexuLFZMqfR6EgZ8pnZ4vBKUbBJWpQKCWrpKtKzywAZuh OlG2F6NpswO1wDVZhZSYWCIKq8iAKstC0dLT1NUfMbwXBa+zsaSNuhSo2QHMg+Rav+AqYBLFxsfq kGvymZcS2Ojb590j3/PHxqEz988ekYLJikkQ8A4ejioInb2rl9CQmIkNoeSaGNHhmwQNZgNhwNNR ZDmKErOsYugJgcstLxHo2VBlY5Z9NnFsu7iB5AuQIpbkfFPy3QI7+2rk8zd0QzCUHjEMYDCTVjQc J5pegFJUCQMGiEQQrCHQldan/NZdmPpV57SlK3ISSNoM3twFX79GAAA7 --=_related 0059222EC125794B_=-- From emmanuel.baccelli@gmail.com Thu Nov 17 08:26:03 2011 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 8E0F621F9A5A for ; Thu, 17 Nov 2011 08:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.744 X-Spam-Level: X-Spam-Status: No, score=-3.744 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 wO3P+hblk7Tg for ; Thu, 17 Nov 2011 08:26:02 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 860FE21F9A51 for ; Thu, 17 Nov 2011 08:26:00 -0800 (PST) Received: by yenq4 with SMTP id q4so1527099yen.31 for ; Thu, 17 Nov 2011 08:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=RDQRsAR56nSois7R4hpaEtkwUEmn5OBo+UR2Z6LYSFk=; b=BjRSR07rI2aboB3VA/QssKegytZe7ygrJ83hSYnYkifasPbq81UTXnEAEZbwoS4HdL iTTNApRtCj9DiX1mpQ3u9fb1LG2EPyBigmGLTslhkKZ7vDJU6RzM9LWX6aTdJVSib1FZ EuzCaLTDoguJH2vBziLVjWCOkg2o68tRb8gwE= Received: by 10.224.194.137 with SMTP id dy9mr23292045qab.65.1321547158397; Thu, 17 Nov 2011 08:25:58 -0800 (PST) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.229.233.136 with HTTP; Thu, 17 Nov 2011 08:25:06 -0800 (PST) In-Reply-To: <106982518.340250.1321546433816.JavaMail.root@zmbs1.inria.fr> References: <1373977554.319419.1321468695445.JavaMail.root@mail17.pantherlink.uwm.edu> <106982518.340250.1321546433816.JavaMail.root@zmbs1.inria.fr> From: Emmanuel Baccelli Date: Thu, 17 Nov 2011 17:25:06 +0100 X-Google-Sender-Auth: xwgd1pd85fVjDO4pxE6C9zHHmxI Message-ID: To: roll@ietf.org Content-Type: multipart/related; boundary=20cf300fb503ee248b04b1f0acbf Subject: Re: [Roll] Hosts part of the RPL instance? Re: definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 16:26:03 -0000 --20cf300fb503ee248b04b1f0acbf Content-Type: multipart/alternative; boundary=20cf300fb503ee248804b1f0acbe --20cf300fb503ee248804b1f0acbe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I also agree with Ulrich, i.e. to keep the usual definitions of hosts, routers and routing domain. An RPL routing domain would then naturally be a routing domain where the routing protocol in use is RPL. Thus, is there a need for any particular new definition? cheers Emmanuel On Thu, Nov 17, 2011 at 5:13 PM, Yvonne-Anne Pignolet < yvonne-anne.pignolet@ch.abb.com> wrote: > I fully agree with Ulrich > *Yvonne-Anne Pignolet* > Dr. Sc. ETH > ABB Schweiz AG > Segelhofstrasse 1K > 5400 Baden-D=E4ttwil, Switzerland > Phone: +41 58 586 86 56 > Mobile: +41 79 766 10 54 > email: *yvonne-anne.pignolet@ch.abb.com* > > > roll-bounces@ietf.org wrote on 17.11.2011 02:00:06: > > > From: Ulrich Herberg > > To: Mukul Goyal > > Cc: "roll@ietf.org" > > Date: 17.11.2011 01:59 > > Subject: Re: [Roll] Hosts part of the RPL instance? Re: definition > > of "RPL Domain" > > Sent by: roll-bounces@ietf.org > > > > My 2cts on the various terminology discussions: > > > > - An "RPL host" seems contradictory to me. Either it is a host, in > > which case it does not know anything about RPL, or it is an RPL > > router (leaf node or not, it still remains a router). We should > > allow for hosts (or be prepared to fight with the IAB for the next > > years why we think that we should break the IP architecture). > > > > - A question that comes to my mind: Is it specified anywhere how to > > add the RPL IP headers for the traffic direction to a data packet > > from a host received by an RPL router? > > > > - "RPL domain"; We should just stick to official terminology, i.e, > > "Routing Domain" in this case. I think it has been specified in RFC1136= . > > > > - RPL traffic: I don't like the term. I would stick to either > > control traffic or data traffic. Everyone understands these terms. > > No need to invent new terms. > > > > Regards > > Ulrich > > > > On Nov 17, 2011, at 2:38, Mukul Goyal wrote: > > > > > I guess the desired behavior would be: > > > > > > A host sends out a message to its RPL router. The router adds RPL > > SRH or RPL option to the IPv6 header and forwards the message > > further. No need for IP-in-IP tunneling. Any error message comes > > back to the router and the router handles the message. The host just > > sends and receives messages. > > > > > > Thanks > > > Mukul > > > > > > ----- Original Message ----- > > > From: "Mukul Goyal" > > > To: "Don Sturek" > > > Cc: roll@ietf.org > > > Sent: Wednesday, November 16, 2011 12:29:59 PM > > > Subject: Re: [Roll] definition of "RPL Domain" > > > > > > Hi Don > > > > > > I dont want hosts to know about RPL. I just want the RPL routers > > to consider the hosts as part of the RPL instance so that the RPL > > router does not have to do IP-in-IP tunneling to forward packets > > generated by a host. > > > > > > Thanks > > > Mukul > > > > > > ----- Original Message ----- > > > From: "Don Sturek" > > > To: "Mukul Goyal" , "S=E9bastien Dawans" > > > > > Cc: roll@ietf.org > > > Sent: Wednesday, November 16, 2011 12:22:55 PM > > > Subject: Re: [Roll] definition of "RPL Domain" > > > > > > Hi Mukul, > > > > > > I guess my view on this is the opposite of yours. I would like to se= e > > > host-only devices not need to know anything about RPL. Here is why: > > > 1) Code savings. Removing RPL from these host only devices would > allow > > > for deployment on smaller footprint devices > > > 2) Battery operated devices. Some host only devices are deployed o= n > > > non-mains powered devices. It would be nice for these devices to not > have > > > to listen for any RPL control messages yet still support transmission > into > > > a RPL routing domain. > > > > > > Don > > > > > > > > > > > > On 11/16/11 10:07 AM, "Mukul Goyal" wrote: > > > > > >> Hi Sebastien > > >> > > >> First, I would like to clarify that the need to define "RPL domain" > arose > > >> because draft-ietf-6man-rpl-option and > draft-ietf-6man-rpl-routing-header > > >> were using the term. Now, these drafts use the term "RPL instance" a= nd > > >> hence there is no real need to define the term "RPL domain" any more= . > I > > >> will change draft-ietf-roll-p2p-measurement so that all references t= o > > >> "RPL domain" are changed to "RPL Instance". > > >> > > >> Now returning to the question whether hosts should be considered par= t > of > > >> the RPL Instance, the benefit of doing so is that there is no need t= o > use > > >> IP-in-IP tunneling when a host sends out some data. If a host is not > > >> considered part of the RPL Instance, its default RPL router is > obliged to > > >> use IP-in-IP tunneling to forward the packet further. IP-in-IP > tunneling > > >> means an extra IPv6 header and thus less space for payload if you > want to > > >> avoid fragmentation. Also, if the packet is traveling along a DAG, t= he > > >> encapsulation/decapsulation needs to be done at every hop, which > sounds > > >> fairly heavy duty processing to me. > > >> > > >> So, I would like to explore if there is a way we could consider host= s > to > > >> be a part of the RPL Instance. > > >> > > >> Regards, > > >> Mukul > > >> > > >>> On what ground would you assume that a non-RPL aware host connected > to a > > >>> RPL-router (in this case I would call it a border router) is in a/t= he > > >>> RPL Domain? > > >> > > >>> From what I've seen in the drafts, the term "RPL Domain"'s primary > > >>> purpose it to differentiate the limits of "RPL-aware" nodes for IP > > >>> traffic that needs to transit to or from a set of RPL-aware hosts > (for > > >>> example, to define where to add/remove the RPL IPv6 Hop-by-Hop > Option if > > >>> used). > > >> > > >>> To me, this interpretation of RPL Domain is thus only useful in a > local > > >>> context and not to meant to designate one or more bounded set of > nodes. > > >>> That's the role of DODAGs and Instances. > > >> > > >>> Best Regards, > > >> > > >>> S=E9bastien Dawans > > >> > > >> On 11/16/2011 02:20 PM, Mukul Goyal wrote: > > >>> So, the revised doubts are as follows: > > >>> > > >>> 1. It is clear that RPL routers are within an RPL domain but what > about > > >>> the RPL-unaware IPv6 hosts attached to an RPL router? I would imagi= ne > > >>> that such hosts are also within an RPL domain. > > >>> > > >>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a > set > > >>> of RPL instances in the LLN? Can multiple RPL domains exist within = an > > >>> LLN? Or is it that an RPL domain is same as an LLN using RPL as a > > >>> routing protocol? > > >>> > > >>> THanks > > >>> Mukul > > >>> > > >>> ----- Original Message ----- > > >>> From: "Mukul Goyal" > > >>> To: "Thomas Heide Clausen" > > >>> Cc: "roll" > > >>> Sent: Wednesday, November 16, 2011 7:15:59 AM > > >>> Subject: Re: [Roll] definition of "RPL Domain" > > >>> > > >>> > > >>>> Now that we are at it: what is an RPL host? Or rather, why is this > > >>>> even a conceivable thing to define? Afaik, RPL is a routing > protocol, > > >>>> and as such should concern only routers - not hosts? > > >>>> > > >>> My bad. By RPL host, I actually meant an RPL leaf node. I think thi= s > > >>> term "RPL host" was in use at one point in time but I cant find a > > >>> reference to it in current spec. > > >>> > > >>> THanks > > >>> Mukul > > >>> > > >>> > > >>> > > >>> ----- Original Message ----- > > >>> From: "Thomas Heide Clausen" > > >>> To: "Mukul Goyal" > > >>> Cc: "JP Vasseur", "roll" > > >>> Sent: Wednesday, November 16, 2011 6:25:31 AM > > >>> Subject: Re: [Roll] definition of "RPL Domain" > > >>> > > >>> Now that we are at it: what is an RPL host? Or rather, why is this > even > > >>> a conceivable thing to define? Afaik, RPL is a routing protocol, an= d > as > > >>> such should concern only routers - not hosts? > > >>> > > >>> I worry if this is inventing an entire ecosystem which "pretends to > be > > >>> just like the Internet, except it is not", as it needs entirely new > > >>> stacks, protocols, translators/gateways everywhere, and with no rea= l > > >>> traces of IP as we know it remaining? > > >>> > > >>> > > >> > > >> _______________________________________________ > > >> Roll mailing list > > >> Roll@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/roll > > > >> _______________________________________________ > > >> Roll mailing list > > >> Roll@ietf.org > > >> https://www.ietf.org/mailman/listinfo/roll > > > > > > > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --20cf300fb503ee248804b1f0acbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I also agree with Ulrich, i.e. to keep the usual definitions of hosts, rout= ers and routing domain. An RPL routing domain would then naturally be a rou= ting domain where the routing protocol in use is RPL. Thus, is there a need= for any particular new definition?
cheers
Emmanuel

On Thu, Nov 17, 2= 011 at 5:13 PM, Yvonne-Anne Pignolet <yvonne-anne.pignolet@ch.abb.com><= /span> wrote:
I full= y agree with Ulrich
Yvonne-Anne Pignolet=
Dr. Sc. ETH
ABB Schweiz AG
Segelhofstrasse 1K
5400 Baden-D=E4ttwil, Switzerland
Phone: +41 58 586 86 56
Mobile: +41 79 766 10 54
email: yvonne-anne.pigno= let@ch.abb.com



roll-bounces@ietf.org wrote on 17.11.2011 02:00:06:

> From: Ulrich Herberg <ulrich@herberg.name>
> To: Mukul Goyal <mukul@uwm.edu>
> Cc: "roll@ietf.org" <roll@ietf.org>
> Date: 17.11.2011 01:59
> Subject: Re: [Roll] Hosts part of the RPL ins= tance? Re: definition
> of "RPL Domain"
> Sent by: roll-bounces@ietf.org
>
> My 2cts on the various terminology discussions:
>
> - An "RPL host" seems contradictory to me. Either it is a host, in
> which case it does not know anything about RPL, or it is an RPL
> router (leaf node or not, it still remains a router). We should
> allow for hosts (or be prepared to fight with the IAB for the next
> years why we think that we should break the IP architecture).
>
> - A question that comes to my mind: Is it specified anywhere how to
> add the RPL IP headers for the traffic direction to a data packet
> from a host received by an RPL router?
>
> - "RPL domain"; We should just stick to official terminology= , i.e,
> "Routing Domain" in this case. I think it has been specified in RFC1136.
>
> - RPL traffic: I don't like the term. I would stick to either
> control traffic or data traffic. Everyone understands these terms.
> No need to invent new terms.
>
> Regards
> Ulrich
>
> On Nov 17, 2011, at 2:38, Mukul Goyal <mukul@uwm.edu> wrote:
>
> > I guess the desired behavior would be:
> >
> > A host sends out a message to its RPL router. The router adds RPL
> SRH or RPL option to the IPv6 header and forwards the message
> further. No need for IP-in-IP tunneling. Any error message comes
> back to the router and the router handles the message. The host just > sends and receives messages.
> >
> > Thanks
> > Mukul
> >
> > ----- Original Message -----
> > From: "Mukul Goyal" <mukul@uwm.edu>
> > To: "Don Sturek" <d.sturek@att.net>
> > Cc: roll@ietf.= org
> > Sent: Wednesday, November 16, 2011 12:29:59 PM
> > Subject: Re: [Roll] definition of "RPL Domain"
> >
> > Hi Don
> >
> > I dont want hosts to know about RPL. I just want the RPL routers
> to consider the hosts as part of the RPL instance so that the RPL
> router does not have to do IP-in-IP tunneling to forward packets
> generated by a host.
> >
> > Thanks
> > Mukul
> >
> > ----- Original Message -----
> > From: "Don Sturek" <d.sturek@att.net>
> > To: "Mukul Goyal" <mukul@uwm.edu>, "S=E9bastien Dawans"
> <seb= astien.dawans@cetic.be>
> > Cc: roll@ietf.= org
> > Sent: Wednesday, November 16, 2011 12:22:55 PM
> > Subject: Re: [Roll] definition of "RPL Domain"
> >
> > Hi Mukul,
> >
> > I guess my view on this is the opposite of yours. =A0I would like to see
> > host-only devices not need to know anything about RPL. =A0Here is why:
> > 1) =A0Code savings. =A0 Removing RPL from these host only devices would allow
> > for deployment on smaller footprint devices
> > 2) =A0Battery operated devices. =A0 Some host only devices are deployed on
> > non-mains powered devices. =A0It would be nice for these devices to not have
> > to listen for any RPL control messages yet still support transmis= sion into
> > a RPL routing domain.
> >
> > Don
> >
> >
> >
> > On 11/16/11 10:07 AM, "Mukul Goyal" <mukul@uwm.edu> wrote:
> >
> >> Hi Sebastien
> >>
> >> First, I would like to clarify that the need to define "= RPL domain" arose
> >> because draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-ro= uting-header
> >> were using the term. Now, these drafts use the term "RPL instance" and
> >> hence there is no real need to define the term "RPL domain" any more. I
> >> will change draft-ietf-roll-p2p-measurement so that all refer= ences to
> >> "RPL domain" are changed to "RPL Instance"= ;.
> >>
> >> Now returning to the question whether hosts should be conside= red part of
> >> the RPL Instance, the benefit of doing so is that there is no need to use
> >> IP-in-IP tunneling when a host sends out some data. If a host is not
> >> considered part of the RPL Instance, its default RPL router is obliged to
> >> use IP-in-IP tunneling to forward the packet further. IP-in-I= P tunneling
> >> means an extra IPv6 header and thus less space for payload if you want to
> >> avoid fragmentation. Also, if the packet is traveling along a DAG, the
> >> encapsulation/decapsulation needs to be done at every hop, which sounds
> >> fairly heavy duty processing to me.
> >>
> >> So, I would like to explore if there is a way we could consid= er hosts to
> >> be a part of the RPL Instance.
> >>
> >> Regards,
> >> Mukul
> >>
> >>> On what ground would you assume that a non-RPL aware host connected to a
> >>> RPL-router (in this case I would call it a border router) is in a/the
> >>> RPL Domain?
> >>
> >>> From what I've seen in the drafts, the term "RPL Domain"'s primary
> >>> purpose it to differentiate the limits of "RPL-aware= " nodes for IP
> >>> traffic that needs to transit to or from a set of RPL-awa= re hosts (for
> >>> example, to define where to add/remove the RPL IPv6 Hop-b= y-Hop Option if
> >>> used).
> >>
> >>> To me, this interpretation of RPL Domain is thus only useful in a local
> >>> context and not to meant to designate one or more bounded set of nodes.
> >>> That's the role of DODAGs and Instances.
> >>
> >>> Best Regards,
> >>
> >>> S=E9bastien Dawans
> >>
> >> On 11/16/2011 02:20 PM, Mukul Goyal wrote:
> >>> So, the revised doubts are as follows:
> >>>
> >>> 1. It is clear that RPL routers are within an RPL domain but what about
> >>> the RPL-unaware IPv6 hosts attached to an RPL router? I would imagine
> >>> that such hosts are also within an RPL domain.
> >>>
> >>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set
> >>> of RPL instances in the LLN? Can multiple RPL domains exist within an
> >>> LLN? Or is it that an RPL domain is same as an LLN using RPL as a
> >>> routing protocol?
> >>>
> >>> THanks
> >>> Mukul
> >>>
> >>> ----- Original Message -----
> >>> From: "Mukul Goyal"<mukul@uwm.edu>
> >>> To: "Thomas Heide Clausen"<thomas@thomasclausen.org&g= t;
> >>> Cc: "roll"<roll@ietf.org>
> >>> Sent: Wednesday, November 16, 2011 7:15:59 AM
> >>> Subject: Re: [Roll] definition of "RPL Domain"<= br> > >>>
> >>>
> >>>> Now that we are at it: what is an RPL host? Or rather= , why is this
> >>>> even a conceivable thing to define? Afaik, RPL is a routing protocol,
> >>>> and as such should concern only routers - not hosts?<= br> > >>>>
> >>> My bad. By RPL host, I actually meant an RPL leaf node. I think this
> >>> term "RPL host" was in use at one point in time but I cant find a
> >>> reference to it in current spec.
> >>>
> >>> THanks
> >>> Mukul
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>> From: "Thomas Heide Clausen"<thomas@thomasclausen.org= >
> >>> To: "Mukul Goyal"<mukul@uwm.edu>
> >>> Cc: "JP Vasseur"<jpv@cisco.com>, "roll"<roll@ietf.org>
> >>> Sent: Wednesday, November 16, 2011 6:25:31 AM
> >>> Subject: Re: [Roll] definition of "RPL Domain"<= br> > >>>
> >>> Now that we are at it: what is an RPL host? Or rather, why is this even
> >>> a conceivable thing to define? Afaik, RPL is a routing protocol, and as
> >>> such should concern only routers - not hosts?
> >>>
> >>> I worry if this is inventing an entire ecosystem which "pretends to be
> >>> just like the Internet, except it is not", as it needs entirely new
> >>> stacks, protocols, translators/gateways everywhere, and with no real
> >>> traces of IP as we know it remaining?
> >>>
> >>>
> >>
> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.= org
> >>
https://www.ietf.o= rg/mailman/listinfo/roll

> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.= org
> >> https://www.ietf.org/mailman/l= istinfo/roll
> >
> >
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org<= /a>
> > https://www.ietf.org/mailman/listi= nfo/roll
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org<= /a>
> > https://www.ietf.org/mailman/listi= nfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org > https://www.ietf.org/mailman/listinfo/r= oll

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


--20cf300fb503ee248804b1f0acbe-- --20cf300fb503ee248b04b1f0acbf Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <_1_13A4F47413A4F0740059222EC125794B> X-Attachment-Id: fbd431bebb3becc5_0.0.1 R0lGODlhSgAdALMNAPiusf8AD/q/wfaZm/BTVfWNkPSAg/NvcfvNze9ARO80N/3i4/7+/v///wAA AAAAACH5BAHoAw0ALAAAAABKAB0AAAT/sMk5Qbih4SCob8O2aRgBfKCIkZeJosW4Ga8Uqpl6fLfK YrvaRPTL1HpEHI2ClKmWNYsT03k1V7gAgpktYrY1Q3J27GaDNjMOjfL5rGpVgovzXuYv6RRzQl0v doATfzldLwduImx0iXKMY44vdXV+cYqPexuLFZMqfR6EgZ8pnZ4vBKUbBJWpQKCWrpKtKzywAZuh OlG2F6NpswO1wDVZhZSYWCIKq8iAKstC0dLT1NUfMbwXBa+zsaSNuhSo2QHMg+Rav+AqYBLFxsfq kGvymZcS2Ojb590j3/PHxqEz988ekYLJikkQ8A4ejioInb2rl9CQmIkNoeSaGNHhmwQNZgNhwNNR ZDmKErOsYugJgcstLxHo2VBlY5Z9NnFsu7iB5AuQIpbkfFPy3QI7+2rk8zd0QzCUHjEMYDCTVjQc J5pegFJUCQMGiEQQrCHQldan/NZdmPpV57SlK3ISSNoM3twFX79GAAA7 --20cf300fb503ee248b04b1f0acbf-- From robert.cragie@gridmerge.com Thu Nov 17 08:47:24 2011 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 698D021F9656 for ; Thu, 17 Nov 2011 08:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPNNbjqN2BND for ; Thu, 17 Nov 2011 08:47:23 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3E721F9655 for ; Thu, 17 Nov 2011 08:47:23 -0800 (PST) Received: from client-86-27-31-206.glfd.adsl.virginmedia.com ([86.27.31.206] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1RR57R-0006qa-DB for roll@ietf.org; Thu, 17 Nov 2011 16:47:21 +0000 Message-ID: <4EC53A97.3020409@gridmerge.com> Date: Thu, 17 Nov 2011 16:47:19 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: roll@ietf.org References: <1373977554.319419.1321468695445.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080409030808020804050009" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] Hosts part of the RPL instance? Re: definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 16:47:24 -0000 This is a cryptographically signed message in MIME format. --------------ms080409030808020804050009 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable +1 The only consideration which we may need is the concept of a 'LLN host', = i.e. one which is sleepy. In this case the parent router (protocol=20 indeterminate) may need to buffer data for it. However this is nothing=20 to do with RPL or any routing protocol but does fall into the ND area of = discussion. Robert On 17/11/2011 1:00 AM, Ulrich Herberg wrote: > My 2cts on the various terminology discussions: > > - An "RPL host" seems contradictory to me. Either it is a host, in whic= h case it does not know anything about RPL, or it is an RPL router (leaf = node or not, it still remains a router). We should allow for hosts (or be= prepared to fight with the IAB for the next years why we think that we s= hould break the IP architecture). > > - A question that comes to my mind: Is it specified anywhere how to add= the RPL IP headers for the traffic direction to a data packet from a hos= t received by an RPL router? > > - "RPL domain"; We should just stick to official terminology, i.e, "Rou= ting Domain" in this case. I think it has been specified in RFC1136. > > - RPL traffic: I don't like the term. I would stick to either control t= raffic or data traffic. Everyone understands these terms. No need to inve= nt new terms. > > Regards > Ulrich > > On Nov 17, 2011, at 2:38, Mukul Goyal wrote: > >> I guess the desired behavior would be: >> >> A host sends out a message to its RPL router. The router adds RPL SRH = or RPL option to the IPv6 header and forwards the message further. No nee= d for IP-in-IP tunneling. Any error message comes back to the router and = the router handles the message. The host just sends and receives messages= =2E >> >> Thanks >> Mukul >> >> ----- Original Message ----- >> From: "Mukul Goyal" >> To: "Don Sturek" >> Cc: roll@ietf.org >> Sent: Wednesday, November 16, 2011 12:29:59 PM >> Subject: Re: [Roll] definition of "RPL Domain" >> >> Hi Don >> >> I dont want hosts to know about RPL. I just want the RPL routers to co= nsider the hosts as part of the RPL instance so that the RPL router does = not have to do IP-in-IP tunneling to forward packets generated by a host.= >> >> Thanks >> Mukul >> >> ----- Original Message ----- >> From: "Don Sturek" >> To: "Mukul Goyal", "S=C3=A9bastien Dawans" >> Cc: roll@ietf.org >> Sent: Wednesday, November 16, 2011 12:22:55 PM >> Subject: Re: [Roll] definition of "RPL Domain" >> >> Hi Mukul, >> >> I guess my view on this is the opposite of yours. I would like to see= >> host-only devices not need to know anything about RPL. Here is why: >> 1) Code savings. Removing RPL from these host only devices would al= low >> for deployment on smaller footprint devices >> 2) Battery operated devices. Some host only devices are deployed on= >> non-mains powered devices. It would be nice for these devices to not = have >> to listen for any RPL control messages yet still support transmission = into >> a RPL routing domain. >> >> Don >> >> >> >> On 11/16/11 10:07 AM, "Mukul Goyal" wrote: >> >>> Hi Sebastien >>> >>> First, I would like to clarify that the need to define "RPL domain" a= rose >>> because draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-he= ader >>> were using the term. Now, these drafts use the term "RPL instance" an= d >>> hence there is no real need to define the term "RPL domain" any more.= I >>> will change draft-ietf-roll-p2p-measurement so that all references to= >>> "RPL domain" are changed to "RPL Instance". >>> >>> Now returning to the question whether hosts should be considered part= of >>> the RPL Instance, the benefit of doing so is that there is no need to= use >>> IP-in-IP tunneling when a host sends out some data. If a host is not >>> considered part of the RPL Instance, its default RPL router is oblige= d to >>> use IP-in-IP tunneling to forward the packet further. IP-in-IP tunnel= ing >>> means an extra IPv6 header and thus less space for payload if you wan= t to >>> avoid fragmentation. Also, if the packet is traveling along a DAG, th= e >>> encapsulation/decapsulation needs to be done at every hop, which soun= ds >>> fairly heavy duty processing to me. >>> >>> So, I would like to explore if there is a way we could consider hosts= to >>> be a part of the RPL Instance. >>> >>> Regards, >>> Mukul >>> >>>> On what ground would you assume that a non-RPL aware host connected = to a >>>> RPL-router (in this case I would call it a border router) is in a/th= e >>>> RPL Domain? >>>> From what I've seen in the drafts, the term "RPL Domain"'s primary >>>> purpose it to differentiate the limits of "RPL-aware" nodes for IP >>>> traffic that needs to transit to or from a set of RPL-aware hosts (f= or >>>> example, to define where to add/remove the RPL IPv6 Hop-by-Hop Optio= n if >>>> used). >>>> To me, this interpretation of RPL Domain is thus only useful in a lo= cal >>>> context and not to meant to designate one or more bounded set of nod= es. >>>> That's the role of DODAGs and Instances. >>>> Best Regards, >>>> S=C3=A9bastien Dawans >>> On 11/16/2011 02:20 PM, Mukul Goyal wrote: >>>> So, the revised doubts are as follows: >>>> >>>> 1. It is clear that RPL routers are within an RPL domain but what ab= out >>>> the RPL-unaware IPv6 hosts attached to an RPL router? I would imagin= e >>>> that such hosts are also within an RPL domain. >>>> >>>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a s= et >>>> of RPL instances in the LLN? Can multiple RPL domains exist within a= n >>>> LLN? Or is it that an RPL domain is same as an LLN using RPL as a >>>> routing protocol? >>>> >>>> THanks >>>> Mukul >>>> >>>> ----- Original Message ----- >>>> From: "Mukul Goyal" >>>> To: "Thomas Heide Clausen" >>>> Cc: "roll" >>>> Sent: Wednesday, November 16, 2011 7:15:59 AM >>>> Subject: Re: [Roll] definition of "RPL Domain" >>>> >>>> >>>>> Now that we are at it: what is an RPL host? Or rather, why is this >>>>> even a conceivable thing to define? Afaik, RPL is a routing protoco= l, >>>>> and as such should concern only routers - not hosts? >>>>> >>>> My bad. By RPL host, I actually meant an RPL leaf node. I think this= >>>> term "RPL host" was in use at one point in time but I cant find a >>>> reference to it in current spec. >>>> >>>> THanks >>>> Mukul >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Thomas Heide Clausen" >>>> To: "Mukul Goyal" >>>> Cc: "JP Vasseur", "roll" >>>> Sent: Wednesday, November 16, 2011 6:25:31 AM >>>> Subject: Re: [Roll] definition of "RPL Domain" >>>> >>>> Now that we are at it: what is an RPL host? Or rather, why is this e= ven >>>> a conceivable thing to define? Afaik, RPL is a routing protocol, and= as >>>> such should concern only routers - not hosts? >>>> >>>> I worry if this is inventing an entire ecosystem which "pretends to = be >>>> just like the Internet, except it is not", as it needs entirely new >>>> stacks, protocols, translators/gateways everywhere, and with no real= >>>> traces of IP as we know it remaining? >>>> >>>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------ms080409030808020804050009 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTExNzE2NDcxOVowIwYJKoZI hvcNAQkEMRYEFMjnfbT0T6GsK8ZR5xSGwDougWblMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG 9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3 BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQCTOlD7HJsm4YK+ACekbDQN OZjvXfbNdRVmt+FAOC1W6SbGxMpNHdKnc53QOIRvXAIOax3dWPudINhCT22qRK0HGbAE4Uzd gtPu9ELAYE0XekHeUt9zgZn1alAjYY9YCw3cK14MNQoXoiI1Nk0B5ufBXB5S+0i1x6YAEEFE pEMuRrP4j50d21mi/qm6p9suCxm8J7JdlDGfxowKBicFukMmqm8DC8jc8SPgmMsn1evzx1gh IeltmHuykkdAmW+wg1LTosmNdRSz6hyhGcb4bEBo5L24NEa9xMzO6wYR/+4AOMiI4eFU1bug hJbz0aNVywpoR9UmfzgwT5ZyimTXD76hAAAAAAAA --------------ms080409030808020804050009-- From prvs=29562bbfa=mukul@uwm.edu Thu Nov 17 08:50:19 2011 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 5A36221F9899 for ; Thu, 17 Nov 2011 08:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 4+muM8C+GDC1 for ; Thu, 17 Nov 2011 08:50:18 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id C344221F9885 for ; Thu, 17 Nov 2011 08:50:18 -0800 (PST) Received: from localhost (HELO mta03.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 17 Nov 2011 10:50:18 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 5ECA11FD014; Thu, 17 Nov 2011 10:50:18 -0600 (CST) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqQATJ9C9N9F; Thu, 17 Nov 2011 10:50:18 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 3C95A1FD013; Thu, 17 Nov 2011 10:50:18 -0600 (CST) Date: Thu, 17 Nov 2011 10:50:18 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <296370087.333581.1321548618120.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <2028531660.333477.1321548338028.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: [Roll] RPL instance as the boundary for RPL option/source route header X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 16:50:19 -0000 Hi Jonathan Couple of queries: 1) A packet with an RPL option cant cross the RPL instance it was generated in. Here, are n't you implicitly assuming that RPLInstanceID is global? What happens when RPLInstanceID is local? In that case, I wonder if a packet with an RPL option must not leave the set of DODAGs identified by RPLInstanceID and the DODAGID (same as source's IPv6 address)? 2) How do you define the RPL instance that constitutes the boundaries that a packet with RPL Source Route header must not cross? SRH does not have any field for RPLInstanceID. Thanks Mukul From prvs=29562bbfa=mukul@uwm.edu Thu Nov 17 08:53:51 2011 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 65F1A11E80E6 for ; Thu, 17 Nov 2011 08:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 crY+XkVG8qHG for ; Thu, 17 Nov 2011 08:53:51 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7607711E80C5 for ; Thu, 17 Nov 2011 08:53:45 -0800 (PST) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 17 Nov 2011 10:53:45 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id E11C22B3ED9; Thu, 17 Nov 2011 10:52:20 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DieyM6kUkXQg; Thu, 17 Nov 2011 10:52:19 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 981832B3ED2; Thu, 17 Nov 2011 10:52:19 -0600 (CST) Date: Thu, 17 Nov 2011 10:53:43 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <1294161514.333699.1321548823711.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <296370087.333581.1321548618120.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] RPL instance as the boundary for RPL option/source route header X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 16:53:51 -0000 >2) How do you define the RPL instance that constitutes the boundaries that a packet with RPL Source Route header must not cross? SRH does not have any field for RPLInstanceID. Further, it does not really make any sense to limit a source-routed packet to an RPL instance. Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "Jonathan Hui" Cc: "roll" Sent: Thursday, November 17, 2011 10:50:18 AM Subject: [Roll] RPL instance as the boundary for RPL option/source route header Hi Jonathan Couple of queries: 1) A packet with an RPL option cant cross the RPL instance it was generated in. Here, are n't you implicitly assuming that RPLInstanceID is global? What happens when RPLInstanceID is local? In that case, I wonder if a packet with an RPL option must not leave the set of DODAGs identified by RPLInstanceID and the DODAGID (same as source's IPv6 address)? 2) How do you define the RPL instance that constitutes the boundaries that a packet with RPL Source Route header must not cross? SRH does not have any field for RPLInstanceID. Thanks Mukul _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jonhui@cisco.com Thu Nov 17 12:24:47 2011 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 D7F0D11E80CD for ; Thu, 17 Nov 2011 12:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 IXkMCpyFGxlY for ; Thu, 17 Nov 2011 12:24:47 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4C011E809C for ; Thu, 17 Nov 2011 12:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=1199; q=dns/txt; s=iport; t=1321561486; x=1322771086; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kYFxOw1/Pg3Xhvksb4L4VcCdj7S6kRBEyYpEq34wbAY=; b=b3SSm6G3VS2/0l6Sh1ibumV6p6RgfWALnV2j02GziPthyBDOjz7EdEn4 Sf3lRA+b/7FfUCj2peEtXzgDttaYfKIWwbUaNl6yaIqj8ry8Uq393/Of4 KTlhoCfHplX0gsJH3YQ0VIQWiSnXNSkOwqJlmBFc+itQEUl7B1t5B0Gz7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJZsxU6rRDoG/2dsb2JhbABCDqohgQWBcgEBAQMBEgEnPwULC0ZXBjWHYJd2AZ47iTRjBIgVjCCRRVg X-IronPort-AV: E=Sophos;i="4.69,529,1315180800"; d="scan'208";a="14921788" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 17 Nov 2011 20:24:46 +0000 Received: from sjc-vpn6-1368.cisco.com (sjc-vpn6-1368.cisco.com [10.21.125.88]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAHKOk5h010546; Thu, 17 Nov 2011 20:24:46 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <296370087.333581.1321548618120.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Thu, 17 Nov 2011 12:24:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <515DB1E3-B860-410C-A417-7C1C5E684B23@cisco.com> References: <296370087.333581.1321548618120.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Cc: roll Subject: Re: [Roll] RPL instance as the boundary for RPL option/source route header X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 20:24:48 -0000 Hi Mukul, On Nov 17, 2011, at 8:50 AM, Mukul Goyal wrote: > Couple of queries: >=20 > 1) A packet with an RPL option cant cross the RPL instance it was = generated in. Here, are n't you implicitly assuming that RPLInstanceID = is global? What happens when RPLInstanceID is local? In that case, I = wonder if a packet with an RPL option must not leave the set of DODAGs = identified by RPLInstanceID and the DODAGID (same as source's IPv6 = address)? No assumption that RPL Instance ID is global. The tunnel exit-point = must be within the same RPL Instance as the tunnel entry-point. If the = original packet needs to be forwarded outside the RPL Instance, then it = must exit the tunnel and therefore strip the RPL Option. That is true = whether the instance is global or local. > 2) How do you define the RPL instance that constitutes the boundaries = that a packet with RPL Source Route header must not cross? SRH does not = have any field for RPLInstanceID. You are correct. I guess "RPL domain" was the better terminology here. = If you agree with my proposed definition of "RPL domain", I can make the = change in the next revision. -- Jonathan Hui From jonhui@cisco.com Thu Nov 17 12:32:50 2011 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 8FF9821F96FC for ; Thu, 17 Nov 2011 12:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.571, 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 G-OLMOFDN2zp for ; Thu, 17 Nov 2011 12:32:49 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 96AC521F9412 for ; Thu, 17 Nov 2011 12:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=8228; q=dns/txt; s=iport; t=1321561969; x=1322771569; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=S0zbDUH1bDKCkZwVCPWrOhbxa4MgJm/1x8SupozrDD4=; b=fypbjEMXfbWOhk6kF4h1V+qMUFLhdMXz5uOol9nbTLp4C2TjMd9kU+Qx dLeqh2CGNnYBcFst8wOPNT8JapcS2iTz90uV4iwZWYhjgutPBrtz8ije/ pSWkd8JXwPUIKtEnCffrWKtO2qj8pKDFkF6ju6p44P7H2nqOMyO+9QtX5 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkAAPluxU6rRDoJ/2dsb2JhbABCmX6OXIFWgQWBcgEBAQECAQEBAQ8BWwsFBwQLEQEDAQEBLiciBggGEyKHYAiXcQGeOQSJNGMEiBWMIJId X-IronPort-AV: E=Sophos;i="4.69,529,1315180800"; d="scan'208";a="14923628" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 17 Nov 2011 20:32:49 +0000 Received: from sjc-vpn6-1368.cisco.com (sjc-vpn6-1368.cisco.com [10.21.125.88]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAHKWnpw027728; Thu, 17 Nov 2011 20:32:49 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Jonathan Hui In-Reply-To: Date: Thu, 17 Nov 2011 12:32:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1373977554.319419.1321468695445.JavaMail.root@mail17.pantherlink.uwm.edu> To: Ulrich Herberg X-Mailer: Apple Mail (2.1084) Cc: "roll@ietf.org" Subject: Re: [Roll] Hosts part of the RPL instance? Re: definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 20:32:50 -0000 There case where you want to be a bit more specific. The following phrases should be unambiguous by now: - RPL routing domain - RPL control/data traffic Can we move on now? -- Jonathan Hui On Nov 16, 2011, at 5:00 PM, Ulrich Herberg wrote: > My 2cts on the various terminology discussions: >=20 > - An "RPL host" seems contradictory to me. Either it is a host, in = which case it does not know anything about RPL, or it is an RPL router = (leaf node or not, it still remains a router). We should allow for hosts = (or be prepared to fight with the IAB for the next years why we think = that we should break the IP architecture). >=20 > - A question that comes to my mind: Is it specified anywhere how to = add the RPL IP headers for the traffic direction to a data packet from a = host received by an RPL router? >=20 > - "RPL domain"; We should just stick to official terminology, i.e, = "Routing Domain" in this case. I think it has been specified in RFC1136. >=20 > - RPL traffic: I don't like the term. I would stick to either control = traffic or data traffic. Everyone understands these terms. No need to = invent new terms. >=20 > Regards > Ulrich >=20 > On Nov 17, 2011, at 2:38, Mukul Goyal wrote: >=20 >> I guess the desired behavior would be: >>=20 >> A host sends out a message to its RPL router. The router adds RPL SRH = or RPL option to the IPv6 header and forwards the message further. No = need for IP-in-IP tunneling. Any error message comes back to the router = and the router handles the message. The host just sends and receives = messages. >>=20 >> Thanks >> Mukul >>=20 >> ----- Original Message ----- >> From: "Mukul Goyal" >> To: "Don Sturek" >> Cc: roll@ietf.org >> Sent: Wednesday, November 16, 2011 12:29:59 PM >> Subject: Re: [Roll] definition of "RPL Domain" >>=20 >> Hi Don >>=20 >> I dont want hosts to know about RPL. I just want the RPL routers to = consider the hosts as part of the RPL instance so that the RPL router = does not have to do IP-in-IP tunneling to forward packets generated by a = host. >>=20 >> Thanks >> Mukul >>=20 >> ----- Original Message ----- >> From: "Don Sturek" >> To: "Mukul Goyal" , "S=E9bastien Dawans" = >> Cc: roll@ietf.org >> Sent: Wednesday, November 16, 2011 12:22:55 PM >> Subject: Re: [Roll] definition of "RPL Domain" >>=20 >> Hi Mukul, >>=20 >> I guess my view on this is the opposite of yours. I would like to = see >> host-only devices not need to know anything about RPL. Here is why: >> 1) Code savings. Removing RPL from these host only devices would = allow >> for deployment on smaller footprint devices >> 2) Battery operated devices. Some host only devices are deployed = on >> non-mains powered devices. It would be nice for these devices to not = have >> to listen for any RPL control messages yet still support transmission = into >> a RPL routing domain. >>=20 >> Don >>=20 >>=20 >>=20 >> On 11/16/11 10:07 AM, "Mukul Goyal" wrote: >>=20 >>> Hi Sebastien >>>=20 >>> First, I would like to clarify that the need to define "RPL domain" = arose >>> because draft-ietf-6man-rpl-option and = draft-ietf-6man-rpl-routing-header >>> were using the term. Now, these drafts use the term "RPL instance" = and >>> hence there is no real need to define the term "RPL domain" any = more. I >>> will change draft-ietf-roll-p2p-measurement so that all references = to >>> "RPL domain" are changed to "RPL Instance". >>>=20 >>> Now returning to the question whether hosts should be considered = part of >>> the RPL Instance, the benefit of doing so is that there is no need = to use >>> IP-in-IP tunneling when a host sends out some data. If a host is not >>> considered part of the RPL Instance, its default RPL router is = obliged to >>> use IP-in-IP tunneling to forward the packet further. IP-in-IP = tunneling >>> means an extra IPv6 header and thus less space for payload if you = want to >>> avoid fragmentation. Also, if the packet is traveling along a DAG, = the >>> encapsulation/decapsulation needs to be done at every hop, which = sounds >>> fairly heavy duty processing to me. >>>=20 >>> So, I would like to explore if there is a way we could consider = hosts to >>> be a part of the RPL Instance. >>>=20 >>> Regards, >>> Mukul >>>=20 >>>> On what ground would you assume that a non-RPL aware host connected = to a >>>> RPL-router (in this case I would call it a border router) is in = a/the >>>> RPL Domain? >>>=20 >>>> =46rom what I've seen in the drafts, the term "RPL Domain"'s = primary >>>> purpose it to differentiate the limits of "RPL-aware" nodes for IP >>>> traffic that needs to transit to or from a set of RPL-aware hosts = (for >>>> example, to define where to add/remove the RPL IPv6 Hop-by-Hop = Option if >>>> used). >>>=20 >>>> To me, this interpretation of RPL Domain is thus only useful in a = local >>>> context and not to meant to designate one or more bounded set of = nodes. >>>> That's the role of DODAGs and Instances. >>>=20 >>>> Best Regards, >>>=20 >>>> S=E9bastien Dawans >>>=20 >>> On 11/16/2011 02:20 PM, Mukul Goyal wrote: >>>> So, the revised doubts are as follows: >>>>=20 >>>> 1. It is clear that RPL routers are within an RPL domain but what = about >>>> the RPL-unaware IPv6 hosts attached to an RPL router? I would = imagine >>>> that such hosts are also within an RPL domain. >>>>=20 >>>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a = set >>>> of RPL instances in the LLN? Can multiple RPL domains exist within = an >>>> LLN? Or is it that an RPL domain is same as an LLN using RPL as a >>>> routing protocol? >>>>=20 >>>> THanks >>>> Mukul >>>>=20 >>>> ----- Original Message ----- >>>> From: "Mukul Goyal" >>>> To: "Thomas Heide Clausen" >>>> Cc: "roll" >>>> Sent: Wednesday, November 16, 2011 7:15:59 AM >>>> Subject: Re: [Roll] definition of "RPL Domain" >>>>=20 >>>>=20 >>>>> Now that we are at it: what is an RPL host? Or rather, why is this >>>>> even a conceivable thing to define? Afaik, RPL is a routing = protocol, >>>>> and as such should concern only routers - not hosts? >>>>>=20 >>>> My bad. By RPL host, I actually meant an RPL leaf node. I think = this >>>> term "RPL host" was in use at one point in time but I cant find a >>>> reference to it in current spec. >>>>=20 >>>> THanks >>>> Mukul >>>>=20 >>>>=20 >>>>=20 >>>> ----- Original Message ----- >>>> From: "Thomas Heide Clausen" >>>> To: "Mukul Goyal" >>>> Cc: "JP Vasseur", "roll" >>>> Sent: Wednesday, November 16, 2011 6:25:31 AM >>>> Subject: Re: [Roll] definition of "RPL Domain" >>>>=20 >>>> Now that we are at it: what is an RPL host? Or rather, why is this = even >>>> a conceivable thing to define? Afaik, RPL is a routing protocol, = and as >>>> such should concern only routers - not hosts? >>>>=20 >>>> I worry if this is inventing an entire ecosystem which "pretends to = be >>>> just like the Internet, except it is not", as it needs entirely new >>>> stacks, protocols, translators/gateways everywhere, and with no = real >>>> traces of IP as we know it remaining? >>>>=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 >>=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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=296325093=mukul@uwm.edu Thu Nov 17 19:10:42 2011 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 D45A421F8482 for ; Thu, 17 Nov 2011 19:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 B1UDpUDr4K9G for ; Thu, 17 Nov 2011 19:10:14 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 367BA21F8479 for ; Thu, 17 Nov 2011 19:10:14 -0800 (PST) Received: from localhost (HELO mta03.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 17 Nov 2011 21:10:09 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 63AF61FD010; Thu, 17 Nov 2011 21:10:09 -0600 (CST) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRGDJq4gZMaa; Thu, 17 Nov 2011 21:10:09 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 07E1A1FD00F; Thu, 17 Nov 2011 21:10:09 -0600 (CST) Date: Thu, 17 Nov 2011 21:10:07 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <9832945.342738.1321585807730.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <99C9CB3F-6637-456F-AAD0-4C7474219CAE@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 03:10:42 -0000 I agree with this definition of RPL domain. The definition implies that RPL devices may have links/interfaces that are considered exterior to the RPL domain. Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Mukul Goyal" Cc: "JP Vasseur" , "roll" Sent: Wednesday, November 16, 2011 7:37:32 AM Subject: Re: [Roll] definition of "RPL Domain" How about a definition derived from RFC 1629: A "RPL domain" is a routing domain, as stated in Section 3.2 of RFC 1629, where the common routing protocol is RPL. The above definition would unambiguously give the following answers to your questions: 1) Given the definition above, devices that do not operate RPL are not a part of the RPL domain. 2) Because RPL devices may support more than one instance, a RPL domain may contain any number of instances. The term seems to be used most often in draft-ietf-roll-p2p-measurement. I suggest going through and verifying whether "RPL Instance" or "RPL domain" was intended. Happy to see any alternative definitions you may have in mind. -- Jonathan Hui On Nov 16, 2011, at 2:45 AM, Mukul Goyal wrote: > Hi JP > >> RPL domain: set of devices using RPL as a routing protocol. > > I think this definition is little too vague. Some of the points that need clarification: > > 1. It is clear that RPL hosts and routers (as defined towards the end of terminology section in RPL-19) are within an RPL domain but what about the RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagine that such hosts are also within an RPL domain. > > 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or is it that an RPL domain is same as an LLN using RPL as a routing protocol? > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: "roll" > Sent: Wednesday, November 16, 2011 2:33:50 AM > Subject: Re: definition of "RPL Domain" > > Hi Mukul, > > On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: > >> Hi JP >> >> I was wondering if the term "RPL Domain" could be defined in the terminology draft. >> > > How about > > RPL domain: set of devices using RPL as a routing protocol. > > Thanks. > > JP. > >> Thanks >> Mukul >> >> ----- Forwarded Message ----- >> From: "Joseph Reddy" >> To: ipv6@ietf.org >> Sent: Friday, October 14, 2011 7:15:05 PM >> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> >> >> Hi Jonathan, >> >> The draft uses the term "RPL domain" in several places and this is not clearly defined. >> >> I would imagine that it includes all nodes that are downstream of the RPL border router. But can you clarify if Host nodes that are downstream of the border router but do not implement any part of RPL ( even as RPL Leaf nodes ) should be considered part of the "RPL domain" ? >> >> In section 5, the draft now says "..Datagrams destined to nodes outside the RPL domain are dropped if the outer-most IPv6 header contains a RPL Option..." >> >> This text would imply that any RPL node sending packets to nodes outside should always tunnel to the Root ? Is that the intention really or am I missing something here.. >> >> Also note that if non-RPL Host is not considered part of the RPL domain, then I am not sure that a forwarding router can know if the destination is inside the domain or not. >> >> >> -Regards, Joseph >> >> >> ------------------------------ >> >> Message: 5 >> Date: Tue, 11 Oct 2011 22:23:10 -0700 >> From: Jonathan Hui >> To: IETF IPv6 Mailing List >> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >> Content-Type: text/plain; charset=us-ascii >> >> >> This update is intended to address Jari Arkko's AD review. >> >> Summary of changes: >> - Clarify when the RPL Option is used. >> - Updated text on recommendations for avoiding fragmentation. >> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >> - Specify RPL Border Router operations in terms of forwarding decision outcomes. >> - Expand security section. >> >> -- >> Jonathan Hui >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Date: October 11, 2011 10:17:15 PM PDT >>> To: i-d-announce@ietf.org >>> Cc: ipv6@ietf.org >>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. >>> >>> Title : RPL Option for Carrying RPL Information in Data-Plane Datagrams >>> Author(s) : Jonathan W. Hui >>> JP Vasseur >>> Filename : draft-ietf-6man-rpl-option-04.txt >>> Pages : 14 >>> Date : 2011-10-11 >>> >>> The RPL protocol requires data-plane datagrams to carry RPL routing >>> information that is processed by RPL routers when forwarding those >>> datagrams. This document describes the RPL Option for use within a >>> RPL domain. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=296325093=mukul@uwm.edu Thu Nov 17 19:25:24 2011 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 6DF3A11E80A5 for ; Thu, 17 Nov 2011 19:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 494GM-32mn22 for ; Thu, 17 Nov 2011 19:25:24 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id D77D511E8098 for ; Thu, 17 Nov 2011 19:25:23 -0800 (PST) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 17 Nov 2011 21:25:23 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 8047112E3BC; Thu, 17 Nov 2011 21:25:23 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V943KcycbvHK; Thu, 17 Nov 2011 21:25:23 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 57C7712E3BD; Thu, 17 Nov 2011 21:25:23 -0600 (CST) Date: Thu, 17 Nov 2011 21:25:23 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <1151171117.342832.1321586723289.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <515DB1E3-B860-410C-A417-7C1C5E684B23@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] RPL instance as the boundary for RPL option/source route header X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 03:25:24 -0000 Hi Jonathan >> Couple of queries: >> >> 1) A packet with an RPL option cant cross the RPL instance it was generated in. Here, are n't you implicitly assuming that RPLInstanceID is global? What happens when RPLInstanceID is local? In that case, I wonder if a packet with an RPL option must not leave the set of DODAGs identified by RPLInstanceID and the DODAGID (same as source's IPv6 address)? >No assumption that RPL Instance ID is global. The tunnel exit-point must be within the same RPL Instance as the tunnel entry-point. If the original packet needs to be forwarded outside the RPL Instance, then it must exit the tunnel and therefore strip the RPL Option. That is true whether the instance is global or local. This makes sense now. >> 2) How do you define the RPL instance that constitutes the boundaries that a packet with RPL Source Route header must not cross? SRH does not have any field for RPLInstanceID. >You are correct. I guess "RPL domain" was the better terminology here. If you agree with my proposed definition of "RPL domain", I can make the change in the next revision. As I mentioned I agree with the definition of "RPL domain" you mentioned earlier. So, please make the change. Thanks Mukul -- Jonathan Hui From jpv@cisco.com Mon Nov 21 11:15:41 2011 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 C6DFB21F8B6F for ; Mon, 21 Nov 2011 11:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.31 X-Spam-Level: X-Spam-Status: No, score=-106.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, 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 Oms-kZGLD9pb for ; Mon, 21 Nov 2011 11:15:37 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8851821F8B66 for ; Mon, 21 Nov 2011 11:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=263; q=dns/txt; s=iport; t=1321902936; x=1323112536; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=HgWVtCTHyB5j4TQLdPquz4ljDsyLLaGPbCjizCeQcIk=; b=QeVyR73PkNOajT/GboR7r89p/qoRT0EDxrqBxy4UdwmrgPAuSOcoQBt1 jkfK8LWPJ4TYO9yFkL5Xn5Nqb01bClVQirmI8bmEw/6VyVoyOBEWUiOgF L6lhrv9ZkseqOvXJ+2KZVjpmffFxX7U92XgnDE2mdlF1PW3J/GgSVn0gs k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsGANaiyk6rRDoH/2dsb2JhbABDnnIDi0iBBYILASc/gT4cGYdplg8Bnk6JNGMElDyFPQmMQA X-IronPort-AV: E=Sophos;i="4.69,548,1315180800"; d="scan'208";a="13800103" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 21 Nov 2011 19:15:36 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pALJFaNO007785; Mon, 21 Nov 2011 19:15:36 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 11:15:35 -0800 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 11:15:35 -0800 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2011 20:15:33 +0100 Message-Id: <2BDD2284-F58B-46E5-B119-FFAC9AD98601@cisco.com> To: roll WG Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-OriginalArrivalTime: 21 Nov 2011 19:15:35.0638 (UTC) FILETIME=[F24E7F60:01CCA881] Subject: [Roll] Minutes IETF-82 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 19:15:41 -0000 Hi, The Minutes of the ROLL IETF-82 meetings have been uploaded: = http://www.ietf.org/proceedings/82/minutes/roll.txt If you have any comments, please provide your comments by Nov 30 noon = ET. Many Thanks to Dan for the minutes ! Cheers. JP.= From ietf@thomasclausen.org Wed Nov 23 00:40:53 2011 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 70C3221F8C0D for ; Wed, 23 Nov 2011 00:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 G5K6Fx4rmNkl for ; Wed, 23 Nov 2011 00:40:53 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 07BD021F8C0C for ; Wed, 23 Nov 2011 00:40:53 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C7003CCFE2 for ; Wed, 23 Nov 2011 00:40:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 0A9931BD5C02; Wed, 23 Nov 2011 00:40:52 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 55A2E1BD5BDB; Wed, 23 Nov 2011 00:40:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Thomas Clausen In-Reply-To: <2BDD2284-F58B-46E5-B119-FFAC9AD98601@cisco.com> Date: Wed, 23 Nov 2011 09:40:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5A4EAC78-A568-4DBE-8D39-04D618999A26@thomasclausen.org> References: <2BDD2284-F58B-46E5-B119-FFAC9AD98601@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1251.1) Cc: roll WG Subject: Re: [Roll] Minutes IETF-82 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 08:40:53 -0000 Dear JP, all, I am concerned that the minutes are rather brief and high-level, and do = not reflect in sufficient detail the issues that were discussed and = capture the questions which were brought forward. I would suggest = revising the minutes to better capture the discussions for posterity. For example, and I will give but one example, but it applies throughout: = for item 2, the minutes do not capture the issue that was given a lot of = microphone-time: whether this document is supposed to be providing = deployment guidelines and parametrization of RPL so as to make it = operational in a given environment - or, rather, be a "marketing = document".=20 I recall mentioning at the mike that the WG chairs previously promised = the applicability documents as the place where all (e.g.) my worries = about how to make RPL work in the different deployments (or, even, if = RPL could work in these deployments) would be laid to rest by explaining = exactly how to parametrize RPL for these deployments. I also recall = expressing some disappointment that this applicability document in its = present form doesn't offer any of these guidelines whatsoever - but = rather satisfies itself by asserting (as Geoff Mulligan pointed out at = the mike) that the protocol works. Adrian Farrel (RTG AD) suggested at the mike that the document in its = present form should aim for Informational - which, probably, is = appropriate. However I also asked at the mike where, then, the = "explaining exactly how to parametrize RPL for these deployments", which = had been promised, would appear. (And, didn't get any answer to that = question=85.) On the very same item, I see that the draft being discussed is indicated = as "draft-popa-roll-applicability-ami-04" - whereas I see in the tools = server that "draft-ietf-roll-applicability-ami-04" exists -- are they = different documents? Same documents with different names? Was the = draft-ietf- version withdrawn?=20 Thank you in advance for your consideration of these comments for the = minutes, Respectfully yours, Thomas On Nov 21, 2011, at 8:15 PM, JP Vasseur wrote: > Hi, >=20 > The Minutes of the ROLL IETF-82 meetings have been uploaded: = http://www.ietf.org/proceedings/82/minutes/roll.txt >=20 > If you have any comments, please provide your comments by Nov 30 noon = ET. >=20 > Many Thanks to Dan for the minutes ! >=20 > Cheers. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.uh.edu Wed Nov 23 10:06:07 2011 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 4130821F8B66 for ; Wed, 23 Nov 2011 10:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeLiEdZxbsHJ for ; Wed, 23 Nov 2011 10:06:06 -0800 (PST) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5D221F8ADC for ; Wed, 23 Nov 2011 10:06:06 -0800 (PST) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 8D90C23CA7E for ; Wed, 23 Nov 2011 12:06:06 -0600 (CST) 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 VqSy8SXBvzBH for ; Wed, 23 Nov 2011 12:06:06 -0600 (CST) Received: from it.cs.uh.edu (it.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 3814623CA7F for ; Wed, 23 Nov 2011 12:06:03 -0600 (CST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by it.cs.uh.edu (Postfix) with ESMTP id 59FE32A280CC for ; Wed, 23 Nov 2011 12:24:36 -0600 (CST) Received: by qyk32 with SMTP id 32so1706405qyk.31 for ; Wed, 23 Nov 2011 10:06:01 -0800 (PST) Received: by 10.68.47.4 with SMTP id z4mr9959218pbm.39.1322071561069; Wed, 23 Nov 2011 10:06:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.134.17 with HTTP; Wed, 23 Nov 2011 10:05:40 -0800 (PST) From: Omprakash Gnawali Date: Wed, 23 Nov 2011 12:05:40 -0600 Message-ID: To: Thomas Clausen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: roll WG Subject: [Roll] parameterizing RPL for deployments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 18:06:07 -0000 Thanks Thomas about the details of the discussions at IETF 82. I just want to remind the WG about a draft that is collecting recommendations and explanations on how to configure RPL: http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-02 - om_p On Wed, Nov 23, 2011 at 2:40 AM, Thomas Clausen wr= ote: > Dear JP, all, > > I am concerned that the minutes are rather brief and high-level, and do n= ot reflect in sufficient detail the issues that were discussed and capture = the questions which were brought forward. I would suggest revising the minu= tes to better capture the discussions for posterity. > > > For example, and I will give but one example, but it applies throughout: = for item 2, the minutes do not capture the issue that was given a lot of mi= crophone-time: whether this document is supposed to be providing deployment= guidelines and parametrization of RPL so as to make it operational in a gi= ven environment - or, rather, be a "marketing document". > > I recall mentioning at the mike that the WG chairs previously promised th= e applicability documents as the place where all (e.g.) my worries about ho= w to make RPL work in the different deployments (or, even, if RPL could wor= k in these deployments) would be laid to rest by explaining exactly how to = parametrize RPL for these deployments. I also recall expressing some disapp= ointment that this applicability document in its present form doesn't offer= any of these guidelines whatsoever - but rather satisfies itself by assert= ing (as Geoff Mulligan pointed out at the mike) that the protocol works. > > Adrian Farrel (RTG AD) suggested at the mike =A0that the document in its = present form should aim for Informational - which, probably, is appropriate= . However I also asked at the mike where, then, the "explaining exactly how= to parametrize RPL for these deployments", which had been promised, would = appear. (And, didn't get any answer to that question=85.) > > On the very same item, I see that the draft being discussed is indicated = as "draft-popa-roll-applicability-ami-04" - whereas I see in the tools serv= er that "draft-ietf-roll-applicability-ami-04" exists -- are they different= documents? Same documents with different names? Was the draft-ietf- versio= n withdrawn? > > Thank you in advance for your consideration of these comments for the min= utes, > > Respectfully yours, > > Thomas > > On Nov 21, 2011, at 8:15 PM, JP Vasseur wrote: > >> Hi, >> >> The Minutes of the ROLL IETF-82 meetings have been uploaded: http://www.= ietf.org/proceedings/82/minutes/roll.txt >> >> If you have any comments, please provide your comments by Nov 30 noon ET= . >> >> Many Thanks to Dan for the minutes ! >> >> Cheers. >> >> JP. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From ietf@thomasclausen.org Wed Nov 23 10:25:34 2011 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 1112F11E8099 for ; Wed, 23 Nov 2011 10:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 GnVK8RUO4RNU for ; Wed, 23 Nov 2011 10:25:33 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB5311E807F for ; Wed, 23 Nov 2011 10:25:33 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 3BD4ECD17E for ; Wed, 23 Nov 2011 10:25:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 79D4D1BDC017; Wed, 23 Nov 2011 10:25:30 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 0C34E1BDC011; Wed, 23 Nov 2011 10:25:28 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Thomas Clausen In-Reply-To: Date: Wed, 23 Nov 2011 19:25:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <795205D3-705D-43D0-9168-7EBE5E8F94DA@thomasclausen.org> References: To: Omprakash Gnawali X-Mailer: Apple Mail (2.1251.1) Cc: roll WG Subject: Re: [Roll] parameterizing RPL for deployments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 18:25:34 -0000 Ompra, This I-D is actually much much closer to what I would like to see the WG = produce as part of the applicability statements. I would encourage that = this work be continued in the WG=85. Thomas On Nov 23, 2011, at 7:05 PM, Omprakash Gnawali wrote: > Thanks Thomas about the details of the discussions at IETF 82. I just > want to remind the WG about a draft that is collecting recommendations > and explanations on how to configure RPL: >=20 > http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-02 >=20 > - om_p >=20 > On Wed, Nov 23, 2011 at 2:40 AM, Thomas Clausen = wrote: >> Dear JP, all, >>=20 >> I am concerned that the minutes are rather brief and high-level, and = do not reflect in sufficient detail the issues that were discussed and = capture the questions which were brought forward. I would suggest = revising the minutes to better capture the discussions for posterity. >>=20 >>=20 >> For example, and I will give but one example, but it applies = throughout: for item 2, the minutes do not capture the issue that was = given a lot of microphone-time: whether this document is supposed to be = providing deployment guidelines and parametrization of RPL so as to make = it operational in a given environment - or, rather, be a "marketing = document". >>=20 >> I recall mentioning at the mike that the WG chairs previously = promised the applicability documents as the place where all (e.g.) my = worries about how to make RPL work in the different deployments (or, = even, if RPL could work in these deployments) would be laid to rest by = explaining exactly how to parametrize RPL for these deployments. I also = recall expressing some disappointment that this applicability document = in its present form doesn't offer any of these guidelines whatsoever - = but rather satisfies itself by asserting (as Geoff Mulligan pointed out = at the mike) that the protocol works. >>=20 >> Adrian Farrel (RTG AD) suggested at the mike that the document in = its present form should aim for Informational - which, probably, is = appropriate. However I also asked at the mike where, then, the = "explaining exactly how to parametrize RPL for these deployments", which = had been promised, would appear. (And, didn't get any answer to that = question=85.) >>=20 >> On the very same item, I see that the draft being discussed is = indicated as "draft-popa-roll-applicability-ami-04" - whereas I see in = the tools server that "draft-ietf-roll-applicability-ami-04" exists -- = are they different documents? Same documents with different names? Was = the draft-ietf- version withdrawn? >>=20 >> Thank you in advance for your consideration of these comments for the = minutes, >>=20 >> Respectfully yours, >>=20 >> Thomas >>=20 >> On Nov 21, 2011, at 8:15 PM, JP Vasseur wrote: >>=20 >>> Hi, >>>=20 >>> The Minutes of the ROLL IETF-82 meetings have been uploaded: = http://www.ietf.org/proceedings/82/minutes/roll.txt >>>=20 >>> If you have any comments, please provide your comments by Nov 30 = noon ET. >>>=20 >>> Many Thanks to Dan for the minutes ! >>>=20 >>> Cheers. >>>=20 >>> JP. >>> _______________________________________________ >>> 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 From trakadasp@yahoo.gr Wed Nov 23 10:52:04 2011 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 E9E4621F8B1E for ; Wed, 23 Nov 2011 10:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.116 X-Spam-Level: X-Spam-Status: No, score=0.116 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 xClT2yAvMHjz for ; Wed, 23 Nov 2011 10:52:04 -0800 (PST) Received: from nm24-vm5.bullet.mail.ird.yahoo.com (nm24-vm5.bullet.mail.ird.yahoo.com [212.82.109.196]) by ietfa.amsl.com (Postfix) with SMTP id D077821F8B1D for ; Wed, 23 Nov 2011 10:52:03 -0800 (PST) Received: from [77.238.189.231] by nm24.bullet.mail.ird.yahoo.com with NNFMP; 23 Nov 2011 18:51:54 -0000 Received: from [212.82.108.242] by tm12.bullet.mail.ird.yahoo.com with NNFMP; 23 Nov 2011 18:51:54 -0000 Received: from [127.0.0.1] by omp1007.mail.ird.yahoo.com with NNFMP; 23 Nov 2011 18:51:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 9186.1883.bm@omp1007.mail.ird.yahoo.com Received: (qmail 93627 invoked by uid 60001); 23 Nov 2011 18:51:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s1024; t=1322074313; bh=LesXx4Lqed5PdmbUmwieJdGcck6hugGpDr+2911LUeI=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Xnc2Nj7AZLUHt++lsV2LCMXamnJsnBBr63FSjE2cXjAmN1oPnJFRBebq75akMdKhqBeQxqmkt7BcafP8J3bek6eldVrKt8ht/VsYMdhbnS+/45+fTasqDzwo+CA2j3osSKfNF3CNyYjUNF+igftNRLTtkgnr+ER+z3JU8I4+HMI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.gr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=ldcGPo2lpiZUnw7Ab0T3AidLAU8a21HlIMgFszofxVgXUfsWWVwCeq+FkqAQudVFfQiee+KqHVbxcINRK84RUzcXeeEdIBUUDBNn/vHuHRPvfxZS69mdtEMl9sLYeghjAIVLvGwvEFXK8gdbS9GLvh5dhthi/QbCCOPYAd7sWj8=; X-YMail-OSG: VcGJu_UVM1noevt59lGCX3Qz3avk2u2aXUvqCgVffVKpgBM W8C_hnKsBZa42i2hcG2Cx53w7PUZbh9nctTf7nW5Vdogdew94VPPqufodFeK bxMqCyPNFYPuNR7P99XXC_obZYnWhyt2nkpmhC0WkaGwjkWCMgpLBMYUF_K3 KdzGZSzBrvw.Ws6gNYKr4vDJEaLg2xbRSbKXWHZXa3Wso4h3eXgftfZvuJn1 buiBsVI1.3gjRcU1FI.hNLBTd_ubGTSm0CGXDiJtzds13jBHNP2C2r1LlS5h xns3OKefgYiXxF4r.Vob.6JHFlb6pwnACdB7YP1jTcYekeCuxz1w4GZoPp3L jkJChlsKPspLlBWpAFczvuojlT.KxSJ2gC9.EG6PDb_TvsQwU5qeUGH16Pqy wUbpTP_zlenAahjA- Received: from [46.177.22.197] by web29616.mail.ird.yahoo.com via HTTP; Wed, 23 Nov 2011 18:51:53 GMT X-Mailer: YahooMailWebService/0.8.115.331698 References: <20111123184314.28309.29962.idtracker@ietfa.amsl.com> Message-ID: <1322074313.93406.YahooMailNeo@web29616.mail.ird.yahoo.com> Date: Wed, 23 Nov 2011 18:51:53 +0000 (GMT) From: Panos Trakadas To: "roll@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="171789166-1249899958-1322074313=:93406" Subject: [Roll] =?iso-8859-7?q?=D3=F7=E5=F4=3A_New_Version_Notification_fo?= =?iso-8859-7?q?r_draft-zahariadis-roll-metrics-composition-02=2Etxt?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Panos Trakadas List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 18:52:05 -0000 --171789166-1249899958-1322074313=:93406 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable Hi all,=0A=0AWe posted an updated version of "Design Principles for Routing= Metrics Composition in LLN", taking into consideration and incorporating c= omments from several ROLL WG members.=0AChanges from previous version:=0A1.= Metric values in Figures 2 and 3.=0A2. Definition and inclusion of RSSI me= tric.=0A3. New Figure 7 to show impact by adopting a non-isotonic composite= metric.=0A4. Corrected typos throughout the text.=0A=0AWe are looking forw= ard for additional comments.=0A=0AThanks,=0APanos.=0A=0A=0A________________= ________________=0A =C1=F0=EF: "internet-drafts@ietf.org" =0A=D0=F1=EF=F2: trakadasp@yahoo.gr =0A=CA=EF=E9=ED.: trakadasp@ad= ae.gr; zahariad@teihal.gr; trakadasp@yahoo.gr =0A=D3=F4=DC=EB=E8=E7=EA=E5: = 8:43 =EC.=EC. =D4=E5=F4=DC=F1=F4=E7, 23 =CD=EF=E5=EC=E2=F1=DF=EF=F5 2011=0A= =C8=E5=EC=E1: New Version Notification for draft-zahariadis-roll-metrics-co= mposition-02.txt=0A =0AA new version of I-D, draft-zahariadis-roll-metrics-= composition-02.txt has been successfully submitted by Panos Trakadas and po= sted to the IETF repository.=0A=0AFilename:=A0=A0=A0 =0A draft-zahariadis-r= oll-metrics-composition=0ARevision:=A0=A0=A0 02=0ATitle:=A0=A0=A0 =A0=A0= =A0 Design Guidelines for Routing Metrics Composition in LLN=0ACreation da= te:=A0=A0=A0 2011-11-23=0AWG ID:=A0=A0=A0 =A0=A0=A0 Individual Submission= =0ANumber of pages: 20=0A=0AAbstract:=0A=A0 This document specifies the gu= idelines for designing efficient=0A=A0 composite routing metrics to be app= lied to the Routing for Low Power=0A=A0 and Lossy Networks (RPL) routing p= rotocol.=0A=0A=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=0A=0AThe IETF Secretariat --171789166-1249899958-1322074313=:93406 Content-Type: text/html; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable
Hi all,
We posted an updated version of "Design Princip= les for Routing Metrics Composition in LLN", taking into consideration and = incorporating comments from several ROLL WG members.
Changes from previous version:
1. Metric values in Figur= es 2 and 3.
2. Definition and= inclusion of RSSI metric.
3.= New=0A Figure 7 to show impact by adopting a non-isotonic composite metric= .
4. Corrected typos througho= ut the text.

We are looking forward for additional co= mments.
<= span id=3D"yiv2039822560yui_3_2_0_15_132206029241381">
Thanks,
Panos.

=C1=F0=EF: "internet-drafts@ietf.o= rg" <internet-drafts@ietf.org>
=D0=F1=EF=F2: trakadasp@yahoo.gr
=CA=EF=E9=ED.: trakadasp@adae.gr; zahariad@teihal= .gr; trakadasp@yahoo.gr
=D3=F4= =DC=EB=E8=E7=EA=E5: 8:43 =EC.=EC. =D4=E5=F4=DC=F1=F4=E7, 23 =CD= =EF=E5=EC=E2=F1=DF=EF=F5 2011
=C8= =E5=EC=E1: New Version Notification for draft-zahariadis-roll-me= trics-composition-02.txt
A new version of I-D, draft-zahariadis-roll-metrics-composition-02.txt has been successfully sub= mitted by Panos Trakadas and posted to the IETF repository.

Filename= :    =0A draft-zahariadis-roll-metrics-composition
Revisi= on:    02
Title:        D= esign Guidelines for Routing Metrics Composition in LLN
Creation date:&n= bsp;   2011-11-23
WG ID:       = Individual Submission
Number of pages: 20

Abstract:
  = This document specifies the guidelines for designing efficient
  c= omposite routing metrics to be applied to the Routing for Low Power
&nbs= p; and Lossy Networks (RPL) routing protocol.


    &nb= sp;                     &= nbsp;                    =                     &nbs= p;            


The IETF Secretari= at


--171789166-1249899958-1322074313=:93406-- From prvs=30246f852=mukul@uwm.edu Thu Nov 24 10:29:48 2011 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 E95F321F8C3D for ; Thu, 24 Nov 2011 10:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 RelCpaLDMqjC for ; Thu, 24 Nov 2011 10:29:47 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id DF07B21F8C3C for ; Thu, 24 Nov 2011 10:29:46 -0800 (PST) Received: from localhost (HELO mta01.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 24 Nov 2011 12:29:45 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id DF762E6A75; Thu, 24 Nov 2011 12:29:45 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0kh2IvLC6Zr; Thu, 24 Nov 2011 12:29:45 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 78DC6E6A74; Thu, 24 Nov 2011 12:29:45 -0600 (CST) Date: Thu, 24 Nov 2011 12:29:45 -0600 (CST) From: Mukul Goyal To: Jonathan Hui Message-ID: <979084170.409806.1322159385346.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <9832945.342738.1321585807730.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 18:29:49 -0000 Hi Jonathan, JP Just wondering if you could confirm that the next version of the terminology draft will have this definition of RPL domain included. This would allow me to refer to the terminology draft for the definition of RPL domain in the p2p-measurement draft. Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "Jonathan Hui" Cc: "roll" Sent: Thursday, November 17, 2011 9:10:07 PM Subject: Re: [Roll] definition of "RPL Domain" I agree with this definition of RPL domain. The definition implies that RPL devices may have links/interfaces that are considered exterior to the RPL domain. Thanks Mukul ----- Original Message ----- From: "Jonathan Hui" To: "Mukul Goyal" Cc: "JP Vasseur" , "roll" Sent: Wednesday, November 16, 2011 7:37:32 AM Subject: Re: [Roll] definition of "RPL Domain" How about a definition derived from RFC 1629: A "RPL domain" is a routing domain, as stated in Section 3.2 of RFC 1629, where the common routing protocol is RPL. The above definition would unambiguously give the following answers to your questions: 1) Given the definition above, devices that do not operate RPL are not a part of the RPL domain. 2) Because RPL devices may support more than one instance, a RPL domain may contain any number of instances. The term seems to be used most often in draft-ietf-roll-p2p-measurement. I suggest going through and verifying whether "RPL Instance" or "RPL domain" was intended. Happy to see any alternative definitions you may have in mind. -- Jonathan Hui On Nov 16, 2011, at 2:45 AM, Mukul Goyal wrote: > Hi JP > >> RPL domain: set of devices using RPL as a routing protocol. > > I think this definition is little too vague. Some of the points that need clarification: > > 1. It is clear that RPL hosts and routers (as defined towards the end of terminology section in RPL-19) are within an RPL domain but what about the RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagine that such hosts are also within an RPL domain. > > 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or is it that an RPL domain is same as an LLN using RPL as a routing protocol? > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: "roll" > Sent: Wednesday, November 16, 2011 2:33:50 AM > Subject: Re: definition of "RPL Domain" > > Hi Mukul, > > On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: > >> Hi JP >> >> I was wondering if the term "RPL Domain" could be defined in the terminology draft. >> > > How about > > RPL domain: set of devices using RPL as a routing protocol. > > Thanks. > > JP. > >> Thanks >> Mukul >> >> ----- Forwarded Message ----- >> From: "Joseph Reddy" >> To: ipv6@ietf.org >> Sent: Friday, October 14, 2011 7:15:05 PM >> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> >> >> Hi Jonathan, >> >> The draft uses the term "RPL domain" in several places and this is not clearly defined. >> >> I would imagine that it includes all nodes that are downstream of the RPL border router. But can you clarify if Host nodes that are downstream of the border router but do not implement any part of RPL ( even as RPL Leaf nodes ) should be considered part of the "RPL domain" ? >> >> In section 5, the draft now says "..Datagrams destined to nodes outside the RPL domain are dropped if the outer-most IPv6 header contains a RPL Option..." >> >> This text would imply that any RPL node sending packets to nodes outside should always tunnel to the Root ? Is that the intention really or am I missing something here.. >> >> Also note that if non-RPL Host is not considered part of the RPL domain, then I am not sure that a forwarding router can know if the destination is inside the domain or not. >> >> >> -Regards, Joseph >> >> >> ------------------------------ >> >> Message: 5 >> Date: Tue, 11 Oct 2011 22:23:10 -0700 >> From: Jonathan Hui >> To: IETF IPv6 Mailing List >> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >> Content-Type: text/plain; charset=us-ascii >> >> >> This update is intended to address Jari Arkko's AD review. >> >> Summary of changes: >> - Clarify when the RPL Option is used. >> - Updated text on recommendations for avoiding fragmentation. >> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >> - Specify RPL Border Router operations in terms of forwarding decision outcomes. >> - Expand security section. >> >> -- >> Jonathan Hui >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Date: October 11, 2011 10:17:15 PM PDT >>> To: i-d-announce@ietf.org >>> Cc: ipv6@ietf.org >>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. >>> >>> Title : RPL Option for Carrying RPL Information in Data-Plane Datagrams >>> Author(s) : Jonathan W. Hui >>> JP Vasseur >>> Filename : draft-ietf-6man-rpl-option-04.txt >>> Pages : 14 >>> Date : 2011-10-11 >>> >>> The RPL protocol requires data-plane datagrams to carry RPL routing >>> information that is processed by RPL routers when forwarding those >>> datagrams. This document describes the RPL Option for use within a >>> RPL domain. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > _______________________________________________ > 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 jpv@cisco.com Fri Nov 25 05:47:07 2011 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 45DBA21F8C81 for ; Fri, 25 Nov 2011 05:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.767 X-Spam-Level: X-Spam-Status: No, score=-105.767 tagged_above=-999 required=5 tests=[AWL=-3.168, 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 6oeOMsF0Oozx for ; Fri, 25 Nov 2011 05:47:06 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 585B621F8C7E for ; Fri, 25 Nov 2011 05:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=7958; q=dns/txt; s=iport; t=1322228825; x=1323438425; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7kIA1yCUUimetIpfzDLNQM4CPH7OlrTykGxQ1Y3d9pw=; b=C8tt8ykufIZ5H8vsnS9Xen6r84NbRlyJFOY2HlPnNwOsgglTV8Vhc5/Q Aj3gWQzocz4etamnW2O9kXhWhujHg+M6cjAFNA8TViFJKgHz7Wd+usjEs gM8xEKVukb7LYuGEZKoqRfNUL7YP52aqGX+uX43n5hoIjzrhOfjSsEpxz I=; X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; d="scan'208";a="215753" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 25 Nov 2011 13:47:04 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAPDl3vE009352; Fri, 25 Nov 2011 13:47:03 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Nov 2011 21:47:03 +0800 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Nov 2011 21:47:02 +0800 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <979084170.409806.1322159385346.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Fri, 25 Nov 2011 14:47:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <979084170.409806.1322159385346.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1251.1) X-OriginalArrivalTime: 25 Nov 2011 13:47:02.0754 (UTC) FILETIME=[B62A1C20:01CCAB78] Cc: roll Subject: Re: [Roll] definition of "RPL Domain" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 13:47:07 -0000 Hi, On Nov 24, 2011, at 7:29 PM, Mukul Goyal wrote: > Hi Jonathan, JP >=20 > Just wondering if you could confirm that the next version of the = terminology draft will have this definition of RPL domain included. This = would allow me to refer to the terminology draft for the definition of = RPL domain in the p2p-measurement draft. >=20 Nice, I'll summarize the discussion and make sure that everybody agrees = before submitting (soon). Thanks. JP. > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Mukul Goyal" > To: "Jonathan Hui" > Cc: "roll" > Sent: Thursday, November 17, 2011 9:10:07 PM > Subject: Re: [Roll] definition of "RPL Domain" >=20 > I agree with this definition of RPL domain. The definition implies = that RPL devices may have links/interfaces that are considered exterior = to the RPL domain. >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Jonathan Hui" > To: "Mukul Goyal" > Cc: "JP Vasseur" , "roll" > Sent: Wednesday, November 16, 2011 7:37:32 AM > Subject: Re: [Roll] definition of "RPL Domain" >=20 >=20 > How about a definition derived from RFC 1629: > A "RPL domain" is a routing domain, as stated in Section 3.2 of RFC = 1629, where the common routing protocol is RPL. >=20 > The above definition would unambiguously give the following answers to = your questions: > 1) Given the definition above, devices that do not operate RPL are not = a part of the RPL domain. > 2) Because RPL devices may support more than one instance, a RPL = domain may contain any number of instances. >=20 > The term seems to be used most often in = draft-ietf-roll-p2p-measurement. I suggest going through and verifying = whether "RPL Instance" or "RPL domain" was intended. >=20 > Happy to see any alternative definitions you may have in mind. >=20 > -- > Jonathan Hui >=20 > On Nov 16, 2011, at 2:45 AM, Mukul Goyal wrote: >=20 >> Hi JP >>=20 >>> RPL domain: set of devices using RPL as a routing protocol. >>=20 >> I think this definition is little too vague. Some of the points that = need clarification: >>=20 >> 1. It is clear that RPL hosts and routers (as defined towards the end = of terminology section in RPL-19) are within an RPL domain but what = about the RPL-unaware IPv6 hosts attached to an RPL router/host? I would = imagine that such hosts are also within an RPL domain. >>=20 >> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a = set of RPL instances in the LLN? Can multiple RPL domains exist within = an LLN? Or is it that an RPL domain is same as an LLN using RPL as a = routing protocol? >>=20 >> Thanks >> Mukul =20 >>=20 >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "Mukul Goyal" >> Cc: "roll" >> Sent: Wednesday, November 16, 2011 2:33:50 AM >> Subject: Re: definition of "RPL Domain" >>=20 >> Hi Mukul, >>=20 >> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote: >>=20 >>> Hi JP >>>=20 >>> I was wondering if the term "RPL Domain" could be defined in the = terminology draft.=20 >>>=20 >>=20 >> How about >>=20 >> RPL domain: set of devices using RPL as a routing protocol. >>=20 >> Thanks. >>=20 >> JP. >>=20 >>> Thanks >>> Mukul=20 >>>=20 >>> ----- Forwarded Message ----- >>> From: "Joseph Reddy" >>> To: ipv6@ietf.org >>> Sent: Friday, October 14, 2011 7:15:05 PM >>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>=20 >>>=20 >>> Hi Jonathan, >>>=20 >>> The draft uses the term "RPL domain" in several places and this is = not clearly defined.=20 >>>=20 >>> I would imagine that it includes all nodes that are downstream of = the RPL border router. But can you clarify if Host nodes that are = downstream of the border router but do not implement any part of RPL ( = even as RPL Leaf nodes ) should be considered part of the "RPL domain" ? >>>=20 >>> In section 5, the draft now says "..Datagrams destined to nodes = outside the RPL domain are dropped if the outer-most IPv6 header = contains a RPL Option..." >>>=20 >>> This text would imply that any RPL node sending packets to nodes = outside should always tunnel to the Root ? Is that the intention really = or am I missing something here..=20 >>>=20 >>> Also note that if non-RPL Host is not considered part of the RPL = domain, then I am not sure that a forwarding router can know if the = destination is inside the domain or not.=20 >>>=20 >>>=20 >>> -Regards, Joseph >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> Message: 5 >>> Date: Tue, 11 Oct 2011 22:23:10 -0700 >>> From: Jonathan Hui >>> To: IETF IPv6 Mailing List >>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt >>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> >>> Content-Type: text/plain; charset=3Dus-ascii >>>=20 >>>=20 >>> This update is intended to address Jari Arkko's AD review. >>>=20 >>> Summary of changes: >>> - Clarify when the RPL Option is used. >>> - Updated text on recommendations for avoiding fragmentation. >>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs. >>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. >>> - Specify RPL Border Router operations in terms of forwarding = decision outcomes. >>> - Expand security section. >>>=20 >>> -- >>> Jonathan Hui >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Date: October 11, 2011 10:17:15 PM PDT >>>> To: i-d-announce@ietf.org >>>> Cc: ipv6@ietf.org >>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Maintenance Working = Group of the IETF. >>>>=20 >>>> Title : RPL Option for Carrying RPL Information in = Data-Plane Datagrams >>>> Author(s) : Jonathan W. Hui >>>> JP Vasseur >>>> Filename : draft-ietf-6man-rpl-option-04.txt >>>> Pages : 14 >>>> Date : 2011-10-11 >>>>=20 >>>> The RPL protocol requires data-plane datagrams to carry RPL routing >>>> information that is processed by RPL routers when forwarding those >>>> datagrams. This document describes the RPL Option for use within a >>>> RPL domain. >>>>=20 >>>>=20 >>>> A URL for this Internet-Draft is: >>>> = http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> This Internet-Draft can be retrieved at: >>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Sat Nov 26 14:36:26 2011 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 DFA8D21F8B7B for ; Sat, 26 Nov 2011 14:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.033 X-Spam-Level: X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[AWL=-1.518, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] 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 Xg7XB9HiDrU7 for ; Sat, 26 Nov 2011 14:36:26 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7E421F8B49 for ; Sat, 26 Nov 2011 14:36:25 -0800 (PST) Received: from marajade.sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id 1E980343DB for ; Sat, 26 Nov 2011 17:34:51 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 2973398CC5; Sat, 26 Nov 2011 17:36:31 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 24A7798CB4 for ; Sat, 26 Nov 2011 17:36:31 -0500 (EST) From: Michael Richardson To: roll@ietf.org X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Sat, 26 Nov 2011 17:36:30 -0500 Message-ID: <22330.1322346990@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] roll-rpl-mib-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 22:36:27 -0000 I did a brief review of sehgal-roll-rpl-mib-01. (I note that it has now officially expired from the ID repository) I do not believe that the WG make a clear decision about whether or not to adopt it, with many, including myself, wondering if it will really even live in real devices. I know that the authors have implemented this Contiki, so perhaps it would fit in many places. I am not a MIB lawyer, and I don't play one on TV. So, I mostly focused on section 4. My single comment is that it appears that there are no counters or other structures to deal with the secure forms of the RPL messages. Specifically for failures to hash, authenticate, and lists of nodes that might be sending messages with incorrect keys. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From yoav@yitran.com Mon Nov 28 06:01:50 2011 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 434DA21F8BDB for ; Mon, 28 Nov 2011 06:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 3ZWBxrCs8Zhv for ; Mon, 28 Nov 2011 06:01:49 -0800 (PST) Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) by ietfa.amsl.com (Postfix) with SMTP id 56E1D21F8BDC for ; Mon, 28 Nov 2011 06:01:48 -0800 (PST) Received: from mail-ey0-f169.google.com ([209.85.215.169]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKTtOUQ3dFocndN0n+jxoosrEG2jO8Orre@postini.com; Mon, 28 Nov 2011 06:01:48 PST Received: by mail-ey0-f169.google.com with SMTP id h1so2136836eaa.0 for ; Mon, 28 Nov 2011 06:01:39 -0800 (PST) Received: by 10.180.104.35 with SMTP id gb3mr46249833wib.11.1322488899517; Mon, 28 Nov 2011 06:01:39 -0800 (PST) From: Yoav Ben-Yehezkel MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acyt1CChqlAGRWyyR8emqAQ/Xcfxkg== Date: Mon, 28 Nov 2011 15:59:35 +0200 Message-ID: <6c71e16e38119b2034498004067f3368@mail.gmail.com> To: roll@ietf.org Content-Type: multipart/alternative; boundary=f46d044267a0133c5904b2cbf12e Subject: [Roll] question about working with RPL with multiple rates X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 14:01:50 -0000 --f46d044267a0133c5904b2cbf12e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Roll-ers, I=92m working on an implementation of RPL for a power-line technology. L1/L= 2 of the technology allows to operate at different rates at the per link (by controlling modulation, coding parameters, tone masks, etc.). I was wondering if anyone had any experience working with RPL using PHY/DLL that support multiple rates? The application is a metering application where meter polling is used for data traffic, so P2MP and MP2P are used. We want to use external memory for the DODAG root with non-storing mode. I=92m mostly interested to get the WG impression on the following two issue= s: 1. I assume DIOs are sent at the lowest (and most robust) rate to cover as many potential children possible. My question is since DIOs are transmitted at robust rates to many potential children, how does the potential children know which parent is best to choose from? Does RPL assume capability to derive link quality information about a higher rate from the received DIO at lower rate by L1/L2? 2. Another question is concerning how to differentiate between links where one direction can be used at high rate vs. the link on the other direction can be used at a lower rate. If a network contains 100 routers sending DIOs at robust rate that a node receives, how does this potential child know which node to use as a preferred parent assuming potential parents can be used on the way up at the same rate, but the downward route can be used at higher rate by one of them (i.e. more optimal parent)? I=92d appreciate any thoughts the WG wishes to share on this issue. Best regards, Yoav --f46d044267a0133c5904b2cbf12e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Dear Roll-ers,

=A0

I=92m working on an implementatio= n of RPL for a power-line technology. L1/L2 of the technology allows to ope= rate at different rates at the per link (by controlling modulation, coding = parameters, tone masks, etc.).

I was wondering if anyone had any experience working= with RPL using PHY/DLL that support multiple rates?

The application is a metering application where meter polling is used = for data traffic, so P2MP and MP2P are used.

We want to use external memory for the DODAG root wi= th non-storing mode.

=A0

I=92m mostly interested to get the WG impression on the following two iss= ues:

1.=A0=A0=A0=A0=A0=A0 I assume DIOs are sent at the lowest (and most robust) rate to cover a= s many potential children possible. My question is since DIOs are transmitt= ed at robust rates to many potential children, how does the potential child= ren know which parent is best to choose from? Does RPL assume capability to= derive link quality information about a higher rate from the received DIO = at lower rate by L1/L2?

2.=A0=A0=A0=A0=A0=A0 Another question is concerning how to differentiate between links wher= e one direction can be used at high rate vs. the link on the other directio= n can be used at a lower rate. If a network contains 100 routers sending DI= Os at robust rate that a node receives, how does this potential child know = which node to use as a preferred parent assuming potential parents can be u= sed on the way up at the same rate, but the downward route can be used at h= igher rate by one of them (i.e. more optimal parent)? =A0

=A0

I=92d appreciate any t= houghts the WG wishes to share on this issue.

Best regards,

Yoav

=A0

--f46d044267a0133c5904b2cbf12e-- From c.chauvenet@watteco.com Mon Nov 28 06:56:21 2011 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 E7DDF21F8B40 for ; Mon, 28 Nov 2011 06:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFYgRxemTUbP for ; Mon, 28 Nov 2011 06:56:21 -0800 (PST) Received: from TX2EHSOBE003.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 199D321F8B31 for ; Mon, 28 Nov 2011 06:56:21 -0800 (PST) Received: from mail103-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.22; Mon, 28 Nov 2011 14:55:33 +0000 Received: from mail103-tx2 (localhost [127.0.0.1]) by mail103-tx2-R.bigfish.com (Postfix) with ESMTP id E79AB180137; Mon, 28 Nov 2011 14:57:17 +0000 (UTC) X-SpamScore: -23 X-BigFish: VPS-23(zzc89bhc85eh4082Kzz1202hzz1033IL8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); SRV:BULK; H:IE2RD2HUB040.red002.local; RD:none; EFVD:NLI Received: from mail103-tx2 (localhost.localdomain [127.0.0.1]) by mail103-tx2 (MessageSwitch) id 1322492237185098_29375; Mon, 28 Nov 2011 14:57:17 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.253]) by mail103-tx2.bigfish.com (Postfix) with ESMTP id 270FCC0049; Mon, 28 Nov 2011 14:57:17 +0000 (UTC) Received: from IE2RD2HUB040.red002.local (213.199.187.153) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 28 Nov 2011 14:55:31 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB040.red002.local ([10.17.10.79]) with mapi; Mon, 28 Nov 2011 06:56:12 -0800 From: C Chauvenet To: Yoav Ben-Yehezkel Date: Mon, 28 Nov 2011 06:56:14 -0800 Thread-Topic: [Roll] question about working with RPL with multiple rates Thread-Index: Acyt3d5NBtc0f9hyTaaufjS+4Kf1GQ== Message-ID: References: <6c71e16e38119b2034498004067f3368@mail.gmail.com> In-Reply-To: <6c71e16e38119b2034498004067f3368@mail.gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_E1D659F47B7F4536ACBD46E9318A8BF5wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] question about working with RPL with multiple rates X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 14:56:22 -0000 --_000_E1D659F47B7F4536ACBD46E9318A8BF5wattecocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Yoav, The "best parent" feature is all about metrics, so you have to define a met= ric that reflects how "good" a parent is. In RPL you have 2 options : metrics defined in the metric related draft and= OF0. In OF0, you build you own metric to reflect an indicator of "how good is th= e metric". The RPL metrics draft define particular metrics, for instance, Energy, thro= ughput, latency=85 In your case, all seems to be related to data rate, so it may be good to lo= ok at the throughput metric of the metric draft. With the use of that metric, you could use throughput measurements on a lin= k to determine how good a link is in you parent selection. Note that the draft define the format of the metric container to use, but d= oes not define how to calculate the metric. You have to compute the metric yourself. Best, C=E9dric. Le 28 nov. 2011 =E0 14:59, Yoav Ben-Yehezkel a =E9crit : Dear Roll-ers, I=92m working on an implementation of RPL for a power-line technology. L1/L= 2 of the technology allows to operate at different rates at the per link (b= y controlling modulation, coding parameters, tone masks, etc.). I was wondering if anyone had any experience working with RPL using PHY/DLL= that support multiple rates? The application is a metering application where meter polling is used for d= ata traffic, so P2MP and MP2P are used. We want to use external memory for the DODAG root with non-storing mode. I=92m mostly interested to get the WG impression on the following two issue= s: 1. I assume DIOs are sent at the lowest (and most robust) rate to cov= er as many potential children possible. My question is since DIOs are trans= mitted at robust rates to many potential children, how does the potential c= hildren know which parent is best to choose from? Does RPL assume capabilit= y to derive link quality information about a higher rate from the received = DIO at lower rate by L1/L2? 2. Another question is concerning how to differentiate between links = where one direction can be used at high rate vs. the link on the other dire= ction can be used at a lower rate. If a network contains 100 routers sendin= g DIOs at robust rate that a node receives, how does this potential child k= now which node to use as a preferred parent assuming potential parents can = be used on the way up at the same rate, but the downward route can be used = at higher rate by one of them (i.e. more optimal parent)? I=92d appreciate any thoughts the WG wishes to share on this issue. Best regards, Yoav _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_E1D659F47B7F4536ACBD46E9318A8BF5wattecocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

In RPL you have 2 options : metrics defined in = the metric related draft and OF0.

In OF0, you buil= d you own metric to reflect an indicator of "how good is the metric".
=

The RPL metrics draft define particular metrics, for in= stance, Energy, throughput, latency=85

In your cas= e, all seems to be related to data rate, so it may be good to look at the t= hroughput metric of the metric draft.
With the use of that metric= , you could use throughput measurements on a link to determine how good a l= ink is in you parent selection.
Note that the draft define the fo= rmat of the metric container to use, but does not define how to calculate t= he metric.
You have to compute the metric yourself.
Best,
C=E9dric.

Le= 28 nov. 2011 =E0 14:59, Yoav Ben-Yehezkel a =E9crit :

Dear Roll-ers,

 

I=92m working on a= n implementation of RPL for a power-line technology. L1/L2 of the technolog= y allows to operate at different rates at the per link (by controlling modu= lation, coding parameters, tone masks, etc.).
I was wondering if anyone ha= d any experience working with RPL using PHY/DLL that support multiple rates= ?
We want to use external memory = for the DODAG root with non-storing mode.

 

I=92m mo= stly interested to get the WG impression on the following two issues:
=
1.       I assume DIOs are sent at the lowest (and most robust) rate to cover as= many potential children possible. My question is since DIOs are transmitte= d at robust rates to many potential children, how does the potential childr= en know which parent is best to choose from? Does RPL assume capability to = derive link quality information about a higher rate from the received DIO a= t lower rate by L1/L2?
2.   &n= bsp;   <= /span>Another question is concerning how to differ= entiate between links where one direction can be used at high rate vs. the = link on the other direction can be used at a lower rate. If a network conta= ins 100 routers sending DIOs at robust rate that a node receives, how does = this potential child know which node to use as a preferred parent assuming = potential parents can be used on the way up at the same rate, but the downw= ard route can be used at higher rate by one of them (i.e. more optimal pare= nt)?  

 

I=92d appreciate any thoughts the WG w= ishes to share on this issue.

Best regards,
Yoav
<= p class=3D"MsoNormal" style=3D"margin-top: 0in; margin-right: 0in; margin-l= eft: 0in; margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, s= ans-serif; "> 

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

= --_000_E1D659F47B7F4536ACBD46E9318A8BF5wattecocom_-- From pal@cs.stanford.edu Mon Nov 28 09:23:29 2011 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 8034021F8B4C for ; Mon, 28 Nov 2011 09:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqvq5Iqva98z for ; Mon, 28 Nov 2011 09:23:29 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0DABA21F8B4A for ; Mon, 28 Nov 2011 09:23:29 -0800 (PST) Received: from dn0a2103b4.sunet ([10.33.3.180]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1RV4vQ-0001Jh-9a; Mon, 28 Nov 2011 09:23:28 -0800 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <6c71e16e38119b2034498004067f3368@mail.gmail.com> Date: Mon, 28 Nov 2011 09:23:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <814FA4F1-3C5A-4EA3-84F3-39123430304F@cs.stanford.edu> References: <6c71e16e38119b2034498004067f3368@mail.gmail.com> To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 3134a374f3853b94094f80bd9e2b84a0 Cc: roll@ietf.org Subject: Re: [Roll] question about working with RPL with multiple rates X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 17:23:29 -0000 On Nov 28, 2011, at 5:59 AM, Yoav Ben-Yehezkel wrote: > Dear Roll-ers, > =20 > I=92m working on an implementation of RPL for a power-line technology. = L1/L2 of the technology allows to operate at different rates at the per = link (by controlling modulation, coding parameters, tone masks, etc.). > I was wondering if anyone had any experience working with RPL using = PHY/DLL that support multiple rates? > The application is a metering application where meter polling is used = for data traffic, so P2MP and MP2P are used. > We want to use external memory for the DODAG root with non-storing = mode. > =20 > I=92m mostly interested to get the WG impression on the following two = issues: > 1. I assume DIOs are sent at the lowest (and most robust) rate = to cover as many potential children possible. My question is since DIOs = are transmitted at robust rates to many potential children, how does the = potential children know which parent is best to choose from? The objective function defines how to do so, using one or more of=20 - locally measured link properties, - Rank, and=20 - metric containers. > Does RPL assume capability to derive link quality information about a = higher rate from the received DIO at lower rate by L1/L2? No. While some link/physical layers might be able to compute metrics = solely from received packets, others can't. In the wireless research = world they're called "asymmetric links," i.e., where A can hear B well = but B cannot hear A well. The assumption is that the protocol is somehow = estimating link quality. How this is done is=20 > 2. Another question is concerning how to differentiate between = links where one direction can be used at high rate vs. the link on the = other direction can be used at a lower rate. If a network contains 100 = routers sending DIOs at robust rate that a node receives, how does this = potential child know which node to use as a preferred parent assuming = potential parents can be used on the way up at the same rate, but the = downward route can be used at higher rate by one of them (i.e. more = optimal parent)? =20 You'd express this in the link metric. RPL does not assume that the = metric value of AB is the same as BA. Research tackled this a bit in = WiFi meshes, for example, by extending ETX (expected number of = transmissions) to ETT (expected time of transmission).=20 Phil= From daniel@olddog.co.uk Mon Nov 28 10:24:26 2011 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 D7E8F21F8B29 for ; Mon, 28 Nov 2011 10:24:26 -0800 (PST) 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 Sdv7t8W+kiYj for ; Mon, 28 Nov 2011 10:24:26 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id E659A21F8797 for ; Mon, 28 Nov 2011 10:24:25 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id pASIOMSX015160; Mon, 28 Nov 2011 18:24:22 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id pASIOJxu015148; Mon, 28 Nov 2011 18:24:21 GMT From: "Daniel King" To: "'Thomas Clausen'" References: <2BDD2284-F58B-46E5-B119-FFAC9AD98601@cisco.com> <5A4EAC78-A568-4DBE-8D39-04D618999A26@thomasclausen.org> In-Reply-To: <5A4EAC78-A568-4DBE-8D39-04D618999A26@thomasclausen.org> Date: Mon, 28 Nov 2011 18:24:17 -0000 Message-ID: <00b401ccadfa$f1f9f020$d5edd060$@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: AQHaCBqCQfPFzpjAo6j3BfNu/bV4hQGgDvl8lZrUQ7A= Content-language: en-gb Cc: 'roll WG' Subject: Re: [Roll] Minutes IETF-82 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 18:24:27 -0000 Hi Thomas, Firstly thank you for taking the time to review the minutes. As the minute taker let me try to respond to your concerns. My objective, as directed by the co-chairs, is to provide a synopsis of ROLL discussions. The intention is NOT to provide a verbatim record of the ROLL meeting. If anyone would like a reproduction of the session the audio is recorded and archived (http://www.ietf.org/audio/ietf82/). If you, or anyone else (actually this is highly encouraged), feel that the minutes are not a reasonable summary then it would be helpful to suggest textual updates and/or clarifications. These will then be reviewed by the minute taker and attending co-chair(s), before being added to the record, if appropriate. Moving forward you would be most welcome to join me as a minute taker at future ROLL sessions. Or simply provide updates or clarifications to the minutes I create. Regarding your specific concerns and subsequent question concerning item 2 (draft-ietf-roll-applicability-ami-04). I disagree with you assessment, and I quote "the minutes do not capture the issue that was given a lot of microphone-time: whether this document is supposed to be providing deployment guidelines and parametrization of RPL". The minutes specifically state "A number of participants were concerned that the document excluded comprehensive deployment information and detailed scalability information.". Therefore any subsequent recommendation, question, or concern you have, would be better directed to the authors, and/or relevant participants, via the ROLL mailing list. If other ROLL contributors feel as strongly as you do on this specific subject, or indeed any issue, they are entitled to support you. The authors can then address your comments or not. Either way, the imperfect but effective process of IETF "rough" consensus will be used to sanity check the comment or request, with any suitable action being taken. Acknowledging that no action may be a perfectly legitimate response. A final note, the draft listed under item 2 should be "draft-ietf-roll-applicability-ami-04" and not "draft-popa-roll-applicability-ami-04". This will be corrected in the next version of the minutes. Thanks! Br, Dan. -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Thomas Clausen Sent: 23 November 2011 08:41 To: JP Vasseur Cc: roll WG Subject: Re: [Roll] Minutes IETF-82 Dear JP, all, I am concerned that the minutes are rather brief and high-level, and do not reflect in sufficient detail the issues that were discussed and capture the questions which were brought forward. I would suggest revising the minutes to better capture the discussions for posterity. For example, and I will give but one example, but it applies throughout: for item 2, the minutes do not capture the issue that was given a lot of microphone-time: whether this document is supposed to be providing deployment guidelines and parametrization of RPL so as to make it operational in a given environment - or, rather, be a "marketing document". I recall mentioning at the mike that the WG chairs previously promised the applicability documents as the place where all (e.g.) my worries about how to make RPL work in the different deployments (or, even, if RPL could work in these deployments) would be laid to rest by explaining exactly how to parametrize RPL for these deployments. I also recall expressing some disappointment that this applicability document in its present form doesn't offer any of these guidelines whatsoever - but rather satisfies itself by asserting (as Geoff Mulligan pointed out at the mike) that the protocol works. Adrian Farrel (RTG AD) suggested at the mike that the document in its present form should aim for Informational - which, probably, is appropriate. However I also asked at the mike where, then, the "explaining exactly how to parametrize RPL for these deployments", which had been promised, would appear. (And, didn't get any answer to that question..) On the very same item, I see that the draft being discussed is indicated as "draft-popa-roll-applicability-ami-04" - whereas I see in the tools server that "draft-ietf-roll-applicability-ami-04" exists -- are they different documents? Same documents with different names? Was the draft-ietf- version withdrawn? Thank you in advance for your consideration of these comments for the minutes, Respectfully yours, Thomas On Nov 21, 2011, at 8:15 PM, JP Vasseur wrote: > Hi, > > The Minutes of the ROLL IETF-82 meetings have been uploaded: http://www.ietf.org/proceedings/82/minutes/roll.txt > > If you have any comments, please provide your comments by Nov 30 noon ET. > > Many Thanks to Dan for the minutes ! > > Cheers. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From ietf@thomasclausen.org Mon Nov 28 11:00:41 2011 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 ED33111E80B7 for ; Mon, 28 Nov 2011 11:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FkD5OfrLGAs for ; Mon, 28 Nov 2011 11:00:41 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id E563D11E80B5 for ; Mon, 28 Nov 2011 11:00:40 -0800 (PST) Received: from mtg91-1-82-227-24-173.fbx.proxad.net ([82.227.24.173] helo=[192.168.147.111]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1RV6RU-000FqI-6x; Mon, 28 Nov 2011 19:00:40 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.227.24.173 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18I3eBtanGD4/IjOt6OCwza Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Thomas Clausen In-Reply-To: <00b401ccadfa$f1f9f020$d5edd060$@olddog.co.uk> Date: Mon, 28 Nov 2011 20:00:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7D4B0562-921F-4B8B-875A-6A9DC3ECB436@thomasclausen.org> References: <2BDD2284-F58B-46E5-B119-FFAC9AD98601@cisco.com> <5A4EAC78-A568-4DBE-8D39-04D618999A26@thomasclausen.org> <00b401ccadfa$f1f9f020$d5edd060$@olddog.co.uk> To: "Daniel King" X-Mailer: Apple Mail (2.1251.1) Cc: 'roll WG' Subject: Re: [Roll] Minutes IETF-82 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 19:00:42 -0000 Dear Dan, (I really do not want to throw stones at you, the minutes are the = responsibility of the WG chairs. Let me profoundly thank you in passing = for the service you do the community) I am, of course, not expecting a meeting transcript, alas, a lot of IETF = procedure depends on discussions and decisions being properly = "on-record" and so I do believe that a synopsis isn't the proper form of = minutes. Rather, something which retains the key points of the = discussions explicitly would be extremely helpful. Here's an example of minutes; while not perfect, a lot more informative = for potential follow-up discussions: http://www.ietf.org/proceedings/82/minutes/manet.txt Note that my email was a request to more explicitly be reflecting the = discussions at the meeting, and the arguments brought forward, in the = minutes so that these discussions and arguments are on-record. My email = was not about the IETF decision-making process, so I am not sure as to = why you would bring this up? As you indicate that a subsequent version of minutes are in the works, = may I humbly request/suggest that it be more explicit as to the = discussions, arguments (and their content), contention points and so on? Respectfully yours, Thomas On Nov 28, 2011, at 7:24 PM, Daniel King wrote: > Hi Thomas,=20 >=20 > Firstly thank you for taking the time to review the minutes. As the = minute > taker let me try to respond to your concerns.=20 >=20 > My objective, as directed by the co-chairs, is to provide a synopsis = of ROLL > discussions. The intention is NOT to provide a verbatim record of the = ROLL > meeting. If anyone would like a reproduction of the session the audio = is > recorded and archived (http://www.ietf.org/audio/ietf82/). If you, or > anyone else (actually this is highly encouraged), feel that the = minutes are > not a reasonable summary then it would be helpful to suggest textual = updates > and/or clarifications. These will then be reviewed by the minute taker = and > attending co-chair(s), before being added to the record, if = appropriate. > Moving forward you would be most welcome to join me as a minute taker = at > future ROLL sessions. Or simply provide updates or clarifications to = the > minutes I create. >=20 > Regarding your specific concerns and subsequent question concerning = item 2 > (draft-ietf-roll-applicability-ami-04). I disagree with you = assessment, and > I quote "the minutes do not capture the issue that was given a lot of > microphone-time: whether this document is supposed to be providing > deployment guidelines and parametrization of RPL". The minutes = specifically > state "A number of participants were concerned that the document = excluded > comprehensive deployment information and detailed scalability = information.". > Therefore any subsequent recommendation, question, or concern you = have, > would be better directed to the authors, and/or relevant participants, = via > the ROLL mailing list. If other ROLL contributors feel as strongly as = you do > on this specific subject, or indeed any issue, they are entitled to = support > you. The authors can then address your comments or not. Either way, = the > imperfect but effective process of IETF "rough" consensus will be used = to > sanity check the comment or request, with any suitable action being = taken. > Acknowledging that no action may be a perfectly legitimate response.=20= >=20 > A final note, the draft listed under item 2 should be > "draft-ietf-roll-applicability-ami-04" and not > "draft-popa-roll-applicability-ami-04". This will be corrected in the = next > version of the minutes. >=20 > Thanks! > Br, Dan.=20 > =09 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > Thomas Clausen > Sent: 23 November 2011 08:41 > To: JP Vasseur > Cc: roll WG > Subject: Re: [Roll] Minutes IETF-82 >=20 > Dear JP, all, >=20 > I am concerned that the minutes are rather brief and high-level, and = do not > reflect in sufficient detail the issues that were discussed and = capture the > questions which were brought forward. I would suggest revising the = minutes > to better capture the discussions for posterity. >=20 >=20 > For example, and I will give but one example, but it applies = throughout: for > item 2, the minutes do not capture the issue that was given a lot of > microphone-time: whether this document is supposed to be providing > deployment guidelines and parametrization of RPL so as to make it > operational in a given environment - or, rather, be a "marketing = document".=20 >=20 > I recall mentioning at the mike that the WG chairs previously promised = the > applicability documents as the place where all (e.g.) my worries about = how > to make RPL work in the different deployments (or, even, if RPL could = work > in these deployments) would be laid to rest by explaining exactly how = to > parametrize RPL for these deployments. I also recall expressing some > disappointment that this applicability document in its present form = doesn't > offer any of these guidelines whatsoever - but rather satisfies itself = by > asserting (as Geoff Mulligan pointed out at the mike) that the = protocol > works. >=20 > Adrian Farrel (RTG AD) suggested at the mike that the document in its > present form should aim for Informational - which, probably, is = appropriate. > However I also asked at the mike where, then, the "explaining exactly = how to > parametrize RPL for these deployments", which had been promised, would > appear. (And, didn't get any answer to that question..) >=20 > On the very same item, I see that the draft being discussed is = indicated as > "draft-popa-roll-applicability-ami-04" - whereas I see in the tools = server > that "draft-ietf-roll-applicability-ami-04" exists -- are they = different > documents? Same documents with different names? Was the draft-ietf- = version > withdrawn?=20 >=20 > Thank you in advance for your consideration of these comments for the > minutes, >=20 > Respectfully yours, >=20 > Thomas >=20 > On Nov 21, 2011, at 8:15 PM, JP Vasseur wrote: >=20 >> Hi, >>=20 >> The Minutes of the ROLL IETF-82 meetings have been uploaded: > http://www.ietf.org/proceedings/82/minutes/roll.txt >>=20 >> If you have any comments, please provide your comments by Nov 30 noon = ET. >>=20 >> Many Thanks to Dan for the minutes ! >>=20 >> Cheers. >>=20 >> JP. >> _______________________________________________ >> 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 From Alireza.Sahami@vis.uni-stuttgart.de Fri Nov 25 02:16:50 2011 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 AB66D21F8B6D; Fri, 25 Nov 2011 02:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 emODDlr26fRF; Fri, 25 Nov 2011 02:16:49 -0800 (PST) Received: from Bagatelle.visus.uni-stuttgart.de (bagatelle.visus.uni-stuttgart.de [129.69.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE2B21F8B27; Fri, 25 Nov 2011 02:16:47 -0800 (PST) Received: from BAGATELLE.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7]) by Bagatelle.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7%19]) with mapi id 14.01.0339.001; Fri, 25 Nov 2011 11:16:44 +0100 From: Alireza Sahami To: "inss2012@lists.andreas-bulling.de" , "mobicom@acm.org" , "tccc@lists.cs.columbia.edu" , "sensorium@lists.stanford.edu" , "tinyos@millennium.berkeley.edu" , "contiki-developers@lists.sourceforge.net" , "MOBISYS@LISTSERV.ACM.ORG" , "micro_publicity@crhc.uiuc.edu" , "tccn@comsoc.org" , "discuss-gnuradio@gnu.org" , "pvs@csl.sri.com" , "ecoop-info@ecoop.org" , "tcpp-announce@cc.gatech.edu" , "grin@di.unipi.it" , "podc-related@acm.org" , "ahsntc-mailing-list@list.trlab.ca" , "dmanet@zpr.uni-koeln.de" , "sigops-announce@listserv.acm.org" , "SIGMOBILE-MEMBERS@LISTSERV.ACM.ORG" , "mip4@ietf.org" , "mip6@ietf.org" , "roll@ietf.org" , "announcements@lists.artist-embedded.org" , "SENSORNET@LISTSERV.ACM.ORG" , "mobisys@acm.org" , "sigmobile-members@acm.org" , "rtss@cse.unl.edu" , "cps@cse.unl.edu" , "btnode-development@list.ee.ethz.ch" , "sbc-l@sbc.org.br" , "emstar-users@cens.ucla.edu" , "disc-announce@listes.epfl.ch" , "multicomm@comsoc.org" , "6lowpan@lists.ietf.org" <6lowpan@lists.ietf.org> Thread-Topic: INSS 2012 - International Conference of Networked Sensing Systems Thread-Index: AQHMq1tVYm4+AueHP026Rp1fET259w== Date: Fri, 25 Nov 2011 10:16:44 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.69.180.21] Content-Type: multipart/alternative; boundary="_000_CAF529A223627alirezasahamivisunistuttgartde_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 28 Nov 2011 22:19:08 -0800 Subject: [Roll] INSS 2012 - International Conference of Networked Sensing Systems X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 10:16:50 -0000 --_000_CAF529A223627alirezasahamivisunistuttgartde_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D (Please accept our apologies if you receive multiple copies of this CFP.) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Call for Papers The Ninth International Conference of Networked Sensing Systems (INSS 2012) Antwerp, Belgium, June 11-14, 2012 Submission Deadline: December 24, 2011 http://www.inss-conf.org/2012 Scope and Theme: --------------- During the past years, the International Conference on Networked Sensing Sy= stems (INSS) has established itself as a scientific event where academic an= d industrial experts from the areas of next generation sensor systems, sens= or network applications, and measurement and control engineering come toget= her. The INSS provides a forum to hear about the latest developments in the= se areas, to exchange ideas, and to start up collaborations within these fi= elds and between industry and academia. INSS 2012 is the ninth annual conference in the series, and features a high= ly selective technical program. We invite outstanding research papers from = the field of sensor technology, wireless networking, or applications of net= worked sensor systems. The conference especially encourages submissions tha= t investigate research issues shared between all the three areas. INSS 2012 invites the submission of regular, short, and industry papers. Al= l submissions will be peer-reviewed and evaluated on the basis of originali= ty, significance of contribution, technical correctness, and presentation. = Papers submitted must not be under simultaneous review for any other confer= ence, journal, workshop, or other publication. All accepted papers will be = published at IEEE Xplore digital library. Authors are required to attend th= e conference to present their work. Regular/Short Paper Track ------------------------- Regular papers must be 4-8 pages long (two-column format) and include an ab= stract of 100-150 words. Short papers must be 2-4 pages long (two-column fo= rmat) and include an abstract of 100-150 words. All papers should be format= ted according to the IEEE transactions format. Short papers are suitable fo= r interactive discussions. Presentation time of accepted regular and short = papers is decided on acceptance notification. Topics of regular/short paper= track include but are not limited to: o Theoretical Study on Networked Sensing Systems o Applications of Networked Sensing Systems o Prototypes, Field Studies & Test beds for Networked Sensing Systems o Safety and Security of Networked Sensing Systems o Data Management for Networked Sensing Systems o Middleware for Networked Sensing Systems o Self-Organizing Networked Sensing Systems and Autonomic/Bio-Inspired Syst= ems o Intelligent Sensing Systems o Sensor Phenomena and Modeling o Sensors and Sensing Systems o Sensors and Actuators for Smart Meter and Smart Grid Applications o Human Behavior Sensing and Ambient Support o Human Health Monitoring and Biomedical Measurement o Measurement and Control Issues in Networked Sensing Systems o Networked Sensing Systems involving Haptic Interactions o Materials, Design, Fabrication, and Packaging of Sensors Industry Paper Track -------------------- INSS also offers an industry track. In this track, new and interesting deve= lopments in networks for industrial applications can be recognized, whether= in the area of sensor systems, wireless networks, industrial network appli= cations, networks for safety related systems and applications, different se= curity aspects in networks fault tolerant and redundant networks and many o= thers. This session focuses on innovative, new and interesting network appl= ications and research results for industries or developments which will be = important in the near future. The industry track intends to provide discuss= ion for practitioners, developers, and researchers in order to examine prac= tical issues.?Industry papers are suitable for industry researchers to pres= ent not only technical, but also practical issues surrounding production, d= eployment, and commercialisation of networked sensing technology. Industry = papers must be 2-4 pages long (two-column format) and include an abstract o= f 100-150 words. Papers should be formatted according to the IEEE transacti= ons format. The submitted industry papers will be reviewed by industry trac= k TPC members and accepted papers will be presented in the main conference'= s industry track session. The industry track aims at providing a forum amon= g practitioners, developers, and researchers to discuss practical issues in= cluding but not limited to: o Designing networked sensing systems for commercial applications o Service models and architectures for successful deployments o Production engineering for networked sensing systems o Deployment and evaluation of networked sensing systems in practical appli= cations Paper submission ---------------- Submissions should be in PDF format and will be handled through EDAS. http://edas.info/N11501 Important Dates (both regular/short and industry tracks) -------------------------------------------------------- Paper Submissions Due: December 24th, 2011 Notification of Acceptance: March 15th, 2012 Camera-Ready Papers: April 15th, 2012 Conference Dates: June 11 - 14, 2012 Committees ---------- Honorary Chair: Danny Goderis, Bell Labs, Alcatel-Lucent, Belgium General Chairs: Fahim Kawsar, Bell Labs, Alcatel-Lucent, Belgium Tian He, University of Minnesota, USA Program Chair: Hiroyuki Shinoda, University of Tokyo, Japan Program Vice Chairs: Hedda Schmidtke, TecO and Karlsruhe Institute of Technology, Germany Niwat Thepvilojanapong, Mie University, Japan Simon Egerton, Monash University, Malaysia and Australia Industrial Track Chairs: Xueli An, Bell Labs, Alcatel-Lucent, Belgium Bing Zhang, NICT, Japan Workshop Chairs: Fabio Pianese, Bell Labs, Alcatel-Lucent, Belgium Takuro Yonezawa, Keio University, Japan Poster Chairs: Andreas Bulling, University of Cambridge / Lancaster University, UK Jean-Baptiste Labrune, Bell Labs, Alcatel-Lucent, France Demonstration Chairs: Mathieu Boussard, Bell Labs, Alcatel-Lucent, France Till Riedel, TecO and Karlsruhe Institute of Technology, Germany Web Chair: Henning Schild, Bell Labs, Alcatel-Lucent, Belgium Publicity Chair: Alireza Sahami, University of Stuttgart, Germany Student Volunteer Chair: Jo Vermeulen, Hasselt University, Belgium Publication Chair: Hiroki Ishizuka, University of Tokyo, Japan Local Arrangement: Brigitte Van Dam, Alcatel-Lucent, Belgium Rita Daelemans, Alcatel-Lucent, Belgium Technical Program Committee: Tarek Abdelzaher, University of Illinois, Urbana Champaign Michael Beigl, KIT Christian Decker, TecO, University of Karlsruhe Simon Egerton, Monash University David Evans, University of Cambridge Yu Gu, Singapore University of Technology and Design Satoshi Honda, Keio University Hideto Iwaoka, Kanazawa Institute of Technology Yoshihiro Kawahara, The University of Tokyo Hideyuki Kawashima, University of Tsukuba Fahim Kawsar, Bell Labs Daeyoung Kim, Korea Advanced Institute of Science and Technology Narito Kurata, Kajima Satoshi Kurihara, Osaka University Marc Langheinrich, University of Lugano (USI) Hyunyoung Lee, Texas A&M University Pedro Marron, University of Duisburg-Essen and Fraunhofer FKIE Masateru Minami, Shibaura Institute of Technology Jin Nakazawa, Keio University Hiroshi Noguchi, The University of Tokyo Marcelo Pias, Cambridge University Till Riedel, TecO, Karlsruhe Institute of Technology Hedda Schmidtke, KIT TecO Hiroyuki Shinoda, University of Tokyo Niwat Thepvilojanapong, Mie University Yoshito Tobe, Tokyo Denki University Kristof Van Laerhoven, TU Darmstadt Matthias Woehrle, Delft University of Technology Gang Zhou, College of William and Mary --_000_CAF529A223627alirezasahamivisunistuttgartde_ Content-Type: text/html; charset="us-ascii" Content-ID: <43BF5554023962418F261041164BCA86@visus.uni-stuttgart.de> Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
(Please accept our apologies if you receive multiple copies of this CF= P.)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Call for = Papers 
The Ninth International Conference of Networked Sensing Systems (IN= SS 2012)

Antwerp, = Belgium, June 11-14, 2012
Submissio= n Deadline: December 24, 2011
http://ww= w.inss-conf.org/2012

Scope and= Theme:
---------= ------
During th= e past years, the International Conference on Networked Sensing Systems (IN= SS) has established itself as a scientific event where academic and industr= ial experts from the areas of next generation sensor systems, sensor network applications, and measurement and control e= ngineering come together. The INSS provides a forum to hear about the lates= t developments in these areas, to exchange ideas, and to start up collabora= tions within these fields and between industry and academia.

INSS 2012= is the ninth annual conference in the series, and features a highly select= ive technical program. We invite outstanding research papers from the field= of sensor technology, wireless networking, or applications of networked sensor systems. The conference especially enc= ourages submissions that investigate research issues shared between all the= three areas.

INSS 2012= invites the submission of regular, short, and industry papers. All submiss= ions will be peer-reviewed and evaluated on the basis of originality, signi= ficance of contribution, technical correctness, and presentation. Papers submitted must not be under simultaneous review f= or any other conference, journal, workshop, or other publication. All accep= ted papers will be published at IEEE Xplore digital library. Authors are re= quired to attend the conference to present their work.

Regular/S= hort Paper Track
---------= ----------------
Regular p= apers must be 4-8 pages long (two-column format) and include an abstract of= 100-150 words. Short papers must be 2-4 pages long (two-column format) and= include an abstract of 100-150 words. All papers should be formatted according to the IEEE transactions format. = Short papers are suitable for interactive discussions. Presentation time of= accepted regular and short papers is decided on acceptance notification. T= opics of regular/short paper track include but are not limited to:
o Theoretical Study on Networked Sensing Systems
o Applications of Networked Sensing Systems
o Prototypes, Field Studies & Test beds for Networked Sensing Syst= ems
o Safety and Security of Networked Sensing Systems
o Data Management for Networked Sensing Systems
o Middleware for Networked Sensing Systems 
o Self-Organizing Networked Sensing Systems and Autonomic/Bio-Inspired= Systems
o Intelligent Sensing Systems
o Sensor Phenomena and Modeling
o Sensors and Sensing Systems
o Sensors and Actuators for Smart Meter and Smart Grid Applications&nb= sp;
o Human Behavior Sensing and Ambient Support
o Human Health Monitoring and Biomedical Measurement
o Measurement and Control Issues in Networked Sensing Systems
o Networked Sensing Systems involving Haptic Interactions
o Materials, Design, Fabrication, and Packaging of Sensors

Industry = Paper Track
---------= -----------
INSS also= offers an industry track. In this track, new and interesting developments = in networks for industrial applications can be recognized, whether in the a= rea of sensor systems, wireless networks, industrial network applications, networks for safety related systems and a= pplications, different security aspects in networks fault tolerant and redu= ndant networks and many others. This session focuses on innovative, new and= interesting network applications and research results for industries or developments which will be importan= t in the near future. The industry track intends to provide discussion for = practitioners, developers, and researchers in order to examine practical is= sues.?Industry papers are suitable for industry researchers to present not only technical, but also practical= issues surrounding production, deployment, and commercialisation of networ= ked sensing technology. Industry papers must be 2-4 pages long (two-column = format) and include an abstract of 100-150 words. Papers should be formatted according to the IEEE transac= tions format. The submitted industry papers will be reviewed by industry tr= ack TPC members and accepted papers will be presented in the main conferenc= e's industry track session. The industry track aims at providing a forum among practitioners, developers, = and researchers to discuss practical issues including but not limited to:
o Designing networked sensing systems for commercial applications
o Service models and architectures for successful deployments
o Production engineering for networked sensing systems
o Deployment and evaluation of networked sensing systems in practical = applications

Paper sub= mission
---------= -------
Submissio= ns should be in PDF format and will be handled through EDAS. 
http://ed= as.info/N11501

Important= Dates (both regular/short and industry tracks) 
---------= -----------------------------------------------
Paper Sub= missions Due: December 24th, 2011 
Notificat= ion of Acceptance: March 15th, 2012
Camera-Re= ady Papers: April 15th, 2012
Conferenc= e Dates: June 11 - 14, 2012

Committee= s
---------= -

Honorary = Chair:
Danny God= eris, Bell Labs, Alcatel-Lucent, Belgium

General C= hairs:
Fahim Kaw= sar, Bell Labs, Alcatel-Lucent, Belgium
Tian He, = University of Minnesota, USA

Program C= hair:
Hiroyuki = Shinoda, University of Tokyo, Japan

Program V= ice Chairs:
Hedda Sch= midtke, TecO and Karlsruhe Institute of Technology, Germany
Niwat The= pvilojanapong, Mie University, Japan
Simon Ege= rton, Monash University, Malaysia and Australia

Industria= l Track Chairs:
Xueli An,= Bell Labs, Alcatel-Lucent, Belgium
Bing Zhan= g, NICT, Japan

Workshop = Chairs:
Fabio Pia= nese, Bell Labs, Alcatel-Lucent, Belgium
Takuro Yo= nezawa, Keio University, Japan

Poster Ch= airs:
Andreas B= ulling, University of Cambridge / Lancaster University, UK
Jean-Bapt= iste Labrune, Bell Labs, Alcatel-Lucent, France

Demonstra= tion Chairs:
Mathieu B= oussard, Bell Labs, Alcatel-Lucent, France
Till Ried= el, TecO and Karlsruhe Institute of Technology, Germany

Web Chair= :
Henning S= child, Bell Labs, Alcatel-Lucent, Belgium

Publicity= Chair:
Alireza S= ahami, University of Stuttgart, Germany

Student V= olunteer Chair:
Jo Vermeu= len, Hasselt University, Belgium

Publicati= on Chair:
Hiroki Is= hizuka, University of Tokyo, Japan

Local Arr= angement:
Brigitte = Van Dam, Alcatel-Lucent, Belgium
Rita Dael= emans, Alcatel-Lucent, Belgium

Technical= Program Committee:
Tarek Abd= elzaher, University of Illinois, Urbana Champaign
Michael B= eigl, KIT
Christian= Decker, TecO, University of Karlsruhe
Simon Ege= rton, Monash University
David Eva= ns, University of Cambridge
Yu Gu, Si= ngapore University of Technology and Design
Satoshi H= onda, Keio University
Hideto Iw= aoka, Kanazawa Institute of Technology
Yoshihiro= Kawahara, The University of Tokyo
Hideyuki = Kawashima, University of Tsukuba
Fahim Kaw= sar, Bell Labs
Daeyoung = Kim, Korea Advanced Institute of Science and Technology
Narito Ku= rata, Kajima
Satoshi K= urihara, Osaka University
Marc Lang= heinrich, University of Lugano (USI)
Hyunyoung= Lee, Texas A&M University
Pedro Mar= ron, University of Duisburg-Essen and Fraunhofer FKIE
Masateru = Minami, Shibaura Institute of Technology
Jin Nakaz= awa, Keio University
Hiroshi N= oguchi, The University of Tokyo
Marcelo P= ias, Cambridge University
Till Ried= el, TecO, Karlsruhe Institute of Technology
Hedda Sch= midtke, KIT TecO
Hiroyuki = Shinoda, University of Tokyo
Niwat The= pvilojanapong, Mie University
Yoshito T= obe, Tokyo Denki University
Kristof V= an Laerhoven, TU Darmstadt
Matthias = Woehrle, Delft University of Technology
Gang Zhou= , College of William and Mary
--_000_CAF529A223627alirezasahamivisunistuttgartde_-- From Alireza.Sahami@vis.uni-stuttgart.de Fri Nov 25 04:25:27 2011 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 4A76521F8BF0; Fri, 25 Nov 2011 04:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 s-aEtdApxMC8; Fri, 25 Nov 2011 04:25:26 -0800 (PST) Received: from Bagatelle.visus.uni-stuttgart.de (bagatelle.visus.uni-stuttgart.de [129.69.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 29EA221F8BCD; Fri, 25 Nov 2011 04:25:25 -0800 (PST) Received: from BAGATELLE.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7]) by Bagatelle.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7%19]) with mapi id 14.01.0339.001; Fri, 25 Nov 2011 13:25:21 +0100 From: Alireza Sahami To: Alireza Sahami Thread-Topic: INSS 2012 - International Conference of Networked Sensing Systems Thread-Index: AQHMq21MgCcTESzmbEKqm+9PRv/I9w== Date: Fri, 25 Nov 2011 12:25:20 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.69.180.21] Content-Type: multipart/alternative; boundary="_000_CAF547C723847alirezasahamivisunistuttgartde_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 28 Nov 2011 22:19:08 -0800 Subject: [Roll] INSS 2012 - International Conference of Networked Sensing Systems X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 12:25:27 -0000 --_000_CAF547C723847alirezasahamivisunistuttgartde_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D (Please accept our apologies if you receive multiple copies of this CFP.) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Call for Papers The Ninth International Conference of Networked Sensing Systems (INSS 2012) Antwerp, Belgium, June 11-14, 2012 Submission Deadline: December 24, 2011 http://www.inss-conf.org/2012 Scope and Theme: --------------- During the past years, the International Conference on Networked Sensing Sy= stems (INSS) has established itself as a scientific event where academic an= d industrial experts from the areas of next generation sensor systems, sens= or network applications, and measurement and control engineering come toget= her. The INSS provides a forum to hear about the latest developments in the= se areas, to exchange ideas, and to start up collaborations within these fi= elds and between industry and academia. INSS 2012 is the ninth annual conference in the series, and features a high= ly selective technical program. We invite outstanding research papers from = the field of sensor technology, wireless networking, or applications of net= worked sensor systems. The conference especially encourages submissions tha= t investigate research issues shared between all the three areas. INSS 2012 invites the submission of regular, short, and industry papers. Al= l submissions will be peer-reviewed and evaluated on the basis of originali= ty, significance of contribution, technical correctness, and presentation. = Papers submitted must not be under simultaneous review for any other confer= ence, journal, workshop, or other publication. All accepted papers will be = published at IEEE Xplore digital library. Authors are required to attend th= e conference to present their work. Regular/Short Paper Track ------------------------- Regular papers must be 4-8 pages long (two-column format) and include an ab= stract of 100-150 words. Short papers must be 2-4 pages long (two-column fo= rmat) and include an abstract of 100-150 words. All papers should be format= ted according to the IEEE transactions format. Short papers are suitable fo= r interactive discussions. Presentation time of accepted regular and short = papers is decided on acceptance notification. Topics of regular/short paper= track include but are not limited to: o Theoretical Study on Networked Sensing Systems o Applications of Networked Sensing Systems o Prototypes, Field Studies & Test beds for Networked Sensing Systems o Safety and Security of Networked Sensing Systems o Data Management for Networked Sensing Systems o Middleware for Networked Sensing Systems o Self-Organizing Networked Sensing Systems and Autonomic/Bio-Inspired Syst= ems o Intelligent Sensing Systems o Sensor Phenomena and Modeling o Sensors and Sensing Systems o Sensors and Actuators for Smart Meter and Smart Grid Applications o Human Behavior Sensing and Ambient Support o Human Health Monitoring and Biomedical Measurement o Measurement and Control Issues in Networked Sensing Systems o Networked Sensing Systems involving Haptic Interactions o Materials, Design, Fabrication, and Packaging of Sensors Industry Paper Track -------------------- INSS also offers an industry track. In this track, new and interesting deve= lopments in networks for industrial applications can be recognized, whether= in the area of sensor systems, wireless networks, industrial network appli= cations, networks for safety related systems and applications, different se= curity aspects in networks fault tolerant and redundant networks and many o= thers. This session focuses on innovative, new and interesting network appl= ications and research results for industries or developments which will be = important in the near future. The industry track intends to provide discuss= ion for practitioners, developers, and researchers in order to examine prac= tical issues.?Industry papers are suitable for industry researchers to pres= ent not only technical, but also practical issues surrounding production, d= eployment, and commercialisation of networked sensing technology. Industry = papers must be 2-4 pages long (two-column format) and include an abstract o= f 100-150 words. Papers should be formatted according to the IEEE transacti= ons format. The submitted industry papers will be reviewed by industry trac= k TPC members and accepted papers will be presented in the main conference'= s industry track session. The industry track aims at providing a forum amon= g practitioners, developers, and researchers to discuss practical issues in= cluding but not limited to: o Designing networked sensing systems for commercial applications o Service models and architectures for successful deployments o Production engineering for networked sensing systems o Deployment and evaluation of networked sensing systems in practical appli= cations Paper submission ---------------- Submissions should be in PDF format and will be handled through EDAS. http://edas.info/N11501 Important Dates (both regular/short and industry tracks) -------------------------------------------------------- Paper Submissions Due: December 24th, 2011 Notification of Acceptance: March 15th, 2012 Camera-Ready Papers: April 15th, 2012 Conference Dates: June 11 - 14, 2012 Committees ---------- Honorary Chair: Danny Goderis, Bell Labs, Alcatel-Lucent, Belgium General Chairs: Fahim Kawsar, Bell Labs, Alcatel-Lucent, Belgium Tian He, University of Minnesota, USA Program Chair: Hiroyuki Shinoda, University of Tokyo, Japan Program Vice Chairs: Hedda Schmidtke, TecO and Karlsruhe Institute of Technology, Germany Niwat Thepvilojanapong, Mie University, Japan Simon Egerton, Monash University, Malaysia and Australia Industrial Track Chairs: Xueli An, Bell Labs, Alcatel-Lucent, Belgium Bing Zhang, NICT, Japan Workshop Chairs: Fabio Pianese, Bell Labs, Alcatel-Lucent, Belgium Takuro Yonezawa, Keio University, Japan Poster Chairs: Andreas Bulling, University of Cambridge / Lancaster University, UK Jean-Baptiste Labrune, Bell Labs, Alcatel-Lucent, France Demonstration Chairs: Mathieu Boussard, Bell Labs, Alcatel-Lucent, France Till Riedel, TecO and Karlsruhe Institute of Technology, Germany Web Chair: Henning Schild, Bell Labs, Alcatel-Lucent, Belgium Publicity Chair: Alireza Sahami, University of Stuttgart, Germany Student Volunteer Chair: Jo Vermeulen, Hasselt University, Belgium Publication Chair: Hiroki Ishizuka, University of Tokyo, Japan Local Arrangement: Brigitte Van Dam, Alcatel-Lucent, Belgium Rita Daelemans, Alcatel-Lucent, Belgium Technical Program Committee: Tarek Abdelzaher, University of Illinois, Urbana Champaign Michael Beigl, KIT Christian Decker, TecO, University of Karlsruhe Simon Egerton, Monash University David Evans, University of Cambridge Yu Gu, Singapore University of Technology and Design Satoshi Honda, Keio University Hideto Iwaoka, Kanazawa Institute of Technology Yoshihiro Kawahara, The University of Tokyo Hideyuki Kawashima, University of Tsukuba Fahim Kawsar, Bell Labs Daeyoung Kim, Korea Advanced Institute of Science and Technology Narito Kurata, Kajima Satoshi Kurihara, Osaka University Marc Langheinrich, University of Lugano (USI) Hyunyoung Lee, Texas A&M University Pedro Marron, University of Duisburg-Essen and Fraunhofer FKIE Masateru Minami, Shibaura Institute of Technology Jin Nakazawa, Keio University Hiroshi Noguchi, The University of Tokyo Marcelo Pias, Cambridge University Till Riedel, TecO, Karlsruhe Institute of Technology Hedda Schmidtke, KIT TecO Hiroyuki Shinoda, University of Tokyo Niwat Thepvilojanapong, Mie University Yoshito Tobe, Tokyo Denki University Kristof Van Laerhoven, TU Darmstadt Matthias Woehrle, Delft University of Technology Gang Zhou, College of William and Mary --_000_CAF547C723847alirezasahamivisunistuttgartde_ Content-Type: text/html; charset="us-ascii" Content-ID: <9EA45AFFD45F3D449AD0D7CAA6A4F248@visus.uni-stuttgart.de> Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
(Please accept our apologies if you receive multiple copies of this CF= P.)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Call for = Papers 
The Ninth International Conference of Networked Sensing Systems (IN= SS 2012)

Antwerp, = Belgium, June 11-14, 2012
Submissio= n Deadline: December 24, 2011

Scope and= Theme:
---------= ------
During th= e past years, the International Conference on Networked Sensing Systems (IN= SS) has established itself as a scientific event where academic and industr= ial experts from the areas of next generation sensor systems, sensor network applications, and measurement and control e= ngineering come together. The INSS provides a forum to hear about the lates= t developments in these areas, to exchange ideas, and to start up collabora= tions within these fields and between industry and academia.

INSS 2012= is the ninth annual conference in the series, and features a highly select= ive technical program. We invite outstanding research papers from the field= of sensor technology, wireless networking, or applications of networked sensor systems. The conference especially enc= ourages submissions that investigate research issues shared between all the= three areas.

INSS 2012= invites the submission of regular, short, and industry papers. All submiss= ions will be peer-reviewed and evaluated on the basis of originality, signi= ficance of contribution, technical correctness, and presentation. Papers submitted must not be under simultaneous review f= or any other conference, journal, workshop, or other publication. All accep= ted papers will be published at IEEE Xplore digital library. Authors are re= quired to attend the conference to present their work.

Regular/S= hort Paper Track
---------= ----------------
Regular p= apers must be 4-8 pages long (two-column format) and include an abstract of= 100-150 words. Short papers must be 2-4 pages long (two-column format) and= include an abstract of 100-150 words. All papers should be formatted according to the IEEE transactions format. = Short papers are suitable for interactive discussions. Presentation time of= accepted regular and short papers is decided on acceptance notification. T= opics of regular/short paper track include but are not limited to:
o Theoretical Study on Networked Sensing Systems
o Applications of Networked Sensing Systems
o Prototypes, Field Studies & Test beds for Networked Sensing Syst= ems
o Safety and Security of Networked Sensing Systems
o Data Management for Networked Sensing Systems
o Middleware for Networked Sensing Systems 
o Self-Organizing Networked Sensing Systems and Autonomic/Bio-Inspired= Systems
o Intelligent Sensing Systems
o Sensor Phenomena and Modeling
o Sensors and Sensing Systems
o Sensors and Actuators for Smart Meter and Smart Grid Applications&nb= sp;
o Human Behavior Sensing and Ambient Support
o Human Health Monitoring and Biomedical Measurement
o Measurement and Control Issues in Networked Sensing Systems
o Networked Sensing Systems involving Haptic Interactions
o Materials, Design, Fabrication, and Packaging of Sensors

Industry = Paper Track
---------= -----------
INSS also= offers an industry track. In this track, new and interesting developments = in networks for industrial applications can be recognized, whether in the a= rea of sensor systems, wireless networks, industrial network applications, networks for safety related systems and a= pplications, different security aspects in networks fault tolerant and redu= ndant networks and many others. This session focuses on innovative, new and= interesting network applications and research results for industries or developments which will be importan= t in the near future. The industry track intends to provide discussion for = practitioners, developers, and researchers in order to examine practical is= sues.?Industry papers are suitable for industry researchers to present not only technical, but also practical= issues surrounding production, deployment, and commercialisation of networ= ked sensing technology. Industry papers must be 2-4 pages long (two-column = format) and include an abstract of 100-150 words. Papers should be formatted according to the IEEE transac= tions format. The submitted industry papers will be reviewed by industry tr= ack TPC members and accepted papers will be presented in the main conferenc= e's industry track session. The industry track aims at providing a forum among practitioners, developers, = and researchers to discuss practical issues including but not limited to:
o Designing networked sensing systems for commercial applications
o Service models and architectures for successful deployments
o Production engineering for networked sensing systems
o Deployment and evaluation of networked sensing systems in practical = applications

Paper sub= mission
---------= -------
Submissio= ns should be in PDF format and will be handled through EDAS. 

Important= Dates (both regular/short and industry tracks) 
---------= -----------------------------------------------
Paper Sub= missions Due: December 24th, 2011 
Notificat= ion of Acceptance: March 15th, 2012
Camera-Re= ady Papers: April 15th, 2012
Conferenc= e Dates: June 11 - 14, 2012

Committee= s
---------= -

Honorary = Chair:
Danny God= eris, Bell Labs, Alcatel-Lucent, Belgium

General C= hairs:
Fahim Kaw= sar, Bell Labs, Alcatel-Lucent, Belgium
Tian He, = University of Minnesota, USA

Program C= hair:
Hiroyuki = Shinoda, University of Tokyo, Japan

Program V= ice Chairs:
Hedda Sch= midtke, TecO and Karlsruhe Institute of Technology, Germany
Niwat The= pvilojanapong, Mie University, Japan
Simon Ege= rton, Monash University, Malaysia and Australia

Industria= l Track Chairs:
Xueli An,= Bell Labs, Alcatel-Lucent, Belgium
Bing Zhan= g, NICT, Japan

Workshop = Chairs:
Fabio Pia= nese, Bell Labs, Alcatel-Lucent, Belgium
Takuro Yo= nezawa, Keio University, Japan

Poster Ch= airs:
Andreas B= ulling, University of Cambridge / Lancaster University, UK
Jean-Bapt= iste Labrune, Bell Labs, Alcatel-Lucent, France

Demonstra= tion Chairs:
Mathieu B= oussard, Bell Labs, Alcatel-Lucent, France
Till Ried= el, TecO and Karlsruhe Institute of Technology, Germany

Web Chair= :
Henning S= child, Bell Labs, Alcatel-Lucent, Belgium

Publicity= Chair:
Alireza S= ahami, University of Stuttgart, Germany

Student V= olunteer Chair:
Jo Vermeu= len, Hasselt University, Belgium

Publicati= on Chair:
Hiroki Is= hizuka, University of Tokyo, Japan

Local Arr= angement:
Brigitte = Van Dam, Alcatel-Lucent, Belgium
Rita Dael= emans, Alcatel-Lucent, Belgium

Technical= Program Committee:
Tarek Abd= elzaher, University of Illinois, Urbana Champaign
Michael B= eigl, KIT
Christian= Decker, TecO, University of Karlsruhe
Simon Ege= rton, Monash University
David Eva= ns, University of Cambridge
Yu Gu, Si= ngapore University of Technology and Design
Satoshi H= onda, Keio University
Hideto Iw= aoka, Kanazawa Institute of Technology
Yoshihiro= Kawahara, The University of Tokyo
Hideyuki = Kawashima, University of Tsukuba
Fahim Kaw= sar, Bell Labs
Daeyoung = Kim, Korea Advanced Institute of Science and Technology
Narito Ku= rata, Kajima
Satoshi K= urihara, Osaka University
Marc Lang= heinrich, University of Lugano (USI)
Hyunyoung= Lee, Texas A&M University
Pedro Mar= ron, University of Duisburg-Essen and Fraunhofer FKIE
Masateru = Minami, Shibaura Institute of Technology
Jin Nakaz= awa, Keio University
Hiroshi N= oguchi, The University of Tokyo
Marcelo P= ias, Cambridge University
Till Ried= el, TecO, Karlsruhe Institute of Technology
Hedda Sch= midtke, KIT TecO
Hiroyuki = Shinoda, University of Tokyo
Niwat The= pvilojanapong, Mie University
Yoshito T= obe, Tokyo Denki University
Kristof V= an Laerhoven, TU Darmstadt
Matthias = Woehrle, Delft University of Technology
Gang Zhou= , College of William and Mary
--_000_CAF547C723847alirezasahamivisunistuttgartde_-- From yoav@yitran.com Mon Nov 28 22:40:08 2011 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 6704D11E80B8 for ; Mon, 28 Nov 2011 22:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.676 X-Spam-Level: X-Spam-Status: No, score=-4.676 tagged_above=-999 required=5 tests=[AWL=1.301, 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 rJfP7WNZ64vj for ; Mon, 28 Nov 2011 22:40:07 -0800 (PST) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with SMTP id E202511E80BB for ; Mon, 28 Nov 2011 22:40:06 -0800 (PST) Received: from mail-ey0-f169.google.com ([209.85.215.169]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTtR+O8IiPLLxevTanxC6PwL55/IilxiX@postini.com; Mon, 28 Nov 2011 22:40:07 PST Received: by mail-ey0-f169.google.com with SMTP id h1so3157366eaa.0 for ; Mon, 28 Nov 2011 22:39:55 -0800 (PST) Received: by 10.180.104.35 with SMTP id gb3mr48949122wib.11.1322548795013; Mon, 28 Nov 2011 22:39:55 -0800 (PST) From: Yoav Ben-Yehezkel References: <6c71e16e38119b2034498004067f3368@mail.gmail.com> <814FA4F1-3C5A-4EA3-84F3-39123430304F@cs.stanford.edu> In-Reply-To: <814FA4F1-3C5A-4EA3-84F3-39123430304F@cs.stanford.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEnk1KyOox/iZZxui3Yaxcy4NDBAAL6IHxQlvXKc1A= Date: Tue, 29 Nov 2011 08:37:08 +0200 Message-ID: <8c5da7bb93eed5a19295c45e55939849@mail.gmail.com> To: Philip Levis Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] question about working with RPL with multiple rates X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 06:40:08 -0000 Thanks C=E9dric and Philip for the clarification. ETT seems like an interesting approach. Best regards, Yoav -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: Monday, November 28, 2011 7:23 PM To: Yoav Ben-Yehezkel Cc: roll@ietf.org Subject: Re: [Roll] question about working with RPL with multiple rates On Nov 28, 2011, at 5:59 AM, Yoav Ben-Yehezkel wrote: > Dear Roll-ers, > > I=92m working on an implementation of RPL for a power-line technology. L1/L2 of the technology allows to operate at different rates at the per link (by controlling modulation, coding parameters, tone masks, etc.). > I was wondering if anyone had any experience working with RPL using PHY/DLL that support multiple rates? > The application is a metering application where meter polling is used for data traffic, so P2MP and MP2P are used. > We want to use external memory for the DODAG root with non-storing mode. > > I=92m mostly interested to get the WG impression on the following two issues: > 1. I assume DIOs are sent at the lowest (and most robust) rate to cover as many potential children possible. My question is since DIOs are transmitted at robust rates to many potential children, how does the potential children know which parent is best to choose from? The objective function defines how to do so, using one or more of - locally measured link properties, - Rank, and - metric containers. > Does RPL assume capability to derive link quality information about a higher rate from the received DIO at lower rate by L1/L2? No. While some link/physical layers might be able to compute metrics solely from received packets, others can't. In the wireless research world they're called "asymmetric links," i.e., where A can hear B well but B cannot hear A well. The assumption is that the protocol is somehow estimating link quality. How this is done is > 2. Another question is concerning how to differentiate between links where one direction can be used at high rate vs. the link on the other direction can be used at a lower rate. If a network contains 100 routers sending DIOs at robust rate that a node receives, how does this potential child know which node to use as a preferred parent assuming potential parents can be used on the way up at the same rate, but the downward route can be used at higher rate by one of them (i.e. more optimal parent)? You'd express this in the link metric. RPL does not assume that the metric value of AB is the same as BA. Research tackled this a bit in WiFi meshes, for example, by extending ETX (expected number of transmissions) to ETT (expected time of transmission). Phil From j.schoenwaelder@jacobs-university.de Tue Nov 29 02:48:06 2011 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 CBB0A21F849D for ; Tue, 29 Nov 2011 02:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.739 X-Spam-Level: X-Spam-Status: No, score=-102.739 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 GeINuBNt5b51 for ; Tue, 29 Nov 2011 02:48:06 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E346321F84AE for ; Tue, 29 Nov 2011 02:48:05 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2FD420C8D; Tue, 29 Nov 2011 11:48:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YlrSt_7Ou8yM; Tue, 29 Nov 2011 11:48:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25BD620C4A; Tue, 29 Nov 2011 11:48:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1E0811BE8345; Tue, 29 Nov 2011 11:47:45 +0100 (CET) Date: Tue, 29 Nov 2011 11:47:45 +0100 From: Juergen Schoenwaelder To: Michael Richardson Message-ID: <20111129104743.GA30102@elstar.local> Mail-Followup-To: Michael Richardson , roll@ietf.org References: <22330.1322346990@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22330.1322346990@marajade.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: roll@ietf.org Subject: Re: [Roll] roll-rpl-mib-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 10:48:06 -0000 On Sat, Nov 26, 2011 at 05:36:30PM -0500, Michael Richardson wrote: > > I did a brief review of sehgal-roll-rpl-mib-01. > (I note that it has now officially expired from the ID repository) There is meanwhile -02 in place (but with only minor changes). > My single comment is that it appears that there are no counters or > other structures to deal with the secure forms of the RPL messages. > Specifically for failures to hash, authenticate, and lists of nodes > that might be sending messages with incorrect keys. Looking at the text in section 10.7. of draft-ietf-roll-rpl-19, there should be a counters for messages discarded because (a) integrity check failures, (b) replay check failures and (c) delay protection checks. In fact, we likely need a bunch of counters such as: rplInDiscards dropped due to resource shortages rplInDelayProtectFailures dropped due to delay protection failures rplInReplayCheckFailures dropped due to replay check failures rplInMACFailures dropped due to MAC check failures rplInUnknownMsgTypes dropped due to unknown code numbers rplInHeaderErrors dropped due to header parsing errors rplInReceived received RPL messages We might also need a few counters for outgoing messages, e.g. rplOutRequests RPL messages to be sent rplOutDiscards dropped due to resource shortages We will look into this for the next revision and create some definitions. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From culler@EECS.Berkeley.EDU Tue Nov 29 10:18:36 2011 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 042D311E80B5 for ; Tue, 29 Nov 2011 10:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu10LAhWwRtH for ; Tue, 29 Nov 2011 10:18:35 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA7E11E80AC for ; Tue, 29 Nov 2011 10:18:35 -0800 (PST) Received: from dhcp-44-228.eecs.berkeley.edu (dhcp-44-228.EECS.Berkeley.EDU [128.32.44.228]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.5/8.13.5) with ESMTP id pATIITnH020988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Nov 2011 10:18:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: David Culler In-Reply-To: <5A4EAC78-A568-4DBE-8D39-04D618999A26@thomasclausen.org> Date: Tue, 29 Nov 2011 10:16:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <49FA4ECD-488A-4680-9256-832F9442250E@EECS.Berkeley.EDU> References: <2BDD2284-F58B-46E5-B119-FFAC9AD98601@cisco.com> <5A4EAC78-A568-4DBE-8D39-04D618999A26@thomasclausen.org> To: Thomas Clausen X-Mailer: Apple Mail (2.1084) Cc: roll WG Subject: Re: [Roll] Minutes IETF-82 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 18:18:36 -0000 I thought that Dan did a good job of summarizing and up-leveling. = Indeed, there was more detailed discussion on some of the points at the = meeting. I was tempted to go in and augment that. But after reviewing = the notes, I felt that Dan had captured much of the outcome, if not all = the commentary leading up to that. I'm fine if folks want to have = additional detail captured. I prefer that it contain content, rather = than positioning. On Nov 23, 2011, at 12:40 AM, Thomas Clausen wrote: > Dear JP, all, >=20 > I am concerned that the minutes are rather brief and high-level, and = do not reflect in sufficient detail the issues that were discussed and = capture the questions which were brought forward. I would suggest = revising the minutes to better capture the discussions for posterity. >=20 >=20 > For example, and I will give but one example, but it applies = throughout: for item 2, the minutes do not capture the issue that was = given a lot of microphone-time: whether this document is supposed to be = providing deployment guidelines and parametrization of RPL so as to make = it operational in a given environment - or, rather, be a "marketing = document".=20 >=20 > I recall mentioning at the mike that the WG chairs previously promised = the applicability documents as the place where all (e.g.) my worries = about how to make RPL work in the different deployments (or, even, if = RPL could work in these deployments) would be laid to rest by explaining = exactly how to parametrize RPL for these deployments. I also recall = expressing some disappointment that this applicability document in its = present form doesn't offer any of these guidelines whatsoever - but = rather satisfies itself by asserting (as Geoff Mulligan pointed out at = the mike) that the protocol works. >=20 > Adrian Farrel (RTG AD) suggested at the mike that the document in its = present form should aim for Informational - which, probably, is = appropriate. However I also asked at the mike where, then, the = "explaining exactly how to parametrize RPL for these deployments", which = had been promised, would appear. (And, didn't get any answer to that = question=85.) >=20 > On the very same item, I see that the draft being discussed is = indicated as "draft-popa-roll-applicability-ami-04" - whereas I see in = the tools server that "draft-ietf-roll-applicability-ami-04" exists -- = are they different documents? Same documents with different names? Was = the draft-ietf- version withdrawn?=20 >=20 > Thank you in advance for your consideration of these comments for the = minutes, >=20 > Respectfully yours, >=20 > Thomas >=20 > On Nov 21, 2011, at 8:15 PM, JP Vasseur wrote: >=20 >> Hi, >>=20 >> The Minutes of the ROLL IETF-82 meetings have been uploaded: = http://www.ietf.org/proceedings/82/minutes/roll.txt >>=20 >> If you have any comments, please provide your comments by Nov 30 noon = ET. >>=20 >> Many Thanks to Dan for the minutes ! >>=20 >> Cheers. >>=20 >> JP. >> _______________________________________________ >> 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 yoav@yitran.com Tue Nov 29 12:24:44 2011 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 206241F0CB0 for ; Tue, 29 Nov 2011 12:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.326 X-Spam-Level: X-Spam-Status: No, score=-6.326 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 kyaKBk8YQcOz for ; Tue, 29 Nov 2011 12:24:42 -0800 (PST) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with SMTP id EDA1621F8B5B for ; Tue, 29 Nov 2011 12:24:38 -0800 (PST) Received: from mail-fx0-f53.google.com ([209.85.161.53]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTtU/ho1ts245TdxeZD9/mRaTNqn3FJSX@postini.com; Tue, 29 Nov 2011 12:24:42 PST Received: by mail-fx0-f53.google.com with SMTP id q2so92801faa.12 for ; Tue, 29 Nov 2011 12:24:38 -0800 (PST) Received: by 10.180.104.35 with SMTP id gb3mr50699733wib.11.1322598278117; Tue, 29 Nov 2011 12:24:38 -0800 (PST) From: Yoav Ben-Yehezkel MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acyu04PCqW7QkuVjRCeei851PmupjA== Date: Tue, 29 Nov 2011 22:20:14 +0200 Message-ID: To: draft-thubert-roll-asymlink@tools.ietf.org Content-Type: multipart/alternative; boundary=f46d044267a08c3a3b04b2e568fe Cc: roll@ietf.org Subject: [Roll] Mail regarding draft-thubert-roll-asymlink X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 20:24:44 -0000 --f46d044267a08c3a3b04b2e568fe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Roll-ers, Find below comments to the draft. Mostly editorial, I hope they make sense. Best regards, Yoav Comments to Introduction section 1: In one hand, RPL requires bi-directional links for the control, but on the other, there is no requirement that the properties of a link are the same in both directions. In fact, a perfect symmetry is rarely present in Low Power and Lossy Networks (LLNs), whether links are based on radios or power-line. 1. Replace =93In one hand=94 with =93On one hand=94 2. Replace =93on the other,=94 with =93on the other hand,=94. 3. Replace =93whether links are based on radios or power-line=94 with =93such as wireless radio or power-line links.=94 Some initial implementations require that the quality of both directions of a link is evaluated as very good so that the link can be used for control and data in both directions. This eliminates asymmetrical links that are very good in one direction, but only good enough for scarce activity in the other direction. 4. Replace =93that the quality of both directions of a link is evaluated as very good=94 with =93that the quality of both directions of a = link is evaluated as operational at an acceptable level=94 =96 because they do n= ot necessarily have to be very good. Comments to Terminology section 2: The term upwards qualifies a link, a DODAG or an instance that is optimal for sending traffic in the general direction of the root, though may be usable but suboptimal for traffic coming form the direction of the root. The term downwards qualifies the same words for the opposite direction. 1. Should the term =93instance=94 be replaced with the term =93RPL instance=94? 2. What does =93general direction of the root=94 means? Shouldn=92t i= t simply be =93towards the root=94? 3. Replace =93though may be usable but suboptimal for traffic coming = * form* the direction of the root=93 with =93though may be usable but subopti= mal for traffic coming *from* the direction of the root=94 (form=3Dfrom) 4. Replace =93The term downwards qualifies the same *words* for the opposite direction=94 with =93The term downwards qualifies the same *wording,* *only *for opposite directions=94 5. Question: shouldn=92t the terms =93upwards=94 and =93downwards=94 = be included into the terminology draft? bi-directional: A link is bi-directional when traffic confirmed possible in both direction, in a fashion that is sufficient to operate RPL control. 1. Replace =93possible in both direction=94 with =93possible in both direction*s*=94 (missing =91s=92). asymmetric: A link is assymetric if it is bi-directional, but exhibits important differences in link characteristics for both directions. 1. Replace =93A link is a*ssym*etric=94 with =93A link is a*symm*etri= c=94 (typo) 2. Replace =93important=94 with =93major=94 Comments to The asymmetrical link problem section 3: 1. Capitalize first letter of each word like in all other sections. Comments to Solution Overview section 4: One direct consequence of that design choice is that a topology must be very good for both upwards and downwards traffic; 1. Replace =93very good=94 with =93operational at an acceptable level= =94. In that case, an asymmetrical link, that can only be used for traffic in one direction, can not participate to the routing topology. 1. Replace =93can not=94 with =93cannot=94. OTOH, with RPL as it is specified,... 1. Replace =93OTOH=94 with =93On the other hand=94. ... so that a node may transfer traffic from an instance onto another. 1. Replace =93an instance onto another=94 with =93an upwards instance= onto the downwards instance=94. Comments to Modified DIO section 5: Directional (D): The Directional (D) flag is set to indicate that the instance is intended for directional operation, and reset otherwise. When it is set, a MOP of 0 indicates the upwards direction whereas any other value specified in [I-D.ietf-roll-rpl] indicates downwards. All other values of MOP will be considered downwards unless explicitly specified otherwise. 1. Replace =93and reset otherwise=94 with =93and is reset otherwise= =94. 2. Replace =93upwards direction=94 with =93upwards=94, or add the wor= d =93direction=94 to all subsequence indications of the word =93downwards=94 3. Replace =93will be considered downwards=94 with =93shall be consid= ered downwards=94. Comments to Operations section 6: This specification allows an organization of Instances as follows: 1. Replace =93Instances=94 with =93instances=94 (non-capitalized =91I= =92) The direction is indicated by the MOP field, a MOP of 0 means upwards and otherwise is downwards. 2. Replace =93a MOP of 0 means=94 with =93a MOP set to a value 0 indi= cates=94 3. Replace =93and otherwise is downwards=94 with =93and indicates dow= nwards if set otherwise=94. Transferring from an upwards instance to a downwards instance if generally desirable. Other forms of transfers are generally not desirable. Policies MAY be put in place to ovreride that general guidance. 1. Replace =93if=94 with =93is=94 2. Remove =93generally=94 and =93general=94 or explain what they mean= . 3. Replace =93put in place=94 with =93used=94 4. Replace =93ovreride" with =93override=94 Comments to Backward compatibility section 7: 1. Replace =93Backward=94 with =93Backwards=94 2. Replace =93compatibility=94 with =93Compatibility=94 (capital =91C= =92) An OF is generally designed to compute a Rank of a directional link in a fashion that is diffent from a bidirectional link, and in particular will not use the same metrics and thusobtain different ranks for a same situation. 1. Replace =93diffent=94 with =93different=94 2. Missing space between =93thus=94 and =93obtain=94 An OF that supports directional links SHOULD favor directional links ove= r non directional links, in a fashion that is to be specified with the OF. In the case of OF0 [I-D.ietf-roll-of0], the 'D' flag should be accounted for before the computation of item 8 in the "Selection Of The Preferred Parent" section 4.2.1., that is before Ranks and be calculated and compared. 1. Replace =93specified with the OF=94 with =93specified by the OF=94 2. Replace =93section 4.2.1.,=94 with =93section 4.2.1,=94 (remove ex= tra dot) 3. Replace =93that is before *R*anks and be calculated and compared=94 with =93that is before *r*anks are calculated and compared=94 (is there anything else that needs comparison other than the rank?) Comments to IANA Considerations section 8: This specification requires that a bit in DIO be assigned to indicate directional link operations as specified in section 1. Replace =93a bit in DIO be assigned=94 with =93a bit in DIO shall = be assigned=94 2. Replace =93as specified in section=94 with =93as specified in sect= ion 5=94 Comments to Security Considerations section 9: Security Considerations for this proposal are to be developed in accordance with recommendations laid out in, for example, [I-D.tsao-roll-security-framework]. 1. Replace =93Security *C*onsiderations for this proposal=94 in the f= irst line with =93Security *c*onsiderations for this proposal=94 (non-capitalize= d =91c=92) --f46d044267a08c3a3b04b2e568fe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Dear Roll-ers,

Find below comments to the draft.

Mo= stly editorial, I hope they make sense.

Best regards,

Yoav

=A0

Comments to Introduction section 1:

=A0=A0 In one hand, RPL requires bi-directional links for the control,= but

=A0=A0 on the other, there is no requirement that the prop= erties of a link

=A0=A0 are the same in both dir= ections.=A0 In fact, a perfect symmetry is

=A0=A0 rarely present in Low Power and Lossy Networks (LLN= s), whether links

=A0=A0 are based on radios or = power-line.

1.=A0=A0=A0=A0=A0=A0 <= /span>Replace =93In one hand=94 with =93On one hand=94

2.=A0=A0=A0=A0=A0=A0 <= /span>Replace =93on the other,=94 with =93on the other hand,=94.

3.=A0=A0=A0=A0=A0=A0 <= /span>Replace =93whether links are based on radios or power-line=94 with = =93such as wireless radio or power-line links.=94

=A0
=A0=A0 Some initial implementations require that the qua=
lity of both
=A0=A0 directions of a link is evaluated as very goo=
d so that the link can
=A0=A0 be used for control and data in bot=
h directions.=A0 This eliminates
=A0=A0 asymmetrical links that are very good in one direction, but onl=
y good
=A0=A0 enough for scarce activity in the other direction.<=
/pre>
=A0

4.=A0=A0=A0=A0=A0=A0 Rep=
lace =93that the quality of both directions of a link is evaluated as very =
good=94 with =93that the quality of both directions of a link is evaluated =
as operational at an acceptable level=94 =96 because they do not necessaril=
y have to be very good.


=A0
Comments to Terminology sect=
ion 2:
=A0=A0 The term upwards qualifies a link, a DODAG or =
an instance that is


=A0=A0 optimal for sending traffic in the general direction of the roo=
t,
=A0=A0 though may be usable but suboptimal for traffic coming =
form the
=A0=A0 direction of the root.=A0 The term downwards qual=
ifies the same words


=A0=A0 for the opposite direction.
1.=A0=A0=
=A0=A0=A0=A0 Should the term =93inst=
ance=94 be replaced with the term =93RPL instance=94? 


2.=A0=A0=A0=A0=A0=A0 <=
/span>What does =93general direction of the root=94 means? Shouldn=92t it s=
imply be =93towards the root=94?


3.=A0=A0=A0=A0=A0=A0 <=
/span>Replace =93though may be usable but suboptimal for traffic coming =
form the direction of the root=93 with =93though may be usable but subo=
ptimal for traffic coming from the direction of the root=94 (form=3D=
from)


4.=A0=A0=A0=A0=A0=A0 <=
/span>Replace =93The term downwards qualifies the same words for the=
 opposite direction=94 with =93The term downwards qualifies the same wor=
ding, only for opposite directions=94


5.=A0=A0=A0=A0=A0=A0 <=
/span>Question: shouldn=92t the terms =93upwards=94 and =93downwards=94 be =
included into the terminology draft?


=A0
=A0
=A0=A0 bi-dire=
ctional:=A0 A link is bi-directional when traffic confirmed
=A0=
=A0=A0=A0=A0 possible in both direction, in a fashion that is sufficient to=

=A0=A0=A0=A0=A0 operate RPL control.


=A0
1.=A0=A0=A0=A0=A0=A0 Replace =93possible in both direction=94 with =93possibl=
e in both directions=94 (missing =91s=92).


=A0
=A0=A0 asymmetric:=A0 A link is assymetric if it is bi-d=
irectional, but
=A0=A0=A0=A0=A0 exhibits important differences in=
 link characteristics for both
=A0=A0=A0=A0=A0 directions.
<=
p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l16 level=
1 lfo4">
1.=A0=A0=A0=A0=A0=A0 Rep=
lace =93A link is assymetric=94 with =93A link is asymmetric=
=94 (typo)


2.=A0=A0=A0=A0=A0=A0 <=
/span>Replace =93important=94 with =93major=94


=A0
Comments to The asym=
metrical link problem section 3:

1.=A0=A0=A0=A0=A0=A0 Cap=
italize first letter of each word like in all other sections.


=A0
Comments to Solution Overview =
section 4:
=A0=A0 One direct consequence of that design
=A0=A0 choice is that a topology must be very good for both upwards and
=A0=A0 downwards traffic; 
1.<=
span style=3D"font:7.0pt "Times New Roman"">=A0=A0=A0=A0=A0=A0 Replace =93very good=94 with =93operat=
ional at an acceptable level=94.


=A0
=A0 =A0In that case, an asymmetrical lin=
k,
=A0=A0 that can only be used for traffic in one direction, can=
 not
=A0=A0 participate to the routing topology.=A0 
1.=A0=A0=A0=A0=A0=A0 Rep=
lace =93can not=94 with =93cannot=94.


=A0
=A0 =A0OTOH, with RPL as it is specified,...
1.=A0=A0=A0=A0=A0=A0 R=
eplace =93OTOH=94 with =93On the other hand=94.


=A0
=A0=A0 ... so that a node may transfer traffic from an i=
nstance onto another.
1.=A0=A0=A0=A0=A0=A0 =
Replace =93an instance onto another=94 with=
 =93an upwards instance onto the downwards instance=94.


=A0
Comments to Modified DIO secti=
on 5:
=A0=A0 Directional (D):=A0 The Directional (D) flag is set =
to indicate that
=A0=A0=A0=A0=A0=A0=A0=A0 the instance is intende=
d for directional operation, and reset


=A0=A0=A0=A0=A0=A0=A0=A0 otherwise.=A0 When it is set, a MOP of 0 indi=
cates the upwards
=A0=A0=A0=A0=A0=A0=A0=A0 direction whereas any =
other value specified in
=A0=A0=A0=A0=A0=A0=A0=A0 [I-D.ietf-roll-=
rpl] indicates downwards.=A0 All other values of


=A0=A0=A0=A0=A0=A0=A0=A0 MOP will be considered downwards unless expli=
citly specified
=A0=A0=A0=A0=A0=A0=A0=A0 otherwise.
=
1.=A0=A0=A0=A0=A0=A0 Rep=
lace =93and reset otherwise=94 with =93and is reset otherwise=94.


2.=A0=A0=A0=A0=A0=A0 Replace =93upwards direction=94 with =93upwards=94, or add the word =
=93direction=94 to all subsequence indications of the word =93downwards=94<=
/p>

3.=A0=A0=A0=A0=A0=A0 Replace =93will be considered downwards=94 with =93shall be considered=
 downwards=94.


=A0
Comments to Operation=
s section 6:
=A0
=A0=A0 This specification allow=
s an organization of Instances as follows:

1.=A0=A0=A0=A0=A0=A0 Rep=
lace =93Instances=94 with =93instances=94 (non-capitalized =91I=92)
=A0
=A0=A0=A0=A0=A0 The direction is indicated by the MOP field,=
 a MOP of 0 means
=A0=A0=A0=A0=A0 upwards and otherwise is downwards.

2.=A0=A0=A0=A0=A0=A0 Replace= =93a MOP of 0 means=94 with =93a MOP set to a value 0 indicates=94

3.=A0=A0=A0=A0=A0=A0 <= /span>Replace =93and otherwise is downwards=94 with =93and indicates downwa= rds if set otherwise=94.

=A0

=A0 =A0=A0=A0=A0Transferring from an upw=
ards instance to a downwards instance if
=A0=A0=A0=A0=A0 generall=
y desirable. Other forms of transfers are generally not
=A0=A0=A0=
=A0=A0 desirable.=A0 Policies MAY be put in place to ovreride that general<=
/pre>

=A0=A0=A0=A0=A0 guidance.
=A0
1.=
=A0=A0=A0=A0=A0=A0 Replace =93if=94 =
with =93is=94


2.=A0=A0=A0=A0=A0=A0 =
Remove =93generally=94 and =93general=94 or explain what they mean.<=
/p>

3.=A0=A0=A0=A0=A0=A0 =
Replace =93put in place=94 with =93used=94


4.=A0=A0=A0=A0=A0=A0 =
Replace =93ovreride" with =93override=94


=A0
Comments to Backward =
compatibility section 7:
1.=A0=A0=A0=A0=A0=
=A0 Replace =93Backward=94 with =93B=
ackwards=94


2.=A0=A0=A0=A0=A0=A0 <=
/span>Replace =93compatibility=94 with =93Compatibility=94 (capital =91C=92=
)


=A0
=A0=A0 An OF is generally designed to co=
mpute a Rank of a directional link
=A0=A0 in a fashion that is di=
ffent from a bidirectional link, and in
=A0=A0 particular will no=
t use the same metrics and thusobtain different


=A0=A0 ranks for a same situation. 
1.=A0=A0=
=A0=A0=A0=A0 Replace =93diffent=94 w=
ith =93different=94


2.=A0=A0=A0=A0=A0=A0 <=
/span>Missing space between =93thus=94 and =93obtain=94


=A0
=A0=A0 An OF that supports directional l=
inks SHOULD favor directional links over
=A0=A0 non directional l=
inks, in a fashion that is to be specified with the
=A0=A0 OF.=A0=
 In the case of OF0 [I-D.ietf-roll-of0], the 'D' flag should be

=A0=A0 accounted for before the computation of item 8 in the "Sel=
ection Of
=A0=A0 The Preferred Parent" section 4.2.1., that =
is before Ranks and be
=A0=A0 calculated and compared.

1.=A0=A0=A0=A0=A0=A0 Rep=
lace =93specified with the OF=94 with =93specified by the OF=94

2.=A0=A0=A0=A0=A0=A0 Rep=
lace =93section 4.2.1.,=94 with =93section 4.2.1,=94 (remove extra dot)
=

3.=A0=A0=A0=A0=A0=A0 Replace =93that is before Ranks and be=
 calculated and compared=94 with =93that is before ranks are calcula=
ted and compared=94 (is there anything else that needs comparison other tha=
n the rank?)


=A0
Comments to IANA Cons=
iderations section 8:
=A0=A0 This specification requires t=
hat a bit in DIO be assigned to indicate
=A0=A0 directional link =
operations as specified in section


1.=A0=A0=A0=A0=A0=A0 =
Replace =93a bit in DIO be assigned=94 with =93a bit in DIO shall be=
 assigned=94


2.=A0=A0=A0=A0=A0=A0 =
Replace =93as specified in section=94 with =93as specified in sectio=
n 5=94


=A0
Comments to Security =
Considerations section 9:
=A0=A0 Security Considerations f=
or this proposal are to be developed in
=A0=A0 accordance with re=
commendations laid out in, for example,


=A0=A0 [I-D.tsao-roll-security-framework].
1.=A0=A0=A0=A0=A0=A0 Replace =93Sec=
urity Considerations for this proposal=94 in the first line with =93=
Security considerations for this proposal=94 (non-capitalized =91c=
=92)


=A0
=A0
=A0
=A0
=A0
=A0
--f46d044267a08c3a3b04b2e568fe-- From pthubert@cisco.com Tue Nov 29 22:51:55 2011 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 6AB4911E808B for ; Tue, 29 Nov 2011 22:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 DOeDa5zq80Jc for ; Tue, 29 Nov 2011 22:51:48 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 366C811E8083 for ; Tue, 29 Nov 2011 22:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=65534; q=dns/txt; s=iport; t=1322635905; x=1323845505; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ZKHiltx1aMUcVLZXGojj13L3/VXuWrQko2V8+jlh5Os=; b=hhcV3L/a2Dwyyj17LDA8tOnevK4etjKWRWrkdW5A1ODZP5tALqrTjsYo 2DXVeLXqUktZ6EzAebgcUzwDZmMhx6LKjJDJJYLQa8+N9HPWdIjyLHvms rVdlHNyF/foV7BPXD8tDctfcoOEoEGYmpyo8F3/1L8nhxruo8zG0mhKKk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAL3R1U6Q/khL/2dsb2JhbABEgk2oNoEFgXIBAQEEDAYBCREDSRACAQgRBAEBCwYQAQYBBgFFCQgBAQQBCQkIEwehXQGeNoouYwSmaA X-IronPort-AV: E=Sophos;i="4.69,595,1315180800"; d="scan'208,217";a="122779494" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 30 Nov 2011 06:51:43 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAU6ph1o013484; Wed, 30 Nov 2011 06:51:43 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Nov 2011 07:51:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAF2C.851F2C1B" Date: Wed, 30 Nov 2011 07:50:31 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Mail regarding draft-thubert-roll-asymlink Thread-Index: Acyu04PCqW7QkuVjRCeei851PmupjAAWK8fA References: From: "Pascal Thubert (pthubert)" To: "Yoav Ben-Yehezkel" , X-OriginalArrivalTime: 30 Nov 2011 06:51:43.0398 (UTC) FILETIME=[8522E460:01CCAF2C] Cc: roll@ietf.org Subject: Re: [Roll] Mail regarding draft-thubert-roll-asymlink X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 06:51:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCAF2C.851F2C1B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks a bunch Yoav. =20 On the side, do you see that this work is useful for your applications? =20 Cheers, =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Yoav Ben-Yehezkel Sent: mardi 29 novembre 2011 21:20 To: draft-thubert-roll-asymlink@tools.ietf.org Cc: roll@ietf.org Subject: [Roll] Mail regarding draft-thubert-roll-asymlink =20 Dear Roll-ers, Find below comments to the draft.=20 Mostly editorial, I hope they make sense. Best regards, Yoav =20 Comments to Introduction section 1: In one hand, RPL requires bi-directional links for the control, but on the other, there is no requirement that the properties of a link are the same in both directions. In fact, a perfect symmetry is rarely present in Low Power and Lossy Networks (LLNs), whether links are based on radios or power-line. 1. Replace "In one hand" with "On one hand"=20 2. Replace "on the other," with "on the other hand,". 3. Replace "whether links are based on radios or power-line" with "such as wireless radio or power-line links." =20 Some initial implementations require that the quality of both directions of a link is evaluated as very good so that the link can be used for control and data in both directions. This eliminates asymmetrical links that are very good in one direction, but only good enough for scarce activity in the other direction. =20 4. Replace "that the quality of both directions of a link is evaluated as very good" with "that the quality of both directions of a link is evaluated as operational at an acceptable level" - because they do not necessarily have to be very good. =20 Comments to Terminology section 2: The term upwards qualifies a link, a DODAG or an instance that is optimal for sending traffic in the general direction of the root, though may be usable but suboptimal for traffic coming form the direction of the root. The term downwards qualifies the same words for the opposite direction. 1. Should the term "instance" be replaced with the term "RPL instance"?=20 2. What does "general direction of the root" means? Shouldn't it simply be "towards the root"? 3. Replace "though may be usable but suboptimal for traffic coming form the direction of the root" with "though may be usable but suboptimal for traffic coming from the direction of the root" (form=3Dfrom) 4. Replace "The term downwards qualifies the same words for the opposite direction" with "The term downwards qualifies the same wording, only for opposite directions" 5. Question: shouldn't the terms "upwards" and "downwards" be included into the terminology draft? =20 =20 bi-directional: A link is bi-directional when traffic confirmed possible in both direction, in a fashion that is sufficient to operate RPL control. =20 1. Replace "possible in both direction" with "possible in both directions" (missing 's'). =20 asymmetric: A link is assymetric if it is bi-directional, but exhibits important differences in link characteristics for both directions. 1. Replace "A link is assymetric" with "A link is asymmetric" (typo) 2. Replace "important" with "major" =20 Comments to The asymmetrical link problem section 3: 1. Capitalize first letter of each word like in all other sections. =20 Comments to Solution Overview section 4: One direct consequence of that design choice is that a topology must be very good for both upwards and =20 downwards traffic;=20 1. Replace "very good" with "operational at an acceptable level". =20 In that case, an asymmetrical link, that can only be used for traffic in one direction, can not participate to the routing topology. =20 1. Replace "can not" with "cannot". =20 OTOH, with RPL as it is specified,... 1. Replace "OTOH" with "On the other hand". =20 ... so that a node may transfer traffic from an instance onto another. 1. Replace "an instance onto another" with "an upwards instance onto the downwards instance". =20 Comments to Modified DIO section 5: Directional (D): The Directional (D) flag is set to indicate that the instance is intended for directional operation, and reset otherwise. When it is set, a MOP of 0 indicates the upwards direction whereas any other value specified in [I-D.ietf-roll-rpl] indicates downwards. All other values of MOP will be considered downwards unless explicitly specified otherwise. 1. Replace "and reset otherwise" with "and is reset otherwise". 2. Replace "upwards direction" with "upwards", or add the word "direction" to all subsequence indications of the word "downwards" 3. Replace "will be considered downwards" with "shall be considered downwards". =20 Comments to Operations section 6: =20 This specification allows an organization of Instances as follows: 1. Replace "Instances" with "instances" (non-capitalized 'I') =20 The direction is indicated by the MOP field, a MOP of 0 means upwards and otherwise is downwards. 2. Replace "a MOP of 0 means" with "a MOP set to a value 0 indicates" 3. Replace "and otherwise is downwards" with "and indicates downwards if set otherwise". =20 Transferring from an upwards instance to a downwards instance if generally desirable. Other forms of transfers are generally not desirable. Policies MAY be put in place to ovreride that general guidance. =20 1. Replace "if" with "is" 2. Remove "generally" and "general" or explain what they mean. 3. Replace "put in place" with "used" 4. Replace "ovreride" with "override" =20 Comments to Backward compatibility section 7: 1. Replace "Backward" with "Backwards" 2. Replace "compatibility" with "Compatibility" (capital 'C') =20 An OF is generally designed to compute a Rank of a directional link in a fashion that is diffent from a bidirectional link, and in particular will not use the same metrics and thusobtain different ranks for a same situation.=20 1. Replace "diffent" with "different" 2. Missing space between "thus" and "obtain" =20 An OF that supports directional links SHOULD favor directional links over non directional links, in a fashion that is to be specified with the OF. In the case of OF0 [I-D.ietf-roll-of0], the 'D' flag should be accounted for before the computation of item 8 in the "Selection Of The Preferred Parent" section 4.2.1., that is before Ranks and be calculated and compared. 1. Replace "specified with the OF" with "specified by the OF" 2. Replace "section 4.2.1.," with "section 4.2.1," (remove extra dot) 3. =20 4. Replace "that is before Ranks and be calculated and compared" with "that is before ranks are calculated and compared" (is there anything else that needs comparison other than the rank?) =20 Comments to IANA Considerations section 8: This specification requires that a bit in DIO be assigned to indicate directional link operations as specified in section 1. Replace "a bit in DIO be assigned" with "a bit in DIO shall be assigned" 2. Replace "as specified in section" with "as specified in section 5" =20 Comments to Security Considerations section 9: Security Considerations for this proposal are to be developed in accordance with recommendations laid out in, for example, [I-D.tsao-roll-security-framework]. 1. Replace "Security Considerations for this proposal" in the first line with "Security considerations for this proposal" (non-capitalized 'c') =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CCAF2C.851F2C1B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks a bunch = Yoav.

 

On the = side, do you see that this work is useful for your = applications?

 

Cheers,

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Yoav Ben-Yehezkel
Sent: mardi 29 novembre 2011 = 21:20
To: = draft-thubert-roll-asymlink@tools.ietf.org
Cc: = roll@ietf.org
Subject: [Roll] Mail regarding = draft-thubert-roll-asymlink

 

Dear Roll-ers,

Find below comments to the draft. =

Mostly = editorial, I hope they make sense.

Best = regards,

Yoav

 

Comments to = Introduction section 1:

   In one hand, RPL requires bi-directional links for = the control, but

   on the = other, there is no requirement that the properties of a link

   are the same in both directions.  In fact, a = perfect symmetry is

   rarely = present in Low Power and Lossy Networks (LLNs), whether = links

   are = based on radios or power-line.

1.       = Replace “In one = hand” with “On one hand”

2.       = Replace “on the = other,” with “on the other = hand,”.

3.       = Replace “whether = links are based on radios or power-line” with “such as = wireless radio or power-line = links.”

 
   Some initial implementations require that the =
quality of both
   directions of a link is evaluated as very good =
so that the link can
   be used for control and data in both =
directions.  This eliminates
   asymmetrical links that are very good in one =
direction, but only good
   enough for scarce activity in the other =
direction.

 

4.       = Replace “that = the quality of both directions of a link is evaluated as very = good” with “that the quality of both directions of a link is = evaluated as operational at an acceptable level” – because = they do not necessarily have to be very good.

 

Comments to = Terminology section 2:

   =
The term upwards qualifies a link, a DODAG or an instance that =
is
   optimal =
for sending traffic in the general direction of the =
root,
   though =
may be usable but suboptimal for traffic coming form =
the
   =
direction of the root.  The term downwards qualifies the same =
words
   for =
the opposite direction.

1.       = Should the term = “instance” be replaced with the term “RPL = instance”?

2.       = What does = “general direction of the root” means? Shouldn’t it = simply be “towards the root”?

3.       = Replace “though = may be usable but suboptimal for traffic coming form the = direction of the root“ with “though may be usable but = suboptimal for traffic coming from the direction of the = root” (form=3Dfrom)

4.       = Replace “The = term downwards qualifies the same words for the opposite = direction” with “The term downwards qualifies the same = wording, only for opposite = directions”

5.       = Question: = shouldn’t the terms “upwards” and = “downwards” be included into the terminology = draft?

 
 
   bi-directional:  A link is bi-directional =
when traffic confirmed
      possible in both direction, =
in a fashion that is sufficient to
      operate RPL =
control.
 

1.       = Replace = “possible in both direction” with “possible in both = directions” (missing = ‘s’).

 
   asymmetric:  A link is assymetric if it =
is bi-directional, but
      exhibits important =
differences in link characteristics for =
both
      =
directions.

1.       = Replace “A link = is assymetric” with “A link is = asymmetric” (typo)

2.       = Replace = “important” with “major”

 

Comments to =
The asymmetrical link problem section =
3:

1.       = Capitalize first = letter of each word like in all other = sections.

 
Comments to Solution Overview =
section 4:
   One direct consequence of that =
design
   =
choice is that a topology must be very good for both upwards =
and
 
   downwards traffic;

1.       = Replace “very = good” with “operational at an acceptable = level”.

 

  =
 In that case, an asymmetrical =
link,
   that =
can only be used for traffic in one direction, can =
not
   =
participate to the routing topology. 

1.       = Replace “can = not” with “cannot”.

 
   OTOH, with RPL as it is =
specified,...

1.       = Replace = “OTOH” with “On the other = hand”.

 
   ... so that a node may transfer traffic from =
an instance onto another.

1.       = Replace “an = instance onto another” with “an upwards instance onto the = downwards instance”.

 
Comments to Modified DIO section =
5:
   =
Directional (D):  The Directional (D) flag is set to indicate =
that
         the =
instance is intended for directional operation, and =
reset
         =
otherwise.  When it is set, a MOP of 0 indicates the =
upwards
         direction =
whereas any other value specified in
         =
[I-D.ietf-roll-rpl] indicates downwards.  All other values =
of
         MOP will =
be considered downwards unless explicitly =
specified
         =
otherwise.

1.       = Replace “and = reset otherwise” with “and is reset = otherwise”.

2.       = Replace “upwards = direction” with “upwards”, or add the word = “direction” to all subsequence indications of the word = “downwards”

3.       = Replace “will be = considered downwards” with “shall be considered = downwards”.

 

Comments to Operations section =
6:
 
   This specification allows an organization of =
Instances as follows:

1.       = Replace = “Instances” with “instances” (non-capitalized = ‘I’)

 
      The direction is indicated =
by the MOP field, a MOP of 0 means
      upwards and otherwise is =
downwards.

2.       = Replace “a MOP = of 0 means” with “a MOP set to a value 0 = indicates”

3.       = Replace “and = otherwise is downwards” with “and indicates downwards if set = otherwise”.

 

  =
    Transferring from an upwards instance to a =
downwards instance if
      generally desirable. Other =
forms of transfers are generally not
      desirable.  Policies =
MAY be put in place to ovreride that =
general
      =
guidance.
 

1.       = Replace = “if” with “is”

2.       = Remove = “generally” and “general” or explain what they = mean.

3.       = Replace “put in = place” with “used”

4.       = Replace = “ovreride" with = “override”

 

Comments to Backward compatibility =
section 7:

1.       = Replace = “Backward” with = “Backwards”

2.       = Replace = “compatibility” with “Compatibility” (capital = ‘C’)

 

   An OF is generally designed to compute a Rank =
of a directional link
   in a fashion that is diffent from a =
bidirectional link, and in
   particular will not use the same metrics and =
thusobtain different
   ranks for a same situation. =

1.       = Replace = “diffent” with = “different”

2.       = Missing space between = “thus” and “obtain”

 

   An OF that supports directional links SHOULD =
favor directional links over
   non directional links, in a fashion that is to =
be specified with the
   OF.  In the case of OF0 =
[I-D.ietf-roll-of0], the 'D' flag should =
be
   accounted =
for before the computation of item 8 in the "Selection =
Of
   The =
Preferred Parent" section 4.2.1., that is before Ranks and =
be
   =
calculated and compared.

1.       = Replace = “specified with the OF” with “specified by the = OF”

2.       = Replace “section = 4.2.1.,” with “section 4.2.1,” (remove extra = dot)

3.   
4.  Replace =
“that is before Ranks and be calculated and compared” =
with “that is before ranks are calculated and =
compared” (is there anything else that needs comparison other than =
the rank?)

 

Comments to IANA Considerations =
section 8:
   This specification requires that a bit in DIO =
be assigned to indicate
   directional link operations as specified in =
section

1.       = Replace “a bit = in DIO be assigned” with “a bit in DIO shall be = assigned”

2.       = Replace “as = specified in section” with “as specified in section = 5”

 

Comments to Security Considerations =
section 9:
   Security Considerations for this proposal are =
to be developed in
   accordance with recommendations laid out in, =
for example,
   =
[I-D.tsao-roll-security-framework].

1.       = Replace = “Security Considerations for this proposal” in the = first line with “Security considerations for this = proposal” (non-capitalized = ‘c’)

 

 

 
 
 

 

------_=_NextPart_001_01CCAF2C.851F2C1B-- From yoav@yitran.com Tue Nov 29 23:07:06 2011 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 08AFC21F8663 for ; Tue, 29 Nov 2011 23:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.876 X-Spam-Level: X-Spam-Status: No, score=-6.876 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 kXOTyAkZ5Acv for ; Tue, 29 Nov 2011 23:07:04 -0800 (PST) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with SMTP id 72B5C21F861E for ; Tue, 29 Nov 2011 23:07:03 -0800 (PST) Received: from mail-ey0-f169.google.com ([209.85.215.169]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTtXWFI0O7Y7aP8D5WfpYtHH25OkBQfBp@postini.com; Tue, 29 Nov 2011 23:07:03 PST Received: by mail-ey0-f169.google.com with SMTP id h1so307191eaa.0 for ; Tue, 29 Nov 2011 23:06:59 -0800 (PST) Received: by 10.216.136.165 with SMTP id w37mr141508wei.63.1322636819697; Tue, 29 Nov 2011 23:06:59 -0800 (PST) From: Yoav Ben-Yehezkel References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD05Ow7TCgMEYS9E4k6fJEbM9+heQNUk284l1nsmpA= Date: Wed, 30 Nov 2011 09:04:24 +0200 Message-ID: <632e9525de2f52226a3b07603ee56083@mail.gmail.com> To: "Pascal Thubert (pthubert)" , draft-thubert-roll-asymlink@tools.ietf.org Content-Type: multipart/alternative; boundary=0016e6da2eb7ce0f8404b2ee6112 Cc: roll@ietf.org Subject: Re: [Roll] Mail regarding draft-thubert-roll-asymlink X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 07:07:06 -0000 --0016e6da2eb7ce0f8404b2ee6112 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Pascal, This is exactly what I am trying to find out =96 and that=92s why I=92ve re= viewed it. I can update when I reach some conclusion. As a side note - I was given credit and acknowledgement for some reason so I thought it=92d be nice if I actually contributed something J Best regards and thanks, Yoav *From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] *Sent:* Wednesday, November 30, 2011 8:51 AM *To:* Yoav Ben-Yehezkel; draft-thubert-roll-asymlink@tools.ietf.org *Cc:* roll@ietf.org *Subject:* RE: [Roll] Mail regarding draft-thubert-roll-asymlink Thanks a bunch Yoav. On the side, do you see that this work is useful for your applications? Cheers, Pascal *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of *Yoav Ben-Yehezkel *Sent:* mardi 29 novembre 2011 21:20 *To:* draft-thubert-roll-asymlink@tools.ietf.org *Cc:* roll@ietf.org *Subject:* [Roll] Mail regarding draft-thubert-roll-asymlink Dear Roll-ers, Find below comments to the draft. Mostly editorial, I hope they make sense. Best regards, Yoav Comments to Introduction section 1: In one hand, RPL requires bi-directional links for the control, but on the other, there is no requirement that the properties of a link are the same in both directions. In fact, a perfect symmetry is rarely present in Low Power and Lossy Networks (LLNs), whether links are based on radios or power-line. 1. Replace =93In one hand=94 with =93On one hand=94 2. Replace =93on the other,=94 with =93on the other hand,=94. 3. Replace =93whether links are based on radios or power-line=94 with =93such as wireless radio or power-line links.=94 Some initial implementations require that the quality of both directions of a link is evaluated as very good so that the link can be used for control and data in both directions. This eliminates asymmetrical links that are very good in one direction, but only good enough for scarce activity in the other direction. 4. Replace =93that the quality of both directions of a link is evaluated as very good=94 with =93that the quality of both directions of a = link is evaluated as operational at an acceptable level=94 =96 because they do n= ot necessarily have to be very good. Comments to Terminology section 2: The term upwards qualifies a link, a DODAG or an instance that is optimal for sending traffic in the general direction of the root, though may be usable but suboptimal for traffic coming form the direction of the root. The term downwards qualifies the same words for the opposite direction. 1. Should the term =93instance=94 be replaced with the term =93RPL instance=94? 2. What does =93general direction of the root=94 means? Shouldn=92t i= t simply be =93towards the root=94? 3. Replace =93though may be usable but suboptimal for traffic coming = * form* the direction of the root=93 with =93though may be usable but subopti= mal for traffic coming *from* the direction of the root=94 (form=3Dfrom) 4. Replace =93The term downwards qualifies the same *words* for the opposite direction=94 with =93The term downwards qualifies the same *wording,* *only *for opposite directions=94 5. Question: shouldn=92t the terms =93upwards=94 and =93downwards=94 = be included into the terminology draft? bi-directional: A link is bi-directional when traffic confirmed possible in both direction, in a fashion that is sufficient to operate RPL control. 1. Replace =93possible in both direction=94 with =93possible in both direction*s*=94 (missing =91s=92). asymmetric: A link is assymetric if it is bi-directional, but exhibits important differences in link characteristics for both directions. 1. Replace =93A link is a*ssym*etric=94 with =93A link is a*symm*etri= c=94 (typo) 2. Replace =93important=94 with =93major=94 Comments to The asymmetrical link problem section 3: 1. Capitalize first letter of each word like in all other sections. Comments to Solution Overview section 4: One direct consequence of that design choice is that a topology must be very good for both upwards and downwards traffic; 1. Replace =93very good=94 with =93operational at an acceptable level= =94. In that case, an asymmetrical link, that can only be used for traffic in one direction, can not participate to the routing topology. 1. Replace =93can not=94 with =93cannot=94. OTOH, with RPL as it is specified,... 1. Replace =93OTOH=94 with =93On the other hand=94. ... so that a node may transfer traffic from an instance onto another. 1. Replace =93an instance onto another=94 with =93an upwards instance= onto the downwards instance=94. Comments to Modified DIO section 5: Directional (D): The Directional (D) flag is set to indicate that the instance is intended for directional operation, and reset otherwise. When it is set, a MOP of 0 indicates the upwards direction whereas any other value specified in [I-D.ietf-roll-rpl] indicates downwards. All other values of MOP will be considered downwards unless explicitly specified otherwise. 1. Replace =93and reset otherwise=94 with =93and is reset otherwise= =94. 2. Replace =93upwards direction=94 with =93upwards=94, or add the wor= d =93direction=94 to all subsequence indications of the word =93downwards=94 3. Replace =93will be considered downwards=94 with =93shall be consid= ered downwards=94. Comments to Operations section 6: This specification allows an organization of Instances as follows: 1. Replace =93Instances=94 with =93instances=94 (non-capitalized =91I= =92) The direction is indicated by the MOP field, a MOP of 0 means upwards and otherwise is downwards. 2. Replace =93a MOP of 0 means=94 with =93a MOP set to a value 0 indi= cates=94 3. Replace =93and otherwise is downwards=94 with =93and indicates dow= nwards if set otherwise=94. Transferring from an upwards instance to a downwards instance if generally desirable. Other forms of transfers are generally not desirable. Policies MAY be put in place to ovreride that general guidance. 1. Replace =93if=94 with =93is=94 2. Remove =93generally=94 and =93general=94 or explain what they mean= . 3. Replace =93put in place=94 with =93used=94 4. Replace =93ovreride" with =93override=94 Comments to Backward compatibility section 7: 1. Replace =93Backward=94 with =93Backwards=94 2. Replace =93compatibility=94 with =93Compatibility=94 (capital =91C= =92) An OF is generally designed to compute a Rank of a directional link in a fashion that is diffent from a bidirectional link, and in particular will not use the same metrics and thusobtain different ranks for a same situation. 1. Replace =93diffent=94 with =93different=94 2. Missing space between =93thus=94 and =93obtain=94 An OF that supports directional links SHOULD favor directional links ove= r non directional links, in a fashion that is to be specified with the OF. In the case of OF0 [I-D.ietf-roll-of0], the 'D' flag should be accounted for before the computation of item 8 in the "Selection Of The Preferred Parent" section 4.2.1., that is before Ranks and be calculated and compared. 1. Replace =93specified with the OF=94 with =93specified by the OF=94 2. Replace =93section 4.2.1.,=94 with =93section 4.2.1,=94 (remove ex= tra dot) 3. 4. Replace =93that is before *R*anks and be calculated and compared=94 with =93that is before *r*anks are calculated and compared=94 (is there anything else that needs comparison other than the rank?) Comments to IANA Considerations section 8: This specification requires that a bit in DIO be assigned to indicate directional link operations as specified in section 1. Replace =93a bit in DIO be assigned=94 with =93a bit in DIO shall = be assigned=94 2. Replace =93as specified in section=94 with =93as specified in sect= ion 5=94 Comments to Security Considerations section 9: Security Considerations for this proposal are to be developed in accordance with recommendations laid out in, for example, [I-D.tsao-roll-security-framework]. 1. Replace =93Security *C*onsiderations for this proposal=94 in the f= irst line with =93Security *c*onsiderations for this proposal=94 (non-capitalize= d =91c=92) --0016e6da2eb7ce0f8404b2ee6112 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Pascal,

=A0=

This is exactly what I am trying to find out = =96 and that=92s why I=92ve reviewed it. I can update when I reach some con= clusion.

=A0=

As a side note - I was= given credit and acknowledgement for some reason so I thought it=92d be ni= ce if I actually contributed something J

=A0

Best regards and thanks,

Yoav

=A0

From: Pascal Thubert (pthubert)= [mailto:pthubert@cisco.com]
Sent: Wednesday, November 30, 2011 8:51 AM
To: Yoav Ben-Ye= hezkel; draft= -thubert-roll-asymlink@tools.ietf.org
Cc: roll@ietf.org
Subject: RE: [Roll] Mail regarding draft-thubert-roll-asymlink

=A0

Thanks a bunch Yoav.

=A0

On the side, do you se= e that this work is useful for your applications?

=A0

= Cheers,

=A0

Pascal=

= =A0

=A0

Dear Roll-ers,

Find below comment= s to the draft.

Mostly editorial, I hope they make sense.

Best regards,

Yoav

=A0

Comments to Introduction section 1:

=A0=A0 In one hand, RPL requires bi-directional links for the control,= but

=A0=A0 on the other, there is no requirement that the prop= erties of a link

=A0=A0 are the same in both dir= ections.=A0 In fact, a perfect symmetry is

=A0=A0 rarely present in Low Power and Lossy Networks (LLN= s), whether links

=A0=A0 are based on radios or = power-line.

1.=A0=A0=A0=A0=A0=A0 <= /span>Replace =93In one hand=94 with =93On one hand=94

2.=A0=A0=A0=A0=A0=A0 <= /span>Replace =93on the other,=94 with =93on the other hand,=94.

3.=A0=A0=A0=A0=A0=A0 <= /span>Replace =93whether links are based on radios or power-line=94 with = =93such as wireless radio or power-line links.=94

=A0
=A0=A0 Some initial implementations require that the qua=
lity of both
=A0=A0 directions of a link is evaluated as very goo=
d so that the link can
=A0=A0 be used for control and data in bot=
h directions.=A0 This eliminates
=A0=A0 asymmetrical links that are very good in one direction, but onl=
y good
=A0=A0 enough for scarce activity in the other direction.<=
/pre>
=A0

4.=A0=A0=A0=A0=A0=A0 Rep=
lace =93that the quality of both directions of a link is evaluated as very =
good=94 with =93that the quality of both directions of a link is evaluated =
as operational at an acceptable level=94 =96 because they do not necessaril=
y have to be very good.


=A0
Comments to Terminology sect=
ion 2:
=A0=A0 The term upwards qualifies a link, a DODAG or =
an instance that is


=A0=A0 optimal for sending traffic in the general direction of the roo=
t,
=A0=A0 though may be usable but suboptimal for traffic coming =
form the
=A0=A0 direction of the root.=A0 The term downwards qual=
ifies the same words


=A0=A0 for the opposite direction.
1.=A0=A0=
=A0=A0=A0=A0 Should the term =93inst=
ance=94 be replaced with the term =93RPL instance=94? 


2.=A0=A0=A0=A0=A0=A0 <=
/span>What does =93general direction of the root=94 means? Shouldn=92t it s=
imply be =93towards the root=94?


3.=A0=A0=A0=A0=A0=A0 <=
/span>Replace =93though may be usable but suboptimal for traffic coming =
form the direction of the root=93 with =93though may be usable but subo=
ptimal for traffic coming from the direction of the root=94 (form=3D=
from)


4.=A0=A0=A0=A0=A0=A0 <=
/span>Replace =93The term downwards qualifies the same words for the=
 opposite direction=94 with =93The term downwards qualifies the same wor=
ding, only for opposite directions=94


5.=A0=A0=A0=A0=A0=A0 <=
/span>Question: shouldn=92t the terms =93upwards=94 and =93downwards=94 be =
included into the terminology draft?


=A0
=A0
=A0=A0 bi-dire=
ctional:=A0 A link is bi-directional when traffic confirmed
=A0=
=A0=A0=A0=A0 possible in both direction, in a fashion that is sufficient to=

=A0=A0=A0=A0=A0 operate RPL control.


=A0
1.=A0=A0=A0=A0=A0=A0 Replace =93possible in both direction=94 with =93possibl=
e in both directions=94 (missing =91s=92).


=A0
=A0=A0 asymmetric:=A0 A link is assymetric if it is bi-d=
irectional, but
=A0=A0=A0=A0=A0 exhibits important differences in=
 link characteristics for both
=A0=A0=A0=A0=A0 directions.
<=
p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l16 level=
1 lfo8">
1.=A0=A0=A0=A0=A0=A0 Rep=
lace =93A link is assymetric=94 with =93A link is asymmetric=
=94 (typo)

2.=A0=A0=A0=A0=A0=A0 Rep=
lace =93important=94 with =93major=94
=A0


Comments to The asymmetrical link problem se=
ction 3:
1.=A0=A0=A0=A0=A0=A0 Capitalize first letter of each word like in all other=
 sections.


=A0
Comments to Solution Overview =
section 4:
=A0=A0 One direct consequence of that design
=A0=A0 choice is that a topology must be very good for both upwards and
=A0
=A0=A0 downwards traffic; 
1.=A0=A0=
=A0=A0=A0=A0 Replace =93very good=94=
 with =93operational at an acceptable level=94.


=A0
=A0 =A0In that case, an asymmetrical lin=
k,
=A0=A0 that can only be used for traffic in one direction, can=
 not
=A0=A0 participate to the routing topology.=A0 

1.=A0=A0=A0=A0=A0=A0 Rep=
lace =93can not=94 with =93cannot=94.
=A0
=A0 =A0OTOH, wi=
th RPL as it is specified,...


1.=A0=A0=A0=A0=A0=A0 <=
/span>Replace =93OTOH=94 with =93On the other hand=94.


=A0
=A0=A0 ... so that a node may transfer traffic from an i=
nstance onto another.
1.=A0=A0=A0=A0=A0=A0 Replace =93an instance onto another=94 wit=
h =93an upwards instance onto the downwards instance=94.


=A0
Comments to Modified DIO secti=
on 5:
=A0=A0 Directional (D):=A0 The Directional (D) flag is set =
to indicate that
=A0=A0=A0=A0=A0=A0=A0=A0 the instance is intende=
d for directional operation, and reset


=A0=A0=A0=A0=A0=A0=A0=A0 otherwise.=A0 When it is set, a MOP of 0 indi=
cates the upwards
=A0=A0=A0=A0=A0=A0=A0=A0 direction whereas any =
other value specified in
=A0=A0=A0=A0=A0=A0=A0=A0 [I-D.ietf-roll-=
rpl] indicates downwards.=A0 All other values of


=A0=A0=A0=A0=A0=A0=A0=A0 MOP will be considered downwards unless expli=
citly specified
=A0=A0=A0=A0=A0=A0=A0=A0 otherwise.
1.=A0=A0=A0=A0=A0=A0 Re=
place =93and reset otherwise=94 with =93and is reset otherwise=94.


2.=A0=A0=A0=A0=A0=A0 <=
/span>Replace =93upwards direction=94 with =93upwards=94, or add the word =
=93direction=94 to all subsequence indications of the word =93downwards=94<=
/p>

3.=A0=A0=A0=A0=A0=A0 <=
/span>Replace =93will be considered downwards=94 with =93shall be considere=
d downwards=94.


=A0
Comments to Operation=
s section 6:
=A0
=A0=A0 This specification allow=
s an organization of Instances as follows:

1.=A0=A0=A0=A0=A0=A0 Rep=
lace =93Instances=94 with =93instances=94 (non-capitalized =91I=92)
=A0
=A0=A0=A0=A0=A0 The direction is indicated by the MOP field,=
 a MOP of 0 means
=A0=A0=A0=A0=A0 upwards and otherwise is downwards.

2.=A0=A0=A0=A0=A0=A0 Replace= =93a MOP of 0 means=94 with =93a MOP set to a value 0 indicates=94

3.=A0=A0=A0=A0=A0=A0 <= /span>Replace =93and otherwise is downwards=94 with =93and indicates downwa= rds if set otherwise=94.

=A0

=A0 =A0=A0=A0=A0Transferring from an upw=
ards instance to a downwards instance if
=A0=A0=A0=A0=A0 generall=
y desirable. Other forms of transfers are generally not
=A0=A0=A0=
=A0=A0 desirable.=A0 Policies MAY be put in place to ovreride that general<=
/pre>

=A0=A0=A0=A0=A0 guidance.
=A0
1.=
=A0=A0=A0=A0=A0=A0 Replace =93if=94 =
with =93is=94


2.=A0=A0=A0=A0=A0=A0 =
Remove =93generally=94 and =93general=94 or explain what they mean.<=
/p>

3.=A0=A0=A0=A0=A0=A0 =
Replace =93put in place=94 with =93used=94


4.=A0=A0=A0=A0=A0=A0 =
Replace =93ovreride" with =93override=94


=A0
Comments to Backward =
compatibility section 7:
1.=A0=A0=A0=A0=A0=
=A0 Replace =93Backward=94 with =93B=
ackwards=94


2.=A0=A0=A0=A0=A0=A0 <=
/span>Replace =93compatibility=94 with =93Compatibility=94 (capital =91C=92=
)


=A0
=A0=A0 An OF is generally designed to co=
mpute a Rank of a directional link
=A0=A0 in a fashion that is di=
ffent from a bidirectional link, and in
=A0=A0 particular will no=
t use the same metrics and thusobtain different


=A0=A0 ranks for a same situation. 
1.=A0=A0=
=A0=A0=A0=A0 Replace =93diffent=94 w=
ith =93different=94


2.=A0=A0=A0=A0=A0=A0 <=
/span>Missing space between =93thus=94 and =93obtain=94


=A0
=A0=A0 An OF that supports directional l=
inks SHOULD favor directional links over
=A0=A0 non directional l=
inks, in a fashion that is to be specified with the
=A0=A0 OF.=A0=
 In the case of OF0 [I-D.ietf-roll-of0], the 'D' flag should be

=A0=A0 accounted for before the computation of item 8 in the "Sel=
ection Of
=A0=A0 The Preferred Parent" section 4.2.1., that =
is before Ranks and be
=A0=A0 calculated and compared.

1.=A0=A0=A0=A0=A0=A0 Rep=
lace =93specified with the OF=94 with =93specified by the OF=94

2.=A0=A0=A0=A0=A0=A0 Rep=
lace =93section 4.2.1.,=94 with =93section 4.2.1,=94 (remove extra dot)
=

3.=A0 =A0
4.=A0 Replace =93th=
at is before Ranks and be calculated and compared=94 with =93that is=
 before ranks are calculated and compared=94 (is there anything else=
 that needs comparison other than the rank?)


=A0
Comments to IANA Cons=
iderations section 8:
=A0=A0 This specification requires t=
hat a bit in DIO be assigned to indicate
=A0=A0 directional link =
operations as specified in section


1.=A0=A0=A0=A0=A0=A0 =
Replace =93a bit in DIO be assigned=94 with =93a bit in DIO shall be=
 assigned=94


2.=A0=A0=A0=A0=A0=A0 =
Replace =93as specified in section=94 with =93as specified in sectio=
n 5=94


=A0
Comments to Security =
Considerations section 9:
=A0=A0 Security Considerations f=
or this proposal are to be developed in
=A0=A0 accordance with re=
commendations laid out in, for example,


=A0=A0 [I-D.tsao-roll-security-framework].
1.=A0=A0=A0=A0=A0=A0 Replace =93Sec=
urity Considerations for this proposal=94 in the first line with =93=
Security considerations for this proposal=94 (non-capitalized =91c=
=92)


=A0
=A0
=A0
=A0
=A0
=A0
--0016e6da2eb7ce0f8404b2ee6112-- From pthubert@cisco.com Tue Nov 29 23:24:45 2011 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 AD58011E8083 for ; Tue, 29 Nov 2011 23:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.098 X-Spam-Level: X-Spam-Status: No, score=-11.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, GB_I_LETTER=-2, 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 4Vh3uctT7ypa for ; Tue, 29 Nov 2011 23:24:41 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4DB11E8073 for ; Tue, 29 Nov 2011 23:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=72033; q=dns/txt; s=iport; t=1322637877; x=1323847477; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=yFDVOHul9Mm9fzm/OWoEZ8Ufm11EkuWpgRvlo1+4vVA=; b=V3q7ljmaL8Mv5jOvIkSTFQCpJviCZDYfXWHZ5CLTtXs+kSEAjM6XziaN wCfluKkKrmx0s3ZfXBortpzqNPFNl38XegdydOKLDrtYi7uAg9ByUYIhr GdA5sm1vAbejR7BtYc+SxUv1LVW3C8GgIMN4TR+gxeqbGA77hPdsZuG4o 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAAAAfa1U6Q/khN/2dsb2JhbABEgk2YHJAagQWBcgEBAQQMBgEJEQM+CxACAQgRBAEBCwYQAQYBBgFFCQgCBAEJCQgTB6FVAZ42ii5jBKZo X-IronPort-AV: E=Sophos;i="4.69,595,1315180800"; d="scan'208,217";a="122780527" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 30 Nov 2011 07:24:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAU7OMgI019912; Wed, 30 Nov 2011 07:24:22 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Nov 2011 08:24:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAF31.14A5F85D" Date: Wed, 30 Nov 2011 08:23:06 +0100 Message-ID: In-Reply-To: <632e9525de2f52226a3b07603ee56083@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Mail regarding draft-thubert-roll-asymlink Thread-Index: AQD05Ow7TCgMEYS9E4k6fJEbM9+heQNUk284l1nsmpCAAAZLoA== References: <632e9525de2f52226a3b07603ee56083@mail.gmail.com> From: "Pascal Thubert (pthubert)" To: "Yoav Ben-Yehezkel" , X-OriginalArrivalTime: 30 Nov 2011 07:24:22.0382 (UTC) FILETIME=[14C820E0:01CCAF31] Cc: roll@ietf.org Subject: Re: [Roll] Mail regarding draft-thubert-roll-asymlink X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 07:24:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCAF31.14A5F85D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yoav : =20 I digged the mailing list to figure what had been discussed so far in order to use that as a base for this work. You actually participated to those discussions and provided input. Fair is fair... =20 Pascal =20 From: Yoav Ben-Yehezkel [mailto:yoav@yitran.com]=20 Sent: mercredi 30 novembre 2011 08:04 To: Pascal Thubert (pthubert); draft-thubert-roll-asymlink@tools.ietf.org Cc: roll@ietf.org Subject: RE: [Roll] Mail regarding draft-thubert-roll-asymlink =20 Pascal, =20 This is exactly what I am trying to find out - and that's why I've reviewed it. I can update when I reach some conclusion. =20 As a side note - I was given credit and acknowledgement for some reason so I thought it'd be nice if I actually contributed something J =20 Best regards and thanks, Yoav =20 From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Wednesday, November 30, 2011 8:51 AM To: Yoav Ben-Yehezkel; draft-thubert-roll-asymlink@tools.ietf.org Cc: roll@ietf.org Subject: RE: [Roll] Mail regarding draft-thubert-roll-asymlink =20 Thanks a bunch Yoav. =20 On the side, do you see that this work is useful for your applications? =20 Cheers, =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Yoav Ben-Yehezkel Sent: mardi 29 novembre 2011 21:20 To: draft-thubert-roll-asymlink@tools.ietf.org Cc: roll@ietf.org Subject: [Roll] Mail regarding draft-thubert-roll-asymlink =20 Dear Roll-ers, Find below comments to the draft.=20 Mostly editorial, I hope they make sense. Best regards, Yoav =20 Comments to Introduction section 1: In one hand, RPL requires bi-directional links for the control, but on the other, there is no requirement that the properties of a link are the same in both directions. In fact, a perfect symmetry is rarely present in Low Power and Lossy Networks (LLNs), whether links are based on radios or power-line. 1. Replace "In one hand" with "On one hand"=20 2. Replace "on the other," with "on the other hand,". 3. Replace "whether links are based on radios or power-line" with "such as wireless radio or power-line links." =20 Some initial implementations require that the quality of both directions of a link is evaluated as very good so that the link can be used for control and data in both directions. This eliminates asymmetrical links that are very good in one direction, but only good enough for scarce activity in the other direction. =20 4. Replace "that the quality of both directions of a link is evaluated as very good" with "that the quality of both directions of a link is evaluated as operational at an acceptable level" - because they do not necessarily have to be very good. =20 Comments to Terminology section 2: The term upwards qualifies a link, a DODAG or an instance that is optimal for sending traffic in the general direction of the root, though may be usable but suboptimal for traffic coming form the direction of the root. The term downwards qualifies the same words for the opposite direction. 1. Should the term "instance" be replaced with the term "RPL instance"?=20 2. What does "general direction of the root" means? Shouldn't it simply be "towards the root"? 3. Replace "though may be usable but suboptimal for traffic coming form the direction of the root" with "though may be usable but suboptimal for traffic coming from the direction of the root" (form=3Dfrom) 4. Replace "The term downwards qualifies the same words for the opposite direction" with "The term downwards qualifies the same wording, only for opposite directions" 5. Question: shouldn't the terms "upwards" and "downwards" be included into the terminology draft? =20 =20 bi-directional: A link is bi-directional when traffic confirmed possible in both direction, in a fashion that is sufficient to operate RPL control. =20 1. Replace "possible in both direction" with "possible in both directions" (missing 's'). =20 asymmetric: A link is assymetric if it is bi-directional, but exhibits important differences in link characteristics for both directions. 1. Replace "A link is assymetric" with "A link is asymmetric" (typo) 2. Replace "important" with "major" =20 Comments to The asymmetrical link problem section 3: 1. Capitalize first letter of each word like in all other sections. =20 Comments to Solution Overview section 4: One direct consequence of that design choice is that a topology must be very good for both upwards and =20 =20 downwards traffic;=20 1. Replace "very good" with "operational at an acceptable level". =20 In that case, an asymmetrical link, that can only be used for traffic in one direction, can not participate to the routing topology. =20 1. Replace "can not" with "cannot". =20 OTOH, with RPL as it is specified,... 1. Replace "OTOH" with "On the other hand". =20 ... so that a node may transfer traffic from an instance onto another. 1. Replace "an instance onto another" with "an upwards instance onto the downwards instance". =20 Comments to Modified DIO section 5: Directional (D): The Directional (D) flag is set to indicate that the instance is intended for directional operation, and reset otherwise. When it is set, a MOP of 0 indicates the upwards direction whereas any other value specified in [I-D.ietf-roll-rpl] indicates downwards. All other values of MOP will be considered downwards unless explicitly specified otherwise. 1. Replace "and reset otherwise" with "and is reset otherwise". 2. Replace "upwards direction" with "upwards", or add the word "direction" to all subsequence indications of the word "downwards" 3. Replace "will be considered downwards" with "shall be considered downwards". =20 Comments to Operations section 6: =20 This specification allows an organization of Instances as follows: 1. Replace "Instances" with "instances" (non-capitalized 'I') =20 The direction is indicated by the MOP field, a MOP of 0 means upwards and otherwise is downwards. 2. Replace "a MOP of 0 means" with "a MOP set to a value 0 indicates" 3. Replace "and otherwise is downwards" with "and indicates downwards if set otherwise". =20 Transferring from an upwards instance to a downwards instance if generally desirable. Other forms of transfers are generally not desirable. Policies MAY be put in place to ovreride that general guidance. =20 1. Replace "if" with "is" 2. Remove "generally" and "general" or explain what they mean. 3. Replace "put in place" with "used" 4. Replace "ovreride" with "override" =20 Comments to Backward compatibility section 7: 1. Replace "Backward" with "Backwards" 2. Replace "compatibility" with "Compatibility" (capital 'C') =20 An OF is generally designed to compute a Rank of a directional link in a fashion that is diffent from a bidirectional link, and in particular will not use the same metrics and thusobtain different ranks for a same situation.=20 1. Replace "diffent" with "different" 2. Missing space between "thus" and "obtain" =20 An OF that supports directional links SHOULD favor directional links over non directional links, in a fashion that is to be specified with the OF. In the case of OF0 [I-D.ietf-roll-of0], the 'D' flag should be accounted for before the computation of item 8 in the "Selection Of The Preferred Parent" section 4.2.1., that is before Ranks and be calculated and compared. 1. Replace "specified with the OF" with "specified by the OF" 2. Replace "section 4.2.1.," with "section 4.2.1," (remove extra dot) 3. =20 4. =20 5. Replace "that is before Ranks and be calculated and compared" with "that is before ranks are calculated and compared" (is there anything else that needs comparison other than the rank?) =20 Comments to IANA Considerations section 8: This specification requires that a bit in DIO be assigned to indicate directional link operations as specified in section 1. Replace "a bit in DIO be assigned" with "a bit in DIO shall be assigned" 2. Replace "as specified in section" with "as specified in section 5" =20 Comments to Security Considerations section 9: Security Considerations for this proposal are to be developed in accordance with recommendations laid out in, for example, [I-D.tsao-roll-security-framework]. 1. Replace "Security Considerations for this proposal" in the first line with "Security considerations for this proposal" (non-capitalized 'c') =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CCAF31.14A5F85D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yoav :

 

I digged = the mailing list to figure what had been discussed so far in order to = use that as a base for this work.

You = actually participated to those discussions and provided input. Fair is = fair…

 

Pascal

 

From:= Yoav = Ben-Yehezkel [mailto:yoav@yitran.com]
Sent: mercredi 30 = novembre 2011 08:04
To: Pascal Thubert (pthubert); = draft-thubert-roll-asymlink@tools.ietf.org
Cc: = roll@ietf.org
Subject: RE: [Roll] Mail regarding = draft-thubert-roll-asymlink

 

Pascal,

 

This is exactly what I am trying to = find out – and that’s why I’ve reviewed it. I can = update when I reach some conclusion.

 

As a side note - I was given credit = and acknowledgement for some reason so I thought it’d be nice if I = actually contributed something J

 

Best regards and = thanks,

Yoav

 

From:= Pascal = Thubert (pthubert) [mailto:pthubert@cisco.com] =
Sent: Wednesday, November 30, 2011 8:51 AM
To: Yoav = Ben-Yehezkel; draft-thubert-= roll-asymlink@tools.ietf.org
Cc: roll@ietf.org
Subject: RE: = [Roll] Mail regarding draft-thubert-roll-asymlink

 

Thanks a = bunch Yoav.

 

On the side, do you see that this = work is useful for your applications?

 

Cheers,

 

Pascal

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.= org] On Behalf Of Yoav Ben-Yehezkel
Sent: mardi 29 = novembre 2011 21:20
To: draft-thubert-= roll-asymlink@tools.ietf.org
Cc: roll@ietf.org
Subject: = [Roll] Mail regarding draft-thubert-roll-asymlink

 

Dear = Roll-ers,

Find below comments to the draft.

Mostly editorial, I hope they make = sense.

Best = regards,

Yoav

 

Comments to = Introduction section 1:

   In one hand, RPL requires bi-directional links for = the control, but

   on the = other, there is no requirement that the properties of a link

   are the same in both directions.  In fact, a = perfect symmetry is

   rarely = present in Low Power and Lossy Networks (LLNs), whether = links

   are = based on radios or power-line.

1.       = Replace “In one = hand” with “On one hand”

2.       = Replace “on the = other,” with “on the other = hand,”.

3.       = Replace “whether = links are based on radios or power-line” with “such as = wireless radio or power-line = links.”

 
   Some initial implementations require that the =
quality of both
   directions of a link is evaluated as very good =
so that the link can
   be used for control and data in both =
directions.  This eliminates
   asymmetrical links that are very good in one =
direction, but only good
   enough for scarce activity in the other =
direction.

 

4.       = Replace “that = the quality of both directions of a link is evaluated as very = good” with “that the quality of both directions of a link is = evaluated as operational at an acceptable level” – because = they do not necessarily have to be very good.

 

Comments to = Terminology section 2:

   =
The term upwards qualifies a link, a DODAG or an instance that =
is
   optimal =
for sending traffic in the general direction of the =
root,
   though =
may be usable but suboptimal for traffic coming form =
the
   =
direction of the root.  The term downwards qualifies the same =
words
   for =
the opposite direction.

1.       = Should the term = “instance” be replaced with the term “RPL = instance”?

2.       = What does = “general direction of the root” means? Shouldn’t it = simply be “towards the root”?

3.       = Replace “though = may be usable but suboptimal for traffic coming form the = direction of the root“ with “though may be usable but = suboptimal for traffic coming from the direction of the = root” (form=3Dfrom)

4.       = Replace “The = term downwards qualifies the same words for the opposite = direction” with “The term downwards qualifies the same = wording, only for opposite = directions”

5.       = Question: = shouldn’t the terms “upwards” and = “downwards” be included into the terminology = draft?

 
 
   bi-directional:  A link is bi-directional =
when traffic confirmed
      possible in both direction, =
in a fashion that is sufficient to
      operate RPL =
control.
 

1.       = Replace = “possible in both direction” with “possible in both = directions” (missing = ‘s’).

 
   asymmetric:  A link is assymetric if it =
is bi-directional, but
      exhibits important =
differences in link characteristics for =
both
      =
directions.

1.       = Replace “A link = is assymetric” with “A link is = asymmetric” (typo)

2.       = Replace = “important” with “major”

 

Comments to =
The asymmetrical link problem section =
3:

1.       = Capitalize first = letter of each word like in all other = sections.

 
Comments to Solution Overview =
section 4:
   One direct consequence of that =
design
   =
choice is that a topology must be very good for both upwards =
and
 
 
   downwards traffic;

1.       = Replace “very = good” with “operational at an acceptable = level”.

 

  =
 In that case, an asymmetrical =
link,
   that =
can only be used for traffic in one direction, can =
not
   =
participate to the routing topology. 

1.       = Replace “can = not” with “cannot”.

 
   OTOH, with RPL as it is =
specified,...

1.       = Replace = “OTOH” with “On the other = hand”.

 
   ... so that a node may transfer traffic from =
an instance onto another.

1.       = Replace “an = instance onto another” with “an upwards instance onto the = downwards instance”.

 
Comments to Modified DIO section =
5:
   =
Directional (D):  The Directional (D) flag is set to indicate =
that
         the =
instance is intended for directional operation, and =
reset
         =
otherwise.  When it is set, a MOP of 0 indicates the =
upwards
         direction =
whereas any other value specified in
         =
[I-D.ietf-roll-rpl] indicates downwards.  All other values =
of
         MOP will =
be considered downwards unless explicitly =
specified
         =
otherwise.

1.       = Replace “and = reset otherwise” with “and is reset = otherwise”.

2.       = Replace “upwards = direction” with “upwards”, or add the word = “direction” to all subsequence indications of the word = “downwards”

3.       = Replace “will be = considered downwards” with “shall be considered = downwards”.

 

Comments to Operations section =
6:
 
   This specification allows an organization of =
Instances as follows:

1.       = Replace = “Instances” with “instances” (non-capitalized = ‘I’)

 
      The direction is indicated =
by the MOP field, a MOP of 0 means
      upwards and otherwise is =
downwards.

2.       = Replace “a MOP = of 0 means” with “a MOP set to a value 0 = indicates”

3.       = Replace “and = otherwise is downwards” with “and indicates downwards if set = otherwise”.

 

  =
    Transferring from an upwards instance to a =
downwards instance if
      generally desirable. Other =
forms of transfers are generally not
      desirable.  Policies =
MAY be put in place to ovreride that =
general
      =
guidance.
 

1.       = Replace = “if” with “is”

2.       = Remove = “generally” and “general” or explain what they = mean.

3.       = Replace “put in = place” with “used”

4.       = Replace = “ovreride" with = “override”

 

Comments to Backward compatibility =
section 7:

1.       = Replace = “Backward” with = “Backwards”

2.       = Replace = “compatibility” with “Compatibility” (capital = ‘C’)

 

   An OF is generally designed to compute a Rank =
of a directional link
   in a fashion that is diffent from a =
bidirectional link, and in
   particular will not use the same metrics and =
thusobtain different
   ranks for a same situation. =

1.       = Replace = “diffent” with = “different”

2.       = Missing space between = “thus” and “obtain”

 

   An OF that supports directional links SHOULD =
favor directional links over
   non directional links, in a fashion that is to =
be specified with the
   OF.  In the case of OF0 =
[I-D.ietf-roll-of0], the 'D' flag should =
be
   accounted =
for before the computation of item 8 in the "Selection =
Of
   The =
Preferred Parent" section 4.2.1., that is before Ranks and =
be
   =
calculated and compared.

1.       = Replace = “specified with the OF” with “specified by the = OF”

2.       = Replace “section = 4.2.1.,” with “section 4.2.1,” (remove extra = dot)

3.   
4.   
5.  Replace =
“that is before Ranks and be calculated and compared” =
with “that is before ranks are calculated and =
compared” (is there anything else that needs comparison other than =
the rank?)

 

Comments to IANA Considerations =
section 8:
   This specification requires that a bit in DIO =
be assigned to indicate
   directional link operations as specified in =
section

1.       = Replace “a bit = in DIO be assigned” with “a bit in DIO shall be = assigned”

2.       = Replace “as = specified in section” with “as specified in section = 5”

 

Comments to Security Considerations =
section 9:
   Security Considerations for this proposal are =
to be developed in
   accordance with recommendations laid out in, =
for example,
   =
[I-D.tsao-roll-security-framework].

1.       = Replace = “Security Considerations for this proposal” in the = first line with “Security considerations for this = proposal” (non-capitalized = ‘c’)

 

 

 
 
 

 

------_=_NextPart_001_01CCAF31.14A5F85D--