From pthubert@cisco.com Sun Apr 1 00:41:20 2012 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 06F0321F8697 for ; Sun, 1 Apr 2012 00:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.76 X-Spam-Level: X-Spam-Status: No, score=-6.76 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 XHbmwnN8zMJT for ; Sun, 1 Apr 2012 00:41:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4035721F8693 for ; Sun, 1 Apr 2012 00:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=12370; q=dns/txt; s=iport; t=1333266078; x=1334475678; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=TNzB0oGpq7ORgteCX2t9kiG0RMHDmLx2G/TXeltaD2Q=; b=mu4YBkw66JLTU+uKyaMTJzReA55mNmYwmG36l6DXY8sFck8YJOnC3Bmn ESjKbw7zy98E+casdc70xIbIs4I4keyQWWVzj1+mGycFix4DjsYSLjjSq /X0Tuo+lfNTyCIv5yHyvKDUh7vuSYokKOiLG9Pma7v7deDjZ6A0ULGmCz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAP4FeE+Q/khR/2dsb2JhbABEDoU5sjaBAIEHggoBAQQSARANBEUQAgEIGgIGBhgCAgIBAVUBAQQbEweHZ5sljQiRE4EviVEKAYR5NWMEpCiBaIIwOYFSARY X-IronPort-AV: E=Sophos;i="4.75,352,1330905600"; d="scan'208";a="133937997" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2012 07:41:17 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q317fHJC008793; Sun, 1 Apr 2012 07:41:17 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); Sun, 1 Apr 2012 09:41:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 1 Apr 2012 09:40:29 +0200 Message-ID: In-Reply-To: <404086078.1764222.1333237279941.JavaMail.root@mail17.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Part 2 Re: [Roll] G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 Thread-Index: Ac0Pl8hUSdpuYGU/QCuDjt+fxhheXAAP27QA References: <404086078.1764222.1333237279941.JavaMail.root@mail17.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 01 Apr 2012 07:41:16.0903 (UTC) FILETIME=[D24AFF70:01CD0FDA] Cc: ROLL WG Subject: Re: [Roll] Part 2 Re: G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 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, 01 Apr 2012 07:41:20 -0000 SGkgTXVrdWw6DQoNCkkgdGhpbmsgd2UgbmVlZCB0byBjcmVhdGUgYSBudW1iZXIgb2YgbGFzdCBj YWxsIGlzc3VlcyBmb3IgdHJhY2tpbmcgcHVycG9zZS4gRXZlcnl0aGluZyBJIHNuaXBwZWQgb2Zm IGlzIGFuIGltcGxpY2l0IGFjY2VwdGFuY2Ugb2YgeW91ciByZXNwb25zZS4uLg0KDQoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqDQoNCltQYXNjYWwyXSANCjIpIFNhbWUgcXVlc3Rpb24gaWYgeW91IHdhbnQgdG8gY3JlYXRl IHN0YXRlcyBhdCB0aGUgdGFyZ2V0IHRvIHJvdXRlIGJhY2suIEhvdyBsb25nIGRvZXMgdGhlIHRh cmdldCBuZWVkIHRvIG1haW50YWluIHRoZSByb3V0ZT8gV2hvIGNvbnRyb2xzIHRoYXQsIHRoZSBv cmlnaW4gb3IgdGhlIHRhcmdldD8gSSdkIGV4cGVjdCB0byBmaW5kIGEgc3VnZ2VzdGVkIGxpZmV0 aW1lIGluIHRoZSBSRE8gd2l0aCBhIGNvbmZpcm1hdGlvbiBpbiB0aGUgRFJPIHRvIGxldCB0aGUg dGFyZ2V0IGFtZW5kIGl0Lg0KDQpbTXVrdWwyXQ0KSWYgdGhlIHRhcmdldCB3YW50cyBEUk8tQUNL IGl0IG5lZWRzIHRvIG1haW50YWluIHN0YXRlIHVudGlsIERSTy1BQ0sgaXMgcmVjZWl2ZWQuIE90 aGVyd2lzZSwgdGhlIHRhcmdldCBuZWVkcyB0byByZW1lbWJlciB0aGluZ3MgdW50aWwgaXQgaXMg ZG9uZSBzZW5kaW5nIGFsbCB0aGUgRFJPcy4gSSB3aWxsIGFkZCB0aGUgdGV4dCB0byB0aGlzIGVm ZmVjdC4NCg0KW1Bhc2NhbDNdIA0KSWYgeW91IGFyZSBzZXR0aW5nIHVwIGEgc2hvcnQgdGVybSBj b252ZXJzYXRpb24sIGhvdyBsb25nIGV4YWN0bHkgaXMgdGhhdCBiZWZvcmUgdGhlIG9yaWdpbiBo YXMgdG8gcmVmcmVzaCB0aGUgcm91dGU/IFdoYXQgY29udHJvbHMgY2xlYW4gdXAgaW4gYm90aCBz aWRlcz8gVXN1YWxseSB5b3Ugd2FudCBhIGxpZmV0aW1lIChzZWUgTUlQNiBmb3IgaW5zdGFuY2Up DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KW1Bhc2NhbF0NCiJSUExJbnN0YW5j ZUlEOiBSUExJbnN0YW5jZUlEIE1VU1QgYmUgYSBsb2NhbCB2YWx1ZSBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiA1LjEgb2YgW0ktRC5pZXRmLXJvbGwtcnBsXS4gVGhlIG9yaWdpbiBNVVNUIE5PVCB1 c2UgdGhlIHNhbWUgUlBMSW5zdGFuY2VJRCBpbiB0d28gb3IgbW9yZSBjb25jdXJyZW50IHJvdXRl IGRpc2NvdmVyaWVzLiINCg0KSSdkIHN1Z2dlc3QgdGhhdCB5b3UgZW5mb3JjZSBhIHJvdW5kIHJv YmluIG9yIGFuIG9wYXF1ZSBjaXJjdWxhdGlvbiBzbyB0aGF0IHRoZSBuZXcgaW5zdGFuY2VJRCBp cyB0aGUgbGVhc3QgcmVjZW50bHkgdXNlZCBvbmUgb3V0IG9mIHRoZSA2NCBwb3NzaWJsZS4NCg0K W011a3VsXQ0KSSB0aGluayB3ZSBzaG91bGQgbGVhdmUgaXQgdG8gdGhlIG9yaWdpbiB0byBkZWNp ZGUgd2hpY2ggdmFsdWUgaXQgd2FudHMgdG8gdXNlIGZvciBSUExJbnN0YW5jZUlELiBJIGtub3cg c29tZSBpbXBsZW1lbnRhdGlvbnMgYXJlIHBsYW5uaW5nIHRvIHVzZSBhIGZpeGVkIFJQTEluc3Rh bmNlSUQgdmFsdWUgZm9yIGFsbCByb3V0ZSBkaXNjb3Zlcmllcy4NCg0KW1Bhc2NhbDJdIENoYW5n aW5nIHRoZSBpbnN0YW5jZSBJRCB3aWxsIGhlbHAgZGVidWcgdGhlIG5ldHdvcmsgYW5kIGF2b2lk IGNvbmZsaWN0cyB3aXRoIHN0YWxlIHN0YXRlcy4gV2hhdCdzIHJlYWxseSB1cCB0byB0aGUgZGV2 aWNlIGlzIHRoZSBpbml0aWFsIHNlcXVlbmNlLiBMZWF2aW5nIGl0IHVwIHRvIHRoZSBvcmlnaW4g bWF5IGhlbHAgdGhlIG9yaWdpbiBkZWZlYXQgc29tZSBhdHRhY2tzIHRvIHNvbWUgZGVncmVlLiBP VE9ILCBhZnRlciBhbGwgdGhlIGluc3RhbmNlcyBoYXZlIGJlZW4gcGxheWVkLCBMUlUgZm9yY2Vz IHRvIHJlcGxheSB0aGUgc2FtZSBzZXF1ZW5jZSBhZ2FpbiBzbyB0aGUgc2hpZWxkIGRyb3BzLiBN eSBwcmVmZXJyZWQgYXBwcm9hY2ggd291bGQgYmUgYSBTSE9VTEQgdGhhdCB3b3VsZCBzYXkgdGhh dCB0aGUgbmV4dCBpbnN0YW5jZSBJRCBTSE9VTEQgTk9UIGJlIG9uZSBvZiB0aGUgKDE2PykgbW9z dCByZWNlbnRseSB1c2VkIGFuZCBNVVNUIE5PVCBiZSBvbmUgZm9yIHdoaWNoIHN0YXRlcyBtaWdo dCBzdGlsbCBleGlzdCBpbiB0aGUgbmV0d29yay4gSU9XIGVpdGhlciB0aGUgc3RhdGVzIGRlbGV0 aW9uIHdhcyBhY2tub3dsZWRnZWQsIG9yIGFsbCBwZW5kaW5nIGxpZmV0aW1lcyBhcmUgZXhoYXVz dGVkLg0KDQpbTXVrdWwyXSBNYWtlcyBzZW5zZS4gSSB0aGluayBpdCBpcyBzdWZmaWNpZW50IHRv IGNhdXRpb24gKHdpdGggYSBTSE9VTEQgTk9UKSBhZ2FpbnN0IHJldXNpbmcgaW5zdGFuY2UgaWRz IGZvciB3aGljaCB0aGUgc3RhbGUgc3RhdGUgbWlnaHQgZXhpc3QgaW4gdGhlIG5vZGVzLiBVc2lu ZyBhICJNVVNUIE5PVCIgbWF5IG5vdCBiZSBPSyBzaW5jZSBhIG5vZGUgbWF5IG5ldmVyIGJlIDEw MCUgc3VyZSBhYm91dCBub24tZXhpc3RlbmNlIG9mIHN0YWxlIHN0YXRlIHdpdGggYSBwYXJ0aWN1 bGFyIGluc3RhbmNlIGlkICh0aHVzLCBhbGwgcG9zc2libGUgaW5zdGFuY2UgaWQgdmFsdWVzIHdp bGwgYmVjb21lIHN1c3BlY3QgYW5kIGhlbmNlIHVudXNhYmxlIGFmdGVyIGEgd2hpbGUpLg0KDQpb UGFzY2FsM10gQWdyZWVkLiBOb3RlIHRoYXQgYSBjaXJjdWxhdGlvbiBpcyBhIGJvbnVzIHRvIGRl ZmVhdCByZXBsYXlzLiBBbmQgbm93IHdlJ3JlIGJhY2sgdG8gdGhlIGlzc3VlIGFib3ZlLiBIb3cg ZG9lcyB0aGUgZGV2aWNlIGtub3cgdGhhdCB0aGVyZSBpcyBubyBzdGF0ZSBsZWZ0PyBBIGxpZmV0 aW1lIGRlZmluaXRpb24gd291bGQgYmUgdmVyeSB1c2VmdWwuIFRoYXQgbGlmZXRpbWUgaXMgZGlm ZmVyZW50IGZyb20gdGhlIERBRydzIG9uZSBpbiBSRE8uIEkgdGhpbmsgd2UgaGF2ZSBhbiBvcGVu IGlzc3VlIGhlcmUuDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KW1Bhc2Nh bF0NCiIgR3JvdW5kZWQgKEcpIEZsYWc6IE1VU1QgYmUgc2V0IHRvIHplcm8gc2luY2UgdGhpcyBE QUcgaXMgdGVtcG9yYXJ5IGluIG5hdHVyZSwgaXMgY3JlYXRlZCBzb2xlbHkgZm9yIHRoZSBwdXJw b3NlIG9mIFAyUC1SUEwgcm91dGUgZGlzY292ZXJ5IGFuZCBNVVNUIE5PVCBiZSB1c2VkIGZvciBw YWNrZXQgcm91dGluZy4iDQoNCk9uIHRoZSBjb250cmFyeSBJJ2Qgc2V0IGl0IHRvIDEuIFRoZSBn b2FsIC1iZWluZyB0byByZWFjaCB0aGUgb3JpZ2luLSBpcyBhY3R1YWxseSBhY2hpZXZlZCBieSB0 aGlzIERBRy4NCg0KW011a3VsXQ0KQWN0dWFsbHksIHRoZSBEQUcgaXMgdGVtcG9yYXJ5IGluIG5h dHVyZSBhbmQgdmFuaXNoZXMgYWZ0ZXIgYSBzaG9ydCB3aGlsZS4gRXZlbiB3aGVuIGl0IGV4aXN0 cywgaXQgbXVzdC9zaG91bGQgbm90IGJlIHVzZWQgZm9yIHJvdXRpbmcgcGFja2V0cyBiYWNrIHRv IHRoZSBvcmlnaW4uIFNvLCBJIHRoaW5rIHRoZSBHcm91bmRlZCBmbGFnIHNob3VsZCBiZSB6ZXJv Lg0KDQpbUGFzY2FsMl0gUGxlYXNlIHJldmlzaXQgUkZDIDY2NTAgcGFnZSAxMi4gDQpHIG1lYW5z IHRoYXQgYSBnb2FsIGlzIGFjaGlldmVkLiBTbyBmaXJzdCB5b3UgZGVmaW5lIHRoZSBnb2FsIGFu ZCB0aGVuIHRoZSBiaXQgYmVjb21lcyBvYnZpb3VzLiBXaGF0J3MgeW91ciBnb2FsPyANCkNhbiB0 aGVyZSBiZSBQMlAgREFHcyB0aGF0IGFjaGlldmUgdGhlIGdvYWwgYW5kIG90aGVycyB0aGF0IG1h a2Ugc2Vuc2UgdG8gYnVpbGQgYW5kIHlldCBkbyBub3QgYWNoaWV2ZSB0aGUgZ29hbD8NCklmIHlv dSBhY2NlcHQgdGhhdCB5b3VyIG9wZXJhdGlvbiBjYW4gYWN0dWFsbHkgZGVwZW5kIG9uIE9GIGxv Z2ljLCB0aGVuIHRoZSBzZXR0aW5nIG9mIHRoZSBnb2FsIGluZmx1ZW5jZXMgdGhhdCBsb2dpYy4N CkJ5IGZvcmNpbmcgYSB2YWx1ZSB0byB0aGUgZ29hbCBpbiB0aGUgUFRQIHNwZWMsIHdlIGFjdHVh bGx5IGxpbWl0IHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBkcmFmdC4gDQpNYXliZSB5b3UgY2Fu IGRlZmluZSBhIGRlZmF1bHQgZ29hbCBhbmQgYSBkZWZhdWx0IHNldHRpbmcuIEJ1dCBkbyBub3Qg TVVTVCB0aGF0IGl0IGlzIHNldCB0byAwLi4uDQoNCltNdWt1bDJdDQpXaGVuIGEgbm9kZSBqb2lu cyBhIHRlbXBvcmFyeSBQMlAgREFHLCBpdCBkb2VzIG5vdCBnZXQgYW55IGFkZGl0aW9uYWwgcm91 dGluZyBpbmZvcm1hdGlvbi4gVGhlIERBRyBpcyBnb2luZyB0byBkaXNhcHBlYXIgYWZ0ZXIgc29t ZSB0aW1lLCBzaG91bGQgbm90IGJlIHVzZWQgZm9yIHJvdXRpbmcgd2hpbGUgaXQgZXhpc3RzIGFu ZCB3aGljaCBub2RlcyBlbmQgdXAgYmVpbmcgb24gdGhlIGRpc2NvdmVyZWQgcm91dGUgaXMgbm90 IGtub3duIHVudGlsIHRoZSBEUk8gbWVzc2FnZSBjb21lcyBiYWNrLiBTbywgSSB0aGluaywgYnkg ZGVmYXVsdCwgdGhlIEcgZmxhZyBoYXMgdG8gYmUgemVyby4gSG93ZXZlciwgaWYgdGhlIHNldHRp bmcgb2YgRyBmbGFnIG1heSBhZmZlY3QgaG93IGFuIGludGVybWVkaWF0ZSBub2RlIG1heSBjYWxj dWxhdGUgaXRzIHJhbmsgKGFzIHBlciB0aGUgT0YgYmVpbmcgdXNlZCksIHRoZSBvcmlnaW4gc2hv dWxkIGhhdmUgdGhlIGZsZXhpYmlsaXR5IG9mIHNldHRpbmcgdGhlIGZsYWcgdG8gMS4gU28sIEkg Y291bGQgbW9kaWZ5IHRoZSB0ZXh0IHRvIHNheSB0aGF0ICJ0aGUgb3JpZ2luIHNldHMgdGhlIEcg ZmxhZyBiYXNlZCBvbiBpdHMgcGVyY2VwdGlvbiBvZiBob3cgdGhlIGZsYWcncyB2YWx1ZSB3b3Vs ZCBhZmZlY3QgdGhlIHJhbmsgY2FsY3VsYXRpb24gdW5kZXIgdGhlIE9GIGJlaW5nIHVzZWQuIEJ5 IGRlZmF1bHQsIHRoZSBHIGZsYWcgaXMgc2V0IHRvIHplcm8gZ2l2ZW4gdGhlIHRlbXBvcmFyeSBu YXR1cmUgb2YgdGhlIERBRyBiZWluZyBjcmVhdGVkLiINCg0KW1Bhc2NhbDJdIFdoeSBkbyB5b3Ug ZmVlbCB0aGUgbmVlZCB0byBhZGQgYW55dGhpbmcgYWJvdmUgd2hhdCBSRkMgNjU1MCBzYXlzPyBJ IGRvIG5vdCBzZWUgYW55IGJlbmVmaXQgb3IgYWRkaXRpb25hbCBjbGFyaXR5IGZyb20gZG9pbmcg dGhpcy4NCg0KICANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KW1Bhc2NhbF0i IE1BWSBjYXJyeSBvbmUgb3IgbW9yZSBSUEwgVGFyZ2V0IE9wdGlvbnMgdG8gc3BlY2lmeSBhZGRp dGlvbmFsIHVuaWNhc3QvbXVsdGljYXN0IGFkZHJlc3NlcyBmb3IgdGhlIHRhcmdldC4iDQpOb3cg aGVyZSBJIHdvdWxkIGhhdmUgYSBNVVNUIGNhcnJ5IGF0IGxlYXN0IG9uZSB0YXJnZXQuIFRoYXQg aXMgaW5kZWVkIHdoYXQgbWFrZXMgaXMgYSBsb29rdXAgRElPLi4uDQoNCltNdWt1bF0NCkFzIEkg c3RhdGVkIGluIHRoZSBwcmV2aW91cyBtZXNzYWdlLCB3ZSBuZWVkIHRvIGluY2x1ZGUgdGhlIHRh cmdldCBpbiB0aGUgUDJQLVJETyB0byBzYXZlIGJ5dGVzIGZvciB0aGUgY29tbW9uIGNhc2UgKGRp c2NvdmVyIHJvdXRlIHRvIG9uZSB1bmljYXN0L211bHRpY2FzdCB0YXJnZXQpLiBTbywgd2UgY2Fu bm90IG1ha2UgdXNpbmcgdGhlIHRhcmdldCBvcHRpb24gYSBNVVNULg0KDQpbUGFzY2FsMl0gQ2Vy dGFpbmx5LiBJIHByZWZlciB0aGUgc3BsaXQsIGluIHdoaWNoIGNhc2UgdGhlIE1VU1QgSU1ITyBn b2VzIHRvIHRoZSB0YXJnZXQgYXMgb3Bwb3NlZCB0byB0aGUgUkRPLiBJbiBhIGNhc2Ugd2hlcmUg dGhlIFJETyBpcyBub3QgbmVlZGVkLCB0aGUgdGFyZ2V0IG9ubHkgbWVzc2FnZSBpcyBhY3R1YWxs eSBzaG9ydGVyLi4uDQoNCltNdWt1bDJdIEFzIEkgc2FpZCBiZWZvcmUsIEkgdGhpbmsgYSBQMlAg bW9kZSBESU8gYWx3YXlzIG5lZWRzIHRvIGhhdmUgb25lIFAyUC1SRE8uIEkgZ3Vlc3MsIGluIHRo aXMgY2FzZSwgd2UgYWdyZWUgdG8gZGlzYWdyZWUhDQoNCltQYXNjYWwzXSBDZXJ0YWlubHkuIEFu ZCB0aGVyZSdzIG5vdGhpbmcgYmxvY2tpbmcgd2l0aCB0aGF0IGRpc2FncmVlbWVudCwgbW9zdGx5 IGlmIHRoZSBkcmFmdCB0YXJnZXRzIGV4cGVyaW1lbnRhbC4gDQogSSB0aGluayBpdCdzIE9LIHRv IGtlZXAgeW91ciByZXNwb25zZSBhcyB0aGUgcHJvcG9zZWQgcmVzb2x1dGlvbiBmb3IgdGhlIGlz c3VlLiBTdGlsbCBJJ2QgbGlrZSBhZHZpY2UgZnJvbSBvdGhlcnMgc28gZXhwb3NpbmcgdGhlIGlz c3VlIGFzIExDIHdpbGwgaGVscC4gTGV0J3Mgc2VlIG9uIHdoaWNoIHNpZGUgdGhlIGNvaW4gZmFs bHMuDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KW1Bhc2NhbF0N CkNhbiB0aGUgZGF0YSBvcHRpb24gYmUgZGlmZmVyZW50IGZyb20gb25lIERJTyB0byB0aGUgbmV4 dD8gDQoNCltNdWt1bF0NClRoZSBjb250ZW50cyBvZiB0aGUgZGF0YSBvcHRpb24gYXJlIHNwZWNp ZmllZCBieSB0aGUgb3JpZ2luIChmb3IgdGhlIERJTykgb3IgdGhlIHRhcmdldCAoZm9yIHRoZSBE Uk8pLiBJbiB0aGVvcnksIGFuIG9yaWdpbiBjYW4gc2VuZCBkaWZmZXJlbnQgZGF0YSBvcHRpb25z IGluIGRpZmZlcmVudCBESU9zIGl0IGdlbmVyYXRlcyBmb3IgYSBwYXJ0aWN1bGFyIHJvdXRlIGRp c2NvdmVyeSAoYXNzdW1pbmcgdGhhdCBpdCBkb2VzIGdlbmVyYXRlIG11bHRpcGxlIERJT3M7IGl0 IGlzIHZlcnkgbXVjaCBwb3NzaWJsZSB0aGF0IHRoZSBvcmlnaW4gZ2VuZXJhdGVzIGp1c3Qgb25l IERJTyBhbmQgdGhlbiBzaXRzIHNpbGVudCkuIEJ1dCwgdGhlbiB0aGUgb3JpZ2luIGlzIHRha2lu ZyB0aGUgcmlzayB0aGF0IHNvbWUgb2YgdGhlIGRhdGEgb3B0aW9ucyB3b3VsZCBuZXZlciBlYWNo IHRoZSB0YXJnZXQocykuIEkgZ3Vlc3MgdGhlIG9yaWdpbiBtaWdodCBkbyB0aGlzIGlmIHRoZSBk YXRhIHNlbnQgZWFybGllciBpcyBub3cgc3RhbGUgYW5kIHRoZSBvcmlnaW4gd291bGQgbGlrZSB0 aGUgdGFyZ2V0KHMpIHRvIHJlY2VpdmUgbmV3ZXIgZGF0YS4NCg0KDQpbUGFzY2FsMl0gVGhpcyBz aG91bGQgYmUgZGlzY3Vzc2VkIGluIHRoZSBkcmFmdC4gWW91IG5lZWQgdG8gc2V0IHRoZSBleHBl Y3RhdGlvbiBmb3IgdGhlIHVwcGVyIGxheWVyKHMpLiBJcyB0aGVyZSBhIHdheSB0byBkaWZmZXJl bnRpYXRlIGRpZmZlcmVudCBkYXRhIHNldHM/IEVnIGluc3RhbmNlIG9yIHNlcXVlbmNlIG5iPw0K TXkgc3VnZ2VzdGlvbiBzbyBmYXIgaXMgdGhhdCB0aGUgZGF0YSBzaG91bGQgaGF2ZSAzIGJpdHMg b2YgbmV4dCBoZWFkZXIgYW5kIDUgYml0cyBvZiBzZXF1ZW5jZS4NCg0KW011a3VsMl0gVGhpcyBz b3VuZHMgZ29vZCB0byBtZS4gSSB3aWxsIGluY29ycG9yYXRlIHRoaXMgaW4gdGhlIGRyYWZ0IHVu bGVzcyBJIGhlYXIgYSBiZXR0ZXIgcHJvcG9zYWwuIA0KDQpbUGFzY2FsM10gQ29vbC4gUGxlYXNl IG1ha2UgdGhhdCBhbm90aGVyIExDIGlzc3VlIGFuZCB0aGUgcHJvcG9zZWQgcmVzb2x1dGlvbiwg c2VlIGlmIHRoZXJlIGlzIGFueW9uZSBhZGRpbmcgYW55dGhpbmcgdG8gaXQuDQoNCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpbUGFzY2FsXQ0KIldoZW4gYW4NCmludGVy bWVkaWF0ZSByb3V0ZXIgYWRkcyBpdHNlbGYgdG8gYSByb3V0ZSwgaXQgTVVTVCBlbnN1cmUgdGhh dCB0aGUNCklQdjYgYWRkcmVzcyBhZGRlZCB0byB0aGUgcm91dGUgaXMgcmVhY2hhYmxlIGluIGJv dGggZm9yd2FyZCBhbmQgYmFja3dhcmQgZGlyZWN0aW9ucy4iDQpUaGlzIGlzIHdyaXR0ZW4gd2l0 aCB0aGUgdmlzaW9uIHRoYXQgdGhlIHJvdXRlciBoYXMgYSBzaW5nbGUgaW50ZXJmYWNlIGFuZCBh Y3RzIGFzIGEgcmVwZWF0ZXIuIA0KQnV0IHJlYWxseSBhIHJvdXRlciBjb3VsZCBoYXZlIDIgaW50 ZXJmYWNlcyBvbiBhIHNhbWUgc3VibmV0IGluIHdoaWNoIGNhc2UgdGhhdCBjbGF1c2UgZG9lcyBu b3QgZmx5Lg0KDQpbTXVrdWxdDQpBbGwgSSBtZWFuIGlzIHRoYXQgdGhlIGFjY3VtdWxhdGVkIHJv dXRlIE1VU1QgTk9UIGhhdmUgYW4gYWRkcmVzcyB0aGF0IGNhbm5vdCBiZSBhY2Nlc3NlZCBpbiBv bmUgb2YgdGhlIGRpcmVjdGlvbnMuIElmIHRoZSBhZGRyZXNzIGNhbm5vdCBiZSBhY2Nlc3NlZCBp biB0aGUgYmFja3dhcmQgZGlyZWN0aW9uLCB0aGVuIHRoZSBEUk8gd291bGQgbm90IGJlIGFibGUg dG8gdHJhdmVsIHRvIHRoZSBvcmlnaW4uDQoNCltQYXNjYWwyXSBUaGVuIHlvdSdyZSBwcmV2ZW50 aW5nIGEgcm91dGVyIHdpdGggMiBpbnRlcmZhY2VzLiBUaGF0J3Mgc2FkLiBJJ20gZmluZSBmb3Ig YW4gZXhwZXJpbWVudGFsIGRyYWZ0ICAgYnV0IGZvciBzdGFuZGFyZCB0cmFjayB0aGF0IHdpbGwg aGF2ZSB0byBiZSBjaGFuZ2VkLg0KDQpbTXVrdWwyXSBPSywgSSBhbSBrZWVwaW5nIGl0IHRoZSB3 YXkgaXQgaXMuDQoNCltQYXNjYWwzXSBUaGlzIGFsc28gbmVlZCB0byBiZSBsb2dnZWQgYXMgYSBs YXN0IGNhbGwgaXNzdWUgYW5kIGl0cyBwcm9wb3NlZCByZXNvbHV0aW9uLiBOb3RoaW5nIHdyb25n IHdpdGggaGF2aW5nIGxpbWl0YXRpb25zLCB5ZXQgSSB0aGluayB3ZSBtdXN0IGhhdmUgc3BlY2lm aWMgdGV4dCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBzcGVjIHNvIGZhciBpcyBsaW1pdGVkIHRvIGRl dmljZXMgd2l0aCBhIHNpbmdsZSBpbnRlcmZhY2UuIFdoZW4gd2UgbWFrZSB0aGUgU3RhbmRhcmQg VHJhY2sgdmVyc2lvbiwgSSBleHBlY3Qgd2UnbGwgaGF2ZSB0byBnbyBiZXlvbmQgdGhhdCBsaW1p dGF0aW9uLiBUaGUgZHJhd2JhY2sgaXMgZm9yIGV4cGVyaW1lbnRhbCAgaW1wbGVtZW50YXRpb25z IHRoYXQgbWF5IG5vdCBiZSBpbnRlcm9wZXJhYmxlIHdpdGggdGhlIGZpbmFsIHNvbHV0aW9uLg0K DQpDaGVlcnMsDQogDQpSZWdhcmRzLA0KTXVrdWwNCg== From prvs=43216d518=mukul@uwm.edu Sun Apr 1 20:46:55 2012 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 90FD511E80AA for ; Sun, 1 Apr 2012 20:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 RqDPJoy2Sxq9 for ; Sun, 1 Apr 2012 20:46:54 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 41EC711E8085 for ; Sun, 1 Apr 2012 20:46:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAGAgeU9/AAAB/2dsb2JhbABEhUe2TiMEQBIbGgINGQJZBiyHcKheh32JCYEviVyEeYEYBIhYjQmQL4MFgTYBFg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 5249B1FD0C8; Sun, 1 Apr 2012 22:46:53 -0500 (CDT) 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 98Lq8ljXVZVa; Sun, 1 Apr 2012 22:46:52 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id BE8181FD0C7; Sun, 1 Apr 2012 22:46:52 -0500 (CDT) Date: Sun, 1 Apr 2012 22:46:52 -0500 (CDT) From: Mukul Goyal To: C Chauvenet Message-ID: <466430945.1770002.1333338412632.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.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 and draft-ietf-roll-p2p-rpl-09 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, 02 Apr 2012 03:46:55 -0000 Hi Cedric Thanks for your detailed comments! ***************************************************************************= ******* [Cedric] On big question that rise my mind is, what happened if the route discovery = fail ?=20 Some protocols sends out an error message when the route discovery fails or= get stuck.=C2=A0=20 Do authors think that it could be relevant to add a "discovery-error" messa= ge as defined in other route discovery protocols ?=20 [Mukul] I dont think it is possible to detect the failure of a P2P-RPL route discov= ery. No node knows if a P2P-RPL route discovery has failed. P2P-RPL forms a temporary DAG and the route discovery (well, at least the f= irst half) succeeds when a target joins the DAG. Only the target knows whet= her it joined the DAG or not. So, no node knows if the (first half of the) = route discovery failed. Second half involves the target sending DRO to the origin. If the DRO does = not reach the origin, (the second half of) the route discovery fails. The t= arget can ensure (or at least increase the probability of) success by askin= g for DRO-ACK and retransmitting the DRO if the DRO-ACK is not received wit= hin certain time duration. DRO message travels by multicast, so an intermed= iate router, that forwards a DRO further, has no idea whether the next hop = on the route received the DRO or not. Again, no node knows if the (second h= alf of the) there is no one to generate the discovery-error message. I think an origin might infer the route discovery to have failed, if the DA= G's life time has expired but no DRO is received. But I am not sure we shou= ld mandate this to be the way failure is inferred. We have just 4 values fo= r the DAG life time. So, I think we should leave it to origin how much to w= ait for a DRO before admitting failure. ***************************************************************************= ************************ =20 [Cedric] Another point that has been discussed today during the ROLL meeting, is tha= t some people may find other mechanisms than trickle more efficient to floo= d the RDO.=20 Could we let the door opened to other flooding optimization mechanism, or e= xplicitly say that the trickle mechanism MUST be used ?=20 [Mukul] I think inherent dependence on the trickle mechanism is apparent because of= the fact that the route discovery takes place by forming a temporary DAG. = DAG creation (or DIO generation) depends on trickle algorithm. So, P2P-RPL = also depends on trickle algorithm. P2P-RPL being an extension of core RPL, = I dont think there is a way to separate P2P-RPL from trickle algorithm. ***************************************************************************= ********************************=20 [Cedric] In details :=C2=A0=20 p3 : P2P-RPL does not guarantee discovery of a route.=20 But how do we know if the RDO has been lost, of if the request has failed ?= =20 in other words, how do we know if the route doesn't exist, or if the reques= t has been lost ?=20 In addition, it may be relevant to cite an example where the discovery of a= route cannot be achieved.=20 [Mukul] You mention two possibilities: 1) route does not exist 2) DIO has been lost The second possibility is avoided (to a large extent) by periodic DIO trans= mission as per the trickle algorithm. This ofcourse depends on the life tim= e of the DAG, trickle parameters and how consistent/inconsistent events are= defined. As I discussed above, it is not possible to determine whether the route exi= sts or not. Even if the route exists, P2P-RPL may not be able to discover i= t. This could happen because constraints are too strict or DIOs moving in t= he direction of the target get lost. I will add some text that makes this c= lear. ***************************************************************************= **************** [Cedric] p5 : If there is no existing route between the origin and the target(s) or = the cost measurement for the existing routes fails, the origin will have to guess the constraints to be used in the initial route discovery.=20 Any recommendation to guess the metric in use ? Is it relevant to use hop c= ount by default (to limit the scope) ?=20 [Mukul] I dont think the draft could make any recommendation in this regard or sugg= est any particular metric to be used by default. The draft does allow the r= oute discovery to work without using any routing metric when OF0 is the OF = in use (in this case, the MaxRank field in P2P-RDO still provides a way to = specify the scope of route discovery). ***************************************************************************= *********************** [Cedric]=20 p6 :=C2=A0 P2P-RPL allows for the discovery of one hop-by-hop route or upto= four source routes per target.=20 upto --> up to.=20 Why 4 ? Any reason to limit the choice to 4 ?=20 [Mukul] Because we had just two bits for the purpose and 4 routes to a particular d= estination sounds sufficient. ***************************************************************************= *************************** [Cedric] p6 :=C2=A0 A P2P mode DIO always carries one P2P Route Discovery Option (de= fined in Section 7.1 ) in which the origin specifies the following information:=20 So you should put a MUST for this.=20 [Mukul] OK. ***************************************************************************= ******************************** [Cedric] p9 :=C2=A0 o DIOIntervalMin: 6, which translates to 64ms as the value for I= min parameter in Trickle operation.=20 Should we really fix numbers in this spec ? Could we turn the MUST of these= parameters into recommended values ?=20 Not sure this timing is applicable to all RPL networks.=20 [Mukul] This is the DIOIntervalMin value in the default DODAG Configuration Option,= which comes in effect only when DIO does not contain an explicit DODAG Con= figuration Option. An explicit DODAG Configuration Option can specify any v= alue for its parameters. The recommendations for trickle parameters are mad= e in Section 9.2 ***************************************************************************= *********************************** p12 :=C2=A0 This specification does not allow for the establishment of hop-= by-hop routes in the backward direction. [Cedric]=20 Why ? This would enable to establish 2 routes within a single route request= .=20 Furthermore, you stipulates in the draft that links have to be bidirectiona= l to propagates RDO, in order to be able to send back the DRO.=20 So if I understand it correctly you ensure that you have a reliable path in= both ways. Why using it in a single way only ?=20 [Mukul] Suppose a DRO establishing a forward hop-by-hop route fails to make it to t= he origin. In this case, all we have is some nodes storing the hop-by-hop s= tate for a broken route but that route is never used since the origin never= gets the DRO. On the other hand, if the DRO establishing a backward hop-by= -hop route fails to make it to the origin, we have a broken route that the = target is likely to use (to reach the origin). So, if we want P2P-RPL to es= tablish a backward hop-by-hop route, the target MUST ask for a DRO-ACK from= the origin (to make sure that the DRO does reach the origin and hence the = backward route is not broken). This can be done if you think it will be use= ful. We did not include this in P2P-RPL because we did not have a usecase f= or backward hop-by-hop routes and we wanted to avoid the additional complex= ity.=20 This is how we can implement this functionality: we will let the target dec= ide whether it wants the DRO to establish a backward hop-by-hop route. In t= hat case: 1) the target will set a new flag, the B flag (B for backward hop-by-hop ro= ute), inside the DRO to let intermediate routers know that backward route s= tate needs to be established as well; 2) the target will set the A flag to require a DRO-ACK from the origin; 3) the target will specify (inside a new field in the DRO), an RPLInstanceI= D under which the hop-by-hop state for the backward route will be stored. N= ote that the RPLInstanceID of the forward route (selected by the origin) ma= y not be OK for use in backward route (because the target may have already = used this RPLInstanceID for another hop-by-hop route, using different routi= ng-metrics/constraints/OF, to the origin). When the intermediate routers receive this DRO, they will store the hop-by-= hop state for the backward route. This hop-by-hop state will consist of:=20 1) Target address (taken from P2P-RDO inside the DRO). 2) RPLInstanceID specified by the target 3) The destination, i.e., the origin address (same as DODAGID inside the DR= O). Do you want this functionality? ***************************************************************************= ************** p13 :=C2=A0 The IPv6 addresses in the Address vector MUST be reachable in b= oth forward and backward directions.=20 [Cedric] Does it means that links have to be bidirectional on the path ? How do you = verify that ?=20 [Mukul] The DRO message travels from the target to the origin along a discovered ro= ute. So, yes, the links should have bidirectional reachability. It does not= mean that the link should have same value for the routing metrics in both = direction. Just simple reachability should allow the DRO to travel back to = the origin. ***************************************************************************= ************** p14 :=C2=A0 A DRO message travels from the target to the origin via link-lo= cal multicast along the route specified inside the Address vector in the P2P-RDO.=20 [Cedric] Why using multicast if you know every destinators ?=20 Could we unicast packets to each destinators in the address vector ?=20 [Mukul] DRO travels by link local multicast so that the nodes, that are on the temp= orary DAG but not necessarily on a discovered route, may know that the rout= e discovery is over (via the stop flag) and there is no need to generate an= y more DIOs. This may lead to a significant reduction in the (unnecessary) = DIOs generated. Only the routers on the discovered route do the multicast-b= ased forwarding though.=20 ***************************************************************************= ************* p15 :=C2=A0 Stop (S): This flag, when set to one by a target, indicates tha= t the P2P-RPL route discovery is over. [Cedric]=20 Is this bit really usefull ? My guess is that it will be always set to 1.= =20 If you hear a DRO, this indeed means that the RDO has reached the target, s= o you could just stop processing RDO when you hear a DRO.=20 Do we really need a flag to stop RDO processing or the hearing of a DRO typ= e message could do the job ?=20 [Mukul] A P2P-RPL invocation might involve discovery of multiple source routes. In = that case, receipt of a DRO does not mean route discovery is over. Only whe= n the target sets the stop flag in the DRO, a node could be sure that the r= oute discovery is over. ***************************************************************************= *********** p21 :=C2=A0 Example methods include selecting each route that meets the spe= cified routing constraints until the desired number have been selected or selecting the best routes discovered over a certain time period.=20 [Cedric] How could we know the time to wait until we get all the RDO ?=20 Is there a way to evaluate it according to some parameters related to the n= etwork (diameter of the network for instance) ?=20 [Mukul] This has to be a local decision. Perhaps, the target can look at th= e aggregated values of the routing metrics from the origin and determine it= s distance from the origin. This distance estimate, along with trickle para= meters, could perhaps give it a better idea of how much to wait. I dont thi= nk that the draft should talk about this. ***************************************************************************= ******** p25 :=C2=A0 o DRO_ACK_WAIT_TIME: The time duration a target waits for the D= RO- ACK before retransmitting a DRO message. DRO_ACK_WAIT_TIME has a value of 1 second.=20 [Cedric] I'm not sure it is compliant with all RPL deployments.=20 Could we adapt it to the characteristics of the network used ? [Mukul]=20 I am OK with making DRO_ACK_WAIT_TIME as well as MAX_DRO_RETRANSMISSIONS co= nfigurable parameters. ***************************************************************************= ******* [Cedric] p28 : References need to be updated according to recent RFCs.=20 [Mukul] Yes. ***************************************************************************= ******* Thanks Mukul From prvs=43216d518=mukul@uwm.edu Mon Apr 2 16:25:57 2012 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 C188821F8659 for ; Mon, 2 Apr 2012 16:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.05 X-Spam-Level: X-Spam-Status: No, score=-5.05 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 oIvHATpVD9Lo for ; Mon, 2 Apr 2012 16:25:56 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 532DE21F8656 for ; Mon, 2 Apr 2012 16:25:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAIQ0ek9/AAAB/2dsb2JhbABDhVS1TyNPBxsaAg0ZAlkGLAKHbq0piQaBIYEviVEKAYRLgRgEiFiNCZAvgwWBNgEW Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 0CE481FD0CF; Mon, 2 Apr 2012 18:20:55 -0500 (CDT) 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 QH1XB28egXoZ; Mon, 2 Apr 2012 18:20:54 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 7E5F91FD0B7; Mon, 2 Apr 2012 18:20:54 -0500 (CDT) Date: Mon, 2 Apr 2012 18:20:54 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1986142471.1786230.1333408854376.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.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Part 2 Re: G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 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, 02 Apr 2012 23:25:57 -0000 Hi Pascal ******************************************************************* [Pascal2] 2) Same question if you want to create states at the target to route back. How long does the target need to maintain the route? Who controls that, the origin or the target? I'd expect to find a suggested lifetime in the RDO with a confirmation in the DRO to let the target amend it. [Mukul2] If the target wants DRO-ACK it needs to maintain state until DRO-ACK is received. Otherwise, the target needs to remember things until it is done sending all the DROs. I will add the text to this effect. [Pascal3] If you are setting up a short term conversation, how long exactly is that before the origin has to refresh the route? What controls clean up in both sides? Usually you want a lifetime (see MIP6 for instance) [Mukul3] Is it that you are talking about the lifetime of the hop-by-hop routing state? That is specified in the life time parameters in the DODAG configuration option. The draft says that on page 9 while describing how the DODAG configuration option should be set inside a P2P mode DIO: "The Default Lifetime and Lifetime Unit parameters in DODAG Configuration option indicate the life time of the state the routers maintain for a hop-by-hop route established using P2P-RPL and may be set as desired. " ************************************************************************************* [Pascal] "RPLInstanceID: RPLInstanceID MUST be a local value as described in Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the same RPLInstanceID in two or more concurrent route discoveries." I'd suggest that you enforce a round robin or an opaque circulation so that the new instanceID is the least recently used one out of the 64 possible. [Mukul] I think we should leave it to the origin to decide which value it wants to use for RPLInstanceID. I know some implementations are planning to use a fixed RPLInstanceID value for all route discoveries. [Pascal2] Changing the instance ID will help debug the network and avoid conflicts with stale states. What's really up to the device is the initial sequence. Leaving it up to the origin may help the origin defeat some attacks to some degree. OTOH, after all the instances have been played, LRU forces to replay the same sequence again so the shield drops. My preferred approach would be a SHOULD that would say that the next instance ID SHOULD NOT be one of the (16?) most recently used and MUST NOT be one for which states might still exist in the network. IOW either the states deletion was acknowledged, or all pending lifetimes are exhausted. [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD NOT) against reusing instance ids for which the stale state might exist in the nodes. Using a "MUST NOT" may not be OK since a node may never be 100% sure about non-existence of stale state with a particular instance id (thus, all possible instance id values will become suspect and hence unusable after a while). [Pascal3] Agreed. Note that a circulation is a bonus to defeat replays. And now we're back to the issue above. How does the device know that there is no state left? A lifetime definition would be very useful. That lifetime is different from the DAG's one in RDO. I think we have an open issue here. [Mukul3] As I mentioned above, the life time parameters inside the DODAG configuration option specify the life time of the hop-by-hop routing state for the routes discovered using P2P-RPL. **************************************************************************************** [Pascal] " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in nature, is created solely for the purpose of P2P-RPL route discovery and MUST NOT be used for packet routing." On the contrary I'd set it to 1. The goal -being to reach the origin- is actually achieved by this DAG. [Mukul] Actually, the DAG is temporary in nature and vanishes after a short while. Even when it exists, it must/should not be used for routing packets back to the origin. So, I think the Grounded flag should be zero. [Pascal2] Please revisit RFC 6650 page 12. G means that a goal is achieved. So first you define the goal and then the bit becomes obvious. What's your goal? Can there be P2P DAGs that achieve the goal and others that make sense to build and yet do not achieve the goal? If you accept that your operation can actually depend on OF logic, then the setting of the goal influences that logic. By forcing a value to the goal in the PTP spec, we actually limit the applicability of the draft. Maybe you can define a default goal and a default setting. But do not MUST that it is set to 0... [Mukul2] When a node joins a temporary P2P DAG, it does not get any additional routing information. The DAG is going to disappear after some time, should not be used for routing while it exists and which nodes end up being on the discovered route is not known until the DRO message comes back. So, I think, by default, the G flag has to be zero. However, if the setting of G flag may affect how an intermediate node may calculate its rank (as per the OF being used), the origin should have the flexibility of setting the flag to 1. So, I could modify the text to say that "the origin sets the G flag based on its perception of how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created." [Pascal3] Why do you feel the need to add anything above what RFC 6550 says? I do not see any benefit or additional clarity from doing this. [Mukul3] RFC 6550 is actually kind of confusing in this regard. On page 9, it says "A typical Goal is to construct the DODAG according to a specific Objective Function and to keep connectivity to a set of hosts (e.g., to use an Objective Function that minimizes a metric and is connected to a specific database host to store the collected data)." This seems to associate the goal with both OF and reachability to certain hosts. Later invocations of the term "goal" seem to refer just to the connectivity aspect, e.g., on page 18 RFC 6550 says "A grounded DODAG offers connectivity to hosts that are required for satisfying the application-defined goal." So, my understanding so far was that the "goal" defines connectivity to a certain hosts. The relation to objective function is not clear at all (if one restricts oneself to reading RFC 6550). The temporary DAGs created in P2P-RPL route discovery provide no connectivity whatsoever to the joining nodes. So, the only reason to set the G flag to 1 would be to allow correct use of an OF. So, I think P2P-RPL spec should use the text I offered above (and repeat below): "The origin sets the G flag based on its perception of whether joining how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created." What do you think? **************************************************************************************** [Pascal]" MAY carry one or more RPL Target Options to specify additional unicast/multicast addresses for the target." Now here I would have a MUST carry at least one target. That is indeed what makes is a lookup DIO... [Mukul] As I stated in the previous message, we need to include the target in the P2P-RDO to save bytes for the common case (discover route to one unicast/multicast target). So, we cannot make using the target option a MUST. [Pascal2] Certainly. I prefer the split, in which case the MUST IMHO goes to the target as opposed to the RDO. In a case where the RDO is not needed, the target only message is actually shorter... [Mukul2] As I said before, I think a P2P mode DIO always needs to have one P2P-RDO. I guess, in this case, we agree to disagree! [Pascal3] Certainly. And there's nothing blocking with that disagreement, mostly if the draft targets experimental. I think it's OK to keep your response as the proposed resolution for the issue. Still I'd like advice from others so exposing the issue as LC will help. Let's see on which side the coin falls. [Mukul3] OK. I will be happy to hear additional opinions. ************************************************************************************************ [Pascal] Can the data option be different from one DIO to the next? [Mukul] The contents of the data option are specified by the origin (for the DIO) or the target (for the DRO). In theory, an origin can send different data options in different DIOs it generates for a particular route discovery (assuming that it does generate multiple DIOs; it is very much possible that the origin generates just one DIO and then sits silent). But, then the origin is taking the risk that some of the data options would never each the target(s). I guess the origin might do this if the data sent earlier is now stale and the origin would like the target(s) to receive newer data. [Pascal2] This should be discussed in the draft. You need to set the expectation for the upper layer(s). Is there a way to differentiate different data sets? Eg instance or sequence nb? My suggestion so far is that the data should have 3 bits of next header and 5 bits of sequence. [Mukul2] This sounds good to me. I will incorporate this in the draft unless I hear a better proposal. [Pascal3] Cool. Please make that another LC issue and the proposed resolution, see if there is anyone adding anything to it. [Mukul3] Actually, I would like the next header to be 4 bits and the sequence number to be 4 bits. 4-bit sequence number will still allow up to 16 different messages to be sent during a P2P-RPL discovery. 4 bit next header will allow 16 different possibilities. We can have so many different ways to compress UDP/TCP headers. I think 3 bit next header may not be sufficient. *********************************************************************************************** [Pascal] "When an intermediate router adds itself to a route, it MUST ensure that the IPv6 address added to the route is reachable in both forward and backward directions." This is written with the vision that the router has a single interface and acts as a repeater. But really a router could have 2 interfaces on a same subnet in which case that clause does not fly. [Mukul] All I mean is that the accumulated route MUST NOT have an address that cannot be accessed in one of the directions. If the address cannot be accessed in the backward direction, then the DRO would not be able to travel to the origin. [Pascal2] Then you're preventing a router with 2 interfaces. That's sad. I'm fine for an experimental draft but for standard track that will have to be changed. [Mukul2] OK, I am keeping it the way it is. [Pascal3] This also need to be logged as a last call issue and its proposed resolution. Nothing wrong with having limitations, yet I think we must have specific text to indicate that the spec so far is limited to devices with a single interface. When we make the Standard Track version, I expect we'll have to go beyond that limitation. The drawback is for experimental implementations that may not be interoperable with the final solution. [Mukul3] Could you please explain how does the requirement regarding addresses to be accessible in both forward and backward directions limits P2P-RPL to only single interface devices? I think this requirement means that P2P-RPL cannot be used across link layers. Is that what you mean? I think allowing operation across link layers would require P2P-RDO to accumulate additional information (backward address to be used for forward addresses not accessible in backward direction). I think at the moment we want to avoid this complexity. ******************************************************************************* Thanks Mukul From pthubert@cisco.com Mon Apr 2 23:35:00 2012 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 093E211E8075 for ; Mon, 2 Apr 2012 23:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.014 X-Spam-Level: X-Spam-Status: No, score=-8.014 tagged_above=-999 required=5 tests=[AWL=1.345, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 8rWzJlQbbica for ; Mon, 2 Apr 2012 23:34:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2412F11E8076 for ; Mon, 2 Apr 2012 23:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=18586; q=dns/txt; s=iport; t=1333434896; x=1334644496; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jR6oqJ2BqESVHsSJk5rhMpKaXcNZbzC6KqD8d9U6sFs=; b=WGiWsRJezd4D7yHogvkP5AaNjLh/9zkF0H6b+lQIF9yjf3KVQ8zd3kmn fDG9Q2Y6u7b9qX/WOSZeVCpz6rZ3ICLzoYBFP1qsn104E2NwxdSaAKVqX eWvzPGaZ96mSuAXalGa0XBbypcZ2N9SVCbLDLyS1/twjoqe7DVlFFLU+e 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAE+Zek+Q/khM/2dsb2JhbABCDoVKsS+BAoEHggoBAQQSARANBD4HEAIBCBoCBgYYAgICAQFVAQEEGxECB4dnoC2NCIocgS+JUQoBhEs1YwSkKIFogjA5gVIBFg X-IronPort-AV: E=Sophos;i="4.75,361,1330905600"; d="scan'208";a="134099334" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2012 06:34:53 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q336YqUO020687; Tue, 3 Apr 2012 06:34:52 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); Tue, 3 Apr 2012 08:34:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 3 Apr 2012 08:33:22 +0200 Message-ID: In-Reply-To: <1986142471.1786230.1333408854376.JavaMail.root@mail17.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Part 2 Re: [Roll] G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 Thread-Index: Ac0RJ/VB8VPSHMGNT0SWi1gULWs49wAODgsA References: <1986142471.1786230.1333408854376.JavaMail.root@mail17.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 03 Apr 2012 06:34:53.0175 (UTC) FILETIME=[E0A1D870:01CD1163] Cc: ROLL WG Subject: Re: [Roll] Part 2 Re: G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 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, 03 Apr 2012 06:35:00 -0000 SEkgYWdhaW4gTXVrdWwsDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KW1Bhc2NhbDJdIA0KMikgU2FtZSBxdWVz dGlvbiBpZiB5b3Ugd2FudCB0byBjcmVhdGUgc3RhdGVzIGF0IHRoZSB0YXJnZXQgdG8gcm91dGUg YmFjay4gSG93IGxvbmcgZG9lcyB0aGUgdGFyZ2V0IG5lZWQgdG8gbWFpbnRhaW4gdGhlIHJvdXRl PyBXaG8gY29udHJvbHMgdGhhdCwgdGhlIG9yaWdpbiBvciB0aGUgdGFyZ2V0PyBJJ2QgZXhwZWN0 IHRvIGZpbmQgYSBzdWdnZXN0ZWQgbGlmZXRpbWUgaW4gdGhlIFJETyB3aXRoIGEgY29uZmlybWF0 aW9uIGluIHRoZSBEUk8gdG8gbGV0IHRoZSB0YXJnZXQgYW1lbmQgaXQuDQoNCltNdWt1bDJdDQpJ ZiB0aGUgdGFyZ2V0IHdhbnRzIERSTy1BQ0sgaXQgbmVlZHMgdG8gbWFpbnRhaW4gc3RhdGUgdW50 aWwgRFJPLUFDSyBpcyByZWNlaXZlZC4gT3RoZXJ3aXNlLCB0aGUgdGFyZ2V0IG5lZWRzIHRvIHJl bWVtYmVyIHRoaW5ncyB1bnRpbCBpdCBpcyBkb25lIHNlbmRpbmcgYWxsIHRoZSBEUk9zLiBJIHdp bGwgYWRkIHRoZSB0ZXh0IHRvIHRoaXMgZWZmZWN0Lg0KDQpbUGFzY2FsM10gDQpJZiB5b3UgYXJl IHNldHRpbmcgdXAgYSBzaG9ydCB0ZXJtIGNvbnZlcnNhdGlvbiwgaG93IGxvbmcgZXhhY3RseSBp cyB0aGF0IGJlZm9yZSB0aGUgb3JpZ2luIGhhcyB0byByZWZyZXNoIHRoZSByb3V0ZT8gV2hhdCBj b250cm9scyBjbGVhbiB1cCBpbiBib3RoIHNpZGVzPyBVc3VhbGx5IHlvdSB3YW50IGEgbGlmZXRp bWUgKHNlZSBNSVA2IGZvciBpbnN0YW5jZSkNCg0KW011a3VsM10NCklzIGl0IHRoYXQgeW91IGFy ZSB0YWxraW5nIGFib3V0IHRoZSBsaWZldGltZSBvZiB0aGUgaG9wLWJ5LWhvcCByb3V0aW5nIHN0 YXRlPyBUaGF0IGlzIHNwZWNpZmllZCBpbiB0aGUgbGlmZSB0aW1lIHBhcmFtZXRlcnMgaW4gdGhl IERPREFHIGNvbmZpZ3VyYXRpb24gb3B0aW9uLiBUaGUgZHJhZnQgc2F5cyB0aGF0IG9uIHBhZ2Ug OSB3aGlsZSBkZXNjcmliaW5nIGhvdyB0aGUgRE9EQUcgY29uZmlndXJhdGlvbiBvcHRpb24gc2hv dWxkIGJlIHNldCBpbnNpZGUgYSBQMlAgbW9kZSBESU86DQoNCiJUaGUgRGVmYXVsdCBMaWZldGlt ZSBhbmQgTGlmZXRpbWUgVW5pdCBwYXJhbWV0ZXJzIGluIERPREFHDQogICAgICBDb25maWd1cmF0 aW9uIG9wdGlvbiBpbmRpY2F0ZSB0aGUgbGlmZSB0aW1lIG9mIHRoZSBzdGF0ZSB0aGUNCiAgICAg IHJvdXRlcnMgbWFpbnRhaW4gZm9yIGEgaG9wLWJ5LWhvcCByb3V0ZSBlc3RhYmxpc2hlZCB1c2lu ZyBQMlAtUlBMDQogICAgICBhbmQgbWF5IGJlIHNldCBhcyBkZXNpcmVkLg0KIg0KDQpbUGFzY2Fs NF0gTWF5YmUgdGhhdCdzIHNvIGJ1dCB0aGVuIHlvdSBuZWVkIHRvIHJld29yZCBhIGxpdHRsZSBi aXQgY2F1c2UgeW91IGdvdCBtZSBxaXV0ZSBjb25mdXNlZC4gSSd2ZSBiZWVuIHRhbGtpbmcgb2Yg dGhlIGxpZmV0aW1lIG9mIHRoZSBzdGF0ZXMgYXQgb3JpZ2luIGFuZCB0YXJnZXQgZm9yIG9uZSBj b252ZXJzYXRpb24uIFNpbmNlIHRoZXkgbWlnaHQgYmUgaGF2aW5nIGEgdHJhbnNpZW50IGNvbnZl cnNhdGlvbiwgYW5kIHRoZSBvcmlnaW4gbWlnaHQgcmV1c2UgdGhlIGluc3RhbmNlIElEIHNvb24s IHlvdSBuZWVkIHRvIGdpdmUgYSBsaW1pdCBpbiB0aW1lIHRvIHRoZSBzdGF0ZXMgdGhhdCB5b3Ug YXJlIGNyZWF0aW5nLiBTdGlsbCB0aGF0IGNvbnZlcnNhdGlvbiBpcyBsb25nZXIgdGhhbiB0aGUg c3RhdGVzIGluIHRoZSBpbnRlcm1lZGlhdGUgcm91dGVycy4gU28geW91IGhhdmUgMiBsaWZldGlt ZXMgYW5kIHlvdSBoYXZlIHRvIGJlIHZlcnkgY2xlYXIgd2hpY2ggaXMgd2hpY2guIFBlcnNvbmFs bHksIEknZCBoYXZlIHVzZWQgdGhlIGxpZmV0aW1lIGluIHRoZSBjb25maWd1cmF0aW9uIG9wdGlv biBmb3IgYWxsIHRoZSByb3V0ZXJzIG9uIHRoZSB3YXkgYW5kIEknZCBoYXZlIHVzZWQgdGhlIG5l dyBsaWZldGltZSBpbiB0aGUgUkRPIGFzIHRoZSBjb252ZXJzYXRpb24gbGlmZXRpbWUgaW4gdGhl IGVuZCBwb2ludHMgYmVjYXVzZToNCjEpICB0aGF0IGlzIHRoZSBuZXcgY29uY2VwdC4gDQoyKSBU aGlzIHdvdWxkIGFsbG93IHRoZSB0YXJnZXQgdG8gY29uZmlybSBleGFjdGx5IGhvdyBsb25nIGl0 IGxvY2tzIHJlc291cmNlcywNCjMpIGFuZCB0aGlzIHdvdWxkIGJlIG1vcmUgY29tcGF0aWJsZSB3 aXRoIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgY29uZmlnIG9wdGlvbiBpbiBSRkMgNjU1MC4NCg0K DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCltQYXNjYWxdDQoiUlBMSW5zdGFuY2VJ RDogUlBMSW5zdGFuY2VJRCBNVVNUIGJlIGEgbG9jYWwgdmFsdWUgYXMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gNS4xIG9mIFtJLUQuaWV0Zi1yb2xsLXJwbF0uIFRoZSBvcmlnaW4gTVVTVCBOT1QgdXNl IHRoZSBzYW1lIFJQTEluc3RhbmNlSUQgaW4gdHdvIG9yIG1vcmUgY29uY3VycmVudCByb3V0ZSBk aXNjb3Zlcmllcy4iDQoNCkknZCBzdWdnZXN0IHRoYXQgeW91IGVuZm9yY2UgYSByb3VuZCByb2Jp biBvciBhbiBvcGFxdWUgY2lyY3VsYXRpb24gc28gdGhhdCB0aGUgbmV3IGluc3RhbmNlSUQgaXMg dGhlIGxlYXN0IHJlY2VudGx5IHVzZWQgb25lIG91dCBvZiB0aGUgNjQgcG9zc2libGUuDQoNCltN dWt1bF0NCkkgdGhpbmsgd2Ugc2hvdWxkIGxlYXZlIGl0IHRvIHRoZSBvcmlnaW4gdG8gZGVjaWRl IHdoaWNoIHZhbHVlIGl0IHdhbnRzIHRvIHVzZSBmb3IgUlBMSW5zdGFuY2VJRC4gSSBrbm93IHNv bWUgaW1wbGVtZW50YXRpb25zIGFyZSBwbGFubmluZyB0byB1c2UgYSBmaXhlZCBSUExJbnN0YW5j ZUlEIHZhbHVlIGZvciBhbGwgcm91dGUgZGlzY292ZXJpZXMuDQoNCltQYXNjYWwyXSBDaGFuZ2lu ZyB0aGUgaW5zdGFuY2UgSUQgd2lsbCBoZWxwIGRlYnVnIHRoZSBuZXR3b3JrIGFuZCBhdm9pZCBj b25mbGljdHMgd2l0aCBzdGFsZSBzdGF0ZXMuIFdoYXQncyByZWFsbHkgdXAgdG8gdGhlIGRldmlj ZSBpcyB0aGUgaW5pdGlhbCBzZXF1ZW5jZS4gTGVhdmluZyBpdCB1cCB0byB0aGUgb3JpZ2luIG1h eSBoZWxwIHRoZSBvcmlnaW4gZGVmZWF0IHNvbWUgYXR0YWNrcyB0byBzb21lIGRlZ3JlZS4gT1RP SCwgYWZ0ZXIgYWxsIHRoZSBpbnN0YW5jZXMgaGF2ZSBiZWVuIHBsYXllZCwgTFJVIGZvcmNlcyB0 byByZXBsYXkgdGhlIHNhbWUgc2VxdWVuY2UgYWdhaW4gc28gdGhlIHNoaWVsZCBkcm9wcy4gTXkg cHJlZmVycmVkIGFwcHJvYWNoIHdvdWxkIGJlIGEgU0hPVUxEIHRoYXQgd291bGQgc2F5IHRoYXQg dGhlIG5leHQgaW5zdGFuY2UgSUQgU0hPVUxEIE5PVCBiZSBvbmUgb2YgdGhlICgxNj8pIG1vc3Qg cmVjZW50bHkgdXNlZCBhbmQgTVVTVCBOT1QgYmUgb25lIGZvciB3aGljaCBzdGF0ZXMgbWlnaHQg c3RpbGwgZXhpc3QgaW4gdGhlIG5ldHdvcmsuIElPVyBlaXRoZXIgdGhlIHN0YXRlcyBkZWxldGlv biB3YXMgYWNrbm93bGVkZ2VkLCBvciBhbGwgcGVuZGluZyBsaWZldGltZXMgYXJlIGV4aGF1c3Rl ZC4NCg0KW011a3VsMl0gTWFrZXMgc2Vuc2UuIEkgdGhpbmsgaXQgaXMgc3VmZmljaWVudCB0byBj YXV0aW9uICh3aXRoIGEgU0hPVUxEIE5PVCkgYWdhaW5zdCByZXVzaW5nIGluc3RhbmNlIGlkcyBm b3Igd2hpY2ggdGhlIHN0YWxlIHN0YXRlIG1pZ2h0IGV4aXN0IGluIHRoZSBub2Rlcy4gVXNpbmcg YSAiTVVTVCBOT1QiIG1heSBub3QgYmUgT0sgc2luY2UgYSBub2RlIG1heSBuZXZlciBiZSAxMDAl IHN1cmUgYWJvdXQgbm9uLWV4aXN0ZW5jZSBvZiBzdGFsZSBzdGF0ZSB3aXRoIGEgcGFydGljdWxh ciBpbnN0YW5jZSBpZCAodGh1cywgYWxsIHBvc3NpYmxlIGluc3RhbmNlIGlkIHZhbHVlcyB3aWxs IGJlY29tZSBzdXNwZWN0IGFuZCBoZW5jZSB1bnVzYWJsZSBhZnRlciBhIHdoaWxlKS4NCg0KW1Bh c2NhbDNdIEFncmVlZC4gTm90ZSB0aGF0IGEgY2lyY3VsYXRpb24gaXMgYSBib251cyB0byBkZWZl YXQgcmVwbGF5cy4gQW5kIG5vdyB3ZSdyZSBiYWNrIHRvIHRoZSBpc3N1ZSBhYm92ZS4gSG93IGRv ZXMgdGhlIGRldmljZSBrbm93IHRoYXQgdGhlcmUgaXMgbm8gc3RhdGUgbGVmdD8gQSBsaWZldGlt ZSBkZWZpbml0aW9uIHdvdWxkIGJlIHZlcnkgdXNlZnVsLiBUaGF0IGxpZmV0aW1lIGlzIGRpZmZl cmVudCBmcm9tIHRoZSBEQUcncyBvbmUgaW4gUkRPLiBJIHRoaW5rIHdlIGhhdmUgYW4gb3BlbiBp c3N1ZSBoZXJlLg0KDQpbTXVrdWwzXSBBcyBJIG1lbnRpb25lZCBhYm92ZSwgdGhlIGxpZmUgdGlt ZSBwYXJhbWV0ZXJzIGluc2lkZSB0aGUgRE9EQUcgY29uZmlndXJhdGlvbiBvcHRpb24gc3BlY2lm eSB0aGUgbGlmZSB0aW1lIG9mIHRoZSBob3AtYnktaG9wIHJvdXRpbmcgc3RhdGUgZm9yIHRoZSBy b3V0ZXMgZGlzY292ZXJlZCB1c2luZyBQMlAtUlBMLiANCg0KW1Bhc2NhbDRdIFRoaXMgYm9pbHMg ZG93biB0byB0aGUgdGhyZWFkIGFib3ZlLiBPbmx5IG9uZSBpc3N1ZSByZWFsbHksIHdoaWNoIGxp ZmV0aW1lIGlzIHdoaWNoPyBTbyBJTUhPIG5vIG5lZWQgdG8gbG9nIGFueXRoaW5nIGZvciB0aGlz IHRocmVhZC4NCg0KIA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpbUGFzY2Fs XQ0KIiBHcm91bmRlZCAoRykgRmxhZzogTVVTVCBiZSBzZXQgdG8gemVybyBzaW5jZSB0aGlzIERB RyBpcyB0ZW1wb3JhcnkgaW4gbmF0dXJlLCBpcyBjcmVhdGVkIHNvbGVseSBmb3IgdGhlIHB1cnBv c2Ugb2YgUDJQLVJQTCByb3V0ZSBkaXNjb3ZlcnkgYW5kIE1VU1QgTk9UIGJlIHVzZWQgZm9yIHBh Y2tldCByb3V0aW5nLiINCg0KT24gdGhlIGNvbnRyYXJ5IEknZCBzZXQgaXQgdG8gMS4gVGhlIGdv YWwgLWJlaW5nIHRvIHJlYWNoIHRoZSBvcmlnaW4tIGlzIGFjdHVhbGx5IGFjaGlldmVkIGJ5IHRo aXMgREFHLg0KDQpbTXVrdWxdDQpBY3R1YWxseSwgdGhlIERBRyBpcyB0ZW1wb3JhcnkgaW4gbmF0 dXJlIGFuZCB2YW5pc2hlcyBhZnRlciBhIHNob3J0IHdoaWxlLiBFdmVuIHdoZW4gaXQgZXhpc3Rz LCBpdCBtdXN0L3Nob3VsZCBub3QgYmUgdXNlZCBmb3Igcm91dGluZyBwYWNrZXRzIGJhY2sgdG8g dGhlIG9yaWdpbi4gU28sIEkgdGhpbmsgdGhlIEdyb3VuZGVkIGZsYWcgc2hvdWxkIGJlIHplcm8u DQoNCltQYXNjYWwyXSBQbGVhc2UgcmV2aXNpdCBSRkMgNjY1MCBwYWdlIDEyLiANCkcgbWVhbnMg dGhhdCBhIGdvYWwgaXMgYWNoaWV2ZWQuIFNvIGZpcnN0IHlvdSBkZWZpbmUgdGhlIGdvYWwgYW5k IHRoZW4gdGhlIGJpdCBiZWNvbWVzIG9idmlvdXMuIFdoYXQncyB5b3VyIGdvYWw/IA0KQ2FuIHRo ZXJlIGJlIFAyUCBEQUdzIHRoYXQgYWNoaWV2ZSB0aGUgZ29hbCBhbmQgb3RoZXJzIHRoYXQgbWFr ZSBzZW5zZSB0byBidWlsZCBhbmQgeWV0IGRvIG5vdCBhY2hpZXZlIHRoZSBnb2FsPw0KSWYgeW91 IGFjY2VwdCB0aGF0IHlvdXIgb3BlcmF0aW9uIGNhbiBhY3R1YWxseSBkZXBlbmQgb24gT0YgbG9n aWMsIHRoZW4gdGhlIHNldHRpbmcgb2YgdGhlIGdvYWwgaW5mbHVlbmNlcyB0aGF0IGxvZ2ljLg0K QnkgZm9yY2luZyBhIHZhbHVlIHRvIHRoZSBnb2FsIGluIHRoZSBQVFAgc3BlYywgd2UgYWN0dWFs bHkgbGltaXQgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIGRyYWZ0LiANCk1heWJlIHlvdSBjYW4g ZGVmaW5lIGEgZGVmYXVsdCBnb2FsIGFuZCBhIGRlZmF1bHQgc2V0dGluZy4gQnV0IGRvIG5vdCBN VVNUIHRoYXQgaXQgaXMgc2V0IHRvIDAuLi4NCg0KW011a3VsMl0NCldoZW4gYSBub2RlIGpvaW5z IGEgdGVtcG9yYXJ5IFAyUCBEQUcsIGl0IGRvZXMgbm90IGdldCBhbnkgYWRkaXRpb25hbCByb3V0 aW5nIGluZm9ybWF0aW9uLiBUaGUgREFHIGlzIGdvaW5nIHRvIGRpc2FwcGVhciBhZnRlciBzb21l IHRpbWUsIHNob3VsZCBub3QgYmUgdXNlZCBmb3Igcm91dGluZyB3aGlsZSBpdCBleGlzdHMgYW5k IHdoaWNoIG5vZGVzIGVuZCB1cCBiZWluZyBvbiB0aGUgZGlzY292ZXJlZCByb3V0ZSBpcyBub3Qg a25vd24gdW50aWwgdGhlIERSTyBtZXNzYWdlIGNvbWVzIGJhY2suIFNvLCBJIHRoaW5rLCBieSBk ZWZhdWx0LCB0aGUgRyBmbGFnIGhhcyB0byBiZSB6ZXJvLiBIb3dldmVyLCBpZiB0aGUgc2V0dGlu ZyBvZiBHIGZsYWcgbWF5IGFmZmVjdCBob3cgYW4gaW50ZXJtZWRpYXRlIG5vZGUgbWF5IGNhbGN1 bGF0ZSBpdHMgcmFuayAoYXMgcGVyIHRoZSBPRiBiZWluZyB1c2VkKSwgdGhlIG9yaWdpbiBzaG91 bGQgaGF2ZSB0aGUgZmxleGliaWxpdHkgb2Ygc2V0dGluZyB0aGUgZmxhZyB0byAxLiBTbywgSSBj b3VsZCBtb2RpZnkgdGhlIHRleHQgdG8gc2F5IHRoYXQgInRoZSBvcmlnaW4gc2V0cyB0aGUgRyBm bGFnIGJhc2VkIG9uIGl0cyBwZXJjZXB0aW9uIG9mIGhvdyB0aGUgZmxhZydzIHZhbHVlIHdvdWxk IGFmZmVjdCB0aGUgcmFuayBjYWxjdWxhdGlvbiB1bmRlciB0aGUgT0YgYmVpbmcgdXNlZC4gQnkg ZGVmYXVsdCwgdGhlIEcgZmxhZyBpcyBzZXQgdG8gemVybyBnaXZlbiB0aGUgdGVtcG9yYXJ5IG5h dHVyZSBvZiB0aGUgREFHIGJlaW5nIGNyZWF0ZWQuIg0KDQpbUGFzY2FsM10gV2h5IGRvIHlvdSBm ZWVsIHRoZSBuZWVkIHRvIGFkZCBhbnl0aGluZyBhYm92ZSB3aGF0IFJGQyA2NTUwIHNheXM/IEkg ZG8gbm90IHNlZSBhbnkgYmVuZWZpdCBvciBhZGRpdGlvbmFsIGNsYXJpdHkgZnJvbSBkb2luZyB0 aGlzLg0KDQpbTXVrdWwzXSBSRkMgNjU1MCBpcyBhY3R1YWxseSBraW5kIG9mIGNvbmZ1c2luZyBp biB0aGlzIHJlZ2FyZC4gT24gcGFnZSA5LCBpdCBzYXlzDQoNCiJBIHR5cGljYWwgR29hbCBpcyB0 byBjb25zdHJ1Y3QgdGhlIERPREFHDQogICAgICAgICBhY2NvcmRpbmcgdG8gYSBzcGVjaWZpYyBP YmplY3RpdmUgRnVuY3Rpb24gYW5kIHRvIGtlZXANCiAgICAgICAgIGNvbm5lY3Rpdml0eSB0byBh IHNldCBvZiBob3N0cyAoZS5nLiwgdG8gdXNlIGFuIE9iamVjdGl2ZQ0KICAgICAgICAgRnVuY3Rp b24gdGhhdCBtaW5pbWl6ZXMgYSBtZXRyaWMgYW5kIGlzIGNvbm5lY3RlZCB0byBhIHNwZWNpZmlj DQogICAgICAgICBkYXRhYmFzZSBob3N0IHRvIHN0b3JlIHRoZSBjb2xsZWN0ZWQgZGF0YSkuIg0K DQpUaGlzIHNlZW1zIHRvIGFzc29jaWF0ZSB0aGUgZ29hbCB3aXRoIGJvdGggT0YgYW5kIHJlYWNo YWJpbGl0eSB0byBjZXJ0YWluIGhvc3RzLiBMYXRlciBpbnZvY2F0aW9ucyBvZiB0aGUgdGVybSAi Z29hbCIgc2VlbSB0byByZWZlciBqdXN0IHRvIHRoZSBjb25uZWN0aXZpdHkgYXNwZWN0LCBlLmcu LCBvbiBwYWdlIDE4IFJGQyA2NTUwIHNheXMNCg0KIkEgZ3JvdW5kZWQgRE9EQUcgb2ZmZXJzIGNv bm5lY3Rpdml0eSB0byBob3N0cyB0aGF0IGFyZQ0KICAgcmVxdWlyZWQgZm9yIHNhdGlzZnlpbmcg dGhlIGFwcGxpY2F0aW9uLWRlZmluZWQgZ29hbC4iDQoNClNvLCBteSB1bmRlcnN0YW5kaW5nIHNv IGZhciB3YXMgdGhhdCB0aGUgImdvYWwiIGRlZmluZXMgY29ubmVjdGl2aXR5IHRvIGEgY2VydGFp biBob3N0cy4gVGhlIHJlbGF0aW9uIHRvIG9iamVjdGl2ZSBmdW5jdGlvbiBpcyBub3QgY2xlYXIg YXQgYWxsIChpZiBvbmUgcmVzdHJpY3RzIG9uZXNlbGYgdG8gcmVhZGluZyBSRkMgNjU1MCkuIFRo ZSB0ZW1wb3JhcnkgREFHcyBjcmVhdGVkIGluIFAyUC1SUEwgcm91dGUgZGlzY292ZXJ5IHByb3Zp ZGUgbm8gY29ubmVjdGl2aXR5IHdoYXRzb2V2ZXIgdG8gdGhlIGpvaW5pbmcgbm9kZXMuIFNvLCB0 aGUgb25seSByZWFzb24gdG8gc2V0IHRoZSBHIGZsYWcgdG8gMSB3b3VsZCBiZSB0byBhbGxvdyBj b3JyZWN0IHVzZSBvZiBhbiBPRi4gU28sIEkgdGhpbmsgUDJQLVJQTCBzcGVjIHNob3VsZCB1c2Ug dGhlIHRleHQgSSBvZmZlcmVkIGFib3ZlIChhbmQgcmVwZWF0IGJlbG93KToNCg0KIlRoZSBvcmln aW4gc2V0cyB0aGUgRyBmbGFnIGJhc2VkIG9uIGl0cyBwZXJjZXB0aW9uIG9mIHdoZXRoZXIgam9p bmluZyBob3cgdGhlIGZsYWcncyB2YWx1ZSB3b3VsZCBhZmZlY3QgdGhlIHJhbmsgY2FsY3VsYXRp b24gdW5kZXIgdGhlIE9GIGJlaW5nIHVzZWQuIEJ5IGRlZmF1bHQsIHRoZSBHIGZsYWcgaXMgc2V0 IHRvIHplcm8gZ2l2ZW4gdGhlIHRlbXBvcmFyeSBuYXR1cmUgb2YgdGhlIERBRyBiZWluZyBjcmVh dGVkLiINCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCltQYXNjYWw0XSBJZiB5b3UgdGhpbmsgdGhp cyBhZGRzIHZhbHVlLCBJIHdpbGwgbm90IG9wcG9zZS4gTGV0J3Mga2VlcCB0aGF0IGFzIHRoZSBw cm9wb3NlZCByZXNvbHV0aW9uDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K W1Bhc2NhbF0iIE1BWSBjYXJyeSBvbmUgb3IgbW9yZSBSUEwgVGFyZ2V0IE9wdGlvbnMgdG8gc3Bl Y2lmeSBhZGRpdGlvbmFsIHVuaWNhc3QvbXVsdGljYXN0IGFkZHJlc3NlcyBmb3IgdGhlIHRhcmdl dC4iDQpOb3cgaGVyZSBJIHdvdWxkIGhhdmUgYSBNVVNUIGNhcnJ5IGF0IGxlYXN0IG9uZSB0YXJn ZXQuIFRoYXQgaXMgaW5kZWVkIHdoYXQgbWFrZXMgaXMgYSBsb29rdXAgRElPLi4uDQoNCltNdWt1 bF0NCkFzIEkgc3RhdGVkIGluIHRoZSBwcmV2aW91cyBtZXNzYWdlLCB3ZSBuZWVkIHRvIGluY2x1 ZGUgdGhlIHRhcmdldCBpbiB0aGUgUDJQLVJETyB0byBzYXZlIGJ5dGVzIGZvciB0aGUgY29tbW9u IGNhc2UgKGRpc2NvdmVyIHJvdXRlIHRvIG9uZSB1bmljYXN0L211bHRpY2FzdCB0YXJnZXQpLiBT bywgd2UgY2Fubm90IG1ha2UgdXNpbmcgdGhlIHRhcmdldCBvcHRpb24gYSBNVVNULg0KDQpbUGFz Y2FsMl0gQ2VydGFpbmx5LiBJIHByZWZlciB0aGUgc3BsaXQsIGluIHdoaWNoIGNhc2UgdGhlIE1V U1QgSU1ITyBnb2VzIHRvIHRoZSB0YXJnZXQgYXMgb3Bwb3NlZCB0byB0aGUgUkRPLiBJbiBhIGNh c2Ugd2hlcmUgdGhlIFJETyBpcyBub3QgbmVlZGVkLCB0aGUgdGFyZ2V0IG9ubHkgbWVzc2FnZSBp cyBhY3R1YWxseSBzaG9ydGVyLi4uDQoNCltNdWt1bDJdIEFzIEkgc2FpZCBiZWZvcmUsIEkgdGhp bmsgYSBQMlAgbW9kZSBESU8gYWx3YXlzIG5lZWRzIHRvIGhhdmUgb25lIFAyUC1SRE8uIEkgZ3Vl c3MsIGluIHRoaXMgY2FzZSwgd2UgYWdyZWUgdG8gZGlzYWdyZWUhDQoNCltQYXNjYWwzXSBDZXJ0 YWlubHkuIEFuZCB0aGVyZSdzIG5vdGhpbmcgYmxvY2tpbmcgd2l0aCB0aGF0IGRpc2FncmVlbWVu dCwgbW9zdGx5IGlmIHRoZSBkcmFmdCB0YXJnZXRzIGV4cGVyaW1lbnRhbC4gDQogSSB0aGluayBp dCdzIE9LIHRvIGtlZXAgeW91ciByZXNwb25zZSBhcyB0aGUgcHJvcG9zZWQgcmVzb2x1dGlvbiBm b3IgdGhlIGlzc3VlLiBTdGlsbCBJJ2QgbGlrZSBhZHZpY2UgZnJvbSBvdGhlcnMgc28gZXhwb3Np bmcgdGhlIGlzc3VlIGFzIExDIHdpbGwgaGVscC4gTGV0J3Mgc2VlIG9uIHdoaWNoIHNpZGUgdGhl IGNvaW4gZmFsbHMuDQoNCltNdWt1bDNdIE9LLiBJIHdpbGwgYmUgaGFwcHkgdG8gaGVhciBhZGRp dGlvbmFsIG9waW5pb25zLg0KDQpbUGFzY2FsNF0gRmluZSwgbGV0J3Mga2VlcCB0aGF0IGFzIHRo ZSBwcm9wb3NlZCByZXNvbHV0aW9uDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KW1Bhc2NhbF0NCkNhbiB0aGUgZGF0YSBvcHRpb24gYmUgZGlmZmVyZW50IGZyb20g b25lIERJTyB0byB0aGUgbmV4dD8gDQoNCltNdWt1bF0NClRoZSBjb250ZW50cyBvZiB0aGUgZGF0 YSBvcHRpb24gYXJlIHNwZWNpZmllZCBieSB0aGUgb3JpZ2luIChmb3IgdGhlIERJTykgb3IgdGhl IHRhcmdldCAoZm9yIHRoZSBEUk8pLiBJbiB0aGVvcnksIGFuIG9yaWdpbiBjYW4gc2VuZCBkaWZm ZXJlbnQgZGF0YSBvcHRpb25zIGluIGRpZmZlcmVudCBESU9zIGl0IGdlbmVyYXRlcyBmb3IgYSBw YXJ0aWN1bGFyIHJvdXRlIGRpc2NvdmVyeSAoYXNzdW1pbmcgdGhhdCBpdCBkb2VzIGdlbmVyYXRl IG11bHRpcGxlIERJT3M7IGl0IGlzIHZlcnkgbXVjaCBwb3NzaWJsZSB0aGF0IHRoZSBvcmlnaW4g Z2VuZXJhdGVzIGp1c3Qgb25lIERJTyBhbmQgdGhlbiBzaXRzIHNpbGVudCkuIEJ1dCwgdGhlbiB0 aGUgb3JpZ2luIGlzIHRha2luZyB0aGUgcmlzayB0aGF0IHNvbWUgb2YgdGhlIGRhdGEgb3B0aW9u cyB3b3VsZCBuZXZlciBlYWNoIHRoZSB0YXJnZXQocykuIEkgZ3Vlc3MgdGhlIG9yaWdpbiBtaWdo dCBkbyB0aGlzIGlmIHRoZSBkYXRhIHNlbnQgZWFybGllciBpcyBub3cgc3RhbGUgYW5kIHRoZSBv cmlnaW4gd291bGQgbGlrZSB0aGUgdGFyZ2V0KHMpIHRvIHJlY2VpdmUgbmV3ZXIgZGF0YS4NCg0K DQpbUGFzY2FsMl0gVGhpcyBzaG91bGQgYmUgZGlzY3Vzc2VkIGluIHRoZSBkcmFmdC4gWW91IG5l ZWQgdG8gc2V0IHRoZSBleHBlY3RhdGlvbiBmb3IgdGhlIHVwcGVyIGxheWVyKHMpLiBJcyB0aGVy ZSBhIHdheSB0byBkaWZmZXJlbnRpYXRlIGRpZmZlcmVudCBkYXRhIHNldHM/IEVnIGluc3RhbmNl IG9yIHNlcXVlbmNlIG5iPw0KTXkgc3VnZ2VzdGlvbiBzbyBmYXIgaXMgdGhhdCB0aGUgZGF0YSBz aG91bGQgaGF2ZSAzIGJpdHMgb2YgbmV4dCBoZWFkZXIgYW5kIDUgYml0cyBvZiBzZXF1ZW5jZS4N Cg0KW011a3VsMl0gVGhpcyBzb3VuZHMgZ29vZCB0byBtZS4gSSB3aWxsIGluY29ycG9yYXRlIHRo aXMgaW4gdGhlIGRyYWZ0IHVubGVzcyBJIGhlYXIgYSBiZXR0ZXIgcHJvcG9zYWwuIA0KDQpbUGFz Y2FsM10gQ29vbC4gUGxlYXNlIG1ha2UgdGhhdCBhbm90aGVyIExDIGlzc3VlIGFuZCB0aGUgcHJv cG9zZWQgcmVzb2x1dGlvbiwgc2VlIGlmIHRoZXJlIGlzIGFueW9uZSBhZGRpbmcgYW55dGhpbmcg dG8gaXQuDQoNCltNdWt1bDNdIEFjdHVhbGx5LCBJIHdvdWxkIGxpa2UgdGhlIG5leHQgaGVhZGVy IHRvIGJlIDQgYml0cyBhbmQgdGhlIHNlcXVlbmNlIG51bWJlciB0byBiZSA0IGJpdHMuIDQtYml0 IHNlcXVlbmNlIG51bWJlciB3aWxsIHN0aWxsIGFsbG93IHVwIHRvIDE2IGRpZmZlcmVudCBtZXNz YWdlcyB0byBiZSBzZW50IGR1cmluZyBhIFAyUC1SUEwgZGlzY292ZXJ5LiA0IGJpdCBuZXh0IGhl YWRlciB3aWxsIGFsbG93IDE2IGRpZmZlcmVudCBwb3NzaWJpbGl0aWVzLiBXZSBjYW4gaGF2ZSBz byBtYW55IGRpZmZlcmVudCB3YXlzIHRvIGNvbXByZXNzIFVEUC9UQ1AgaGVhZGVycy4gSSB0aGlu ayAzIGJpdCBuZXh0IGhlYWRlciBtYXkgbm90IGJlIHN1ZmZpY2llbnQuICANCg0KW1Bhc2NhbDRd IENvb2wuIExldCdzIHVzZSB0aGF0IGFzIHRoZSBwcm9wb3NlZCByZXNvbHV0aW9uDQoNCioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpbUGFzY2FsXQ0KIldoZW4gYW4NCmlu dGVybWVkaWF0ZSByb3V0ZXIgYWRkcyBpdHNlbGYgdG8gYSByb3V0ZSwgaXQgTVVTVCBlbnN1cmUg dGhhdCB0aGUNCklQdjYgYWRkcmVzcyBhZGRlZCB0byB0aGUgcm91dGUgaXMgcmVhY2hhYmxlIGlu IGJvdGggZm9yd2FyZCBhbmQgYmFja3dhcmQgZGlyZWN0aW9ucy4iDQpUaGlzIGlzIHdyaXR0ZW4g d2l0aCB0aGUgdmlzaW9uIHRoYXQgdGhlIHJvdXRlciBoYXMgYSBzaW5nbGUgaW50ZXJmYWNlIGFu ZCBhY3RzIGFzIGEgcmVwZWF0ZXIuIA0KQnV0IHJlYWxseSBhIHJvdXRlciBjb3VsZCBoYXZlIDIg aW50ZXJmYWNlcyBvbiBhIHNhbWUgc3VibmV0IGluIHdoaWNoIGNhc2UgdGhhdCBjbGF1c2UgZG9l cyBub3QgZmx5Lg0KDQpbTXVrdWxdDQpBbGwgSSBtZWFuIGlzIHRoYXQgdGhlIGFjY3VtdWxhdGVk IHJvdXRlIE1VU1QgTk9UIGhhdmUgYW4gYWRkcmVzcyB0aGF0IGNhbm5vdCBiZSBhY2Nlc3NlZCBp biBvbmUgb2YgdGhlIGRpcmVjdGlvbnMuIElmIHRoZSBhZGRyZXNzIGNhbm5vdCBiZSBhY2Nlc3Nl ZCBpbiB0aGUgYmFja3dhcmQgZGlyZWN0aW9uLCB0aGVuIHRoZSBEUk8gd291bGQgbm90IGJlIGFi bGUgdG8gdHJhdmVsIHRvIHRoZSBvcmlnaW4uDQoNCltQYXNjYWwyXSBUaGVuIHlvdSdyZSBwcmV2 ZW50aW5nIGEgcm91dGVyIHdpdGggMiBpbnRlcmZhY2VzLiBUaGF0J3Mgc2FkLiBJJ20gZmluZSBm b3IgYW4gZXhwZXJpbWVudGFsIGRyYWZ0ICAgYnV0IGZvciBzdGFuZGFyZCB0cmFjayB0aGF0IHdp bGwgaGF2ZSB0byBiZSBjaGFuZ2VkLg0KDQpbTXVrdWwyXSBPSywgSSBhbSBrZWVwaW5nIGl0IHRo ZSB3YXkgaXQgaXMuDQoNCltQYXNjYWwzXSBUaGlzIGFsc28gbmVlZCB0byBiZSBsb2dnZWQgYXMg YSBsYXN0IGNhbGwgaXNzdWUgYW5kIGl0cyBwcm9wb3NlZCByZXNvbHV0aW9uLiBOb3RoaW5nIHdy b25nIHdpdGggaGF2aW5nIGxpbWl0YXRpb25zLCB5ZXQgSSB0aGluayB3ZSBtdXN0IGhhdmUgc3Bl Y2lmaWMgdGV4dCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBzcGVjIHNvIGZhciBpcyBsaW1pdGVkIHRv IGRldmljZXMgd2l0aCBhIHNpbmdsZSBpbnRlcmZhY2UuIFdoZW4gd2UgbWFrZSB0aGUgU3RhbmRh cmQgVHJhY2sgdmVyc2lvbiwgSSBleHBlY3Qgd2UnbGwgaGF2ZSB0byBnbyBiZXlvbmQgdGhhdCBs aW1pdGF0aW9uLiBUaGUgZHJhd2JhY2sgaXMgZm9yIGV4cGVyaW1lbnRhbCAgaW1wbGVtZW50YXRp b25zIHRoYXQgbWF5IG5vdCBiZSBpbnRlcm9wZXJhYmxlIHdpdGggdGhlIGZpbmFsIHNvbHV0aW9u Lg0KDQpbTXVrdWwzXSBDb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gaG93IGRvZXMgdGhlIHJlcXVp cmVtZW50IHJlZ2FyZGluZyBhZGRyZXNzZXMgdG8gYmUgYWNjZXNzaWJsZSBpbiBib3RoIGZvcndh cmQgYW5kIGJhY2t3YXJkIGRpcmVjdGlvbnMgbGltaXRzIFAyUC1SUEwgdG8gb25seSBzaW5nbGUg aW50ZXJmYWNlIGRldmljZXM/IEkgdGhpbmsgdGhpcyByZXF1aXJlbWVudCBtZWFucyB0aGF0IFAy UC1SUEwgY2Fubm90IGJlIHVzZWQgYWNyb3NzIGxpbmsgbGF5ZXJzLiBJcyB0aGF0IHdoYXQgeW91 IG1lYW4/IEkgdGhpbmsgYWxsb3dpbmcgb3BlcmF0aW9uIGFjcm9zcyBsaW5rIGxheWVycyB3b3Vs ZCByZXF1aXJlIFAyUC1SRE8gdG8gYWNjdW11bGF0ZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIChi YWNrd2FyZCBhZGRyZXNzIHRvIGJlIHVzZWQgZm9yIGZvcndhcmQgYWRkcmVzc2VzIG5vdCBhY2Nl c3NpYmxlIGluIGJhY2t3YXJkIGRpcmVjdGlvbikuIEkgdGhpbmsgYXQgdGhlIG1vbWVudCB3ZSB3 YW50IHRvIGF2b2lkIHRoaXMgY29tcGxleGl0eS4NCg0KW1Bhc2NhbDRdIEJlY2F1c2UgYW4gSVAg YWRkcmVzcyBpcyBhc3NvY2lhdGVkIHRvIGFuIGludGVyZmFjZS4gSWYgeW91IGhhdmUgMiBpbnRl cmZhY2VzLCBldmVuIGluIGEgc2FtZSBzdWJuZXQsIHRoZXJlIHNob3VsZCBiZSAyIGFkZHJlc3Nl cy4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQogIFdlJ3JlIGdldHRpbmcgdGhlcmUgOikN Cg0KUGFzY2FsICANCg== From matteo@ember.com Tue Apr 3 06:44:58 2012 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 E8EB921F85B6 for ; Tue, 3 Apr 2012 06:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.37 X-Spam-Level: X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, MANGLED_NAIL=2.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 zJ9VQcTCtpvx for ; Tue, 3 Apr 2012 06:44:58 -0700 (PDT) Received: from p01c11o148.mxlogic.net (p01c11o148.mxlogic.net [208.65.144.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2659221F85B5 for ; Tue, 3 Apr 2012 06:44:57 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO p01c11o148.mxlogic.net) by p01c11o148.mxlogic.net(mxl_mta-6.13.0-3) with ESMTP id adefa7f4.2aaabfa05940.115682.00-563.220516.p01c11o148.mxlogic.net (envelope-from ); Tue, 03 Apr 2012 07:44:58 -0600 (MDT) X-MXL-Hash: 4f7afeda6f2b1065-fee6fa313787c60d6df68bbaa62cc1b941d265b1 Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c11o148.mxlogic.net(mxl_mta-6.13.0-3) over TLS secured channel with ESMTP id 4defa7f4.0.115626.00-369.220370.p01c11o148.mxlogic.net (envelope-from ); Tue, 03 Apr 2012 07:44:54 -0600 (MDT) X-MXL-Hash: 4f7afed65883cd12-6732de025bc98d8b0f92b0b374ba77d2e8dd9373 Received: from USMAIL.hq.ember.com ([fe80::414:51ae:1b16:3f29]) by USMail.hq.ember.com ([fe80::414:51ae:1b16:3f29%10]) with mapi id 14.01.0355.002; Tue, 3 Apr 2012 09:46:29 -0400 From: Matteo Paris To: Philip Levis Thread-Topic: [Roll] New Version Notification - draft-ietf-roll-minrank-hysteresis-of-07.txt Thread-Index: AQHNA7v6JbPKPVP/ZUe2ufcTZJGhzZaJe3oA Date: Tue, 3 Apr 2012 13:46:28 +0000 Message-ID: References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com> <0500582D-1326-4033-9A82-FD42BB47A29D@ember.com> <4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu> In-Reply-To: <4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.81.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <7C9F74034FF75E41850096B82003694E@ember.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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=PvnVXCDccy0A:10 a=0lGxxKK5Fb8A:10 a=saA6nF2ZJa] X-AnalysisOut: [AA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:1] X-AnalysisOut: [0 a=MYqPJgym4Kx47q1P90kooQ==:17 a=Y1xPKZcGYHaXi7A22PsA:9 a] X-AnalysisOut: [=EaMLpzuPb1U7yo0XIrAA:7 a=CjuIK1q_8ugA:10] Cc: "roll@ietf.org" Subject: Re: [Roll] New Version Notification - draft-ietf-roll-minrank-hysteresis-of-07.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: Tue, 03 Apr 2012 13:44:59 -0000 Hi Phil, my question boils down to whether RPL requires members of the parent set to= have lower DAGRank, or merely lower rank. My reading of the RPL draft is = that all parents must have lower DAGRank. I get this from two clauses in the RPL draft that I quoted below. Unfortun= ately both are confusingly worded. RPL Section 3.5.1 says: "A node A has a rank less than the rank of a node B= if DAGRank(A) is less than DAGRank(B)." I believe the intention here was = to say "if and only if", otherwise the clause is pointless (trivially true)= . RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG parent set= must be of rank less than DAGRank(N)." Here, a rank is being compared wit= h a DAGRank, which is nonsensical, unless "rank" actually means "DAGRank". = It would be much clearer if it said so explicitly, ie "must be of DAGRank = less than DAGRank(N)." =20 What is your interpretation -- are parents required to have lower rank or l= ower DAGRank? Perhaps the confusion is a result of some text accidentally l= eft over from an older version of the draft. Thanks, Matteo PS My emails have not been posting to the list. I'm working on it. On Mar 16, 2012, at 5:29 PM, Philip Levis wrote: >=20 > On Mar 16, 2012, at 1:44 PM, Matteo Paris wrote: >=20 >>=20 >> Hi Phil. These changes were helpful. But I am still unclear on the ran= k computation in section 3.3. From the RPL draft: >>=20 >> RPL Section 3.5.1: "DAGRank(rank) =3D floor(rank/MinHopRankIncrease)" >> RPL Section 3.5.1: "A node A has a rank less than the rank of a node B = if DAGRank(A) is less than DAGRank(B)." >> RPL Section 3.5.2: "[F]or a node N, all parents in the DODAG parent set= must be of rank less than DAGRank(N)." >> RPL Section 8.2.1: "A node's rank MUST be greater than all elements of = its DODAG parent set." >>=20 >> The rank computation in MRHOF section 3.3 can result in parents P for wh= ich DAGRank(P) is not less than DAGRank(N), >> which would seem to violate the third and fourth clauses above, given th= e definitions in the first two clauses. >=20 > How? I intended case 2 in 3.3 to cover this. Can you explain the edge cas= e you see where it does not? >=20 >>=20 >> One other minor question. In the sentence, "The second case covers requ= irement 4..." of MRHOF section 3.3, do you mean requirement 5? >=20 > Yes! It should be requirement 5. I will fix this in the next revision. Th= ank you for catching it. >=20 > Phil From prvs=43413a6b9=mukul@uwm.edu Tue Apr 3 23:17:50 2012 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 D7EE421F85ED for ; Tue, 3 Apr 2012 23:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.204 X-Spam-Level: X-Spam-Status: No, score=-5.204 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 SAUCeBhqKN8p for ; Tue, 3 Apr 2012 23:17:49 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5471321F85E1 for ; Tue, 3 Apr 2012 23:17:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAP/me09/AAAB/2dsb2JhbABFhU61YSNPBxsaAg0ZAlkGLAKHbqgsiFqJCYEviVQKAYQugRgEiFiNC5AwgwWBNgEW Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 67DCE2B3F0F; Wed, 4 Apr 2012 01:17:48 -0500 (CDT) 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 ZirK6l0SZo1T; Wed, 4 Apr 2012 01:17:47 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id C52E12B3F0B; Wed, 4 Apr 2012 01:17:47 -0500 (CDT) Date: Wed, 4 Apr 2012 01:17:47 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <951451541.1806190.1333520267647.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.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Part 2 Re: G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09 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, 04 Apr 2012 06:17:51 -0000 Hi Pascal ******************************************************************* [Pascal2] 2) Same question if you want to create states at the target to route back. How long does the target need to maintain the route? Who controls that, the origin or the target? I'd expect to find a suggested lifetime in the RDO with a confirmation in the DRO to let the target amend it. [Mukul2] If the target wants DRO-ACK it needs to maintain state until DRO-ACK is received. Otherwise, the target needs to remember things until it is done sending all the DROs. I will add the text to this effect. [Pascal3] If you are setting up a short term conversation, how long exactly is that before the origin has to refresh the route? What controls clean up in both sides? Usually you want a lifetime (see MIP6 for instance) [Mukul3] Is it that you are talking about the lifetime of the hop-by-hop routing state? That is specified in the life time parameters in the DODAG configuration option. The draft says that on page 9 while describing how the DODAG configuration option should be set inside a P2P mode DIO: "The Default Lifetime and Lifetime Unit parameters in DODAG Configuration option indicate the life time of the state the routers maintain for a hop-by-hop route established using P2P-RPL and may be set as desired. " [Pascal4] Maybe that's so but then you need to reword a little bit cause you got me qiute confused. I've been talking of the lifetime of the states at origin and target for one conversation. Since they might be having a transient conversation, and the origin might reuse the instance ID soon, you need to give a limit in time to the states that you are creating. Still that conversation is longer than the states in the intermediate routers. So you have 2 lifetimes and you have to be very clear which is which. Personally, I'd have used the lifetime in the configuration option for all the routers on the way and I'd have used the new lifetime in the RDO as the conversation lifetime in the end points because: 1) that is the new concept. 2) This would allow the target to confirm exactly how long it locks resources, 3) and this would be more compatible with the description of the config option in RFC 6550. [Mukul4] There are two lifetimes: 1) Lifetime of the temporary DAG: this is specified inside P2P-RDO 2) Lifetime of the routing state for the hop-by-hop route established using P2P-RPL: this is specified inside the DODAG configuration option. All routers on the established route (including the origin) maintain state for this route for this much time. This time could very well be infinity. Now, lets talk about the "states at origin and target". The origin and the target maintain the state about the temporary DAG for the DAG's life time. This is true for all the nodes that join this DAG. All such nodes maintain state about the temporary DAG until the DAG's life time is over. It is true that the target and the origin exchange DROs and DRO-ACKs and this exchange could conceivably go on even after the temporary DAG's demise. How long should the origin and target indulge in this exchange (and hence remember the possibly dead DAG)? I think it is purely their choice and the draft need not impose any artificial time limit on this. ************************************************************************************* [Pascal] "RPLInstanceID: RPLInstanceID MUST be a local value as described in Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the same RPLInstanceID in two or more concurrent route discoveries." I'd suggest that you enforce a round robin or an opaque circulation so that the new instanceID is the least recently used one out of the 64 possible. [Mukul] I think we should leave it to the origin to decide which value it wants to use for RPLInstanceID. I know some implementations are planning to use a fixed RPLInstanceID value for all route discoveries. [Pascal2] Changing the instance ID will help debug the network and avoid conflicts with stale states. What's really up to the device is the initial sequence. Leaving it up to the origin may help the origin defeat some attacks to some degree. OTOH, after all the instances have been played, LRU forces to replay the same sequence again so the shield drops. My preferred approach would be a SHOULD that would say that the next instance ID SHOULD NOT be one of the (16?) most recently used and MUST NOT be one for which states might still exist in the network. IOW either the states deletion was acknowledged, or all pending lifetimes are exhausted. [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD NOT) against reusing instance ids for which the stale state might exist in the nodes. Using a "MUST NOT" may not be OK since a node may never be 100% sure about non-existence of stale state with a particular instance id (thus, all possible instance id values will become suspect and hence unusable after a while). [Pascal3] Agreed. Note that a circulation is a bonus to defeat replays. And now we're back to the issue above. How does the device know that there is no state left? A lifetime definition would be very useful. That lifetime is different from the DAG's one in RDO. I think we have an open issue here. [Mukul3] As I mentioned above, the life time parameters inside the DODAG configuration option specify the life time of the hop-by-hop routing state for the routes discovered using P2P-RPL. [Pascal4] This boils down to the thread above. Only one issue really, which lifetime is which? So IMHO no need to log anything for this thread. [Mukul4] OK. **************************************************************************************** [Pascal] " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in nature, is created solely for the purpose of P2P-RPL route discovery and MUST NOT be used for packet routing." On the contrary I'd set it to 1. The goal -being to reach the origin- is actually achieved by this DAG. [Mukul] Actually, the DAG is temporary in nature and vanishes after a short while. Even when it exists, it must/should not be used for routing packets back to the origin. So, I think the Grounded flag should be zero. [Pascal2] Please revisit RFC 6650 page 12. G means that a goal is achieved. So first you define the goal and then the bit becomes obvious. What's your goal? Can there be P2P DAGs that achieve the goal and others that make sense to build and yet do not achieve the goal? If you accept that your operation can actually depend on OF logic, then the setting of the goal influences that logic. By forcing a value to the goal in the PTP spec, we actually limit the applicability of the draft. Maybe you can define a default goal and a default setting. But do not MUST that it is set to 0... [Mukul2] When a node joins a temporary P2P DAG, it does not get any additional routing information. The DAG is going to disappear after some time, should not be used for routing while it exists and which nodes end up being on the discovered route is not known until the DRO message comes back. So, I think, by default, the G flag has to be zero. However, if the setting of G flag may affect how an intermediate node may calculate its rank (as per the OF being used), the origin should have the flexibility of setting the flag to 1. So, I could modify the text to say that "the origin sets the G flag based on its perception of how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created." [Pascal3] Why do you feel the need to add anything above what RFC 6550 says? I do not see any benefit or additional clarity from doing this. [Mukul3] RFC 6550 is actually kind of confusing in this regard. On page 9, it says "A typical Goal is to construct the DODAG according to a specific Objective Function and to keep connectivity to a set of hosts (e.g., to use an Objective Function that minimizes a metric and is connected to a specific database host to store the collected data)." This seems to associate the goal with both OF and reachability to certain hosts. Later invocations of the term "goal" seem to refer just to the connectivity aspect, e.g., on page 18 RFC 6550 says "A grounded DODAG offers connectivity to hosts that are required for satisfying the application-defined goal." So, my understanding so far was that the "goal" defines connectivity to a certain hosts. The relation to objective function is not clear at all (if one restricts oneself to reading RFC 6550). The temporary DAGs created in P2P-RPL route discovery provide no connectivity whatsoever to the joining nodes. So, the only reason to set the G flag to 1 would be to allow correct use of an OF. So, I think P2P-RPL spec should use the text I offered above (and repeat below): "The origin sets the G flag based on its perception of whether joining how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created." What do you think? [Pascal4] If you think this adds value, I will not oppose. Let's keep that as the proposed resolution [Mukul4] Sounds good. **************************************************************************************** [Pascal]" MAY carry one or more RPL Target Options to specify additional unicast/multicast addresses for the target." Now here I would have a MUST carry at least one target. That is indeed what makes is a lookup DIO... [Mukul] As I stated in the previous message, we need to include the target in the P2P-RDO to save bytes for the common case (discover route to one unicast/multicast target). So, we cannot make using the target option a MUST. [Pascal2] Certainly. I prefer the split, in which case the MUST IMHO goes to the target as opposed to the RDO. In a case where the RDO is not needed, the target only message is actually shorter... [Mukul2] As I said before, I think a P2P mode DIO always needs to have one P2P-RDO. I guess, in this case, we agree to disagree! [Pascal3] Certainly. And there's nothing blocking with that disagreement, mostly if the draft targets experimental. I think it's OK to keep your response as the proposed resolution for the issue. Still I'd like advice from others so exposing the issue as LC will help. Let's see on which side the coin falls. [Mukul3] OK. I will be happy to hear additional opinions. [Pascal4] Fine, let's keep that as the proposed resolution [Mukul4] OK. ************************************************************************************************ [Pascal] Can the data option be different from one DIO to the next? [Mukul] The contents of the data option are specified by the origin (for the DIO) or the target (for the DRO). In theory, an origin can send different data options in different DIOs it generates for a particular route discovery (assuming that it does generate multiple DIOs; it is very much possible that the origin generates just one DIO and then sits silent). But, then the origin is taking the risk that some of the data options would never each the target(s). I guess the origin might do this if the data sent earlier is now stale and the origin would like the target(s) to receive newer data. [Pascal2] This should be discussed in the draft. You need to set the expectation for the upper layer(s). Is there a way to differentiate different data sets? Eg instance or sequence nb? My suggestion so far is that the data should have 3 bits of next header and 5 bits of sequence. [Mukul2] This sounds good to me. I will incorporate this in the draft unless I hear a better proposal. [Pascal3] Cool. Please make that another LC issue and the proposed resolution, see if there is anyone adding anything to it. [Mukul3] Actually, I would like the next header to be 4 bits and the sequence number to be 4 bits. 4-bit sequence number will still allow up to 16 different messages to be sent during a P2P-RPL discovery. 4 bit next header will allow 16 different possibilities. We can have so many different ways to compress UDP/TCP headers. I think 3 bit next header may not be sufficient. [Pascal4] Cool. Let's use that as the proposed resolution [Mukul4] OK. *********************************************************************************************** [Pascal] "When an intermediate router adds itself to a route, it MUST ensure that the IPv6 address added to the route is reachable in both forward and backward directions." This is written with the vision that the router has a single interface and acts as a repeater. But really a router could have 2 interfaces on a same subnet in which case that clause does not fly. [Mukul] All I mean is that the accumulated route MUST NOT have an address that cannot be accessed in one of the directions. If the address cannot be accessed in the backward direction, then the DRO would not be able to travel to the origin. [Pascal2] Then you're preventing a router with 2 interfaces. That's sad. I'm fine for an experimental draft but for standard track that will have to be changed. [Mukul2] OK, I am keeping it the way it is. [Pascal3] This also need to be logged as a last call issue and its proposed resolution. Nothing wrong with having limitations, yet I think we must have specific text to indicate that the spec so far is limited to devices with a single interface. When we make the Standard Track version, I expect we'll have to go beyond that limitation. The drawback is for experimental implementations that may not be interoperable with the final solution. [Mukul3] Could you please explain how does the requirement regarding addresses to be accessible in both forward and backward directions limits P2P-RPL to only single interface devices? I think this requirement means that P2P-RPL cannot be used across link layers. Is that what you mean? I think allowing operation across link layers would require P2P-RDO to accumulate additional information (backward address to be used for forward addresses not accessible in backward direction). I think at the moment we want to avoid this complexity. [Pascal4] Because an IP address is associated to an interface. If you have 2 interfaces, even in a same subnet, there should be 2 addresses. [Mukul4] But, why would the two IP addresses the device has on the same subnet wont be accessible in both forward and backward directions? ******************************************************************************* Thanks Mukul From trac+roll@trac.tools.ietf.org Wed Apr 4 06:06:38 2012 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 9BA7021F84D8 for ; Wed, 4 Apr 2012 06:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.359 X-Spam-Level: X-Spam-Status: No, score=-101.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24, 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 5TpRGDRRH5Rs for ; Wed, 4 Apr 2012 06:06:38 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id EC32E21F84D6 for ; Wed, 4 Apr 2012 06:06:37 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFPux-000656-KK; Wed, 04 Apr 2012 09:06:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Wed, 04 Apr 2012 13:06:30 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/85 Message-ID: <055.04b63ad43f3bc000d32addde8cd227ef@trac.tools.ietf.org> X-Trac-Ticket-ID: 85 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 04 Apr 2012 06:07:28 -0700 Cc: roll@ietf.org Subject: [Roll] [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 13:06:38 -0000 #85: which lifetime is for the end points (origin and target) vs. intermediate nodes. Problem (currently open) ------------------------------ P2P creates temporary states in the transient DAG and less-but-still temporary states in the endpoints. These are 2 different lifetimes. The spec has 2 lifetimes, one in the config option and one in the RDO. The spec is not sufficiently clear about which is which. In can appear to be conflicting since the config option is supposed to apply to all routers on the path. On the side, and in order to allow the reuse of instance ID, the origin must be sure that all states for a previous usage of the same value are gone. So we need a clear control / negotiation of the lifetimes on the states that come with an instanceID. Again this is not clear enough in the spec. [Pascal2] 2) Same question if you want to create states at the target to route back. How long does the target need to maintain the route? Who controls that, the origin or the target? I'd expect to find a suggested lifetime in the RDO with a confirmation in the DRO to let the target amend it. [Mukul2] If the target wants DRO-ACK it needs to maintain state until DRO-ACK is received. Otherwise, the target needs to remember things until it is done sending all the DROs. I will add the text to this effect. [Pascal3] If you are setting up a short term conversation, how long exactly is that before the origin has to refresh the route? What controls clean up in both sides? Usually you want a lifetime (see MIP6 for instance) [Mukul3] Is it that you are talking about the lifetime of the hop-by-hop routing state? That is specified in the life time parameters in the DODAG configuration option. The draft says that on page 9 while describing how the DODAG configuration option should be set inside a P2P mode DIO: "The Default Lifetime and Lifetime Unit parameters in DODAG Configuration option indicate the life time of the state the routers maintain for a hop-by-hop route established using P2P-RPL and may be set as desired. " [Pascal4] Maybe that's so but then you need to reword a little bit cause you got me qiute confused. I've been talking of the lifetime of the states at origin and target for one conversation. Since they might be having a transient conversation, and the origin might reuse the instance ID soon, you need to give a limit in time to the states that you are creating. Still that conversation is longer than the states in the intermediate routers. So you have 2 lifetimes and you have to be very clear which is which. Personally, I'd have used the lifetime in the configuration option for all the routers on the way and I'd have used the new lifetime in the RDO as the conversation lifetime in the end points because: 1) that is the new concept. 2) This would allow the target to confirm exactly how long it locks resources, 3) and this would be more compatible with the description of the config option in RFC 6550. [Mukul4] There are two lifetimes: 1) Lifetime of the temporary DAG: this is specified inside P2P-RDO 2) Lifetime of the routing state for the hop-by-hop route established using P2P-RPL: this is specified inside the DODAG configuration option. All routers on the established route (including the origin) maintain state for this route for this much time. This time could very well be infinity. Now, lets talk about the "states at origin and target". The origin and the target maintain the state about the temporary DAG for the DAG's life time. This is true for all the nodes that join this DAG. All such nodes maintain state about the temporary DAG until the DAG's life time is over. It is true that the target and the origin exchange DROs and DRO-ACKs and this exchange could conceivably go on even after the temporary DAG's demise. How long should the origin and target indulge in this exchange (and hence remember the possibly dead DAG)? I think it is purely their choice and the draft need not impose any artificial time limit on this. Pascal -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Apr 4 06:08:51 2012 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 D161221F86BB for ; Wed, 4 Apr 2012 06:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=0.620, 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 GJ7-i+Zmic1E for ; Wed, 4 Apr 2012 06:08:51 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0650521F8604 for ; Wed, 4 Apr 2012 06:08:51 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFPxC-0006AP-9S; Wed, 04 Apr 2012 09:08:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Wed, 04 Apr 2012 13:08:50 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/86 Message-ID: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org> X-Trac-Ticket-ID: 86 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #86: G flag: do we need that text? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 13:08:51 -0000 #86: G flag: do we need that text? Problem (resolition is proposed) ------------------------------ Disagreement on the meaning of 'G' bit and imposed setting to 0; Proposed resolution --------------------------- The origin sets the G flag based on its perception of whether joining how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created. Discussion ------------- [Pascal] " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in nature, is created solely for the purpose of P2P-RPL route discovery and MUST NOT be used for packet routing." On the contrary I'd set it to 1. The goal -being to reach the origin- is actually achieved by this DAG. [Mukul] Actually, the DAG is temporary in nature and vanishes after a short while. Even when it exists, it must/should not be used for routing packets back to the origin. So, I think the Grounded flag should be zero. [Pascal2] Please revisit RFC 6650 page 12. G means that a goal is achieved. So first you define the goal and then the bit becomes obvious. What's your goal? Can there be P2P DAGs that achieve the goal and others that make sense to build and yet do not achieve the goal? If you accept that your operation can actually depend on OF logic, then the setting of the goal influences that logic. By forcing a value to the goal in the PTP spec, we actually limit the applicability of the draft. Maybe you can define a default goal and a default setting. But do not MUST that it is set to 0... [Mukul2] When a node joins a temporary P2P DAG, it does not get any additional routing information. The DAG is going to disappear after some time, should not be used for routing while it exists and which nodes end up being on the discovered route is not known until the DRO message comes back. So, I think, by default, the G flag has to be zero. However, if the setting of G flag may affect how an intermediate node may calculate its rank (as per the OF being used), the origin should have the flexibility of setting the flag to 1. So, I could modify the text to say that "the origin sets the G flag based on its perception of how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created." [Pascal3] Why do you feel the need to add anything above what RFC 6550 says? I do not see any benefit or additional clarity from doing this. [Mukul3] RFC 6550 is actually kind of confusing in this regard. On page 9, it says "A typical Goal is to construct the DODAG according to a specific Objective Function and to keep connectivity to a set of hosts (e.g., to use an Objective Function that minimizes a metric and is connected to a specific database host to store the collected data)." This seems to associate the goal with both OF and reachability to certain hosts. Later invocations of the term "goal" seem to refer just to the connectivity aspect, e.g., on page 18 RFC 6550 says "A grounded DODAG offers connectivity to hosts that are required for satisfying the application-defined goal." So, my understanding so far was that the "goal" defines connectivity to a certain hosts. The relation to objective function is not clear at all (if one restricts oneself to reading RFC 6550). The temporary DAGs created in P2P-RPL route discovery provide no connectivity whatsoever to the joining nodes. So, the only reason to set the G flag to 1 would be to allow correct use of an OF. So, I think P2P-RPL spec should use the text I offered above (and repeat below): "The origin sets the G flag based on its perception of whether joining how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created." What do you think? [Pascal4] If you think this adds value, I will not oppose. Let's keep that as the proposed resolution [Mukul4] Sounds good. Pascal -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: applicability-ami | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Apr 4 06:09:58 2012 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 2508B21F8734 for ; Wed, 4 Apr 2012 06:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 hOsi8pkAzLMD for ; Wed, 4 Apr 2012 06:09:57 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 90DC221F86BD for ; Wed, 4 Apr 2012 06:09:57 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFPyG-0006C3-TW; Wed, 04 Apr 2012 09:09:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Wed, 04 Apr 2012 13:09:56 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/87 Message-ID: <055.f551806bbfcbaa57b44d89571c962af8@trac.tools.ietf.org> X-Trac-Ticket-ID: 87 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #87: Can't we split the target from the RDO ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 13:09:58 -0000 #87: Can't we split the target from the RDO ? Problem (proposed resolution) ------------------------------ The RDO is a garbage option will all sorts of data in it. The advocated reason for that is conciseness since separate options mean overhead. OTOH, it makes more sense to have all the targets expresses as target options as opposed to having one target in the DRO and then all other targets listed after. Having the target separate would allow for a DIO with no RDO but only a target, which would be useful to poll a device on an existing DAG. Currently the draft MUST a RDO and MAY and target option. The suggestion is to allow for a target in DIO without a RDO. Proposed resolution ------------------------- Keep it at that since 1) there are implementations and 2) it's experimental . This resolution implies that the issue will be reopened should the work go for standard track Discussion ------------- [Pascal]" MAY carry one or more RPL Target Options to specify additional unicast/multicast addresses for the target." Now here I would have a MUST carry at least one target. That is indeed what makes is a lookup DIO... [Mukul] As I stated in the previous message, we need to include the target in the P2P-RDO to save bytes for the common case (discover route to one unicast/multicast target). So, we cannot make using the target option a MUST. [Pascal2] Certainly. I prefer the split, in which case the MUST IMHO goes to the target as opposed to the RDO. In a case where the RDO is not needed, the target only message is actually shorter... [Mukul2] As I said before, I think a P2P mode DIO always needs to have one P2P-RDO. I guess, in this case, we agree to disagree! [Pascal3] Certainly. And there's nothing blocking with that disagreement, mostly if the draft targets experimental. I think it's OK to keep your response as the proposed resolution for the issue. Still I'd like advice from others so exposing the issue as LC will help. Let's see on which side the coin falls. [Mukul3] OK. I will be happy to hear additional opinions. [Pascal4] Fine, let's keep that as the proposed resolution [Mukul4] OK. Pascal -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Apr 4 06:10:37 2012 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 6CE8921F8738 for ; Wed, 4 Apr 2012 06:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 5V7M5ddX9w6e for ; Wed, 4 Apr 2012 06:10:37 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DFAF121F86BD for ; Wed, 4 Apr 2012 06:10:34 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFPys-0006fm-8w; Wed, 04 Apr 2012 09:10:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Wed, 04 Apr 2012 13:10:34 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/88 Message-ID: <055.6ee5f9af0660881f34d198ae081e0ce4@trac.tools.ietf.org> X-Trac-Ticket-ID: 88 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #88: Data option and ULP X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 13:10:37 -0000 #88: Data option and ULP Problem (proposed resolution exists) ------------------------------ An option exists for carrying payload. The use of the option (tunnel, transport?) is not described properly. Proposed resolution ------------------------ Add a next header and a sequence to the data option so upper layers can be determined. Discussion ------------- [Pascal] Can the data option be different from one DIO to the next? [Mukul] The contents of the data option are specified by the origin (for the DIO) or the target (for the DRO). In theory, an origin can send different data options in different DIOs it generates for a particular route discovery (assuming that it does generate multiple DIOs; it is very much possible that the origin generates just one DIO and then sits silent). But, then the origin is taking the risk that some of the data options would never each the target(s). I guess the origin might do this if the data sent earlier is now stale and the origin would like the target(s) to receive newer data. [Pascal2] This should be discussed in the draft. You need to set the expectation for the upper layer(s). Is there a way to differentiate different data sets? Eg instance or sequence nb? My suggestion so far is that the data should have 3 bits of next header and 5 bits of sequence. [Mukul2] This sounds good to me. I will incorporate this in the draft unless I hear a better proposal. [Pascal3] Cool. Please make that another LC issue and the proposed resolution, see if there is anyone adding anything to it. [Mukul3] Actually, I would like the next header to be 4 bits and the sequence number to be 4 bits. 4-bit sequence number will still allow up to 16 different messages to be sent during a P2P-RPL discovery. 4 bit next header will allow 16 different possibilities. We can have so many different ways to compress UDP/TCP headers. I think 3 bit next header may not be sufficient. [Pascal4] Cool. Let's use that as the proposed resolution [Mukul4] OK. Pascal -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Apr 4 06:11:15 2012 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 D260121F8738 for ; Wed, 4 Apr 2012 06:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 yaF6PI502DkL for ; Wed, 4 Apr 2012 06:11:15 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id F2C5421F86BD for ; Wed, 4 Apr 2012 06:11:14 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFPzS-0006vd-JP; Wed, 04 Apr 2012 09:11:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Wed, 04 Apr 2012 13:11:10 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/89 Message-ID: <055.221455d39fc20c241b942c0dcb13bc22@trac.tools.ietf.org> X-Trac-Ticket-ID: 89 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #89: Spec is limited to single interface intermediate routers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 13:11:15 -0000 #89: Spec is limited to single interface intermediate routers Problem (currently open) ------------------------------ The spec does not allow for routers with multiple interfaces. It expects that an address is usable downwards and upwards. Discussion ------------- [Pascal] "When an intermediate router adds itself to a route, it MUST ensure that the IPv6 address added to the route is reachable in both forward and backward directions." This is written with the vision that the router has a single interface and acts as a repeater. But really a router could have 2 interfaces on a same subnet in which case that clause does not fly. [Mukul] All I mean is that the accumulated route MUST NOT have an address that cannot be accessed in one of the directions. If the address cannot be accessed in the backward direction, then the DRO would not be able to travel to the origin. [Pascal2] Then you're preventing a router with 2 interfaces. That's sad. I'm fine for an experimental draft but for standard track that will have to be changed. [Mukul2] OK, I am keeping it the way it is. [Pascal3] This also need to be logged as a last call issue and its proposed resolution. Nothing wrong with having limitations, yet I think we must have specific text to indicate that the spec so far is limited to devices with a single interface. When we make the Standard Track version, I expect we'll have to go beyond that limitation. The drawback is for experimental implementations that may not be interoperable with the final solution. [Mukul3] Could you please explain how does the requirement regarding addresses to be accessible in both forward and backward directions limits P2P-RPL to only single interface devices? I think this requirement means that P2P-RPL cannot be used across link layers. Is that what you mean? I think allowing operation across link layers would require P2P-RDO to accumulate additional information (backward address to be used for forward addresses not accessible in backward direction). I think at the moment we want to avoid this complexity. [Pascal4] Because an IP address is associated to an interface. If you have 2 interfaces, even in a same subnet, there should be 2 addresses. [Mukul4] But, why would the two IP addresses the device has on the same subnet wont be accessible in both forward and backward directions? Pascal -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Wed Apr 4 06:11:46 2012 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 D2B8621F850F for ; Wed, 4 Apr 2012 06:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 Ulrt2VNWwP04 for ; Wed, 4 Apr 2012 06:11:46 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3528421F850C for ; Wed, 4 Apr 2012 06:11:46 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFQ01-0006zR-1h; Wed, 04 Apr 2012 09:11:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Wed, 04 Apr 2012 13:11:44 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/90 Message-ID: <055.61fcc856b7b35899da82ce224df8d83b@trac.tools.ietf.org> X-Trac-Ticket-ID: 90 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #90: use of transient instance ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 13:11:46 -0000 #90: use of transient instance ID Problem (resolution agreed upon) ------------------------------ P2P creates temporary states in the transient DAG with a transient instance ID. The protocol must ensure that if the instance ID is reused then the new operation it is not confused with states resulting from the previous use of the same instance ID. Suggestion is to propose a rotation. Discussion ------------- [Pascal] "RPLInstanceID: RPLInstanceID MUST be a local value as described in Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the same RPLInstanceID in two or more concurrent route discoveries." I'd suggest that you enforce a round robin or an opaque circulation so that the new instanceID is the least recently used one out of the 64 possible. [Mukul] I think we should leave it to the origin to decide which value it wants to use for RPLInstanceID. I know some implementations are planning to use a fixed RPLInstanceID value for all route discoveries. [Pascal2] Changing the instance ID will help debug the network and avoid conflicts with stale states. What's really up to the device is the initial sequence. Leaving it up to the origin may help the origin defeat some attacks to some degree. OTOH, after all the instances have been played, LRU forces to replay the same sequence again so the shield drops. My preferred approach would be a SHOULD that would say that the next instance ID SHOULD NOT be one of the (16?) most recently used and MUST NOT be one for which states might still exist in the network. IOW either the states deletion was acknowledged, or all pending lifetimes are exhausted. [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD NOT) against reusing instance ids for which the stale state might exist in the nodes. Using a "MUST NOT" may not be OK since a node may never be 100% sure about non-existence of stale state with a particular instance id (thus, all possible instance id values will become suspect and hence unusable after a while). [Pascal3] Agreed. Note that a circulation is a bonus to defeat replays. And now we're back to the issue above. How does the device know that there is no state left? A lifetime definition would be very useful. That lifetime is different from the DAG's one in RDO. I think we have an open issue here. [Mukul3] As I mentioned above, the life time parameters inside the DODAG configuration option specify the life time of the hop-by-hop routing state for the routes discovered using P2P-RPL. [Pascal4] This boils down to the thread above. Only one issue really, which lifetime is which? So IMHO no need to log anything for this thread. [Mukul4] OK. Pascal -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From jpv@cisco.com Wed Apr 4 06:17:01 2012 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 27AA221F86D5 for ; Wed, 4 Apr 2012 06:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.588 X-Spam-Level: X-Spam-Status: No, score=-110.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 v8yi6uglFiTs for ; Wed, 4 Apr 2012 06:17:00 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1E63921F86D4 for ; Wed, 4 Apr 2012 06:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=7656; q=dns/txt; s=iport; t=1333545420; x=1334755020; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=JAHfw7TD8VjZGRRIcNh8gqnUEwmxoJu7P8jQnf8amxY=; b=PlSEVAyTxGCQ2EbiJb9l0m5gcNAUL99XGkUueFqKwmS8pE7Y92XXvJq9 lsWma48ddxqCgD9HlE5GdPIbJ/pz0TSQvSXvyPuppcduuIUuNKFzeM2BW MwsmXP4wcHuU/6pO1e8IXYh/iZYTHEu/MaP0As+RAibjYZFzZxDA4vdOe I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAG1JfE+rRDoI/2dsb2JhbABFryYBiHeBB4IJAQEBAgEBAQEBDwFUBxALIyMLJzAGEyKHYgQBC5sSnmaPcWMEiFiNC45HgWmDBw X-IronPort-AV: E=Sophos;i="4.75,367,1330905600"; d="scan'208,217";a="39022132" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 04 Apr 2012 13:16:59 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q34DGxO7020732 for ; Wed, 4 Apr 2012 13:16:59 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 06:16:59 -0700 Received: from sjc-vpn2-1145.cisco.com ([10.21.116.121]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2012 06:16:59 -0700 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_1C27DD71-8175-4F20-BE00-6749F7D026AE" Date: Wed, 4 Apr 2012 06:14:26 -0700 In-Reply-To: <2A95B759-1675-48F3-8B37-190949E0D8FF@cisco.com> To: ROLL WG References: <098D2267-EBD9-4119-B5F1-DC19A129718B@cisco.com> <9BB4C78B-748F-44F1-93C5-D127480B1C17@cisco.com> <2A95B759-1675-48F3-8B37-190949E0D8FF@cisco.com> Message-Id: <82622227-E2C5-47D9-A1F4-39D3E602C002@cisco.com> X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 04 Apr 2012 13:16:59.0380 (UTC) FILETIME=[37625340:01CD1265] Subject: [Roll] ** Opened Tickets ** Re: * end of Last Call * Re: ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 and draft-ietf-roll-p2p-rpl-09 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, 04 Apr 2012 13:17:01 -0000 --Apple-Mail=_1C27DD71-8175-4F20-BE00-6749F7D026AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, In order to ease the tracking of the comments/issues raised during WG = Last Call, we have opened 6 tickets, the mailing is copied of course. Authors are working on solving each of them. Thanks. JP. On Mar 29, 2012, at 10:15 AM, JP Vasseur wrote: > Dear all, >=20 > WG Last calls have now ended. Thanks to all of you who commented - as = a reminder this document will follow the EXPERIMENTAL track (as a = reminder since this was asked during the ROLL WG meeting). >=20 > Authors, could you please address the number of comments posted on the = mailing list ? >=20 > Thanks. >=20 > JP and Michael. >=20 > On Mar 16, 2012, at 8:14 AM, JP Vasseur wrote: >=20 >> This is just a reminder that we have 2 documents in WG Last Call, = which will terminate on March 29, at noon. >> Comments appreciated. >> Thanks. >>=20 >> JP. >>=20 >> On Mar 7, 2012, at 2:15 PM, JP Vasseur wrote: >>=20 >>> Dear all, >>>=20 >>> The two documents draft-ietf-roll-p2p-measurement and = draft-ietf-roll-p2p-rpl have been discussed on the mailing list and = during=20 >>> WG meetings for some time, there several implementations that are = now stable, and the authors believe that the documents are >>> ready for WG Last Call. >>>=20 >>> Thus, this starts a Working Group Last Call on: >>> * draft-ietf-roll-p2p-measurement-04 >>> and >>> * draft-ietf-roll-p2p-rpl-09 >>>=20 >>> Furthermore, an interoperability was carried out last month with = INRIA's implementation against Sigma Design's implementation. >>> The report can be found: = http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf >>>=20 >>> Experiments with P2P-RPL have also taken place on the Senslab = testbed gathering boards based on MSP430 and 802.15.4 at 2.4GHz:=20 >>> = http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf >>>=20 >>> The WG Last Call will last 3-weeks and will end on March 29, at noon = ET. Please send your comments on the mailing list and copy=20 >>> the authors. >>>=20 >>> Thanks. >>>=20 >>> JP and Michael. =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 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_1C27DD71-8175-4F20-BE00-6749F7D026AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

In order to ease the tracking of the = comments/issues raised during WG Last Call, we have opened 6 tickets, = the mailing
is copied of course. Authors are working on = solving each of = them.

Thanks.

JP.
<= div>
On Mar 29, 2012, at 10:15 AM, JP Vasseur = wrote:

Dear = all,

WG Last calls have now ended. Thanks to all of = you who commented - as a reminder this document will follow the = EXPERIMENTAL track (as a reminder since this was asked during the ROLL = WG meeting).

Authors, could you please address = the number of comments posted on the mailing list = ?

Thanks.

JP and = Michael.

On Mar 16, 2012, at 8:14 AM, JP Vasseur = wrote:

This is just a reminder = that we have 2 documents in WG Last Call, which will terminate = on March 29, at noon.
Comments = appreciated.
Thanks.

JP.

=
On Mar 7, 2012, at 2:15 PM, JP Vasseur = wrote:

Dear = all,

The two documents = draft-ietf-roll-p2p-measurement and draft-ietf-roll-p2p-rpl have been = discussed on the mailing list and during 
WG = meetings for some time, there several implementations that are = now stable, and the authors believe that the documents = are
ready for WG Last Call.

Thus, = this starts a Working Group Last Call on:
* = draft-ietf-roll-p2p-measurement-04
and
*= = draft-ietf-roll-p2p-rpl-09

Furthermore,&n= bsp;an interoperability was carried out last month = with INRIA's implementation against Sigma Design's = implementation.

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

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

= --Apple-Mail=_1C27DD71-8175-4F20-BE00-6749F7D026AE-- From jpv@cisco.com Wed Apr 4 06:17:15 2012 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 9533821F86DC for ; Wed, 4 Apr 2012 06:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.589 X-Spam-Level: X-Spam-Status: No, score=-110.589 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 wtQoPUCsBFQt for ; Wed, 4 Apr 2012 06:17:14 -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 E07DD21F86DA for ; Wed, 4 Apr 2012 06:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=7718; q=dns/txt; s=iport; t=1333545434; x=1334755034; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=Nos3jRiZXIPja6qi6eqbwAg9VJNftTtNHYQxnB6yCn4=; b=LtlA1H0+khCxsAsU0H1z+pgDjkzvyUFo01/Ld4VI/cIDJ2SL6RYQ6btb Wu1kloPqu/s+yMD9CTVa8O+mxHiFYVjoaA9TAcSsE/L7gKnGEjNqioJWL 2Xuza5I0u+/psQzEXANhPhuHmLWcdfmMIqAYzklbHo/3ubiSYr+CPekeD g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAOtIfE+rRDoI/2dsb2JhbABDrzMBiHeBB4IJAQEBAgEBAQEBDwFUBxALIyMLJzAGEyKHYgQBC59ulwGPcWMEiFiNC45HgWmDBw X-IronPort-AV: E=Sophos;i="4.75,367,1330905600"; d="scan'208,217";a="35906476" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 04 Apr 2012 13:17:14 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q34DHEbC020932 for ; Wed, 4 Apr 2012 13:17:14 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 06:17:14 -0700 Received: from sjc-vpn2-1145.cisco.com ([10.21.116.121]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2012 06:17:14 -0700 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_E394E0E9-861C-44B9-88CD-2DE351B1FE99" Date: Wed, 4 Apr 2012 06:17:13 -0700 In-Reply-To: <2A95B759-1675-48F3-8B37-190949E0D8FF@cisco.com> To: ROLL WG References: <098D2267-EBD9-4119-B5F1-DC19A129718B@cisco.com> <9BB4C78B-748F-44F1-93C5-D127480B1C17@cisco.com> <2A95B759-1675-48F3-8B37-190949E0D8FF@cisco.com> Message-Id: X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 04 Apr 2012 13:17:14.0208 (UTC) FILETIME=[4038E600:01CD1265] Subject: [Roll] ** Opened Tickets ** Re: * end of Last Call * Re: ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 and draft-ietf-roll-p2p-rpl-09 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, 04 Apr 2012 13:17:15 -0000 --Apple-Mail=_E394E0E9-861C-44B9-88CD-2DE351B1FE99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, In order to ease the tracking of the comments/issues raised during WG = Last Call, we have opened 6 tickets, the mailing is copied of course. Authors are working on solving each of them. Thanks. JP. On Mar 29, 2012, at 10:15 AM, JP Vasseur wrote: > Dear all, >=20 > WG Last calls have now ended. Thanks to all of you who commented - as = a reminder this document will follow the EXPERIMENTAL track (as a = reminder since this was asked during the ROLL WG meeting). >=20 > Authors, could you please address the number of comments posted on the = mailing list ? >=20 > Thanks. >=20 > JP and Michael. >=20 > On Mar 16, 2012, at 8:14 AM, JP Vasseur wrote: >=20 >> This is just a reminder that we have 2 documents in WG Last Call, = which will terminate on March 29, at noon. >> Comments appreciated. >> Thanks. >>=20 >> JP. >>=20 >> On Mar 7, 2012, at 2:15 PM, JP Vasseur wrote: >>=20 >>> Dear all, >>>=20 >>> The two documents draft-ietf-roll-p2p-measurement and = draft-ietf-roll-p2p-rpl have been discussed on the mailing list and = during=20 >>> WG meetings for some time, there several implementations that are = now stable, and the authors believe that the documents are >>> ready for WG Last Call. >>>=20 >>> Thus, this starts a Working Group Last Call on: >>> * draft-ietf-roll-p2p-measurement-04 >>> and >>> * draft-ietf-roll-p2p-rpl-09 >>>=20 >>> Furthermore, an interoperability was carried out last month with = INRIA's implementation against Sigma Design's implementation. >>> The report can be found: = http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf >>>=20 >>> Experiments with P2P-RPL have also taken place on the Senslab = testbed gathering boards based on MSP430 and 802.15.4 at 2.4GHz:=20 >>> = http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf >>>=20 >>> The WG Last Call will last 3-weeks and will end on March 29, at noon = ET. Please send your comments on the mailing list and copy=20 >>> the authors. >>>=20 >>> Thanks. >>>=20 >>> JP and Michael. =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 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_E394E0E9-861C-44B9-88CD-2DE351B1FE99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

In order to ease the tracking of the = comments/issues raised during WG Last Call, we have opened 6 tickets, = the mailing
is copied of course. Authors are working on = solving each of = them.

Thanks.

JP.
<= div>
On Mar 29, 2012, at 10:15 AM, JP Vasseur = wrote:

Dear = all,

WG Last calls have now ended. Thanks to all of = you who commented - as a reminder this document will follow the = EXPERIMENTAL track (as a reminder since this was asked during the ROLL = WG meeting).

Authors, could you please address = the number of comments posted on the mailing list = ?

Thanks.

JP and = Michael.

On Mar 16, 2012, at 8:14 AM, JP Vasseur = wrote:

This is just a reminder = that we have 2 documents in WG Last Call, which will terminate = on March 29, at noon.
Comments = appreciated.
Thanks.

JP.

=
On Mar 7, 2012, at 2:15 PM, JP Vasseur = wrote:

Dear = all,

The two documents = draft-ietf-roll-p2p-measurement and draft-ietf-roll-p2p-rpl have been = discussed on the mailing list and during 
WG = meetings for some time, there several implementations that are = now stable, and the authors believe that the documents = are
ready for WG Last Call.

Thus, = this starts a Working Group Last Call on:
* = draft-ietf-roll-p2p-measurement-04
and
*= = draft-ietf-roll-p2p-rpl-09

Furthermore,&n= bsp;an interoperability was carried out last month = with INRIA's implementation against Sigma Design's = implementation.

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

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

= --Apple-Mail=_E394E0E9-861C-44B9-88CD-2DE351B1FE99-- From trac+roll@trac.tools.ietf.org Wed Apr 4 06:20:20 2012 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 C290B21F8700 for ; Wed, 4 Apr 2012 06:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 MU0LtPePOgM6 for ; Wed, 4 Apr 2012 06:20:20 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 01E3721F86D9 for ; Wed, 4 Apr 2012 06:20:19 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFQ8I-00005l-PO; Wed, 04 Apr 2012 09:20:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Wed, 04 Apr 2012 13:20:18 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/86#comment:1 Message-ID: <070.fd840252444c723473f612f917c37fd3@trac.tools.ietf.org> References: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org> X-Trac-Ticket-ID: 86 In-Reply-To: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 13:20:20 -0000 #86: G flag: do we need that text? Changes (by jpv@…): * component: applicability-ami => p2p-rpl -- -----------------------------------+---------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Resolution: Keywords: | -----------------------------------+---------------------- Ticket URL: roll From richard.kelsey@ember.com Wed Apr 4 06:37:46 2012 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 F200B21F865A for ; Wed, 4 Apr 2012 06:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 uMkVBLw4P2AA for ; Wed, 4 Apr 2012 06:37:46 -0700 (PDT) Received: from p01c12o147.mxlogic.net (p01c12o147.mxlogic.net [208.65.145.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3055F21F8658 for ; Wed, 4 Apr 2012 06:37:46 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO p01c12o147.mxlogic.net) by p01c12o147.mxlogic.net(mxl_mta-6.13.0-3) with ESMTP id aae4c7f4.62347940.1755.00-579.4117.p01c12o147.mxlogic.net (envelope-from ); Wed, 04 Apr 2012 07:37:46 -0600 (MDT) X-MXL-Hash: 4f7c4eaa0e6dca3e-17cf1cc9709c1fa8d8829c76f206216c9bb58a30 Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c12o147.mxlogic.net(mxl_mta-6.13.0-3) over TLS secured channel with ESMTP id 8ae4c7f4.0.1747.00-364.4098.p01c12o147.mxlogic.net (envelope-from ); Wed, 04 Apr 2012 07:37:45 -0600 (MDT) X-MXL-Hash: 4f7c4ea904a570b9-213568f1780b2eed31dcd0a95f9aeeaec4fbc8e5 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.355.2; Wed, 4 Apr 2012 09:39:17 -0400 Date: Wed, 4 Apr 2012 09:36:50 -0400 Message-ID: <87wr5v8vpp.fsf@kelsey-ws.hq.ember.com> To: In-Reply-To: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org> (message from roll issue tracker on Wed, 4 Apr 2012 13:08:50 +0000) From: Richard Kelsey X-Auto-Response-Suppress: DR, OOF, AutoReply References: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org> 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=u-k6GrH3DusA:10 a=saA6nF2ZJa] X-AnalysisOut: [AA:10 a=BLceEmwcHowA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=CH87r3YBytmwzoa-9V8A:9] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? 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, 04 Apr 2012 13:37:47 -0000 > From: roll issue tracker > Date: Wed, 4 Apr 2012 13:08:50 +0000 > > #86: G flag: do we need that text? > > Problem (resolition is proposed) > ------------------------------ > Disagreement on the meaning of 'G' bit and imposed setting to 0; > > Proposed resolution > --------------------------- > The origin sets the G flag based on its perception of whether joining > how the flag's value would affect the rank calculation under the OF > being used. By default, the G flag is set to zero given the temporary > nature of the DAG being created. I disagree with the proposed resolution. It adds needless confusion. The G flag is 0 if and only if the DODAG is floating. There is no point to allowing floating DODAGs with a P2P-RDO option. I suggest that the G bit be set to 1 and that routers be explicitly prohibited from creating floating DODAGs with a P2P-RDO option. -Richard Kelsey From prvs=43413a6b9=mukul@uwm.edu Wed Apr 4 06:54:54 2012 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 1119621F8795 for ; Wed, 4 Apr 2012 06:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.793 X-Spam-Level: X-Spam-Status: No, score=-4.793 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 XIJTdgofYrqi for ; Wed, 4 Apr 2012 06:54:53 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5C01E21F8470 for ; Wed, 4 Apr 2012 06:54:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAJdRfE9/AAAB/2dsb2JhbABDhVu1XwEBBAEjVgUHDxEDAQEBAwINGQJRCAYTiAQFrHaIV4EhgS+ODYEYBIhYjQuQMIMFgTYX Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id A4418499104; Wed, 4 Apr 2012 08:54:52 -0500 (CDT) 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 ZLrONPxPDdQc; Wed, 4 Apr 2012 08:54:52 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 51213499102; Wed, 4 Apr 2012 08:54:52 -0500 (CDT) Date: Wed, 4 Apr 2012 08:54:52 -0500 (CDT) From: Mukul Goyal To: Richard Kelsey Message-ID: <1574412879.1807702.1333547692001.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <87wr5v8vpp.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.91] 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] #86: G flag: do we need that text? 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, 04 Apr 2012 13:54:54 -0000 >The G flag is 0 if and only if the DODAG is floating. I think that the G flag is 1 if and only if the DODAG is grounded. The temporary DAGs used in P2P-RPL are not grounded, they are temporary. I think that all transient/temporary DAGs are floating by their very nature. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: roll@ietf.org Cc: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org Sent: Wednesday, April 4, 2012 8:36:50 AM Subject: Re: [Roll] [roll] #86: G flag: do we need that text? > From: roll issue tracker > Date: Wed, 4 Apr 2012 13:08:50 +0000 > > #86: G flag: do we need that text? > > Problem (resolition is proposed) > ------------------------------ > Disagreement on the meaning of 'G' bit and imposed setting to 0; > > Proposed resolution > --------------------------- > The origin sets the G flag based on its perception of whether joining > how the flag's value would affect the rank calculation under the OF > being used. By default, the G flag is set to zero given the temporary > nature of the DAG being created. I disagree with the proposed resolution. It adds needless confusion. The G flag is 0 if and only if the DODAG is floating. There is no point to allowing floating DODAGs with a P2P-RDO option. I suggest that the G bit be set to 1 and that routers be explicitly prohibited from creating floating DODAGs with a P2P-RDO option. -Richard Kelsey From pthubert@cisco.com Wed Apr 4 07:07:06 2012 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 2831221F87A8 for ; Wed, 4 Apr 2012 07:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 6o0amVVLHAEh for ; Wed, 4 Apr 2012 07:07:05 -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 8467421F87A7 for ; Wed, 4 Apr 2012 07:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2207; q=dns/txt; s=iport; t=1333548424; x=1334758024; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Hgv0PKG4F4M56+03yLG6VQsozfOvXEwS2GrhRNfa2rU=; b=CAqirmUh+qptJfn3VInTKhm6xBoISXInwHh12u6B2qN5oYN9lqYQ1rrC DDlUpe04PId/2I1BBsQ2N00zExGBC1XqqEL1aPOZb1oCZKxrjSOXfvg14 QDxPvyTaEVCI9+Oc84Sqv/hSSrj4ZfPCy3ijWWmRSPTaVxb+wgkZaFGZj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD9VfE+Q/khN/2dsb2JhbABFDrgPgQeCCQEBAQMBAQEBDwEdCjQLBQcEAgEIEQMBAQELBhcBBgEmHwkIAQEEARIIGodiBQubHp5jBI9xYwSkKoFpgjA5gVIX X-IronPort-AV: E=Sophos;i="4.75,369,1330905600"; d="scan'208";a="70118998" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 04 Apr 2012 14:06:56 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q34E6und004589; Wed, 4 Apr 2012 14:06:56 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, 4 Apr 2012 16:06:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Apr 2012 16:05:28 +0200 Message-ID: In-Reply-To: <1574412879.1807702.1333547692001.JavaMail.root@mail17.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #86: G flag: do we need that text? Thread-Index: Ac0SaophQJJzgKBuR2mLoCsE3HbXbwAASefg References: <87wr5v8vpp.fsf@kelsey-ws.hq.ember.com> <1574412879.1807702.1333547692001.JavaMail.root@mail17.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Richard Kelsey" X-OriginalArrivalTime: 04 Apr 2012 14:06:56.0858 (UTC) FILETIME=[32052BA0:01CD126C] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? 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, 04 Apr 2012 14:07:06 -0000 Hello Mukul Floating vs. Grounded depends on the goal of the DODAG. I asked you and will ask again what is your goal? If the goal is to reach the root, then G is 1... If you want to signal something to the OF using the G bit, leave it open. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: mercredi 4 avril 2012 15:55 To: Richard Kelsey Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? >The G flag is 0 if and only if the DODAG is floating. I think that the G flag is 1 if and only if the DODAG is grounded. The temporary DAGs used in P2P-RPL are not grounded, they are temporary. I think that all transient/temporary DAGs are floating by their very nature. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: roll@ietf.org Cc: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org Sent: Wednesday, April 4, 2012 8:36:50 AM Subject: Re: [Roll] [roll] #86: G flag: do we need that text? > From: roll issue tracker > Date: Wed, 4 Apr 2012 13:08:50 +0000 >=20 > #86: G flag: do we need that text? >=20 > Problem (resolition is proposed) > ------------------------------ > Disagreement on the meaning of 'G' bit and imposed setting to 0; >=20 > Proposed resolution > --------------------------- > The origin sets the G flag based on its perception of whether joining > how the flag's value would affect the rank calculation under the OF =20 > being used. By default, the G flag is set to zero given the temporary > nature of the DAG being created. I disagree with the proposed resolution. It adds needless confusion. The G flag is 0 if and only if the DODAG is floating. There is no point to allowing floating DODAGs with a P2P-RDO option. I suggest that the G bit be set to 1 and that routers be explicitly prohibited from creating floating DODAGs with a P2P-RDO option. -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=43413a6b9=mukul@uwm.edu Wed Apr 4 07:16:41 2012 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 BA7FD21F858B for ; Wed, 4 Apr 2012 07:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.703 X-Spam-Level: X-Spam-Status: No, score=-4.703 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 9kucCVS+lsoi for ; Wed, 4 Apr 2012 07:16:41 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id E44A521F8572 for ; Wed, 4 Apr 2012 07:16:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAI1XfE9/AAAB/2dsb2JhbABFhU61XgEBAQMBAQEBIEsLBQcPEQMBAQEDAg0WAwIpHwkIBhOIBAULqCmIVokFBIEvjg2BGASIWI0LkDCDBYE2Fw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 854D42B3F0A; Wed, 4 Apr 2012 09:16:17 -0500 (CDT) 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 S0ynuxxve6o9; Wed, 4 Apr 2012 09:16:17 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 406922B3EF6; Wed, 4 Apr 2012 09:16:17 -0500 (CDT) Date: Wed, 4 Apr 2012 09:16:17 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <999546162.1808100.1333548977015.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.91] 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] #86: G flag: do we need that text? 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, 04 Apr 2012 14:16:41 -0000 Pascal >If the goal is to reach the root, then G is 1... I have told you multiple times that joining a P2P-RPL DAG does not give any sort of connectivity to the node. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Richard Kelsey" Cc: roll@ietf.org Sent: Wednesday, April 4, 2012 9:05:28 AM Subject: RE: [Roll] [roll] #86: G flag: do we need that text? Hello Mukul Floating vs. Grounded depends on the goal of the DODAG. I asked you and will ask again what is your goal? If the goal is to reach the root, then G is 1... If you want to signal something to the OF using the G bit, leave it open. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: mercredi 4 avril 2012 15:55 To: Richard Kelsey Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? >The G flag is 0 if and only if the DODAG is floating. I think that the G flag is 1 if and only if the DODAG is grounded. The temporary DAGs used in P2P-RPL are not grounded, they are temporary. I think that all transient/temporary DAGs are floating by their very nature. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: roll@ietf.org Cc: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org Sent: Wednesday, April 4, 2012 8:36:50 AM Subject: Re: [Roll] [roll] #86: G flag: do we need that text? > From: roll issue tracker > Date: Wed, 4 Apr 2012 13:08:50 +0000 > > #86: G flag: do we need that text? > > Problem (resolition is proposed) > ------------------------------ > Disagreement on the meaning of 'G' bit and imposed setting to 0; > > Proposed resolution > --------------------------- > The origin sets the G flag based on its perception of whether joining > how the flag's value would affect the rank calculation under the OF > being used. By default, the G flag is set to zero given the temporary > nature of the DAG being created. I disagree with the proposed resolution. It adds needless confusion. The G flag is 0 if and only if the DODAG is floating. There is no point to allowing floating DODAGs with a P2P-RDO option. I suggest that the G bit be set to 1 and that routers be explicitly prohibited from creating floating DODAGs with a P2P-RDO option. -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Wed Apr 4 07:25:25 2012 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 0CA5C21F87A8 for ; Wed, 4 Apr 2012 07:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 EWSgtTZ69Zbs for ; Wed, 4 Apr 2012 07:25:24 -0700 (PDT) Received: from p01c12o141.mxlogic.net (p01c12o141.mxlogic.net [208.65.145.64]) by ietfa.amsl.com (Postfix) with ESMTP id 16ECA21F8739 for ; Wed, 4 Apr 2012 07:25:24 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO p01c12o141.mxlogic.net) by p01c12o141.mxlogic.net(mxl_mta-6.13.0-3) with ESMTP id 4d95c7f4.55f6f940.62291.00-573.138571.p01c12o141.mxlogic.net (envelope-from ); Wed, 04 Apr 2012 08:25:24 -0600 (MDT) X-MXL-Hash: 4f7c59d436df0927-b6171dfd27facbabe8ad0d9e4794a41734fdbffb Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c12o141.mxlogic.net(mxl_mta-6.13.0-3) over TLS secured channel with ESMTP id 2d95c7f4.0.62280.00-392.138556.p01c12o141.mxlogic.net (envelope-from ); Wed, 04 Apr 2012 08:25:23 -0600 (MDT) X-MXL-Hash: 4f7c59d32d16ecd7-325046b720c8806ea3ada933ae2535d58204764f 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.355.2; Wed, 4 Apr 2012 10:26:55 -0400 Date: Wed, 4 Apr 2012 10:24:28 -0400 Message-ID: <87ty0z8tib.fsf@kelsey-ws.hq.ember.com> To: Mukul Goyal In-Reply-To: <1574412879.1807702.1333547692001.JavaMail.root@mail17.pantherlink.uwm.edu> (message from Mukul Goyal on Wed, 4 Apr 2012 08:54:52 -0500) From: Richard Kelsey X-Auto-Response-Suppress: DR, OOF, AutoReply References: <1574412879.1807702.1333547692001.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=u-k6GrH3DusA:10 a=saA6nF2ZJa] X-AnalysisOut: [AA:10 a=BLceEmwcHowA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=OQ] X-AnalysisOut: [_ktunLAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=VO00UbjKn] X-AnalysisOut: [nxrcXP_UBsA:9 a=HRSxrBFyZtJl9WO05OkA:7 a=AuRza0os8rYA:10 a] X-AnalysisOut: [=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? 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, 04 Apr 2012 14:25:25 -0000 > Date: Wed, 4 Apr 2012 08:54:52 -0500 > From: Mukul Goyal > > >The G flag is 0 if and only if the DODAG is floating. > > I think that the G flag is 1 if and only if the DODAG is grounded. I agree. G = 0 means floating, G = 1 means grounded. > The temporary DAGs used in P2P-RPL are not grounded, they are > temporary. I think that all transient/temporary DAGs are > floating by their very nature. This I don't follow at all. If a device has a temporary need to send or receive data from many other devices, it makes perfect sense for it to create a a temporary, grounded DODAG. If there is a lot of P2P traffic, it makes perfect sense to have permanent, floating DODAGs for routing that traffic. -Richard Kelsey > ----- Original Message ----- > From: "Richard Kelsey" > To: roll@ietf.org > Cc: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org > Sent: Wednesday, April 4, 2012 8:36:50 AM > Subject: Re: [Roll] [roll] #86: G flag: do we need that text? > > > From: roll issue tracker > > Date: Wed, 4 Apr 2012 13:08:50 +0000 > > > > #86: G flag: do we need that text? > > > > Problem (resolition is proposed) > > ------------------------------ > > Disagreement on the meaning of 'G' bit and imposed setting to 0; > > > > Proposed resolution > > --------------------------- > > The origin sets the G flag based on its perception of whether joining > > how the flag's value would affect the rank calculation under the OF > > being used. By default, the G flag is set to zero given the temporary > > nature of the DAG being created. > > I disagree with the proposed resolution. It adds needless > confusion. The G flag is 0 if and only if the DODAG is floating. > There is no point to allowing floating DODAGs with a P2P-RDO > option. I suggest that the G bit be set to 1 and that routers be > explicitly prohibited from creating floating DODAGs with a > P2P-RDO option. > -Richard Kelsey > From prvs=43413a6b9=mukul@uwm.edu Wed Apr 4 07:26:51 2012 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 15CAD21F85C2 for ; Wed, 4 Apr 2012 07:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 FspX9tlJDnDQ for ; Wed, 4 Apr 2012 07:26:50 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 65E1D21F85B4 for ; Wed, 4 Apr 2012 07:26:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAPJZfE9/AAAB/2dsb2JhbABFhU61XgEBAQMBAQEBIEsEBwUHDxEDAQEBAwINFgMCKR8JCAYTiAQFC6goiFKJBQSBL44NgRgEiFiNC5AwgwWBNhc Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 0B4E72B3F0A; Wed, 4 Apr 2012 09:26:38 -0500 (CDT) 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 Iua5yOzhZfPl; Wed, 4 Apr 2012 09:26:37 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id C18802B3EF6; Wed, 4 Apr 2012 09:26:37 -0500 (CDT) Date: Wed, 4 Apr 2012 09:26:37 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1994083354.1808319.1333549597673.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.91] 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] #86: G flag: do we need that text? 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, 04 Apr 2012 14:26:51 -0000 >Floating vs. Grounded depends on the goal of the DODAG. I asked you and will ask again what is your goal? I am not sure there is a natural way to define this goal. Why is it that a route discovery should specify an application-level goal and that too in just one bit. My opinion is that the grounded bit is quite unnecessary even for core RPL. Connectivity to specific hosts via the root is specified using other means (the Route Information Option) and the relation to OF is not well defined and in my opinion artificial. >If you want to signal something to the OF using the G bit, leave it open. I have no problem leaving it open. But I think the reason has to be right. Richard, on the other hand, wants it to be closed in other direction (always set it to 1) (I dont agree with his reasoning though). Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Richard Kelsey" Cc: roll@ietf.org Sent: Wednesday, April 4, 2012 9:05:28 AM Subject: RE: [Roll] [roll] #86: G flag: do we need that text? Hello Mukul Floating vs. Grounded depends on the goal of the DODAG. I asked you and will ask again what is your goal? If the goal is to reach the root, then G is 1... If you want to signal something to the OF using the G bit, leave it open. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: mercredi 4 avril 2012 15:55 To: Richard Kelsey Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? >The G flag is 0 if and only if the DODAG is floating. I think that the G flag is 1 if and only if the DODAG is grounded. The temporary DAGs used in P2P-RPL are not grounded, they are temporary. I think that all transient/temporary DAGs are floating by their very nature. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: roll@ietf.org Cc: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org Sent: Wednesday, April 4, 2012 8:36:50 AM Subject: Re: [Roll] [roll] #86: G flag: do we need that text? > From: roll issue tracker > Date: Wed, 4 Apr 2012 13:08:50 +0000 > > #86: G flag: do we need that text? > > Problem (resolition is proposed) > ------------------------------ > Disagreement on the meaning of 'G' bit and imposed setting to 0; > > Proposed resolution > --------------------------- > The origin sets the G flag based on its perception of whether joining > how the flag's value would affect the rank calculation under the OF > being used. By default, the G flag is set to zero given the temporary > nature of the DAG being created. I disagree with the proposed resolution. It adds needless confusion. The G flag is 0 if and only if the DODAG is floating. There is no point to allowing floating DODAGs with a P2P-RDO option. I suggest that the G bit be set to 1 and that routers be explicitly prohibited from creating floating DODAGs with a P2P-RDO option. -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=43413a6b9=mukul@uwm.edu Wed Apr 4 07:32:07 2012 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 2C4DB21F85AC for ; Wed, 4 Apr 2012 07:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.613 X-Spam-Level: X-Spam-Status: No, score=-4.613 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 us+Y6WQnD7-K for ; Wed, 4 Apr 2012 07:32:06 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9684921F85A5 for ; Wed, 4 Apr 2012 07:32:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAMdafE9/AAAB/2dsb2JhbABFhU21XgEBBAEjVgwPEQMBAQEDAg0ZAlEIBhOIBAWoM4hSiQmBL44NgRgEiFiNC5AwgwWBNhc Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 98124E6A90; Wed, 4 Apr 2012 09:31:46 -0500 (CDT) 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 uNnmlI9i30jH; Wed, 4 Apr 2012 09:31:46 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 45900E6A72; Wed, 4 Apr 2012 09:31:46 -0500 (CDT) Date: Wed, 4 Apr 2012 09:31:46 -0500 (CDT) From: Mukul Goyal To: Richard Kelsey Message-ID: <1449714963.1808443.1333549906211.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <87ty0z8tib.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.91] 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] #86: G flag: do we need that text? 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, 04 Apr 2012 14:32:07 -0000 Richard, >> The temporary DAGs used in P2P-RPL are not grounded, they are >> temporary. I think that all transient/temporary DAGs are >> floating by their very nature. >This I don't follow at all. If a device has a temporary need to send or receive data from many other devices, it makes perfect sense for it to create a a temporary, grounded DODAG. If there is a lot of P2P traffic, it makes perfect sense to have permanent, floating DODAGs for routing that traffic. Let me modify my statement a little: Transient DAGs used in P2P-RPL are floating by their very nature. Their lifetime is fleetingly small. They are not used for routing. They impart no connectivity to the nodes joining them. Thanks Mukul > ----- Original Message ----- > From: "Richard Kelsey" > To: roll@ietf.org > Cc: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org > Sent: Wednesday, April 4, 2012 8:36:50 AM > Subject: Re: [Roll] [roll] #86: G flag: do we need that text? > > > From: roll issue tracker > > Date: Wed, 4 Apr 2012 13:08:50 +0000 > > > > #86: G flag: do we need that text? > > > > Problem (resolition is proposed) > > ------------------------------ > > Disagreement on the meaning of 'G' bit and imposed setting to 0; > > > > Proposed resolution > > --------------------------- > > The origin sets the G flag based on its perception of whether joining > > how the flag's value would affect the rank calculation under the OF > > being used. By default, the G flag is set to zero given the temporary > > nature of the DAG being created. > > I disagree with the proposed resolution. It adds needless > confusion. The G flag is 0 if and only if the DODAG is floating. > There is no point to allowing floating DODAGs with a P2P-RDO > option. I suggest that the G bit be set to 1 and that routers be > explicitly prohibited from creating floating DODAGs with a > P2P-RDO option. > -Richard Kelsey > From richard.kelsey@ember.com Wed Apr 4 08:11:32 2012 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 3896F21F8650 for ; Wed, 4 Apr 2012 08:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 F6-Un9FwuSeJ for ; Wed, 4 Apr 2012 08:11:31 -0700 (PDT) Received: from p01c11o148.mxlogic.net (p01c11o148.mxlogic.net [208.65.144.71]) by ietfa.amsl.com (Postfix) with ESMTP id 94C2221F864E for ; Wed, 4 Apr 2012 08:11:31 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO p01c11o148.mxlogic.net) by p01c11o148.mxlogic.net(mxl_mta-6.13.0-3) with ESMTP id 3a46c7f4.788c2940.160822.00-533.318207.p01c11o148.mxlogic.net (envelope-from ); Wed, 04 Apr 2012 09:11:31 -0600 (MDT) X-MXL-Hash: 4f7c64a35208acd6-db09035c725abc20621606252ada5fbf935d615b Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c11o148.mxlogic.net(mxl_mta-6.13.0-3) over TLS secured channel with ESMTP id 1a46c7f4.0.160797.00-357.318147.p01c11o148.mxlogic.net (envelope-from ); Wed, 04 Apr 2012 09:11:30 -0600 (MDT) X-MXL-Hash: 4f7c64a22c44d868-6756d4f68cacf52e89ce42b65d7e23197d256b49 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.355.2; Wed, 4 Apr 2012 11:13:01 -0400 Date: Wed, 4 Apr 2012 11:10:35 -0400 Message-ID: <87sjgj8rdg.fsf@kelsey-ws.hq.ember.com> To: Mukul Goyal In-Reply-To: <1449714963.1808443.1333549906211.JavaMail.root@mail17.pantherlink.uwm.edu> (message from Mukul Goyal on Wed, 4 Apr 2012 09:31:46 -0500) From: Richard Kelsey X-Auto-Response-Suppress: DR, OOF, AutoReply References: <1449714963.1808443.1333549906211.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=u-k6GrH3DusA:10 a=saA6nF2ZJa] X-AnalysisOut: [AA:10 a=BLceEmwcHowA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=BF] X-AnalysisOut: [oovdJ-q0XCfr0W7uAA:9] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? 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, 04 Apr 2012 15:11:32 -0000 > Date: Wed, 4 Apr 2012 09:31:46 -0500 > From: Mukul Goyal > > Let me modify my statement a little: > > Transient DAGs used in P2P-RPL are floating by their very > nature. Their lifetime is fleetingly small. They are not used for > routing. They impart no connectivity to the nodes joining them. Mukul, We are talking past each other. From my point of view, grounded is the general case. A floating DODAG is created for a specific purpose, P2P routing between nodes other than the root. The fact that the P2P-RPL DAGs impart no connectivity means that they are definitely not floating. In any case, I think that the important thing is to have the P2P DODAGs all either set G to 0 or to 1. I think it should be 1, but requiring that it be 0 is better than leaving it unspecified. -Richard Kelsey From pthubert@cisco.com Wed Apr 4 09:06:22 2012 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 0B6CC21F852A for ; Wed, 4 Apr 2012 09:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.191 X-Spam-Level: X-Spam-Status: No, score=-9.191 tagged_above=-999 required=5 tests=[AWL=1.408, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVp7pTUHMWgz for ; Wed, 4 Apr 2012 09:06:21 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3006C21F887D for ; Wed, 4 Apr 2012 09:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5284; q=dns/txt; s=iport; t=1333555577; x=1334765177; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=JIWRr8UXsVuNV5si+VfYjQTVLXzwdtIdrAekU7QOu8k=; b=RTrYk9PfEa1WN4a/U/osBbMfsjcXXPgCDKOr0R+TGLdmECrdzUk60E79 y3WOt9TD5VQV68bvuD+AdWZV54RLNrUDM023uz1A7/rQTYsDC3VIsS1MQ wEytYCeCly4d6Z1iGKqAC/Y/Mx++QJK/U8j2v18SC5Lzymewl6dt3rTRd U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAClxfE+tJXHB/2dsb2JhbABFDoVAsVR/gQeCCQEBAQMBAQEBDwEQDQQ6CwUHBAIBCBEDAQEBAwIGBhcBAgICAQElHwkIAQEEEwgah2IFC5s3jQiRVQSBL44NNWMEpCqBaYIwOYFSFw X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="69033550" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 04 Apr 2012 16:06:16 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q34G6FvM010583; Wed, 4 Apr 2012 16:06:16 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, 4 Apr 2012 18:06:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 4 Apr 2012 18:05:50 +0200 Message-ID: In-Reply-To: <999546162.1808100.1333548977015.JavaMail.root@mail17.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #86: G flag: do we need that text? Thread-Index: Ac0SbZS59eKMmhFLSMy1frlEsNwO6QABjxjw References: <999546162.1808100.1333548977015.JavaMail.root@mail17.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 04 Apr 2012 16:06:15.0754 (UTC) FILETIME=[DD0E02A0:01CD127C] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? 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, 04 Apr 2012 16:06:22 -0000 TXVrdWw6DQoNCkkgdGhpbmsgd2UgZGlzYWdyZWUgYmVjYXVzZSBvZiB0aGUgZGVmaW5pdGlvbiBv ZiBnb2FsIGl0c2VsZi4gVGhlIGdvYWwgaXMgYW4gYWJzdHJhY3Rpb24uIFNhbWUgZ29lcyBmb3Ig dGhlIHRlcm0gT2JqZWN0aXZlIGluIE9GLiBSRkMgNjU1MCBvbmx5IGdpdmVzIGV4YW1wbGVzIG9m IHdoYXQgRyBjb3VsZCBiZSB1c2VkIGZvciBidXQgdGhhdCBpcyBub3QgbGltaXRpbmcuIENlcnRh aW5seSB0aGUgYWJzdHJhY3Rpb24gbWF5IGZvciBpbnN0YW5jZSBtZWFuIHRoYXQgZXh0ZXJuYWwg bm9kZXMgYXJlIHJlYWNoYWJsZSB2aWEgdGhlIHJvb3QuIEJ1dCBpdCBjb3VsZCBiZSBzb21ldGhp bmcgZWxzZSBlbnRpcmVseS4gRm9yIGluc3RhbmNlIGl0IGNvdWxkIGRlc2lnbmF0ZSBhIHJvb3Qg dGhhdCBjYW4gYWdncmVnYXRlIGRhdGEuDQoNCkluIHByYWN0aWNlLCBHIGlzIHVzZWQgdG8gZmF2 b3IgYSByb290IHRoYXQgcmVhY2hlcyB0aGUgZ29hbCB2cy4gb25lIHRoYXQgZG9lcyBub3QuIEJ1 dCB0aGF0J3Mgc2Vuc2VsZXNzIGZvciBsb2NhbCBpbnN0YW5jZXMgdGhhdCBoYXZlIGJ5IGRlZmlu aXRpb24gYSBzaW5nbGUgcm9vdC4NCg0KU28gd2hhdGV2ZXIgeW91IHNldCBpdCB0byBkb2VzIG5v dCBtYWtlIGEgZGlmZmVyZW5jZSBmb3IgUkZDIDY1NTAgb3BlcmF0aW9ucy4gSSBmaWd1cmUgaXQg Y291bGQgYmUgdXNlZCBmb3Igc2lnbmFsaW5nIGEgInRyYW5zaWVudCBnb2FsIiBpbmZvcm1hdGlv biB0byBhbiBPRiB0aGF0IGNvdWxkIHVzZSBpdCBmb3IgYSBwdXJwb3NlIEkgY2FuJ3QgZmF0aG9t Lg0KDQpJbiBhbnkgY2FzZSwgYXMgSSBzdWdnZXN0ZWQgZWFybGllciBhbmQgYXMgUmljaGFyZCBh bHNvIHN1Z2dlc3Qgbm93LCBHIFNIT1VMRCBwcm9iYWJseSBiZSAxIGJ5IGRlZmF1bHQgYnV0IE1B WSBiZSBzZXQgb3RoZXJ3aXNlLg0KDQpQYXNjYWwNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3VsQHV3bS5lZHVdIA0KU2VudDog bWVyY3JlZGkgNCBhdnJpbCAyMDEyIDE2OjE2DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0 KQ0KQ2M6IHJvbGxAaWV0Zi5vcmc7IFJpY2hhcmQgS2Vsc2V5DQpTdWJqZWN0OiBSZTogW1JvbGxd IFtyb2xsXSAjODY6IEcgZmxhZzogZG8gd2UgbmVlZCB0aGF0IHRleHQ/DQoNClBhc2NhbA0KDQo+ SWYgdGhlIGdvYWwgaXMgdG8gcmVhY2ggdGhlIHJvb3QsIHRoZW4gRyBpcyAxLi4uDQoNCkkgaGF2 ZSB0b2xkIHlvdSBtdWx0aXBsZSB0aW1lcyB0aGF0IGpvaW5pbmcgYSBQMlAtUlBMIERBRyBkb2Vz IG5vdCBnaXZlIGFueSBzb3J0IG9mIGNvbm5lY3Rpdml0eSB0byB0aGUgbm9kZS4NCg0KVGhhbmtz DQpNdWt1bA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiUGFzY2FsIFRo dWJlcnQgKHB0aHViZXJ0KSIgPHB0aHViZXJ0QGNpc2NvLmNvbT4NClRvOiAiTXVrdWwgR295YWwi IDxtdWt1bEB1d20uZWR1PiwgIlJpY2hhcmQgS2Vsc2V5IiA8cmljaGFyZC5rZWxzZXlAZW1iZXIu Y29tPg0KQ2M6IHJvbGxAaWV0Zi5vcmcNClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxMiA5 OjA1OjI4IEFNDQpTdWJqZWN0OiBSRTogW1JvbGxdIFtyb2xsXSAjODY6IEcgZmxhZzogZG8gd2Ug bmVlZCB0aGF0IHRleHQ/DQoNCkhlbGxvIE11a3VsDQoNCkZsb2F0aW5nIHZzLiBHcm91bmRlZCBk ZXBlbmRzIG9uIHRoZSBnb2FsIG9mIHRoZSBET0RBRy4gSSBhc2tlZCB5b3UgYW5kIHdpbGwgYXNr IGFnYWluIHdoYXQgaXMgeW91ciBnb2FsPw0KSWYgdGhlIGdvYWwgaXMgdG8gcmVhY2ggdGhlIHJv b3QsIHRoZW4gRyBpcyAxLi4uIElmIHlvdSB3YW50IHRvIHNpZ25hbCBzb21ldGhpbmcgdG8gdGhl IE9GIHVzaW5nIHRoZSBHIGJpdCwgbGVhdmUgaXQgIG9wZW4uDQoNCkNoZWVycywNClBhc2NhbA0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiByb2xsLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNdWt1bCBHb3lh bA0KU2VudDogbWVyY3JlZGkgNCBhdnJpbCAyMDEyIDE1OjU1DQpUbzogUmljaGFyZCBLZWxzZXkN CkNjOiByb2xsQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1JvbGxdIFtyb2xsXSAjODY6IEcgZmxh ZzogZG8gd2UgbmVlZCB0aGF0IHRleHQ/DQoNCj5UaGUgRyBmbGFnIGlzIDAgaWYgYW5kIG9ubHkg aWYgdGhlIERPREFHIGlzIGZsb2F0aW5nLg0KDQpJIHRoaW5rIHRoYXQgdGhlIEcgZmxhZyBpcyAx IGlmIGFuZCBvbmx5IGlmIHRoZSBET0RBRyBpcyBncm91bmRlZC4gVGhlIHRlbXBvcmFyeSBEQUdz IHVzZWQgaW4gUDJQLVJQTCBhcmUgbm90IGdyb3VuZGVkLCB0aGV5IGFyZSB0ZW1wb3JhcnkuIEkg dGhpbmsgdGhhdCBhbGwgdHJhbnNpZW50L3RlbXBvcmFyeSBEQUdzIGFyZSBmbG9hdGluZyBieSB0 aGVpciB2ZXJ5IG5hdHVyZS4NCg0KVGhhbmtzDQpNdWt1bA0KDQotLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tDQpGcm9tOiAiUmljaGFyZCBLZWxzZXkiIDxyaWNoYXJkLmtlbHNleUBlbWJlci5j b20+DQpUbzogcm9sbEBpZXRmLm9yZw0KQ2M6IG11a3VsQFVXTS5FRFUsIGpwdkBjaXNjby5jb20s IHJvbGxAaWV0Zi5vcmcNClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxMiA4OjM2OjUwIEFN DQpTdWJqZWN0OiBSZTogW1JvbGxdIFtyb2xsXSAjODY6IEcgZmxhZzogZG8gd2UgbmVlZCB0aGF0 IHRleHQ/DQoNCj4gRnJvbTogcm9sbCBpc3N1ZSB0cmFja2VyIDx0cmFjK3JvbGxAdHJhYy50b29s cy5pZXRmLm9yZz4NCj4gRGF0ZTogV2VkLCA0IEFwciAyMDEyIDEzOjA4OjUwICswMDAwDQo+IA0K PiAjODY6IEcgZmxhZzogZG8gd2UgbmVlZCB0aGF0IHRleHQ/DQo+IA0KPiAgUHJvYmxlbSAocmVz b2xpdGlvbiBpcyBwcm9wb3NlZCkNCj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiAgRGlzYWdyZWVtZW50IG9uIHRoZSBtZWFuaW5nIG9mICdHJyBiaXQgYW5kIGltcG9zZWQgc2V0 dGluZyB0byAwOw0KPiANCj4gIFByb3Bvc2VkIHJlc29sdXRpb24NCj4gIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiAgVGhlIG9yaWdpbiBzZXRzIHRoZSBHIGZsYWcgYmFzZWQgb24gaXRz IHBlcmNlcHRpb24gb2Ygd2hldGhlciBqb2luaW5nDQoNCj4gaG93IHRoZSBmbGFnJ3MgdmFsdWUg d291bGQgYWZmZWN0IHRoZSByYW5rIGNhbGN1bGF0aW9uIHVuZGVyIHRoZSBPRiANCj4gYmVpbmcg dXNlZC4gQnkgZGVmYXVsdCwgdGhlIEcgZmxhZyBpcyBzZXQgdG8gemVybyBnaXZlbiB0aGUgdGVt cG9yYXJ5DQoNCj4gbmF0dXJlIG9mIHRoZSBEQUcgYmVpbmcgY3JlYXRlZC4NCg0KSSBkaXNhZ3Jl ZSB3aXRoIHRoZSBwcm9wb3NlZCByZXNvbHV0aW9uLiAgSXQgYWRkcyBuZWVkbGVzcyBjb25mdXNp b24uDQpUaGUgRyBmbGFnIGlzIDAgaWYgYW5kIG9ubHkgaWYgdGhlIERPREFHIGlzIGZsb2F0aW5n Lg0KVGhlcmUgaXMgbm8gcG9pbnQgdG8gYWxsb3dpbmcgZmxvYXRpbmcgRE9EQUdzIHdpdGggYSBQ MlAtUkRPIG9wdGlvbi4gIEkgc3VnZ2VzdCB0aGF0IHRoZSBHIGJpdCBiZSBzZXQgdG8gMSBhbmQg dGhhdCByb3V0ZXJzIGJlIGV4cGxpY2l0bHkgcHJvaGliaXRlZCBmcm9tIGNyZWF0aW5nIGZsb2F0 aW5nIERPREFHcyB3aXRoIGEgUDJQLVJETyBvcHRpb24uDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC1SaWNoYXJkIEtlbHNleSBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From prvs=43413a6b9=mukul@uwm.edu Wed Apr 4 09:47:02 2012 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 89E1F21F8649 for ; Wed, 4 Apr 2012 09:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.587 X-Spam-Level: X-Spam-Status: No, score=-4.587 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 Y-kLvnT1-CUh for ; Wed, 4 Apr 2012 09:47:01 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 81F7421F8620 for ; Wed, 4 Apr 2012 09:47:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAMF6fE9/AAAB/2dsb2JhbABEhU61YwEBAQMBAQEBIEsLBQcPEQMBAQEDAg0WAwIpHwkIBhOIBAULqEyITIkFBIEvjg2BGASIWI0LkDCDBYE2Fw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 0040EE6A72; Wed, 4 Apr 2012 11:46:51 -0500 (CDT) 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 dD+tC2fawUst; Wed, 4 Apr 2012 11:46:51 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 83D04E6A8E; Wed, 4 Apr 2012 11:46:51 -0500 (CDT) Date: Wed, 4 Apr 2012 11:46:51 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1214709430.1811678.1333558011408.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.91] 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] #86: G flag: do we need that text? 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, 04 Apr 2012 16:47:02 -0000 Pascal >In any case, as I suggested earlier and as Richard also suggest now, G SHOULD probably be 1 by default but MAY be set otherwise. Richard wants the flag to always be either 0 or 1. He prefers it to be always 1 but would settle for it being always zero. I think this is not a critical point. I am OK with whatever resolution you and Richard arrive at. Kindly provide me the resolution text I should put in the draft. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: roll@ietf.org, "Richard Kelsey" Sent: Wednesday, April 4, 2012 11:05:50 AM Subject: RE: [Roll] [roll] #86: G flag: do we need that text? Mukul: I think we disagree because of the definition of goal itself. The goal is an abstraction. Same goes for the term Objective in OF. RFC 6550 only gives examples of what G could be used for but that is not limiting. Certainly the abstraction may for instance mean that external nodes are reachable via the root. But it could be something else entirely. For instance it could designate a root that can aggregate data. In practice, G is used to favor a root that reaches the goal vs. one that does not. But that's senseless for local instances that have by definition a single root. So whatever you set it to does not make a difference for RFC 6550 operations. I figure it could be used for signaling a "transient goal" information to an OF that could use it for a purpose I can't fathom. In any case, as I suggested earlier and as Richard also suggest now, G SHOULD probably be 1 by default but MAY be set otherwise. Pascal -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu] Sent: mercredi 4 avril 2012 16:16 To: Pascal Thubert (pthubert) Cc: roll@ietf.org; Richard Kelsey Subject: Re: [Roll] [roll] #86: G flag: do we need that text? Pascal >If the goal is to reach the root, then G is 1... I have told you multiple times that joining a P2P-RPL DAG does not give any sort of connectivity to the node. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Richard Kelsey" Cc: roll@ietf.org Sent: Wednesday, April 4, 2012 9:05:28 AM Subject: RE: [Roll] [roll] #86: G flag: do we need that text? Hello Mukul Floating vs. Grounded depends on the goal of the DODAG. I asked you and will ask again what is your goal? If the goal is to reach the root, then G is 1... If you want to signal something to the OF using the G bit, leave it open. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: mercredi 4 avril 2012 15:55 To: Richard Kelsey Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? >The G flag is 0 if and only if the DODAG is floating. I think that the G flag is 1 if and only if the DODAG is grounded. The temporary DAGs used in P2P-RPL are not grounded, they are temporary. I think that all transient/temporary DAGs are floating by their very nature. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: roll@ietf.org Cc: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org Sent: Wednesday, April 4, 2012 8:36:50 AM Subject: Re: [Roll] [roll] #86: G flag: do we need that text? > From: roll issue tracker > Date: Wed, 4 Apr 2012 13:08:50 +0000 > > #86: G flag: do we need that text? > > Problem (resolition is proposed) > ------------------------------ > Disagreement on the meaning of 'G' bit and imposed setting to 0; > > Proposed resolution > --------------------------- > The origin sets the G flag based on its perception of whether joining > how the flag's value would affect the rank calculation under the OF > being used. By default, the G flag is set to zero given the temporary > nature of the DAG being created. I disagree with the proposed resolution. It adds needless confusion. The G flag is 0 if and only if the DODAG is floating. There is no point to allowing floating DODAGs with a P2P-RDO option. I suggest that the G bit be set to 1 and that routers be explicitly prohibited from creating floating DODAGs with a P2P-RDO option. -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Wed Apr 4 09:28:59 2012 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 74AF521F8754 for ; Wed, 4 Apr 2012 09:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW-Pi3Gsl6hE for ; Wed, 4 Apr 2012 09:28:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8832821F8746 for ; Wed, 4 Apr 2012 09:28:58 -0700 (PDT) Received: from 10.200.181.228 (unknown [199.119.232.2]) by tuna.sandelman.ca (Postfix) with ESMTPSA id 766FF20168 for ; Wed, 4 Apr 2012 12:34:24 -0400 (EDT) Date: Wed, 04 Apr 2012 12:28:08 -0400 Message-ID: From: Michael Richardson To: roll@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Mailman-Approved-At: Wed, 04 Apr 2012 14:39:00 -0700 Subject: Re: [Roll] [roll] #86: G flag: do we need that text? 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, 04 Apr 2012 16:28:59 -0000 SSB0aGluayB3ZSBuZWVkIHRvIGRldGVybWluZSB3aGF0IGEgZ3JvdW5kZWQgRE9EQUcgaXMuCkRv ZXMgaXQgbWVhbiB0aGF0IGEgbm9kZSBhbm5vdW5jaW5nIHN1Y2ggYSB0aGluZyBpcyBhdHRhY2hl ZCB0byB0aGUgSW50ZXJuZXQ/IChJbiB3aGljaCBjYXNlIFAyUCB1c2FnZSBzaG91bGQgRz0wKQpP ciBkb2VzIGl0IG1lYW4gdGhhdCBhIG5vZGUgaXMgYXR0YWNoZWQgdG8gdGhlIHJlc291cmNlIG5h bWVkIGluIHRoZSBESU8/IChJbiB3aGljaCBjYXNlIG9yaWdpbiBQMlAgc2hvdWxkIEc9MSkKCgpS aWNoYXJkIEtlbHNleSA8cmljaGFyZC5rZWxzZXlAZW1iZXIuY29tPiB3cm90ZToKCj4+IERhdGU6 IFdlZCwgNCBBcHIgMjAxMiAwODo1NDo1MiAtMDUwMAo+PiBGcm9tOiBNdWt1bCBHb3lhbCA8bXVr dWxAdXdtLmVkdT4KPj4gCj4+ID5UaGUgRyBmbGFnIGlzIDAgaWYgYW5kIG9ubHkgaWYgdGhlIERP REFHIGlzIGZsb2F0aW5nLgo+PiAKPj4gSSB0aGluayB0aGF0IHRoZSBHIGZsYWcgaXMgMSBpZiBh bmQgb25seSBpZiB0aGUgRE9EQUcgaXMgZ3JvdW5kZWQuCj4KPkkgYWdyZWUuICBHID0gMCBtZWFu cyBmbG9hdGluZywgRyA9IDEgbWVhbnMgZ3JvdW5kZWQuCj4KPj4gVGhlIHRlbXBvcmFyeSBEQUdz IHVzZWQgaW4gUDJQLVJQTCBhcmUgbm90IGdyb3VuZGVkLCB0aGV5IGFyZQo+PiB0ZW1wb3Jhcnku IEkgdGhpbmsgdGhhdCBhbGwgdHJhbnNpZW50L3RlbXBvcmFyeSBEQUdzIGFyZQo+PiBmbG9hdGlu ZyBieSB0aGVpciB2ZXJ5IG5hdHVyZS4KPgo+VGhpcyBJIGRvbid0IGZvbGxvdyBhdCBhbGwuICBJ ZiBhIGRldmljZSBoYXMgYSB0ZW1wb3JhcnkgbmVlZCB0bwo+c2VuZCBvciByZWNlaXZlIGRhdGEg ZnJvbSBtYW55IG90aGVyIGRldmljZXMsIGl0IG1ha2VzIHBlcmZlY3QKPnNlbnNlIGZvciBpdCB0 byBjcmVhdGUgYSBhIHRlbXBvcmFyeSwgZ3JvdW5kZWQgRE9EQUcuICBJZiB0aGVyZQo+aXMgYSBs b3Qgb2YgUDJQIHRyYWZmaWMsIGl0IG1ha2VzIHBlcmZlY3Qgc2Vuc2UgdG8gaGF2ZSBwZXJtYW5l bnQsCj5mbG9hdGluZyBET0RBR3MgZm9yIHJvdXRpbmcgdGhhdCB0cmFmZmljLiAgCj4KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLVJpY2hhcmQgS2Vsc2V5Cj4KPj4g LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo+PiBGcm9tOiAiUmljaGFyZCBLZWxzZXkiIDxy aWNoYXJkLmtlbHNleUBlbWJlci5jb20+Cj4+IFRvOiByb2xsQGlldGYub3JnCj4+IENjOiBtdWt1 bEBVV00uRURVLCBqcHZAY2lzY28uY29tLCByb2xsQGlldGYub3JnCj4+IFNlbnQ6IFdlZG5lc2Rh eSwgQXByaWwgNCwgMjAxMiA4OjM2OjUwIEFNCj4+IFN1YmplY3Q6IFJlOiBbUm9sbF0gW3JvbGxd ICM4NjogRyBmbGFnOiBkbyB3ZSBuZWVkIHRoYXQgdGV4dD8KPj4gCj4+ID4gRnJvbTogcm9sbCBp c3N1ZSB0cmFja2VyIDx0cmFjK3JvbGxAdHJhYy50b29scy5pZXRmLm9yZz4KPj4gPiBEYXRlOiBX ZWQsIDQgQXByIDIwMTIgMTM6MDg6NTAgKzAwMDAKPj4gPiAKPj4gPiAjODY6IEcgZmxhZzogZG8g d2UgbmVlZCB0aGF0IHRleHQ/Cj4+ID4gCj4+ID4gIFByb2JsZW0gKHJlc29saXRpb24gaXMgcHJv cG9zZWQpCj4+ID4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+PiA+ICBEaXNhZ3Jl ZW1lbnQgb24gdGhlIG1lYW5pbmcgb2YgJ0cnIGJpdCBhbmQgaW1wb3NlZCBzZXR0aW5nIHRvIDA7 Cj4+ID4gCj4+ID4gIFByb3Bvc2VkIHJlc29sdXRpb24KPj4gPiAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCj4+ID4gIFRoZSBvcmlnaW4gc2V0cyB0aGUgRyBmbGFnIGJhc2VkIG9uIGl0cyBw ZXJjZXB0aW9uIG9mIHdoZXRoZXIgam9pbmluZwo+PiA+ICBob3cgdGhlIGZsYWcncyB2YWx1ZSB3 b3VsZCBhZmZlY3QgdGhlIHJhbmsgY2FsY3VsYXRpb24gdW5kZXIgdGhlIE9GCj4+ID4gIGJlaW5n IHVzZWQuIEJ5IGRlZmF1bHQsIHRoZSBHIGZsYWcgaXMgc2V0IHRvIHplcm8gZ2l2ZW4gdGhlIHRl bXBvcmFyeQo+PiA+ICBuYXR1cmUgb2YgdGhlIERBRyBiZWluZyBjcmVhdGVkLgo+PiAKPj4gSSBk aXNhZ3JlZSB3aXRoIHRoZSBwcm9wb3NlZCByZXNvbHV0aW9uLiAgSXQgYWRkcyBuZWVkbGVzcwo+ PiBjb25mdXNpb24uICBUaGUgRyBmbGFnIGlzIDAgaWYgYW5kIG9ubHkgaWYgdGhlIERPREFHIGlz IGZsb2F0aW5nLgo+PiBUaGVyZSBpcyBubyBwb2ludCB0byBhbGxvd2luZyBmbG9hdGluZyBET0RB R3Mgd2l0aCBhIFAyUC1SRE8KPj4gb3B0aW9uLiAgSSBzdWdnZXN0IHRoYXQgdGhlIEcgYml0IGJl IHNldCB0byAxIGFuZCB0aGF0IHJvdXRlcnMgYmUKPj4gZXhwbGljaXRseSBwcm9oaWJpdGVkIGZy b20gY3JlYXRpbmcgZmxvYXRpbmcgRE9EQUdzIHdpdGggYQo+PiBQMlAtUkRPIG9wdGlvbi4KPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtUmljaGFyZCBLZWxzZXkKPj4gCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Um9sbCBtYWls aW5nIGxpc3QKPlJvbGxAaWV0Zi5vcmcKPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbAo= From pal@cs.stanford.edu Wed Apr 4 14:48:55 2012 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 DDD9B21F8595 for ; Wed, 4 Apr 2012 14:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 V0os489no8Lo for ; Wed, 4 Apr 2012 14:48:55 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 26D6C21F8582 for ; Wed, 4 Apr 2012 14:48:55 -0700 (PDT) Received: from dn521390.sunet ([10.32.141.32]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SFY4U-0001T5-7i; Wed, 04 Apr 2012 14:48:54 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Wed, 4 Apr 2012 14:49:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Michael Richardson X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? 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, 04 Apr 2012 21:48:56 -0000 On Apr 4, 2012, at 9:28 AM, Michael Richardson wrote: > I think we need to determine what a grounded DODAG is. > Does it mean that a node announcing such a thing is attached to the = Internet? (In which case P2P usage should G=3D0) > Or does it mean that a node is attached to the resource named in the = DIO? (In which case origin P2P should G=3D1) >=20 The text in 6550 is pretty clear:=20 Goal: The Goal is an application-specific goal that is defined outside the scope of RPL. Any node that roots a DODAG will need to know about this Goal to decide whether or not the Goal can be satisfied. A typical Goal is to construct the DODAG according to a specific Objective Function and to keep connectivity to a set of hosts (e.g., to use an Objective Function that minimizes a metric and is connected to a specific database host to store the collected data). Grounded: A DODAG is grounded when the DODAG root can satisfy the Goal. Floating: A DODAG is floating if it is not grounded. A floating DODAG is not expected to have the properties required to satisfy the goal. It may, however, provide connectivity to other nodes within the DODAG. The common case of the Goal is "has connectivity to the Internet" but = that's not the only case. I think given the Goal for P2P traffic, I = agree with Pascal and Richard that it should be 1. Phil= From prvs=435672ecd=mukul@uwm.edu Wed Apr 4 22:01:22 2012 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 24E4D21F84A6 for ; Wed, 4 Apr 2012 22:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.651 X-Spam-Level: X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[AWL=0.948, 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 7cr2Lf10cwkb for ; Wed, 4 Apr 2012 22:01:21 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9E39B21F86AB for ; Wed, 4 Apr 2012 22:01:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEADgmfU9/AAAB/2dsb2JhbABFhW+2AyNWGxoCDRkCWQaIIahSiUmJCYEviV4BhCmBGASIWY0PkDODBYE2AQ Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 958472B3F11; Thu, 5 Apr 2012 00:01:17 -0500 (CDT) 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 wITwQZF0cuXg; Thu, 5 Apr 2012 00:01:17 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 558222B3F2C; Thu, 5 Apr 2012 00:01:17 -0500 (CDT) Date: Thu, 5 Apr 2012 00:01:17 -0500 (CDT) From: Mukul Goyal To: Ulrich Herberg Message-ID: <1974009367.1822935.1333602077084.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.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Scalability of P2P-RPL 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, 05 Apr 2012 05:01:22 -0000 Hi Ulrich [cedric] > > As discussed today during the meeting, numbers need to be placed given a > particular context. > So, if we put explicitly "4-5 hops" in the requirements, this has to be in > regards to the total number of nodes, the topology, the technology used, the > environment, and other numerous parameters that could justify this "4-5" > value for a particular case. [Ulrich] I am aware that the precise number of hops depends on a number of things. However, I think it should be spelled out that the draft has limitations in terms of scope and is not always applicable in general LLNs of thousands of nodes (at least that's what I infer from the talk yesterday). [Mukul] I dont think what you are suggesting is correct. P2P routes are likely to be better than global DAG based routes when origin and target are only few hops away. As the distance between origin and target increases, P2P routes are likely to be only marginally better than global-DAG-based routes (P2P routes possibly have the advantage that they avoid congested region near the DAG root). But, P2P-RPL can certainly be used in an LLN of thousands of nodes. Just limit the scope of discovery appropriately. Infact, I would argue that P2P-RPL would work very well in an LLN of thousands of nodes because: 1) you can limit the scope of discovery; 2) trickle based propagation of discovery messages allows you to control the pace of spread of discovery messages. [Cedric] > So people working over the 2.4 Ghz may use the 4-5 hops boundary, whereas > people running over sub Ghz may be happy within a single hop boundary. [Ulrich] Sure, I never doubted that depending on the link layer / the topology / the traffic patterns etc there are differences in scope. I just request to add one sentence to make it clear to the reader what the applicability of the draft is. [Mukul] The draft's applicability is certainly not restricted by the size of the network. It is reactive route discovery protocol with a great level of control over how you want to discover routes. [cedric] > > There is a section in the P2P draft that is quite generic, so applicable to > most of the use case, > and shed some light on the tradeoff regarding using > or not the P2P extension, and limit the scope of the flooding : > > A network designer may take into consideration both the benefits > (potentially better routes; > no need to maintain routes proactively) and costs (control messages > generated during the route discovery process) when using P2P-RPL. > > > We may expand this sentence to be more precise on the flooding region. > > What do you think ? [Ulrich] That can be done. But I also think that the Use Cases section should be more specific in which scenarios the draft can be used. [Mukul] What do you have in mind? The use cases section already lists the key scenarios we had in mind while designing this protocol. [cedric] > > I think numbers are always dangerous in documents that need to be frozen at > some point. [Ulrich] I do not insist on fixed numbers, I am aware that the number 4 or 5 was just named as example. But it was clear from them that the draft is limited to small-size networks ... [Mukul] I certainly object to this characterization. [Ulrich] (or at least close peers in a larger network). [Mukul] Look, there are two different questions: 1) can P2P-RPL be used to discover route to a far away target? 2) would such route be much better than the route along a global dag? The answer to first question is "absolutely yes" and that to second question is "probably not (if the root's neighborhood is not congested) and probably yes (if the root's neighborhood is congested)". Thanks Mukul From pthubert@cisco.com Wed Apr 4 23:12:56 2012 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 C792921F875C for ; Wed, 4 Apr 2012 23:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.472 X-Spam-Level: X-Spam-Status: No, score=-9.472 tagged_above=-999 required=5 tests=[AWL=1.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+AOVgmqIKYV for ; Wed, 4 Apr 2012 23:12:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4324E21F86D1 for ; Wed, 4 Apr 2012 23:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=7538; q=dns/txt; s=iport; t=1333606375; x=1334815975; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gSIYWVYI0cZdUGZIx9s3KeSaHgV6BEPQTnwFSQccKBY=; b=hyFRTEVfUjstjSvQKzNF2PRF9wv+ATtrdHOZw1/CEiStLB1cIQn0R0dR ODuq2ddRPwJ1OkWOnBRW3iXxcn6Mt2HZ1WOwu9MhnHttbS1WhNO7Oe3jQ IEGkTSwGSXVRdWafbckVPkuQImK3Z0PPUZg7wVSxaaIQEZ0eSxyCoCqb5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALM3fU+Q/khR/2dsb2JhbABDDoVusWqBAIEHggkBAQEDAQEBAQ8BEA0EOgsFBwQCAQgRAwEBAQMCBgYXAQICAgEBJR8JCAEBBBMIGodnBQufbo0IimkEgS+OCDVjBKQygWmCMDmBUhc X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="134342283" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2012 06:12:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q356ClSu032009; Thu, 5 Apr 2012 06:12:47 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); Thu, 5 Apr 2012 08:12:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 5 Apr 2012 08:11:42 +0200 Message-ID: In-Reply-To: <1214709430.1811678.1333558011408.JavaMail.root@mail17.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #86: G flag: do we need that text? Thread-Index: Ac0SgpKXQixyLHGQT+euzimfyKxiEwAbpCMA References: <1214709430.1811678.1333558011408.JavaMail.root@mail17.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 05 Apr 2012 06:12:46.0962 (UTC) FILETIME=[1EF94D20:01CD12F3] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? 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, 05 Apr 2012 06:12:56 -0000 SGVsbG8gTXVrdWw6DQoNCkkgc3VnZ2VzdCBhIHNlbnRlbmNlIHRoYXQgc2F5cyB0aGF0Og0KDQox KSBGb3IgYSBsb2NhbCBpbnN0YW5jZSB0aGVyZSBjYW4gYmUgb25seSBvbmUgcm9vdCBhbmQgb25l IERPREFHLiBHIGJpdCBjYW5ub3QgYW5kIGlzIG5vdCB1c2VkIGZvciBET0RBRyBzZWxlY3Rpb24g d2l0aGluIGFuIGluc3RhbmNlLiANCjIpIEluIGEgZ2l2ZW4gZGVwbG95bWVudCwgYSBnb2FsIGNh biBiZSBkZWZpbmVkIHRoYXQgc29tZSBQMlAgRE9EQUdzIGFjaGlldmUgYW5kIG90aGVycyBkbyBu b3QuIFRoZSByb290cyB0aGF0IGFjaGlldmUgdGhhdCBnb2FsIHdpbGwgc2V0IHRoZSBHIGJpdCBp biB0aGVpciBQMlAgREFHcy4NCjMpIHRoZSBkZWZhdWx0IGdvYWwgaXMgdG8gY3JlYXRlIGNvbm5l Y3Rpdml0eSBiZXR3ZWVuIG9yaWdpbiBhbmQgdGFyZ2V0LiBTbyBieSBkZWZhdWx0IEcgc2hvdWxk IGJlIHNldCB0byAxLg0KNCkgaWYgYW4gaW50ZXJtZWRpYXRlIHJvdXRlciBkb2VzIG5vdCBoYXZl IGVub3VnaCByZXNvdXJjZXMgdG8gcGFydGljaXBhdGUgdG8gYWxsIERPREFHcyB0aGVuIGl0IHNo b3VsZCBmYXZvciBET0RBR3Mgd2l0aCB0aGUgRyBiaXQgb24uDQoNClRoZSBleGFjdCB3b3JkaW5n IGlzIHlvdXJzLi4uDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3VsQHV3bS5lZHVdIA0KU2VudDog bWVyY3JlZGkgNCBhdnJpbCAyMDEyIDE4OjQ3DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0 KQ0KQ2M6IHJvbGxAaWV0Zi5vcmc7IFJpY2hhcmQgS2Vsc2V5DQpTdWJqZWN0OiBSZTogW1JvbGxd IFtyb2xsXSAjODY6IEcgZmxhZzogZG8gd2UgbmVlZCB0aGF0IHRleHQ/DQoNClBhc2NhbA0KDQo+ SW4gYW55IGNhc2UsIGFzIEkgc3VnZ2VzdGVkIGVhcmxpZXIgYW5kIGFzIFJpY2hhcmQgYWxzbyBz dWdnZXN0IG5vdywgRyBTSE9VTEQgcHJvYmFibHkgYmUgMSBieSBkZWZhdWx0IGJ1dCBNQVkgYmUg c2V0IG90aGVyd2lzZS4NCg0KUmljaGFyZCB3YW50cyB0aGUgZmxhZyB0byBhbHdheXMgYmUgZWl0 aGVyIDAgb3IgMS4gSGUgcHJlZmVycyBpdCB0byBiZSBhbHdheXMgMSBidXQgd291bGQgc2V0dGxl IGZvciBpdCBiZWluZyBhbHdheXMgemVyby4NCg0KSSB0aGluayB0aGlzIGlzIG5vdCBhIGNyaXRp Y2FsIHBvaW50LiBJIGFtIE9LIHdpdGggd2hhdGV2ZXIgcmVzb2x1dGlvbiB5b3UgYW5kIFJpY2hh cmQgYXJyaXZlIGF0LiBLaW5kbHkgcHJvdmlkZSBtZSB0aGUgcmVzb2x1dGlvbiB0ZXh0IEkgc2hv dWxkIHB1dCBpbiB0aGUgZHJhZnQuDQoNClRoYW5rcw0KTXVrdWwNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLQ0KRnJvbTogIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVy dEBjaXNjby5jb20+DQpUbzogIk11a3VsIEdveWFsIiA8bXVrdWxAdXdtLmVkdT4NCkNjOiByb2xs QGlldGYub3JnLCAiUmljaGFyZCBLZWxzZXkiIDxyaWNoYXJkLmtlbHNleUBlbWJlci5jb20+DQpT ZW50OiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTIgMTE6MDU6NTAgQU0NClN1YmplY3Q6IFJFOiBb Um9sbF0gW3JvbGxdICM4NjogRyBmbGFnOiBkbyB3ZSBuZWVkIHRoYXQgdGV4dD8NCg0KTXVrdWw6 DQoNCkkgdGhpbmsgd2UgZGlzYWdyZWUgYmVjYXVzZSBvZiB0aGUgZGVmaW5pdGlvbiBvZiBnb2Fs IGl0c2VsZi4gVGhlIGdvYWwgaXMgYW4gYWJzdHJhY3Rpb24uIFNhbWUgZ29lcyBmb3IgdGhlIHRl cm0gT2JqZWN0aXZlIGluIE9GLiBSRkMgNjU1MCBvbmx5IGdpdmVzIGV4YW1wbGVzIG9mIHdoYXQg RyBjb3VsZCBiZSB1c2VkIGZvciBidXQgdGhhdCBpcyBub3QgbGltaXRpbmcuIENlcnRhaW5seSB0 aGUgYWJzdHJhY3Rpb24gbWF5IGZvciBpbnN0YW5jZSBtZWFuIHRoYXQgZXh0ZXJuYWwgbm9kZXMg YXJlIHJlYWNoYWJsZSB2aWEgdGhlIHJvb3QuIEJ1dCBpdCBjb3VsZCBiZSBzb21ldGhpbmcgZWxz ZSBlbnRpcmVseS4gRm9yIGluc3RhbmNlIGl0IGNvdWxkIGRlc2lnbmF0ZSBhIHJvb3QgdGhhdCBj YW4gYWdncmVnYXRlIGRhdGEuDQoNCkluIHByYWN0aWNlLCBHIGlzIHVzZWQgdG8gZmF2b3IgYSBy b290IHRoYXQgcmVhY2hlcyB0aGUgZ29hbCB2cy4gb25lIHRoYXQgZG9lcyBub3QuIEJ1dCB0aGF0 J3Mgc2Vuc2VsZXNzIGZvciBsb2NhbCBpbnN0YW5jZXMgdGhhdCBoYXZlIGJ5IGRlZmluaXRpb24g YSBzaW5nbGUgcm9vdC4NCg0KU28gd2hhdGV2ZXIgeW91IHNldCBpdCB0byBkb2VzIG5vdCBtYWtl IGEgZGlmZmVyZW5jZSBmb3IgUkZDIDY1NTAgb3BlcmF0aW9ucy4gSSBmaWd1cmUgaXQgY291bGQg YmUgdXNlZCBmb3Igc2lnbmFsaW5nIGEgInRyYW5zaWVudCBnb2FsIiBpbmZvcm1hdGlvbiB0byBh biBPRiB0aGF0IGNvdWxkIHVzZSBpdCBmb3IgYSBwdXJwb3NlIEkgY2FuJ3QgZmF0aG9tLg0KDQpJ biBhbnkgY2FzZSwgYXMgSSBzdWdnZXN0ZWQgZWFybGllciBhbmQgYXMgUmljaGFyZCBhbHNvIHN1 Z2dlc3Qgbm93LCBHIFNIT1VMRCBwcm9iYWJseSBiZSAxIGJ5IGRlZmF1bHQgYnV0IE1BWSBiZSBz ZXQgb3RoZXJ3aXNlLg0KDQpQYXNjYWwNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3VsQHV3bS5lZHVdDQpTZW50OiBtZXJjcmVk aSA0IGF2cmlsIDIwMTIgMTY6MTYNClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpDYzog cm9sbEBpZXRmLm9yZzsgUmljaGFyZCBLZWxzZXkNClN1YmplY3Q6IFJlOiBbUm9sbF0gW3JvbGxd ICM4NjogRyBmbGFnOiBkbyB3ZSBuZWVkIHRoYXQgdGV4dD8NCg0KUGFzY2FsDQoNCj5JZiB0aGUg Z29hbCBpcyB0byByZWFjaCB0aGUgcm9vdCwgdGhlbiBHIGlzIDEuLi4NCg0KSSBoYXZlIHRvbGQg eW91IG11bHRpcGxlIHRpbWVzIHRoYXQgam9pbmluZyBhIFAyUC1SUEwgREFHIGRvZXMgbm90IGdp dmUgYW55IHNvcnQgb2YgY29ubmVjdGl2aXR5IHRvIHRoZSBub2RlLg0KDQpUaGFua3MNCk11a3Vs DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJQYXNjYWwgVGh1YmVydCAo cHRodWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPg0KVG86ICJNdWt1bCBHb3lhbCIgPG11a3Vs QHV3bS5lZHU+LCAiUmljaGFyZCBLZWxzZXkiIDxyaWNoYXJkLmtlbHNleUBlbWJlci5jb20+DQpD Yzogcm9sbEBpZXRmLm9yZw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDEyIDk6MDU6Mjgg QU0NClN1YmplY3Q6IFJFOiBbUm9sbF0gW3JvbGxdICM4NjogRyBmbGFnOiBkbyB3ZSBuZWVkIHRo YXQgdGV4dD8NCg0KSGVsbG8gTXVrdWwNCg0KRmxvYXRpbmcgdnMuIEdyb3VuZGVkIGRlcGVuZHMg b24gdGhlIGdvYWwgb2YgdGhlIERPREFHLiBJIGFza2VkIHlvdSBhbmQgd2lsbCBhc2sgYWdhaW4g d2hhdCBpcyB5b3VyIGdvYWw/DQpJZiB0aGUgZ29hbCBpcyB0byByZWFjaCB0aGUgcm9vdCwgdGhl biBHIGlzIDEuLi4gSWYgeW91IHdhbnQgdG8gc2lnbmFsIHNvbWV0aGluZyB0byB0aGUgT0YgdXNp bmcgdGhlIEcgYml0LCBsZWF2ZSBpdCAgb3Blbi4NCg0KQ2hlZXJzLA0KUGFzY2FsDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE11a3VsIEdveWFsDQpTZW50 OiBtZXJjcmVkaSA0IGF2cmlsIDIwMTIgMTU6NTUNClRvOiBSaWNoYXJkIEtlbHNleQ0KQ2M6IHJv bGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbUm9sbF0gW3JvbGxdICM4NjogRyBmbGFnOiBkbyB3 ZSBuZWVkIHRoYXQgdGV4dD8NCg0KPlRoZSBHIGZsYWcgaXMgMCBpZiBhbmQgb25seSBpZiB0aGUg RE9EQUcgaXMgZmxvYXRpbmcuDQoNCkkgdGhpbmsgdGhhdCB0aGUgRyBmbGFnIGlzIDEgaWYgYW5k IG9ubHkgaWYgdGhlIERPREFHIGlzIGdyb3VuZGVkLiBUaGUgdGVtcG9yYXJ5IERBR3MgdXNlZCBp biBQMlAtUlBMIGFyZSBub3QgZ3JvdW5kZWQsIHRoZXkgYXJlIHRlbXBvcmFyeS4gSSB0aGluayB0 aGF0IGFsbCB0cmFuc2llbnQvdGVtcG9yYXJ5IERBR3MgYXJlIGZsb2F0aW5nIGJ5IHRoZWlyIHZl cnkgbmF0dXJlLg0KDQpUaGFua3MNCk11a3VsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0NCkZyb206ICJSaWNoYXJkIEtlbHNleSIgPHJpY2hhcmQua2Vsc2V5QGVtYmVyLmNvbT4NClRv OiByb2xsQGlldGYub3JnDQpDYzogbXVrdWxAVVdNLkVEVSwganB2QGNpc2NvLmNvbSwgcm9sbEBp ZXRmLm9yZw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDEyIDg6MzY6NTAgQU0NClN1Ympl Y3Q6IFJlOiBbUm9sbF0gW3JvbGxdICM4NjogRyBmbGFnOiBkbyB3ZSBuZWVkIHRoYXQgdGV4dD8N Cg0KPiBGcm9tOiByb2xsIGlzc3VlIHRyYWNrZXIgPHRyYWMrcm9sbEB0cmFjLnRvb2xzLmlldGYu b3JnPg0KPiBEYXRlOiBXZWQsIDQgQXByIDIwMTIgMTM6MDg6NTAgKzAwMDANCj4gDQo+ICM4Njog RyBmbGFnOiBkbyB3ZSBuZWVkIHRoYXQgdGV4dD8NCj4gDQo+ICBQcm9ibGVtIChyZXNvbGl0aW9u IGlzIHByb3Bvc2VkKQ0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICBEaXNh Z3JlZW1lbnQgb24gdGhlIG1lYW5pbmcgb2YgJ0cnIGJpdCBhbmQgaW1wb3NlZCBzZXR0aW5nIHRv IDA7DQo+IA0KPiAgUHJvcG9zZWQgcmVzb2x1dGlvbg0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ICBUaGUgb3JpZ2luIHNldHMgdGhlIEcgZmxhZyBiYXNlZCBvbiBpdHMgcGVyY2Vw dGlvbiBvZiB3aGV0aGVyIGpvaW5pbmcNCg0KPiBob3cgdGhlIGZsYWcncyB2YWx1ZSB3b3VsZCBh ZmZlY3QgdGhlIHJhbmsgY2FsY3VsYXRpb24gdW5kZXIgdGhlIE9GIA0KPiBiZWluZyB1c2VkLiBC eSBkZWZhdWx0LCB0aGUgRyBmbGFnIGlzIHNldCB0byB6ZXJvIGdpdmVuIHRoZSB0ZW1wb3JhcnkN Cg0KPiBuYXR1cmUgb2YgdGhlIERBRyBiZWluZyBjcmVhdGVkLg0KDQpJIGRpc2FncmVlIHdpdGgg dGhlIHByb3Bvc2VkIHJlc29sdXRpb24uICBJdCBhZGRzIG5lZWRsZXNzIGNvbmZ1c2lvbi4NClRo ZSBHIGZsYWcgaXMgMCBpZiBhbmQgb25seSBpZiB0aGUgRE9EQUcgaXMgZmxvYXRpbmcuDQpUaGVy ZSBpcyBubyBwb2ludCB0byBhbGxvd2luZyBmbG9hdGluZyBET0RBR3Mgd2l0aCBhIFAyUC1SRE8g b3B0aW9uLiAgSSBzdWdnZXN0IHRoYXQgdGhlIEcgYml0IGJlIHNldCB0byAxIGFuZCB0aGF0IHJv dXRlcnMgYmUgZXhwbGljaXRseSBwcm9oaWJpdGVkIGZyb20gY3JlYXRpbmcgZmxvYXRpbmcgRE9E QUdzIHdpdGggYSBQMlAtUkRPIG9wdGlvbi4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLVJpY2hhcmQgS2Vsc2V5IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From trac+roll@trac.tools.ietf.org Thu Apr 5 03:59:48 2012 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 2189B21F8698 for ; Thu, 5 Apr 2012 03:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 Vq73elfHkYoH for ; Thu, 5 Apr 2012 03:59:47 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9792F21F8685 for ; Thu, 5 Apr 2012 03:59:47 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFkPl-0002H9-Ji; Thu, 05 Apr 2012 06:59:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Thu, 05 Apr 2012 10:59:40 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/91 Message-ID: <055.920233a6500cd12143f61f93f9b312dd@trac.tools.ietf.org> X-Trac-Ticket-ID: 91 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #91: Is it possible for an origin to get an error message in case the P2P-RPL route discovery fails. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 10:59:48 -0000 #91: Is it possible for an origin to get an error message in case the P2P-RPL route discovery fails. Discussion: [Cedric] On big question that rise my mind is, what happened if the route discovery fail ? Some protocols sends out an error message when the route discovery fails or get stuck. Do authors think that it could be relevant to add a "discovery-error" message as defined in other route discovery protocols ? [Mukul] I dont think it is possible to detect the failure of a P2P-RPL route discovery. No node knows if a P2P-RPL route discovery has failed. P2P-RPL forms a temporary DAG and the route discovery (well, at least the first half) succeeds when a target joins the DAG. Only the target knows whether it joined the DAG or not. So, no node knows if the (first half of the) route discovery failed. Second half involves the target sending DRO to the origin. If the DRO does not reach the origin, (the second half of) the route discovery fails. The target can ensure (or at least increase the probability of) success by asking for DRO-ACK and retransmitting the DRO if the DRO-ACK is not received within certain time duration. DRO message travels by multicast, so an intermediate router, that forwards a DRO further, has no idea whether the next hop on the route received the DRO or not. Again, no node knows if the (second half of the) there is no one to generate the discovery-error message. I think an origin might infer the route discovery to have failed, if the DAG's life time has expired but no DRO is received. But I am not sure we should mandate this to be the way failure is inferred. We have just 4 values for the DAG life time. So, I think we should leave it to origin how much to wait for a DRO before admitting failure. -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Apr 5 04:00:47 2012 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 0C42521F86A8 for ; Thu, 5 Apr 2012 04:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1LQmeNZONuv for ; Thu, 5 Apr 2012 04:00:45 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id D053421F8698 for ; Thu, 5 Apr 2012 04:00:28 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFkQW-0002k2-3E; Thu, 05 Apr 2012 07:00:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Thu, 05 Apr 2012 11:00:28 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/92 Message-ID: <055.4f67aded0ee3d83f8b18258686aba080@trac.tools.ietf.org> X-Trac-Ticket-ID: 92 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #92: Is it possible to make P2P-RPL independent of trickle algorithm X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 11:00:47 -0000 #92: Is it possible to make P2P-RPL independent of trickle algorithm Discussion: [Cedric] Another point that has been discussed today during the ROLL meeting, is that some people may find other mechanisms than trickle more efficient to flood the RDO. Could we let the door opened to other flooding optimization mechanism, or explicitly say that the trickle mechanism MUST be used ? [Mukul] I think inherent dependence on the trickle mechanism is apparent because of the fact that the route discovery takes place by forming a temporary DAG. DAG creation (or DIO generation) depends on trickle algorithm. So, P2P-RPL also depends on trickle algorithm. P2P-RPL being an extension of core RPL, I dont think there is a way to separate P2P-RPL from trickle algorithm. -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Apr 5 04:01:27 2012 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 2FB9221F85F7 for ; Thu, 5 Apr 2012 04:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 qkkSIJqM17lO for ; Thu, 5 Apr 2012 04:01:26 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9839321F85E5 for ; Thu, 5 Apr 2012 04:01:26 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFkRR-0007Mt-N0; Thu, 05 Apr 2012 07:01:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Thu, 05 Apr 2012 11:01:25 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/93 Message-ID: <055.ed950f694b72a8ba34415940cc53be68@trac.tools.ietf.org> X-Trac-Ticket-ID: 93 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 11:01:27 -0000 #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4? Resolution: Open Discussion: p12 : This specification does not allow for the establishment of hop-by- hop routes in the backward direction. [Cedric] Why ? This would enable to establish 2 routes within a single route request. Furthermore, you stipulates in the draft that links have to be bidirectional to propagates RDO, in order to be able to send back the DRO. So if I understand it correctly you ensure that you have a reliable path in both ways. Why using it in a single way only ? [Mukul] Suppose a DRO establishing a forward hop-by-hop route fails to make it to the origin. In this case, all we have is some nodes storing the hop-by-hop state for a broken route but that route is never used since the origin never gets the DRO. On the other hand, if the DRO establishing a backward hop-by-hop route fails to make it to the origin, we have a broken route that the target is likely to use (to reach the origin). So, if we want P2P-RPL to establish a backward hop-by-hop route, the target MUST ask for a DRO-ACK from the origin (to make sure that the DRO does reach the origin and hence the backward route is not broken). This can be done if you think it will be useful. We did not include this in P2P-RPL because we did not have a usecase for backward hop-by-hop routes and we wanted to avoid the additional complexity. This is how we can implement this functionality: we will let the target decide whether it wants the DRO to establish a backward hop-by-hop route. In that case: 1) the target will set a new flag, the B flag (B for backward hop-by-hop route), inside the DRO to let intermediate routers know that backward route state needs to be established as well; 2) the target will set the A flag to require a DRO-ACK from the origin; 3) the target will specify (inside a new field in the DRO), an RPLInstanceID under which the hop-by-hop state for the backward route will be stored. Note that the RPLInstanceID of the forward route (selected by the origin) may not be OK for use in backward route (because the target may have already used this RPLInstanceID for another hop-by-hop route, using different routing-metrics/constraints/OF, to the origin). When the intermediate routers receive this DRO, they will store the hop- by-hop state for the backward route. This hop-by-hop state will consist of: 1) Target address (taken from P2P-RDO inside the DRO). 2) RPLInstanceID specified by the target 3) The destination, i.e., the origin address (same as DODAGID inside the DRO). Do you want this functionality? -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Apr 5 04:01:55 2012 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 0C2CD21F85F8 for ; Thu, 5 Apr 2012 04:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 V3GdZ9ccJ66J for ; Thu, 5 Apr 2012 04:01:54 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 79D5721F86A0 for ; Thu, 5 Apr 2012 04:01:54 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFkRt-0001f8-M9; Thu, 05 Apr 2012 07:01:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Thu, 05 Apr 2012 11:01:53 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/94 Message-ID: <055.5e7958cf85282c164ccf1feb557bf9dc@trac.tools.ietf.org> X-Trac-Ticket-ID: 94 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #94: Why does DRO travel by multicast. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 11:01:55 -0000 #94: Why does DRO travel by multicast. Resolution: Because we want the stop flag in DRO to reach as many nodes as possible. Discussion: p14 : A DRO message travels from the target to the origin via link-local multicast along the route specified inside the Address vector in the P2P-RDO. [Cedric] Why using multicast if you know every destinators ? Could we unicast packets to each destinators in the address vector ? [Mukul] DRO travels by link local multicast so that the nodes, that are on the temporary DAG but not necessarily on a discovered route, may know that the route discovery is over (via the stop flag) and there is no need to generate any more DIOs. This may lead to a significant reduction in the (unnecessary) DIOs generated. Only the routers on the discovered route do the multicast-based forwarding though. -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Apr 5 04:19:01 2012 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 7978721F8738 for ; Thu, 5 Apr 2012 04:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 Ws+KXXeqNp9w for ; Thu, 5 Apr 2012 04:19:01 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DD82421F872A for ; Thu, 5 Apr 2012 04:19:00 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFkiQ-0001hA-Su; Thu, 05 Apr 2012 07:18:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Thu, 05 Apr 2012 11:18:58 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/98 Message-ID: <055.31669a0f4b146ab9900adac19f97cc84@trac.tools.ietf.org> X-Trac-Ticket-ID: 98 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #98: Who decides what metrics go in the metric container inside the Measurement Request? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 11:19:01 -0000 #98: Who decides what metrics go in the metric container inside the Measurement Request? Discussion: [Philip] The one major thing that seems to be missing in the document, however, is exactly how one populates and updates the metric container. For example, what metrics should a node put into the metric container? The metrics that the DODAG root is advertising for that RPL Instance? What happens if the network is using MRHOF and so ETX directly through Rank? The only text I can find is the last paragraph of 5.0: " Next, the router MUST update the routing metric objects, contained in the Metric Container options inside the MO, either by updating the aggregated value for the routing metric or by attaching the local values for the metric inside the object. After updating the routing metrics, the router MUST unicast the MO to the next hop." Is it that the metric container behavior is specified elsewhere? If not, then it's possible for a node meeting this document specification to do whatever it wants with the metric container. I can see a few options: 1) The originator specifies the metrics of interest and nodes update this value as they generate responses/replies. Part of the challenge here is a question of whether one is measuring the forward or reverse route, something the document should be clearer on. This has the advantage that it requires less coordination and specification with respect to RPL and OFs. It has the disadvantage that a node could request a metric the network does not support. 2) All nodes follow the metrics in DIOs. This has the advantage that the ability to handle these metrics is well defined by a RPL instance. It has the disadvantage that it requires coordinating how OFs manage metrics with path discovery. [Mukul] 1) The originator specifies the metrics of interest and nodes update this value as they generate responses/replies. Part of the challenge here is a question of whether one is measuring the forward or reverse route, something the document should be clearer on. This has the advantage that it requires less coordination and specification with respect to RPL and OFs. It has the disadvantage that a node could request a metric the network does not support. This is what we have in mind. I will make it clear in the next revision of the draft. Also, I will clarify that the route being measured is the one in forward direction (from the origin to the target) and an intermediate router MUST drop a Measurement Request if it cannot update (or add local value to) a routing metric specified inside the Metric Container. Thanks Mukul -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: applicability-ami | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Apr 5 04:19:01 2012 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 869AA21F872A for ; Thu, 5 Apr 2012 04:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 vVuPKo-a1FLT for ; Thu, 5 Apr 2012 04:19:01 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1A01D21F872E for ; Thu, 5 Apr 2012 04:19:01 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFkTD-0002JC-F9; Thu, 05 Apr 2012 07:03:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Thu, 05 Apr 2012 11:03:15 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/97 Message-ID: <055.7d6225a737a857a571e335c8e6245a84@trac.tools.ietf.org> X-Trac-Ticket-ID: 97 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #97: A fixed value for DRO_ACK_WAIT_TIME not OK for all P2P-RPL deployments. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 11:19:01 -0000 #97: A fixed value for DRO_ACK_WAIT_TIME not OK for all P2P-RPL deployments. Resolution: Make DRO_ACK_WAIT_TIME as well as MAX_DRO_RETRANSMISSIONS configurable parameters. Discussion: p25 : o DRO_ACK_WAIT_TIME: The time duration a target waits for the DRO- ACK before retransmitting a DRO message. DRO_ACK_WAIT_TIME has a value of 1 second. [Cedric] I'm not sure it is compliant with all RPL deployments. Could we adapt it to the characteristics of the network used ? [Mukul] I am OK with making DRO_ACK_WAIT_TIME as well as MAX_DRO_RETRANSMISSIONS configurable parameters. -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: applicability-ami | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Apr 5 04:19:01 2012 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 BDC9921F872A for ; Thu, 5 Apr 2012 04:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 IQ3cHWW8-RYY for ; Thu, 5 Apr 2012 04:19:01 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 494F621F8736 for ; Thu, 5 Apr 2012 04:19:01 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFkSm-0002Ih-CJ; Thu, 05 Apr 2012 07:02:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Thu, 05 Apr 2012 11:02:48 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/96 Message-ID: <055.f7a4657c0332f6393eb09f355b0158eb@trac.tools.ietf.org> X-Trac-Ticket-ID: 96 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 11:19:01 -0000 #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs? Resolution: This is purely a local decision at the target. The draft should not make any recommendation in this regard. Discussion: p21 : Example methods include selecting each route that meets the specified routing constraints until the desired number have been selected or selecting the best routes discovered over a certain time period. [Cedric] How could we know the time to wait until we get all the RDO ? Is there a way to evaluate it according to some parameters related to the network (diameter of the network for instance) ? [Mukul] This has to be a local decision. Perhaps, the target can look at the aggregated values of the routing metrics from the origin and determine its distance from the origin. This distance estimate, along with trickle parameters, could perhaps give it a better idea of how much to wait. I dont think that the draft should talk about this. -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: applicability-ami | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Apr 5 04:19:02 2012 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 0009121F872A for ; Thu, 5 Apr 2012 04:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 arprMoT1vLgJ for ; Thu, 5 Apr 2012 04:19:01 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE5321F873A for ; Thu, 5 Apr 2012 04:19:01 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFkSM-0002IA-0V; Thu, 05 Apr 2012 07:02:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Thu, 05 Apr 2012 11:02:21 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/95 Message-ID: <055.011df19dbc537f65d6ae0f3e832587d1@trac.tools.ietf.org> X-Trac-Ticket-ID: 95 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 11:19:02 -0000 #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery? Resolution: No because multiple DROs would be generated if multiple source routes are being discovered. Discussion: p15 : Stop (S): This flag, when set to one by a target, indicates that the P2P-RPL route discovery is over. [Cedric] Is this bit really usefull ? My guess is that it will be always set to 1. If you hear a DRO, this indeed means that the RDO has reached the target, so you could just stop processing RDO when you hear a DRO. Do we really need a flag to stop RDO processing or the hearing of a DRO type message could do the job ? [Mukul] A P2P-RPL invocation might involve discovery of multiple source routes. In that case, receipt of a DRO does not mean route discovery is over. Only when the target sets the stop flag in the DRO, a node could be sure that the route discovery is over. -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From prvs=435672ecd=mukul@uwm.edu Thu Apr 5 05:02:11 2012 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 4873321F879E for ; Thu, 5 Apr 2012 05:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.756 X-Spam-Level: X-Spam-Status: No, score=-5.756 tagged_above=-999 required=5 tests=[AWL=0.843, 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 NY+4iE0vIlZT for ; Thu, 5 Apr 2012 05:02:10 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 99D0F21F879B for ; Thu, 5 Apr 2012 05:02:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EANmIfU9/AAAB/2dsb2JhbABDhXy2DQEBBSNWDA8RBAEBAwINEgcCUQgZiA4LrFuJaYEhgS+OE4EYBIhZjRKBEY8jgwU Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 5B06EE6A9B; Thu, 5 Apr 2012 07:01:52 -0500 (CDT) 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 jMiFVkOHio0a; Thu, 5 Apr 2012 07:01:51 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id EC714E6A72; Thu, 5 Apr 2012 07:01:51 -0500 (CDT) Date: Thu, 5 Apr 2012 07:01:51 -0500 (CDT) From: Mukul Goyal To: roll@ietf.org Message-ID: <1978694089.1823608.1333627311894.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <055.31669a0f4b146ab9900adac19f97cc84@trac.tools.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - [unknown] (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] [roll] #98: Who decides what metrics go in the metric container inside the Measurement Request? 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, 05 Apr 2012 12:02:11 -0000 Hi Philip Can we consider this ticket resolved? Thanks Mukul ----- Original Message ----- From: "roll issue tracker" To: mukul@UWM.EDU, jpv@cisco.com Cc: roll@ietf.org Sent: Thursday, April 5, 2012 6:18:58 AM Subject: [roll] #98: Who decides what metrics go in the metric container in= side the Measurement Request? #98: Who decides what metrics go in the metric container inside the Measure= ment Request? Discussion: [Philip] The one major thing that seems to be missing in the document, however, is exactly how one populates and updates the metric container. For example, what metrics should a node put into the metric container? The metrics that the DODAG root is advertising for that RPL Instance? What happens if the network is using MRHOF and so ETX directly through Rank? The only text I can find is the last paragraph of 5.0: " Next, the router MUST update the routing metric objects, contained in the Metric Container options inside the MO, either by updating the aggregated value for the routing metric or by attaching the local values for the metric inside the object. After updating the routing metrics, the router MUST unicast the MO to the next hop." Is it that the metric container behavior is specified elsewhere? If not, then it's possible for a node meeting this document specification to do whatever it wants with the metric container. I can see a few options: 1) The originator specifies the metrics of interest and nodes update this value as they generate responses/replies. Part of the challenge here is a question of whether one is measuring the forward or reverse route, something the document should be clearer on. This has the advantage that it requires less coordination and specification with respect to RPL and OFs. It has the disadvantage that a node could request a metric the network does not support. 2) All nodes follow the metrics in DIOs. This has the advantage that the ability to handle these metrics is well defined by a RPL instance. It has the disadvantage that it requires coordinating how OFs manage metrics with path discovery. [Mukul] 1) The originator specifies the metrics of interest and nodes update this value as they generate responses/replies. Part of the challenge here is a question of whether one is measuring the forward or reverse route, something the document should be clearer on. This has the advantage that it requires less coordination and specification with respect to RPL and OFs. It has the disadvantage that a node could request a metric the network does not support. This is what we have in mind. I will make it clear in the next revision of the draft. Also, I will clarify that the route being measured is the one in forward direction (from the origin to the target) and an intermediate router MUST drop a Measurement Request if it cannot update (or add local value to) a routing metric specified inside the Metric Container. Thanks Mukul --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: applicability-ami | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From prvs=435672ecd=mukul@uwm.edu Thu Apr 5 05:09:44 2012 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 B123221F87EB for ; Thu, 5 Apr 2012 05:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.758 X-Spam-Level: X-Spam-Status: No, score=-4.758 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 Dg17NJEBTVZq for ; Thu, 5 Apr 2012 05:09:43 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1D70E21F87E4 for ; Thu, 5 Apr 2012 05:09:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAC+LfU9/AAAB/2dsb2JhbABDhXy2DQEBBSNLCwUHDxEDAQEBAwINFk0JCAYTiA6saIlqgR0EgS+PKwSIWY0SkDSDBYE2Fw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 6D0EF2B3F0D; Thu, 5 Apr 2012 07:08:27 -0500 (CDT) 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 KPr9Xdc7zYSc; Thu, 5 Apr 2012 07:08:26 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id EB89E2B3F0C; Thu, 5 Apr 2012 07:08:26 -0500 (CDT) Date: Thu, 5 Apr 2012 07:08:26 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1815328858.1823623.1333627706907.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.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - [unknown] (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? 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, 05 Apr 2012 12:09:44 -0000 Hi Pascal >1) For a local instance there can be only one root and one DODAG. G bit cannot and is not used for DODAG selection within an instance. The statement above seems to be at odds with following two statements >2) In a given deployment, a goal can be defined that some P2P DODAGs achieve and others do not. The roots that achieve that goal will set the G bit in their P2P DAGs. 3) the default goal is to create connectivity between origin and target. So by default G should be set to 1. As per statement 1, the G flag can never be 1 for P2P-RPL DAGs because they use local instance ids. As per statement 2/3, the G flag could be 1 and is 1 by default. I am OK with setting G flag to 1 always (as you, Richard and Phil seem to prefer) but I dont know how to reason this. Do we need to provide a reason at all? :) Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: roll@ietf.org, "Richard Kelsey" , "Philip Levis" Sent: Thursday, April 5, 2012 1:11:42 AM Subject: RE: [Roll] [roll] #86: G flag: do we need that text? Hello Mukul: I suggest a sentence that says that: 1) For a local instance there can be only one root and one DODAG. G bit cannot and is not used for DODAG selection within an instance. 2) In a given deployment, a goal can be defined that some P2P DODAGs achieve and others do not. The roots that achieve that goal will set the G bit in their P2P DAGs. 3) the default goal is to create connectivity between origin and target. So by default G should be set to 1. 4) if an intermediate router does not have enough resources to participate to all DODAGs then it should favor DODAGs with the G bit on. The exact wording is yours... Cheers, Pascal -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu] Sent: mercredi 4 avril 2012 18:47 To: Pascal Thubert (pthubert) Cc: roll@ietf.org; Richard Kelsey Subject: Re: [Roll] [roll] #86: G flag: do we need that text? Pascal >In any case, as I suggested earlier and as Richard also suggest now, G SHOULD probably be 1 by default but MAY be set otherwise. Richard wants the flag to always be either 0 or 1. He prefers it to be always 1 but would settle for it being always zero. I think this is not a critical point. I am OK with whatever resolution you and Richard arrive at. Kindly provide me the resolution text I should put in the draft. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: roll@ietf.org, "Richard Kelsey" Sent: Wednesday, April 4, 2012 11:05:50 AM Subject: RE: [Roll] [roll] #86: G flag: do we need that text? Mukul: I think we disagree because of the definition of goal itself. The goal is an abstraction. Same goes for the term Objective in OF. RFC 6550 only gives examples of what G could be used for but that is not limiting. Certainly the abstraction may for instance mean that external nodes are reachable via the root. But it could be something else entirely. For instance it could designate a root that can aggregate data. In practice, G is used to favor a root that reaches the goal vs. one that does not. But that's senseless for local instances that have by definition a single root. So whatever you set it to does not make a difference for RFC 6550 operations. I figure it could be used for signaling a "transient goal" information to an OF that could use it for a purpose I can't fathom. In any case, as I suggested earlier and as Richard also suggest now, G SHOULD probably be 1 by default but MAY be set otherwise. Pascal -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu] Sent: mercredi 4 avril 2012 16:16 To: Pascal Thubert (pthubert) Cc: roll@ietf.org; Richard Kelsey Subject: Re: [Roll] [roll] #86: G flag: do we need that text? Pascal >If the goal is to reach the root, then G is 1... I have told you multiple times that joining a P2P-RPL DAG does not give any sort of connectivity to the node. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Richard Kelsey" Cc: roll@ietf.org Sent: Wednesday, April 4, 2012 9:05:28 AM Subject: RE: [Roll] [roll] #86: G flag: do we need that text? Hello Mukul Floating vs. Grounded depends on the goal of the DODAG. I asked you and will ask again what is your goal? If the goal is to reach the root, then G is 1... If you want to signal something to the OF using the G bit, leave it open. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: mercredi 4 avril 2012 15:55 To: Richard Kelsey Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? >The G flag is 0 if and only if the DODAG is floating. I think that the G flag is 1 if and only if the DODAG is grounded. The temporary DAGs used in P2P-RPL are not grounded, they are temporary. I think that all transient/temporary DAGs are floating by their very nature. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: roll@ietf.org Cc: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org Sent: Wednesday, April 4, 2012 8:36:50 AM Subject: Re: [Roll] [roll] #86: G flag: do we need that text? > From: roll issue tracker > Date: Wed, 4 Apr 2012 13:08:50 +0000 > > #86: G flag: do we need that text? > > Problem (resolition is proposed) > ------------------------------ > Disagreement on the meaning of 'G' bit and imposed setting to 0; > > Proposed resolution > --------------------------- > The origin sets the G flag based on its perception of whether joining > how the flag's value would affect the rank calculation under the OF > being used. By default, the G flag is set to zero given the temporary > nature of the DAG being created. I disagree with the proposed resolution. It adds needless confusion. The G flag is 0 if and only if the DODAG is floating. There is no point to allowing floating DODAGs with a P2P-RDO option. I suggest that the G bit be set to 1 and that routers be explicitly prohibited from creating floating DODAGs with a P2P-RDO option. -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From c.chauvenet@watteco.com Thu Apr 5 06:31:40 2012 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 AD7FB21F85EF for ; Thu, 5 Apr 2012 06:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf5yJhNO-6Ed for ; Thu, 5 Apr 2012 06:31:40 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id BFD6721F85D4 for ; Thu, 5 Apr 2012 06:31:39 -0700 (PDT) Received: from mail76-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 13:31:39 +0000 Received: from mail76-va3 (localhost [127.0.0.1]) by mail76-va3-R.bigfish.com (Postfix) with ESMTP id 29E92360637; Thu, 5 Apr 2012 13:31:39 +0000 (UTC) X-SpamScore: -70 X-BigFish: VPS-70(zzc89bh15caKJzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h93fhd25h) X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail76-va3 (localhost.localdomain [127.0.0.1]) by mail76-va3 (MessageSwitch) id 1333632697312351_875; Thu, 5 Apr 2012 13:31:37 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.243]) by mail76-va3.bigfish.com (Postfix) with ESMTP id 4465A2000EC; Thu, 5 Apr 2012 13:31:37 +0000 (UTC) Received: from AMXPRD0510HT001.eurprd05.prod.outlook.com (157.56.248.181) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 13:31:36 +0000 Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.57.36]) with mapi id 14.16.0135.002; Thu, 5 Apr 2012 13:31:35 +0000 From: C Chauvenet To: "mukul@UWM.EDU" , "jpv@cisco.com" Thread-Topic: [Roll] [roll] #91: Is it possible for an origin to get an error message in case the P2P-RPL route discovery fails. Thread-Index: AQHNExs8Cb9i217zFE+hTC4RxCYWnpaMOSrw Date: Thu, 5 Apr 2012 13:31:35 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D02216366@AMXPRD0510MB390.eurprd05.prod.outlook.com> References: <055.920233a6500cd12143f61f93f9b312dd@trac.tools.ietf.org> In-Reply-To: <055.920233a6500cd12143f61f93f9b312dd@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] [roll] #91: Is it possible for an origin to get an error message in case the P2P-RPL route discovery fails. 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, 05 Apr 2012 13:31:40 -0000 DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogcm9sbC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIHJvbGwgaXNz dWUgdHJhY2tlcg0KRW52b3nDqcKgOiBqZXVkaSA1IGF2cmlsIDIwMTIgMTM6MDANCsOAwqA6IG11 a3VsQFVXTS5FRFU7IGpwdkBjaXNjby5jb20NCkNjwqA6IHJvbGxAaWV0Zi5vcmcNCk9iamV0wqA6 IFtSb2xsXSBbcm9sbF0gIzkxOiBJcyBpdCBwb3NzaWJsZSBmb3IgYW4gb3JpZ2luIHRvIGdldCBh biBlcnJvciBtZXNzYWdlIGluIGNhc2UgdGhlIFAyUC1SUEwgcm91dGUgZGlzY292ZXJ5IGZhaWxz Lg0KDQojOTE6IElzIGl0IHBvc3NpYmxlIGZvciBhbiBvcmlnaW4gdG8gZ2V0IGFuIGVycm9yIG1l c3NhZ2UgaW4gY2FzZSB0aGUgUDJQLVJQTCByb3V0ZSBkaXNjb3ZlcnkgZmFpbHMuDQoNCiBEaXNj dXNzaW9uOg0KIFtDZWRyaWNdDQogT24gYmlnIHF1ZXN0aW9uIHRoYXQgcmlzZSBteSBtaW5kIGlz LCB3aGF0IGhhcHBlbmVkIGlmIHRoZSByb3V0ZSBkaXNjb3ZlcnkgIGZhaWwgPw0KIFNvbWUgcHJv dG9jb2xzIHNlbmRzIG91dCBhbiBlcnJvciBtZXNzYWdlIHdoZW4gdGhlIHJvdXRlIGRpc2NvdmVy eSBmYWlscyAgb3IgZ2V0IHN0dWNrLg0KIERvIGF1dGhvcnMgdGhpbmsgdGhhdCBpdCBjb3VsZCBi ZSByZWxldmFudCB0byBhZGQgYSAiZGlzY292ZXJ5LWVycm9yIg0KIG1lc3NhZ2UgYXMgZGVmaW5l ZCBpbiBvdGhlciByb3V0ZSBkaXNjb3ZlcnkgcHJvdG9jb2xzID8NCg0KIFtNdWt1bF0NCiBJIGRv bnQgdGhpbmsgaXQgaXMgcG9zc2libGUgdG8gZGV0ZWN0IHRoZSBmYWlsdXJlIG9mIGEgUDJQLVJQ TCByb3V0ZSAgZGlzY292ZXJ5LiBObyBub2RlIGtub3dzIGlmIGEgUDJQLVJQTCByb3V0ZSBkaXNj b3ZlcnkgaGFzIGZhaWxlZC4NCg0KIFAyUC1SUEwgZm9ybXMgYSB0ZW1wb3JhcnkgREFHIGFuZCB0 aGUgcm91dGUgZGlzY292ZXJ5ICh3ZWxsLCBhdCBsZWFzdCB0aGUgIGZpcnN0IGhhbGYpIHN1Y2Nl ZWRzIHdoZW4gYSB0YXJnZXQgam9pbnMgdGhlIERBRy4gT25seSB0aGUgdGFyZ2V0IGtub3dzICB3 aGV0aGVyIGl0IGpvaW5lZCB0aGUgREFHIG9yIG5vdC4gU28sIG5vIG5vZGUga25vd3MgaWYgdGhl IChmaXJzdCBoYWxmIG9mDQogdGhlKSByb3V0ZSBkaXNjb3ZlcnkgZmFpbGVkLg0KDQogU2Vjb25k IGhhbGYgaW52b2x2ZXMgdGhlIHRhcmdldCBzZW5kaW5nIERSTyB0byB0aGUgb3JpZ2luLiBJZiB0 aGUgRFJPIGRvZXMgIG5vdCByZWFjaCB0aGUgb3JpZ2luLCAodGhlIHNlY29uZCBoYWxmIG9mKSB0 aGUgcm91dGUgZGlzY292ZXJ5IGZhaWxzLiBUaGUgIHRhcmdldCBjYW4gZW5zdXJlIChvciBhdCBs ZWFzdCBpbmNyZWFzZSB0aGUgcHJvYmFiaWxpdHkgb2YpIHN1Y2Nlc3MgYnkgIGFza2luZyBmb3Ig RFJPLUFDSyBhbmQgcmV0cmFuc21pdHRpbmcgdGhlIERSTyBpZiB0aGUgRFJPLUFDSyBpcyBub3Qg IHJlY2VpdmVkIHdpdGhpbiBjZXJ0YWluIHRpbWUgZHVyYXRpb24uIERSTyBtZXNzYWdlIHRyYXZl bHMgYnkgbXVsdGljYXN0LCAgc28gYW4gaW50ZXJtZWRpYXRlIHJvdXRlciwgdGhhdCBmb3J3YXJk cyBhIERSTyBmdXJ0aGVyLCBoYXMgbm8gaWRlYSAgd2hldGhlciB0aGUgbmV4dCBob3Agb24gdGhl IHJvdXRlIHJlY2VpdmVkIHRoZSBEUk8gb3Igbm90LiBBZ2Fpbiwgbm8gbm9kZSAga25vd3MgaWYg dGhlIChzZWNvbmQgaGFsZiBvZiB0aGUpIHRoZXJlIGlzIG5vIG9uZSB0byBnZW5lcmF0ZSB0aGUg IGRpc2NvdmVyeS1lcnJvciBtZXNzYWdlLg0KDQogSSB0aGluayBhbiBvcmlnaW4gbWlnaHQgaW5m ZXIgdGhlIHJvdXRlIGRpc2NvdmVyeSB0byBoYXZlIGZhaWxlZCwgaWYgdGhlICBEQUcncyBsaWZl IHRpbWUgaGFzIGV4cGlyZWQgYnV0IG5vIERSTyBpcyByZWNlaXZlZC4gQnV0IEkgYW0gbm90IHN1 cmUgd2UgIHNob3VsZCBtYW5kYXRlIHRoaXMgdG8gYmUgdGhlIHdheSBmYWlsdXJlIGlzIGluZmVy cmVkLiBXZSBoYXZlIGp1c3QgNCAgdmFsdWVzIGZvciB0aGUgREFHIGxpZmUgdGltZS4gU28sIEkg dGhpbmsgd2Ugc2hvdWxkIGxlYXZlIGl0IHRvIG9yaWdpbiBob3cgIG11Y2ggdG8gd2FpdCBmb3Ig YSBEUk8gYmVmb3JlIGFkbWl0dGluZyBmYWlsdXJlLg0KDQpbQ2VkcmljMl0NCg0KSSB3YXMgdGhp bmtpbmcgYWJvdXQgYW4gZXJyb3IgbWVzc2FnZSBpZiB0aGUgZGVsaXZlcnkgb2YgYSBtZXNzYWdl IGZhaWxzIHdoZW4gdXNpbmcgYSByb3V0ZSBlc3RhYmxpc2hlZCBieSB0aGUgUDJQLVJQTCBtZWNo YW5pc20uDQpXaGVuIGEgbm9kZSBpbmNsdWRlZCBpbiB0aGUgZGlzY292ZXJlZCByb3V0ZSBjYW5u b3QgYmUgcmVhY2hlZCwgdGhlbiBhbiBlcnJvciBtZXNzYWdlIGNvdWxkIGluaXRpYXRlIGEgbmV3 IHJvdXRlIGRpc2NvdmVyeSB1c2luZyB0aGUgUDJQLVJQTCBtZWNoYW5pc20uDQoNCg0KLS0gDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0N CiBSZXBvcnRlcjogIGpwdkDigKYgICAgICAgICAgICAgICAgICB8ICAgICAgT3duZXI6ICBtdWt1 bEDigKYNCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAgICAgICAgfCAgICAgU3RhdHVzOiAg bmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAgIHwgIE1pbGVzdG9uZToNCkNv bXBvbmVudDogIHAycC1ycGwgICAgICAgICAgICAgICAgfCAgICBWZXJzaW9uOg0KIFNldmVyaXR5 OiAgU3VibWl0dGVkIFdHIERvY3VtZW50ICB8ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDog PGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3JvbGwvdHJhYy90aWNrZXQvOTE+DQpyb2xs IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC8+DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From c.chauvenet@watteco.com Thu Apr 5 06:33:33 2012 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 01DB821F86C6 for ; Thu, 5 Apr 2012 06:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+xl69ReF9Jd for ; Thu, 5 Apr 2012 06:33:32 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53C21F86C4 for ; Thu, 5 Apr 2012 06:33:32 -0700 (PDT) Received: from mail93-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 13:33:31 +0000 Received: from mail93-va3 (localhost [127.0.0.1]) by mail93-va3-R.bigfish.com (Postfix) with ESMTP id 4C82F1A0656; Thu, 5 Apr 2012 13:33:31 +0000 (UTC) X-SpamScore: -70 X-BigFish: VPS-70(zzc89bh15caKJzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h93fhd25h) X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT002.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail93-va3 (localhost.localdomain [127.0.0.1]) by mail93-va3 (MessageSwitch) id 1333632809110535_31795; Thu, 5 Apr 2012 13:33:29 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.237]) by mail93-va3.bigfish.com (Postfix) with ESMTP id EB49E1C0155; Thu, 5 Apr 2012 13:33:28 +0000 (UTC) Received: from AMXPRD0510HT002.eurprd05.prod.outlook.com (157.56.248.181) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 13:33:26 +0000 Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT002.eurprd05.prod.outlook.com ([10.255.57.37]) with mapi id 14.16.0135.002; Thu, 5 Apr 2012 13:33:15 +0000 From: C Chauvenet To: "roll@ietf.org" , "mukul@UWM.EDU" , "jpv@cisco.com" Thread-Topic: [Roll] [roll] #92: Is it possible to make P2P-RPL independent of trickle algorithm Thread-Index: AQHNExtfOwbjn/lazkWu39jVRXfkapaMOt4A Date: Thu, 5 Apr 2012 13:33:14 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D0221638D@AMXPRD0510MB390.eurprd05.prod.outlook.com> References: <055.4f67aded0ee3d83f8b18258686aba080@trac.tools.ietf.org> In-Reply-To: <055.4f67aded0ee3d83f8b18258686aba080@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: Re: [Roll] [roll] #92: Is it possible to make P2P-RPL independent of trickle algorithm 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, 05 Apr 2012 13:33:33 -0000 U2VlIGlubGluZS4NCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiByb2xsLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQg ZGUgcm9sbCBpc3N1ZSB0cmFja2VyDQpFbnZvecOpwqA6IGpldWRpIDUgYXZyaWwgMjAxMiAxMzow MA0Kw4DCoDogbXVrdWxAVVdNLkVEVTsganB2QGNpc2NvLmNvbQ0KQ2PCoDogcm9sbEBpZXRmLm9y Zw0KT2JqZXTCoDogW1JvbGxdIFtyb2xsXSAjOTI6IElzIGl0IHBvc3NpYmxlIHRvIG1ha2UgUDJQ LVJQTCBpbmRlcGVuZGVudCBvZiB0cmlja2xlIGFsZ29yaXRobQ0KDQojOTI6IElzIGl0IHBvc3Np YmxlIHRvIG1ha2UgUDJQLVJQTCBpbmRlcGVuZGVudCBvZiB0cmlja2xlIGFsZ29yaXRobQ0KDQog RGlzY3Vzc2lvbjoNCg0KIFtDZWRyaWNdDQogQW5vdGhlciBwb2ludCB0aGF0IGhhcyBiZWVuIGRp c2N1c3NlZCB0b2RheSBkdXJpbmcgdGhlIFJPTEwgbWVldGluZywgaXMgIHRoYXQgc29tZSBwZW9w bGUgbWF5IGZpbmQgb3RoZXIgbWVjaGFuaXNtcyB0aGFuIHRyaWNrbGUgbW9yZSBlZmZpY2llbnQg dG8gIGZsb29kIHRoZSBSRE8uDQogQ291bGQgd2UgbGV0IHRoZSBkb29yIG9wZW5lZCB0byBvdGhl ciBmbG9vZGluZyBvcHRpbWl6YXRpb24gbWVjaGFuaXNtLCBvciAgZXhwbGljaXRseSBzYXkgdGhh dCB0aGUgdHJpY2tsZSBtZWNoYW5pc20gTVVTVCBiZSB1c2VkID8NCg0KIFtNdWt1bF0NCiBJIHRo aW5rIGluaGVyZW50IGRlcGVuZGVuY2Ugb24gdGhlIHRyaWNrbGUgbWVjaGFuaXNtIGlzIGFwcGFy ZW50IGJlY2F1c2UgIG9mIHRoZSBmYWN0IHRoYXQgdGhlIHJvdXRlIGRpc2NvdmVyeSB0YWtlcyBw bGFjZSBieSBmb3JtaW5nIGEgdGVtcG9yYXJ5ICBEQUcuIERBRyBjcmVhdGlvbiAob3IgRElPIGdl bmVyYXRpb24pIGRlcGVuZHMgb24gdHJpY2tsZSBhbGdvcml0aG0uIFNvLCAgUDJQLVJQTCBhbHNv IGRlcGVuZHMgb24gdHJpY2tsZSBhbGdvcml0aG0uIFAyUC1SUEwgYmVpbmcgYW4gZXh0ZW5zaW9u IG9mICBjb3JlIFJQTCwgSSBkb250IHRoaW5rIHRoZXJlIGlzIGEgd2F5IHRvIHNlcGFyYXRlIFAy UC1SUEwgZnJvbSB0cmlja2xlICBhbGdvcml0aG0uDQoNCltDZWRyaWMyXQ0KRmluZS4gSWYgdGhp cyBpcyBuZWVkZWQgZm9yIFJQTCBjb21wbGlhbmN5LCB0aGVuIEkgYWdyZWUuDQoNCi0tIA0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog UmVwb3J0ZXI6ICBqcHZA4oCmICAgICAgICAgICAgICAgICAgfCAgICAgIE93bmVyOiAgbXVrdWxA 4oCmDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czogIG5l dw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21w b25lbnQ6ICBwMnAtcnBsICAgICAgICAgICAgICAgIHwgICAgVmVyc2lvbjoNCiBTZXZlcml0eTog IFN1Ym1pdHRlZCBXRyBEb2N1bWVudCAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxo dHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9yb2xsL3RyYWMvdGlja2V0LzkyPg0Kcm9sbCA8 aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3JvbGwvPg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From prvs=435672ecd=mukul@uwm.edu Thu Apr 5 06:52:54 2012 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 E03BA21F8577 for ; Thu, 5 Apr 2012 06:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.811 X-Spam-Level: X-Spam-Status: No, score=-5.811 tagged_above=-999 required=5 tests=[AWL=0.788, 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 R306Oykljdr7 for ; Thu, 5 Apr 2012 06:52:54 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1558E21F858D for ; Thu, 5 Apr 2012 06:52:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAJ+ifU9/AAAB/2dsb2JhbABDhXy2DwUBAQEgSwsbGgINEgcCKTAGExmHdQusX4ltgSGBL44TgRgEiFmNEoERjyODBYE2Fw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 903EC2B3EF6; Thu, 5 Apr 2012 08:52:53 -0500 (CDT) 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 zXsi6fN4BOgs; Thu, 5 Apr 2012 08:52:53 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 2D2172B3F0B; Thu, 5 Apr 2012 08:52:53 -0500 (CDT) Date: Thu, 5 Apr 2012 08:52:53 -0500 (CDT) From: Mukul Goyal To: C Chauvenet Message-ID: <1248145519.1824721.1333633973075.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D02216366@AMXPRD0510MB390.eurprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.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] #91: Is it possible for an origin to get an error message in case the P2P-RPL route discovery fails. 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, 05 Apr 2012 13:52:55 -0000 #91: Is it possible for an origin to get an error message in case the P2P-R= PL route discovery fails. Discussion: [Cedric] On big question that rise my mind is, what happened if the route discovery= fail ? Some protocols sends out an error message when the route discovery fails = or get stuck. Do authors think that it could be relevant to add a "discovery-error" message as defined in other route discovery protocols ? [Mukul] I dont think it is possible to detect the failure of a P2P-RPL route disc= overy. No node knows if a P2P-RPL route discovery has failed. P2P-RPL forms a temporary DAG and the route discovery (well, at least the = first half) succeeds when a target joins the DAG. Only the target knows w= hether it joined the DAG or not. So, no node knows if the (first half of the) route discovery failed. Second half involves the target sending DRO to the origin. If the DRO does= not reach the origin, (the second half of) the route discovery fails. The= target can ensure (or at least increase the probability of) success by a= sking for DRO-ACK and retransmitting the DRO if the DRO-ACK is not receive= d within certain time duration. DRO message travels by multicast, so an in= termediate router, that forwards a DRO further, has no idea whether the ne= xt hop on the route received the DRO or not. Again, no node knows if the (= second half of the) there is no one to generate the discovery-error messag= e. I think an origin might infer the route discovery to have failed, if the = DAG's life time has expired but no DRO is received. But I am not sure we s= hould mandate this to be the way failure is inferred. We have just 4 value= s for the DAG life time. So, I think we should leave it to origin how much= to wait for a DRO before admitting failure. [Cedric2] I was thinking about an error message if the delivery of a message fails wh= en using a route established by the P2P-RPL mechanism. When a node included in the discovered route cannot be reached, then an err= or message could initiate a new route discovery using the P2P-RPL mechanism= . [Mukul2] P2P-RPL routes are used in exactly the same manner as core RPL routes, that= is you use an RPL Source Routing Header (RFC6554) or an RPL Option (RFC655= 3) to send a packet to its destination. These RFCs specify what ICMP error = messages could be generated if the route is broken. --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=435672ecd=mukul@uwm.edu Thu Apr 5 06:56:17 2012 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 491B021F8587 for ; Thu, 5 Apr 2012 06:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.877 X-Spam-Level: X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=0.722, 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 CSjd5zWkooGd for ; Thu, 5 Apr 2012 06:56:16 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9965021F8577 for ; Thu, 5 Apr 2012 06:56:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKWjfU9/AAAB/2dsb2JhbABFhW+2DQEBAQQBAQEgSwsMDxEEAQEDAg0WAwIpHwkIBhOIDguoF4lriQmBL44TgRgEiFmNEoERjyODBYE2Fw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 256EC1FD0B7; Thu, 5 Apr 2012 08:56:16 -0500 (CDT) 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 BJSZAgPXmO6u; Thu, 5 Apr 2012 08:56:15 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id C8FDE1FD0BC; Thu, 5 Apr 2012 08:56:15 -0500 (CDT) Date: Thu, 5 Apr 2012 08:56:15 -0500 (CDT) From: Mukul Goyal To: C Chauvenet Message-ID: <1865443707.1824785.1333634175774.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D0221638D@AMXPRD0510MB390.eurprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.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] #92: Is it possible to make P2P-RPL independent of trickle algorithm 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, 05 Apr 2012 13:56:17 -0000 Ticket resolved. Resolution text: P2P-RPL, being an extension of core RPL, cannot be separat= ed from trickle algorithm. Thanks Mukul=20 ----- Original Message ----- From: "C Chauvenet" To: roll@ietf.org, mukul@UWM.EDU, jpv@cisco.com Sent: Thursday, April 5, 2012 8:33:14 AM Subject: RE: [Roll] [roll] #92: Is it possible to make P2P-RPL independent = of trickle algorithm See inline. -----Message d'origine----- De=C2=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part d= e roll issue tracker Envoy=C3=A9=C2=A0: jeudi 5 avril 2012 13:00 =C3=80=C2=A0: mukul@UWM.EDU; jpv@cisco.com Cc=C2=A0: roll@ietf.org Objet=C2=A0: [Roll] [roll] #92: Is it possible to make P2P-RPL independent = of trickle algorithm #92: Is it possible to make P2P-RPL independent of trickle algorithm Discussion: [Cedric] Another point that has been discussed today during the ROLL meeting, is t= hat some people may find other mechanisms than trickle more efficient to f= lood the RDO. Could we let the door opened to other flooding optimization mechanism, or = explicitly say that the trickle mechanism MUST be used ? [Mukul] I think inherent dependence on the trickle mechanism is apparent because = of the fact that the route discovery takes place by forming a temporary DA= G. DAG creation (or DIO generation) depends on trickle algorithm. So, P2P-= RPL also depends on trickle algorithm. P2P-RPL being an extension of core = RPL, I dont think there is a way to separate P2P-RPL from trickle algorith= m. [Cedric2] Fine. If this is needed for RPL compliancy, then I agree. --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=435672ecd=mukul@uwm.edu Thu Apr 5 07:02:46 2012 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 561E921F8680 for ; Thu, 5 Apr 2012 07:02:46 -0700 (PDT) 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 mZWyk+ypwbpN for ; Thu, 5 Apr 2012 07:02:45 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9D84321F866B for ; Thu, 5 Apr 2012 07:02:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAPikfU9/AAAB/2dsb2JhbABDhXy2DQEBBSNWDA8RBAEBAwINGQJRCBmIDgusY4lugSGBL44TgRgEiFmNEoERjyODBQ Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 285191FD0C8; Thu, 5 Apr 2012 09:02:45 -0500 (CDT) 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 3LDhqB+SUzjp; Thu, 5 Apr 2012 09:02:44 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id B20211FD0C7; Thu, 5 Apr 2012 09:02:44 -0500 (CDT) Date: Thu, 5 Apr 2012 09:02:44 -0500 (CDT) From: Mukul Goyal To: roll@ietf.org Message-ID: <1018835258.1824920.1333634564656.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <055.ed950f694b72a8ba34415940cc53be68@trac.tools.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4? 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, 05 Apr 2012 14:02:46 -0000 JP This ticket should be titled differently: Why P2P-RPL cannot establish a backward hop-by-hop route? Thanks Mukul ----- Original Message ----- From: "roll issue tracker" To: mukul@UWM.EDU, jpv@cisco.com Cc: roll@ietf.org Sent: Thursday, April 5, 2012 6:01:25 AM Subject: [roll] #93: A single P2P-RPL invocation can discovery upto 4 sourc= e routes. Why 4? #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4? Resolution: Open Discussion: p12 : This specification does not allow for the establishment of hop-by- hop routes in the backward direction. [Cedric] Why ? This would enable to establish 2 routes within a single route request. Furthermore, you stipulates in the draft that links have to be bidirectional to propagates RDO, in order to be able to send back the DRO. So if I understand it correctly you ensure that you have a reliable path in both ways. Why using it in a single way only ? [Mukul] Suppose a DRO establishing a forward hop-by-hop route fails to make it to the origin. In this case, all we have is some nodes storing the hop-by-hop state for a broken route but that route is never used since the origin never gets the DRO. On the other hand, if the DRO establishing a backward hop-by-hop route fails to make it to the origin, we have a broken route that the target is likely to use (to reach the origin). So, if we want P2P-RPL to establish a backward hop-by-hop route, the target MUST ask for a DRO-ACK from the origin (to make sure that the DRO does reach the origin and hence the backward route is not broken). This can be done if you think it will be useful. We did not include this in P2P-RPL because we did not have a usecase for backward hop-by-hop routes and we wanted to avoid the additional complexity. This is how we can implement this functionality: we will let the target decide whether it wants the DRO to establish a backward hop-by-hop route. In that case: 1) the target will set a new flag, the B flag (B for backward hop-by-hop route), inside the DRO to let intermediate routers know that backward route state needs to be established as well; 2) the target will set the A flag to require a DRO-ACK from the origin; 3) the target will specify (inside a new field in the DRO), an RPLInstanceID under which the hop-by-hop state for the backward route will be stored. Note that the RPLInstanceID of the forward route (selected by the origin) may not be OK for use in backward route (because the target may have already used this RPLInstanceID for another hop-by-hop route, using different routing-metrics/constraints/OF, to the origin). When the intermediate routers receive this DRO, they will store the hop- by-hop state for the backward route. This hop-by-hop state will consist of: 1) Target address (taken from P2P-RDO inside the DRO). 2) RPLInstanceID specified by the target 3) The destination, i.e., the origin address (same as DODAGID inside the DRO). Do you want this functionality? --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From c.chauvenet@watteco.com Thu Apr 5 07:17:35 2012 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 24BBF21F8749 for ; Thu, 5 Apr 2012 07:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6q4iPrX-NgG for ; Thu, 5 Apr 2012 07:17:34 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 10A1621F8748 for ; Thu, 5 Apr 2012 07:17:33 -0700 (PDT) Received: from mail107-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 14:17:33 +0000 Received: from mail107-va3 (localhost [127.0.0.1]) by mail107-va3-R.bigfish.com (Postfix) with ESMTP id 5E17B1E03AE; Thu, 5 Apr 2012 14:17:33 +0000 (UTC) X-SpamScore: -70 X-BigFish: VPS-70(zzc89bh15caKJzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h93fhd25h) X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail107-va3 (localhost.localdomain [127.0.0.1]) by mail107-va3 (MessageSwitch) id 1333635449945212_28484; Thu, 5 Apr 2012 14:17:29 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.238]) by mail107-va3.bigfish.com (Postfix) with ESMTP id C8E50A0097; Thu, 5 Apr 2012 14:17:29 +0000 (UTC) Received: from AMXPRD0510HT005.eurprd05.prod.outlook.com (157.56.248.181) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 14:17:23 +0000 Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.57.40]) with mapi id 14.16.0135.002; Thu, 5 Apr 2012 14:17:21 +0000 From: C Chauvenet To: "mukul@UWM.EDU" Thread-Topic: [Roll] [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4? Thread-Index: AQHNExt2WB0Ei/9t6USXDGCl+MKLpJaMPEqw Date: Thu, 5 Apr 2012 14:17:21 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D02216532@AMXPRD0510MB390.eurprd05.prod.outlook.com> References: <055.ed950f694b72a8ba34415940cc53be68@trac.tools.ietf.org> In-Reply-To: <055.ed950f694b72a8ba34415940cc53be68@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4? 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, 05 Apr 2012 14:17:35 -0000 aW5saW5lDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogcm9sbC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIHJv bGwgaXNzdWUgdHJhY2tlcg0KRW52b3nDqcKgOiBqZXVkaSA1IGF2cmlsIDIwMTIgMTM6MDENCsOA wqA6IG11a3VsQFVXTS5FRFU7IGpwdkBjaXNjby5jb20NCkNjwqA6IHJvbGxAaWV0Zi5vcmcNCk9i amV0wqA6IFtSb2xsXSBbcm9sbF0gIzkzOiBBIHNpbmdsZSBQMlAtUlBMIGludm9jYXRpb24gY2Fu IGRpc2NvdmVyeSB1cHRvIDQgc291cmNlIHJvdXRlcy4gV2h5IDQ/DQoNCiM5MzogQSBzaW5nbGUg UDJQLVJQTCBpbnZvY2F0aW9uIGNhbiBkaXNjb3ZlcnkgdXB0byA0IHNvdXJjZSByb3V0ZXMuIFdo eSA0Pw0KDQogUmVzb2x1dGlvbjogT3Blbg0KDQogRGlzY3Vzc2lvbjoNCg0KIHAxMiA6ICBUaGlz IHNwZWNpZmljYXRpb24gZG9lcyBub3QgYWxsb3cgZm9yIHRoZSBlc3RhYmxpc2htZW50IG9mIGhv cC1ieS0gIGhvcCByb3V0ZXMgaW4gdGhlIGJhY2t3YXJkIGRpcmVjdGlvbi4NCg0KIFtDZWRyaWNd DQogV2h5ID8gVGhpcyB3b3VsZCBlbmFibGUgdG8gZXN0YWJsaXNoIDIgcm91dGVzIHdpdGhpbiBh IHNpbmdsZSByb3V0ZSAgcmVxdWVzdC4NCiBGdXJ0aGVybW9yZSwgeW91IHN0aXB1bGF0ZXMgaW4g dGhlIGRyYWZ0IHRoYXQgbGlua3MgaGF2ZSB0byBiZSAgYmlkaXJlY3Rpb25hbCB0byBwcm9wYWdh dGVzIFJETywgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBzZW5kIGJhY2sgdGhlIERSTy4NCiBTbyBp ZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5IHlvdSBlbnN1cmUgdGhhdCB5b3UgaGF2ZSBhIHJl bGlhYmxlIHBhdGggIGluIGJvdGggd2F5cy4gV2h5IHVzaW5nIGl0IGluIGEgc2luZ2xlIHdheSBv bmx5ID8NCg0KIFtNdWt1bF0NCiBTdXBwb3NlIGEgRFJPIGVzdGFibGlzaGluZyBhIGZvcndhcmQg aG9wLWJ5LWhvcCByb3V0ZSBmYWlscyB0byBtYWtlIGl0IHRvICB0aGUgb3JpZ2luLiBJbiB0aGlz IGNhc2UsIGFsbCB3ZSBoYXZlIGlzIHNvbWUgbm9kZXMgc3RvcmluZyB0aGUgaG9wLWJ5LWhvcCAg c3RhdGUgZm9yIGEgYnJva2VuIHJvdXRlIGJ1dCB0aGF0IHJvdXRlIGlzIG5ldmVyIHVzZWQgc2lu Y2UgdGhlIG9yaWdpbiAgbmV2ZXIgZ2V0cyB0aGUgRFJPLiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYg dGhlIERSTyBlc3RhYmxpc2hpbmcgYSBiYWNrd2FyZCAgaG9wLWJ5LWhvcCByb3V0ZSBmYWlscyB0 byBtYWtlIGl0IHRvIHRoZSBvcmlnaW4sIHdlIGhhdmUgYSBicm9rZW4gcm91dGUgIHRoYXQgdGhl IHRhcmdldCBpcyBsaWtlbHkgdG8gdXNlICh0byByZWFjaCB0aGUgb3JpZ2luKS4gU28sIGlmIHdl IHdhbnQgIFAyUC1SUEwgdG8gZXN0YWJsaXNoIGEgYmFja3dhcmQgaG9wLWJ5LWhvcCByb3V0ZSwg dGhlIHRhcmdldCBNVVNUIGFzayBmb3IgIGEgRFJPLUFDSyBmcm9tIHRoZSBvcmlnaW4gKHRvIG1h a2Ugc3VyZSB0aGF0IHRoZSBEUk8gZG9lcyByZWFjaCB0aGUgb3JpZ2luICBhbmQgaGVuY2UgdGhl IGJhY2t3YXJkIHJvdXRlIGlzIG5vdCBicm9rZW4pLiBUaGlzIGNhbiBiZSBkb25lIGlmIHlvdSB0 aGluayAgaXQgd2lsbCBiZSB1c2VmdWwuIFdlIGRpZCBub3QgaW5jbHVkZSB0aGlzIGluIFAyUC1S UEwgYmVjYXVzZSB3ZSBkaWQgbm90ICBoYXZlIGEgdXNlY2FzZSBmb3IgYmFja3dhcmQgaG9wLWJ5 LWhvcCByb3V0ZXMgYW5kIHdlIHdhbnRlZCB0byBhdm9pZCB0aGUgIGFkZGl0aW9uYWwgY29tcGxl eGl0eS4NCg0KIFRoaXMgaXMgaG93IHdlIGNhbiBpbXBsZW1lbnQgdGhpcyBmdW5jdGlvbmFsaXR5 OiB3ZSB3aWxsIGxldCB0aGUgdGFyZ2V0ICBkZWNpZGUgd2hldGhlciBpdCB3YW50cyB0aGUgRFJP IHRvIGVzdGFibGlzaCBhIGJhY2t3YXJkIGhvcC1ieS1ob3Agcm91dGUuDQogSW4gdGhhdCBjYXNl Og0KIDEpIHRoZSB0YXJnZXQgd2lsbCBzZXQgYSBuZXcgZmxhZywgdGhlIEIgZmxhZyAoQiBmb3Ig YmFja3dhcmQgaG9wLWJ5LWhvcCAgcm91dGUpLCBpbnNpZGUgdGhlIERSTyB0byBsZXQgaW50ZXJt ZWRpYXRlIHJvdXRlcnMga25vdyB0aGF0IGJhY2t3YXJkICByb3V0ZSBzdGF0ZSBuZWVkcyB0byBi ZSBlc3RhYmxpc2hlZCBhcyB3ZWxsOw0KIDIpIHRoZSB0YXJnZXQgd2lsbCBzZXQgdGhlIEEgZmxh ZyB0byByZXF1aXJlIGEgRFJPLUFDSyBmcm9tIHRoZSBvcmlnaW47DQogMykgdGhlIHRhcmdldCB3 aWxsIHNwZWNpZnkgKGluc2lkZSBhIG5ldyBmaWVsZCBpbiB0aGUgRFJPKSwgYW4gIFJQTEluc3Rh bmNlSUQgdW5kZXIgd2hpY2ggdGhlIGhvcC1ieS1ob3Agc3RhdGUgZm9yIHRoZSBiYWNrd2FyZCBy b3V0ZSB3aWxsICBiZSBzdG9yZWQuIE5vdGUgdGhhdCB0aGUgUlBMSW5zdGFuY2VJRCBvZiB0aGUg Zm9yd2FyZCByb3V0ZSAoc2VsZWN0ZWQgYnkgIHRoZSBvcmlnaW4pIG1heSBub3QgYmUgT0sgZm9y IHVzZSBpbiBiYWNrd2FyZCByb3V0ZSAoYmVjYXVzZSB0aGUgdGFyZ2V0ICBtYXkgaGF2ZSBhbHJl YWR5IHVzZWQgdGhpcyBSUExJbnN0YW5jZUlEIGZvciBhbm90aGVyIGhvcC1ieS1ob3Agcm91dGUs ICB1c2luZyBkaWZmZXJlbnQgcm91dGluZy1tZXRyaWNzL2NvbnN0cmFpbnRzL09GLCB0byB0aGUg b3JpZ2luKS4NCiBXaGVuIHRoZSBpbnRlcm1lZGlhdGUgcm91dGVycyByZWNlaXZlIHRoaXMgRFJP LCB0aGV5IHdpbGwgc3RvcmUgdGhlIGhvcC0gIGJ5LWhvcCBzdGF0ZSBmb3IgdGhlIGJhY2t3YXJk IHJvdXRlLiBUaGlzIGhvcC1ieS1ob3Agc3RhdGUgd2lsbCBjb25zaXN0DQogb2Y6DQogMSkgVGFy Z2V0IGFkZHJlc3MgKHRha2VuIGZyb20gUDJQLVJETyBpbnNpZGUgdGhlIERSTykuDQogMikgUlBM SW5zdGFuY2VJRCBzcGVjaWZpZWQgYnkgdGhlIHRhcmdldA0KIDMpIFRoZSBkZXN0aW5hdGlvbiwg aS5lLiwgdGhlIG9yaWdpbiBhZGRyZXNzIChzYW1lIGFzIERPREFHSUQgaW5zaWRlIHRoZSAgRFJP KS4NCg0KIERvIHlvdSB3YW50IHRoaXMgZnVuY3Rpb25hbGl0eT8NCg0KW0NlZHJpYzJdIA0KVGhl IGdyb3VwIGhhcyB0byBkaXNjdXNzIGFuZCBkZWNpZGUgd2V0aGVyIGl0IGlzIHVzZWZ1bGwgb3Ig bm90LiBJIHBlcnNvbm5hbHkgdGhpbmsgdGhhdCBSUEwtUDJQIGRyYWZ0IG1heSBiZSB1c2VkIGZv ciBiaW5kaW5nIGRldmljZXMsIHNvIGl0IGNvdWxkIGJlIHZhbHVhYmxlIHRvIGNyZWF0ZSBhIDIg d2F5IHBhdGggYmV0d2VlbiB0aGUgb3JpZ2luIGFuZCB0aGUgdGFyZ2V0LiBTbyBJIHdvdWxkIHZv dGUgaW4gZmF2b3Igb2Ygc3VjaCBhIG1lY2hhbmlzbS4gDQpUaG91Z2gsIEkgZG9uJ3QgdGhpbmsg d2Ugc2hvdWxkIGNyZWF0ZSBhIG5ldyBEQUcgKGkuZS4gc2VsZWN0IGEgbmV3IFJQTEluc3RhbmNl SUQpIGZvciB0aGUgYmFja3dhcmQgcm91dGUuIFdoYXQgSSB3b3VsZCBsaWtlIGlzIGp1c3QgdGhl IGFiaWxpdHkgZm9yIDIgZGV2aWNlcyB0byBleGNoYW5nZSBwYWNrZXQgaW4gYm90aCB3YXlzIHVz aW5nIHRoZSBzYW1lIHRlbXBvcmFyeSBEQUcgY3JlYXRlZCBieSBSUEwtUDJQLiBMZXQgbWUgZXhw bGFpbiB0aGUgdXNlIGNhc2Ugd2l0aCBhbiBleGFtcGxlIDogRm9yIGluc3RhbmNlLCBpZiB5b3Ug aGF2ZSBub2RlcyBkZXBsb3llZCBpbiBhIGJ1aWxkaW5nIG9yIGEgY2l0eSwgYW5kIHlvdSB3YW50 IHRvIGNvbmZpZ3VyZSBzb21lIG9mIHRoZW0uIEFuIG9wZXJhdG9yIGNvdWxkIGdvIGluIHRoZSBh cmVhIHdoZXJlIGRldmljZXMgdG8gYmUgcHJvZ3JhbW1lZCBhcmUgaW5zdGFsbGVkIChvciBpbiB0 aGUgbmVpZ2hib3Job29kIGF0IGxlYXN0KSB3aXRoIGEgImNvbmZpZ3VyYXRvciBub2RlIiwgYW5k IG5lZWQgdG8gZXN0YWJsaXNoZWQgYSBQMlAgcm91dGUgYmV0d2VlbiB0aGlzIGNvbmZpZ3VyYXRv ciBub2RlIGFuZCB0aGUgbm9kZShzKSB0byBiZSBjb25maWd1cmF0ZWQuIFRoZXkgY3JlYXRlIGEg dGVtcG9yYXJ5IERBRyAocG9zc2libHkgdGhyb3VnaCBzZXZlcmFsIGhvcHMpIGFuZCBleGNoYW5n ZSBjb25maWd1cmF0aW9uIGZyYW1lcy4gQmVjYXVzZSBzdWNoIG1lc3NhZ2VzIGFyZSAgY3JpdGlj YWxseSBpbXBvcnRhbnQsIHlvdSBvZnRlbiBuZWVkIGFwcGxpY2F0aW9uIGxheWVyIGFja25vd2xl ZGdtZW50cywgc28gYSBiYWNrd2FyZCByb3V0ZSBpcyBuZWVkZWQuDQpJcyB0aGUgYWN0dWFsIHNw ZWNpZmljYXRpb24gY29tcGxpYW50IHdpdGggc3VjaCBhIHVzZSBjYXNlIHdpdGhvdXQgbW9kaWZp Y2F0aW9uID8gKHVzaW5nIHBpZ2d5YmFja2VkIERBVEEgaW5zaWRlIFJETyBhbmQgRFJPIG1lc3Nh Z2VzKSA/IE9yIGRvIHdlZSBuZWVkIGFuIGFkZGl0aW9uYWwgbWVjaGFuaXNtIHN1Y2ggYXMgdGhl IG9uZSB5b3UgZGVzY3JpYmVkID8NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGpwdkDigKYgICAgICAg ICAgICAgICAgICB8ICAgICAgT3duZXI6ICBtdWt1bEDigKYNCiAgICAgVHlwZTogIGRlZmVjdCAg ICAgICAgICAgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAg ICAgICAgICAgICAgIHwgIE1pbGVzdG9uZToNCkNvbXBvbmVudDogIHAycC1ycGwgICAgICAgICAg ICAgICAgfCAgICBWZXJzaW9uOg0KIFNldmVyaXR5OiAgU3VibWl0dGVkIFdHIERvY3VtZW50ICB8 ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L3dnL3JvbGwvdHJhYy90aWNrZXQvOTM+DQpyb2xsIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cv cm9sbC8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From c.chauvenet@watteco.com Thu Apr 5 07:20:17 2012 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 5BE0F21F8760 for ; Thu, 5 Apr 2012 07:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kJEnjETc8ME for ; Thu, 5 Apr 2012 07:20:16 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id CB9C521F8753 for ; Thu, 5 Apr 2012 07:20:15 -0700 (PDT) Received: from mail116-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 14:20:14 +0000 Received: from mail116-ch1 (localhost [127.0.0.1]) by mail116-ch1-R.bigfish.com (Postfix) with ESMTP id 5D9DC360508; Thu, 5 Apr 2012 14:20:14 +0000 (UTC) X-SpamScore: -70 X-BigFish: VPS-70(zzc89bh15caKJzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h93fhd25h) X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT002.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail116-ch1 (localhost.localdomain [127.0.0.1]) by mail116-ch1 (MessageSwitch) id 1333635610998073_17723; Thu, 5 Apr 2012 14:20:10 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail116-ch1.bigfish.com (Postfix) with ESMTP id E55174E011C; Thu, 5 Apr 2012 14:20:10 +0000 (UTC) Received: from AMXPRD0510HT002.eurprd05.prod.outlook.com (157.56.248.181) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 14:20:09 +0000 Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT002.eurprd05.prod.outlook.com ([10.255.57.37]) with mapi id 14.16.0135.002; Thu, 5 Apr 2012 14:20:08 +0000 From: C Chauvenet To: "mukul@UWM.EDU" Thread-Topic: [Roll] [roll] #94: Why does DRO travel by multicast. Thread-Index: AQHNExuHIbYVUv+ic02NsuQ750a+6JaMR9tQ Date: Thu, 5 Apr 2012 14:20:08 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D022165B2@AMXPRD0510MB390.eurprd05.prod.outlook.com> References: <055.5e7958cf85282c164ccf1feb557bf9dc@trac.tools.ietf.org> In-Reply-To: <055.5e7958cf85282c164ccf1feb557bf9dc@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] [roll] #94: Why does DRO travel by multicast. 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, 05 Apr 2012 14:20:17 -0000 DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogcm9sbC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIHJvbGwgaXNz dWUgdHJhY2tlcg0KRW52b3nDqcKgOiBqZXVkaSA1IGF2cmlsIDIwMTIgMTM6MDINCsOAwqA6IG11 a3VsQFVXTS5FRFU7IGpwdkBjaXNjby5jb20NCkNjwqA6IHJvbGxAaWV0Zi5vcmcNCk9iamV0wqA6 IFtSb2xsXSBbcm9sbF0gIzk0OiBXaHkgZG9lcyBEUk8gdHJhdmVsIGJ5IG11bHRpY2FzdC4NCg0K Izk0OiBXaHkgZG9lcyBEUk8gdHJhdmVsIGJ5IG11bHRpY2FzdC4NCg0KIFJlc29sdXRpb246IEJl Y2F1c2Ugd2Ugd2FudCB0aGUgc3RvcCBmbGFnIGluIERSTyB0byByZWFjaCBhcyBtYW55IG5vZGVz IGFzICBwb3NzaWJsZS4NCg0KIERpc2N1c3Npb246DQoNCiBwMTQgOiAgQSBEUk8gbWVzc2FnZSB0 cmF2ZWxzIGZyb20gdGhlIHRhcmdldCB0byB0aGUgb3JpZ2luIHZpYSBsaW5rLWxvY2FsICBtdWx0 aWNhc3QgYWxvbmcgdGhlDQogICByb3V0ZSBzcGVjaWZpZWQgaW5zaWRlIHRoZSBBZGRyZXNzIHZl Y3RvciBpbiB0aGUgUDJQLVJETy4NCg0KIFtDZWRyaWNdDQogV2h5IHVzaW5nIG11bHRpY2FzdCBp ZiB5b3Uga25vdyBldmVyeSBkZXN0aW5hdG9ycyA/DQogQ291bGQgd2UgdW5pY2FzdCBwYWNrZXRz IHRvIGVhY2ggZGVzdGluYXRvcnMgaW4gdGhlIGFkZHJlc3MgdmVjdG9yID8NCg0KIFtNdWt1bF0N CiBEUk8gdHJhdmVscyBieSBsaW5rIGxvY2FsIG11bHRpY2FzdCBzbyB0aGF0IHRoZSBub2Rlcywg dGhhdCBhcmUgb24gdGhlICB0ZW1wb3JhcnkgREFHIGJ1dCBub3QgbmVjZXNzYXJpbHkgb24gYSBk aXNjb3ZlcmVkIHJvdXRlLCBtYXkga25vdyB0aGF0IHRoZSAgcm91dGUgZGlzY292ZXJ5IGlzIG92 ZXIgKHZpYSB0aGUgc3RvcCBmbGFnKSBhbmQgdGhlcmUgaXMgbm8gbmVlZCB0byAgZ2VuZXJhdGUg YW55IG1vcmUgRElPcy4gVGhpcyBtYXkgbGVhZCB0byBhIHNpZ25pZmljYW50IHJlZHVjdGlvbiBp biB0aGUNCiAodW5uZWNlc3NhcnkpIERJT3MgZ2VuZXJhdGVkLiBPbmx5IHRoZSByb3V0ZXJzIG9u IHRoZSBkaXNjb3ZlcmVkIHJvdXRlIGRvICB0aGUgbXVsdGljYXN0LWJhc2VkIGZvcndhcmRpbmcg dGhvdWdoLg0KDQpbQ2VkcmljMl0NCk1ha2VzIHNlbnNlLCB0aGFuaydzIGZvciBjbGFyaWZpY2F0 aW9uLg0KVGhpcyB0aWNrZXQgY2FuIGJlIGNsb3NlZC4NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGpw dkDigKYgICAgICAgICAgICAgICAgICB8ICAgICAgT3duZXI6ICBtdWt1bEDigKYNCiAgICAgVHlw ZTogIGRlZmVjdCAgICAgICAgICAgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6 ICBtYWpvciAgICAgICAgICAgICAgICAgIHwgIE1pbGVzdG9uZToNCkNvbXBvbmVudDogIHAycC1y cGwgICAgICAgICAgICAgICAgfCAgICBWZXJzaW9uOg0KIFNldmVyaXR5OiAgU3VibWl0dGVkIFdH IERvY3VtZW50ICB8ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL3dnL3JvbGwvdHJhYy90aWNrZXQvOTQ+DQpyb2xsIDxodHRwOi8vdG9vbHMu aWV0Zi5vcmcvd2cvcm9sbC8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From c.chauvenet@watteco.com Thu Apr 5 07:21:48 2012 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 2346721F8718 for ; Thu, 5 Apr 2012 07:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osy7XLMo6Wvm for ; Thu, 5 Apr 2012 07:21:47 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6BC21F86F8 for ; Thu, 5 Apr 2012 07:21:46 -0700 (PDT) Received: from mail89-am1-R.bigfish.com (10.3.201.230) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 14:21:45 +0000 Received: from mail89-am1 (localhost [127.0.0.1]) by mail89-am1-R.bigfish.com (Postfix) with ESMTP id CCDAEC0231; Thu, 5 Apr 2012 14:21:45 +0000 (UTC) X-SpamScore: -70 X-BigFish: VPS-70(zzc89bh15caKJzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h93fhd25h) X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail89-am1 (localhost.localdomain [127.0.0.1]) by mail89-am1 (MessageSwitch) id 1333635703124826_2024; Thu, 5 Apr 2012 14:21:43 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.230]) by mail89-am1.bigfish.com (Postfix) with ESMTP id 0E6C934024A; Thu, 5 Apr 2012 14:21:43 +0000 (UTC) Received: from AMXPRD0510HT001.eurprd05.prod.outlook.com (157.56.248.181) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 14:21:39 +0000 Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.57.36]) with mapi id 14.16.0135.002; Thu, 5 Apr 2012 14:21:38 +0000 From: C Chauvenet To: "roll@ietf.org" , "mukul@UWM.EDU" , "jpv@cisco.com" Thread-Topic: [Roll] [roll] #97: A fixed value for DRO_ACK_WAIT_TIME not OK for all P2P-RPL deployments. Thread-Index: AQHNEx3w0k66UUklrEm6B1XcZtEnzJaMSGNA Date: Thu, 5 Apr 2012 14:21:38 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D022165D6@AMXPRD0510MB390.eurprd05.prod.outlook.com> References: <055.7d6225a737a857a571e335c8e6245a84@trac.tools.ietf.org> In-Reply-To: <055.7d6225a737a857a571e335c8e6245a84@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: Re: [Roll] [roll] #97: A fixed value for DRO_ACK_WAIT_TIME not OK for all P2P-RPL 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: Thu, 05 Apr 2012 14:21:48 -0000 DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogcm9sbC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIHJvbGwgaXNz dWUgdHJhY2tlcg0KRW52b3nDqcKgOiBqZXVkaSA1IGF2cmlsIDIwMTIgMTM6MDMNCsOAwqA6IG11 a3VsQFVXTS5FRFU7IGpwdkBjaXNjby5jb20NCkNjwqA6IHJvbGxAaWV0Zi5vcmcNCk9iamV0wqA6 IFtSb2xsXSBbcm9sbF0gIzk3OiBBIGZpeGVkIHZhbHVlIGZvciBEUk9fQUNLX1dBSVRfVElNRSBu b3QgT0sgZm9yIGFsbCBQMlAtUlBMIGRlcGxveW1lbnRzLg0KDQojOTc6IEEgZml4ZWQgdmFsdWUg Zm9yIERST19BQ0tfV0FJVF9USU1FIG5vdCBPSyBmb3IgYWxsIFAyUC1SUEwgZGVwbG95bWVudHMu DQoNCiBSZXNvbHV0aW9uOiBNYWtlIERST19BQ0tfV0FJVF9USU1FIGFzIHdlbGwgYXMgTUFYX0RS T19SRVRSQU5TTUlTU0lPTlMgIGNvbmZpZ3VyYWJsZSBwYXJhbWV0ZXJzLg0KDQogRGlzY3Vzc2lv bjoNCg0KIHAyNSA6ICBvIERST19BQ0tfV0FJVF9USU1FOiBUaGUgdGltZSBkdXJhdGlvbiBhIHRh cmdldCB3YWl0cyBmb3IgdGhlIERSTy0gIEFDSyBiZWZvcmUgcmV0cmFuc21pdHRpbmcgYSBEUk8g bWVzc2FnZS4gRFJPX0FDS19XQUlUX1RJTUUgaGFzIGENCiAgICAgIHZhbHVlIG9mIDEgc2Vjb25k Lg0KDQogW0NlZHJpY10NCiBJJ20gbm90IHN1cmUgaXQgaXMgY29tcGxpYW50IHdpdGggYWxsIFJQ TCBkZXBsb3ltZW50cy4NCiBDb3VsZCB3ZSBhZGFwdCBpdCB0byB0aGUgY2hhcmFjdGVyaXN0aWNz IG9mIHRoZSBuZXR3b3JrIHVzZWQgPw0KDQogW011a3VsXQ0KIEkgYW0gT0sgd2l0aCBtYWtpbmcg RFJPX0FDS19XQUlUX1RJTUUgYXMgd2VsbCBhcyBNQVhfRFJPX1JFVFJBTlNNSVNTSU9OUyAgY29u ZmlndXJhYmxlIHBhcmFtZXRlcnMuDQoNCltDZWRyaWMyXQ0KU2FmZSBlbm91Z2guDQoNCi0tIA0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQogUmVwb3J0ZXI6ICBqcHZA4oCmICAgICAgICAgICAgICAgICAgfCAgICAgIE93bmVyOiAgbXVr dWxA4oCmDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czog IG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6DQpD b21wb25lbnQ6ICBhcHBsaWNhYmlsaXR5LWFtaSAgICAgIHwgICAgVmVyc2lvbjoNCiBTZXZlcml0 eTogIFN1Ym1pdHRlZCBXRyBEb2N1bWVudCAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6 IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9yb2xsL3RyYWMvdGlja2V0Lzk3Pg0Kcm9s bCA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3JvbGwvPg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From c.chauvenet@watteco.com Thu Apr 5 07:28:33 2012 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 D389421F8523 for ; Thu, 5 Apr 2012 07:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIZXtO7eYk6L for ; Thu, 5 Apr 2012 07:28:33 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1B28E21F8471 for ; Thu, 5 Apr 2012 07:28:33 -0700 (PDT) Received: from mail60-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 14:28:32 +0000 Received: from mail60-va3 (localhost [127.0.0.1]) by mail60-va3-R.bigfish.com (Postfix) with ESMTP id 61AFF6047E; Thu, 5 Apr 2012 14:28:32 +0000 (UTC) X-SpamScore: -70 X-BigFish: VPS-70(zzc89bh15caKJzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h93fhd25h) X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT002.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail60-va3 (localhost.localdomain [127.0.0.1]) by mail60-va3 (MessageSwitch) id 1333636109764113_19805; Thu, 5 Apr 2012 14:28:29 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.254]) by mail60-va3.bigfish.com (Postfix) with ESMTP id B5EB83A028F; Thu, 5 Apr 2012 14:28:29 +0000 (UTC) Received: from AMXPRD0510HT002.eurprd05.prod.outlook.com (157.56.248.181) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 14:28:28 +0000 Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT002.eurprd05.prod.outlook.com ([10.255.57.37]) with mapi id 14.16.0135.002; Thu, 5 Apr 2012 14:28:28 +0000 From: C Chauvenet To: "roll@ietf.org" , "mukul@UWM.EDU" , "jpv@cisco.com" Thread-Topic: [Roll] [roll] #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs? Thread-Index: AQHNEx3z89ZP4AFw/0ivhS+8MCKZOpaMSO8A Date: Thu, 5 Apr 2012 14:28:27 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D02216681@AMXPRD0510MB390.eurprd05.prod.outlook.com> References: <055.f7a4657c0332f6393eb09f355b0158eb@trac.tools.ietf.org> In-Reply-To: <055.f7a4657c0332f6393eb09f355b0158eb@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: Re: [Roll] [roll] #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs? 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, 05 Apr 2012 14:28:33 -0000 DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogcm9sbC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIHJvbGwgaXNz dWUgdHJhY2tlcg0KRW52b3nDqcKgOiBqZXVkaSA1IGF2cmlsIDIwMTIgMTM6MDMNCsOAwqA6IG11 a3VsQFVXTS5FRFU7IGpwdkBjaXNjby5jb20NCkNjwqA6IHJvbGxAaWV0Zi5vcmcNCk9iamV0wqA6 IFtSb2xsXSBbcm9sbF0gIzk2OiBDYW4gdGhlIGRyYWZ0IHJlY29tbWVuZCBob3cgbXVjaCB0byB3 YWl0IGJlZm9yZSBhIHRhcmdldCBzZWxlY3RzIHJvdXRlcyB0byBiZSBzZW50IGJhY2sgaW4gRFJP cz8NCg0KIzk2OiBDYW4gdGhlIGRyYWZ0IHJlY29tbWVuZCBob3cgbXVjaCB0byB3YWl0IGJlZm9y ZSBhIHRhcmdldCBzZWxlY3RzIHJvdXRlcyB0byBiZSBzZW50IGJhY2sgaW4gRFJPcz8NCg0KIFJl c29sdXRpb246IFRoaXMgaXMgcHVyZWx5IGEgbG9jYWwgZGVjaXNpb24gYXQgdGhlIHRhcmdldC4g VGhlIGRyYWZ0ICBzaG91bGQgbm90IG1ha2UgYW55IHJlY29tbWVuZGF0aW9uIGluIHRoaXMgcmVn YXJkLg0KDQogRGlzY3Vzc2lvbjoNCg0KIHAyMSA6ICBFeGFtcGxlIG1ldGhvZHMgaW5jbHVkZSBz ZWxlY3RpbmcgZWFjaCByb3V0ZSB0aGF0IG1lZXRzIHRoZSAgc3BlY2lmaWVkIHJvdXRpbmcgY29u c3RyYWludHMNCiAgIHVudGlsIHRoZSBkZXNpcmVkIG51bWJlciBoYXZlIGJlZW4gc2VsZWN0ZWQg b3Igc2VsZWN0aW5nIHRoZSBiZXN0DQogICByb3V0ZXMgZGlzY292ZXJlZCBvdmVyIGEgY2VydGFp biB0aW1lIHBlcmlvZC4NCg0KIFtDZWRyaWNdDQogSG93IGNvdWxkIHdlIGtub3cgdGhlIHRpbWUg dG8gd2FpdCB1bnRpbCB3ZSBnZXQgYWxsIHRoZSBSRE8gPw0KIElzIHRoZXJlIGEgd2F5IHRvIGV2 YWx1YXRlIGl0IGFjY29yZGluZyB0byBzb21lIHBhcmFtZXRlcnMgcmVsYXRlZCB0byB0aGUgIG5l dHdvcmsgKGRpYW1ldGVyIG9mIHRoZSBuZXR3b3JrIGZvciBpbnN0YW5jZSkgPw0KDQogW011a3Vs XSBUaGlzIGhhcyB0byBiZSBhIGxvY2FsIGRlY2lzaW9uLiBQZXJoYXBzLCB0aGUgdGFyZ2V0IGNh biBsb29rIGF0ICB0aGUgYWdncmVnYXRlZCB2YWx1ZXMgb2YgdGhlIHJvdXRpbmcgbWV0cmljcyBm cm9tIHRoZSBvcmlnaW4gYW5kIGRldGVybWluZSAgaXRzIGRpc3RhbmNlIGZyb20gdGhlIG9yaWdp bi4gVGhpcyBkaXN0YW5jZSBlc3RpbWF0ZSwgYWxvbmcgd2l0aCB0cmlja2xlICBwYXJhbWV0ZXJz LCBjb3VsZCBwZXJoYXBzIGdpdmUgaXQgYSBiZXR0ZXIgaWRlYSBvZiBob3cgbXVjaCB0byB3YWl0 LiBJICBkb250IHRoaW5rIHRoYXQgdGhlIGRyYWZ0IHNob3VsZCB0YWxrIGFib3V0IHRoaXMuDQoN CltDZWRyaWMyXQ0KT0ssIGxldCdzIHNheSBpdCBpcyB1cCB0byB0aGUgaW1wbGVtZW50YXRpb24g YW5kIHNob3VsZCBiZSBkZXRlcmluaWVkIGFjY29yZGluZyB0byB0aGUgc3BlY2lmaWMgc2V0IG9m IG1ldHJpYy9jb250cmFpbnRzIGluIHVzZS4NCkEgdGFyZ2V0IGZyb20gYSBEQUcgYmFzZWQgb24g YSBsYXRlbmN5IG1ldHJpYyBjb3VsZCB3YWl0IGp1c3QgYSBmZXcgbXMgYWZ0ZXIgcmVjZWl2aW5n IHRoZSBmaXJzdCBSRE8gIGFuZCBzZWxlY3QgdGhlIGJlc3QgcGF0aCBhY2NvcmRpbmcgdG8gdGhl IGxhdGVuY3kgbWV0cmljLg0KQSB0YXJnZXQgZnJvbSBhIERBRyBiYXNlZCBvbiBhIGVuZXJneSBt ZXRyaWMgY291bGQgd2FpdCBtdWNoIG1vcmUgdGltZSBhZnRlciByZWNlaXZpbmcgdGhlIGZpcnN0 IFJETyB0byBiZSBzdXJlIHRvIHVzZSBhbiBlbmVyZ3kgZWZmaWNpZW50IHBhdGgsIHRoYXQgY291 bGQgYmUgZGlzY292ZXJlZCBhZnRlciBzb21lIHRpbWUsIGJlY2F1c2Ugb2YgZHV0eSBjeWNsaW5n IG5vZGVzIGZvciBpbnN0YW5jZS4NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGpwdkDigKYgICAgICAg ICAgICAgICAgICB8ICAgICAgT3duZXI6ICBtdWt1bEDigKYNCiAgICAgVHlwZTogIGRlZmVjdCAg ICAgICAgICAgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAg ICAgICAgICAgICAgIHwgIE1pbGVzdG9uZToNCkNvbXBvbmVudDogIGFwcGxpY2FiaWxpdHktYW1p ICAgICAgfCAgICBWZXJzaW9uOg0KIFNldmVyaXR5OiAgU3VibWl0dGVkIFdHIERvY3VtZW50ICB8 ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L3dnL3JvbGwvdHJhYy90aWNrZXQvOTY+DQpyb2xsIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cv cm9sbC8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From c.chauvenet@watteco.com Thu Apr 5 07:38:38 2012 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 57DB821F85CC for ; Thu, 5 Apr 2012 07:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV7PTkT2rlHY for ; Thu, 5 Apr 2012 07:38:37 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id C48F421F85C3 for ; Thu, 5 Apr 2012 07:38:36 -0700 (PDT) Received: from mail9-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 14:38:35 +0000 Received: from mail9-am1 (localhost [127.0.0.1]) by mail9-am1-R.bigfish.com (Postfix) with ESMTP id ECEAB2E03CA; Thu, 5 Apr 2012 14:38:35 +0000 (UTC) X-SpamScore: -73 X-BigFish: VPS-73(z4b6Kzc89bh15caKJzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h93fhd25h) X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail9-am1 (localhost.localdomain [127.0.0.1]) by mail9-am1 (MessageSwitch) id 1333636714124172_24988; Thu, 5 Apr 2012 14:38:34 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.229]) by mail9-am1.bigfish.com (Postfix) with ESMTP id 0CB2D480063; Thu, 5 Apr 2012 14:38:34 +0000 (UTC) Received: from AMXPRD0510HT005.eurprd05.prod.outlook.com (157.56.248.181) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 14:38:33 +0000 Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.57.40]) with mapi id 14.16.0135.002; Thu, 5 Apr 2012 14:38:32 +0000 From: C Chauvenet To: "roll@ietf.org" , "mukul@UWM.EDU" , "jpv@cisco.com" Thread-Topic: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery? Thread-Index: AQHNEx32hh4lWAafiEaDmA/VlsX0qpaMTC1w Date: Thu, 5 Apr 2012 14:38:31 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D022166C5@AMXPRD0510MB390.eurprd05.prod.outlook.com> References: <055.011df19dbc537f65d6ae0f3e832587d1@trac.tools.ietf.org> In-Reply-To: <055.011df19dbc537f65d6ae0f3e832587d1@trac.tools.ietf.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: Re: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery? 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, 05 Apr 2012 14:38:38 -0000 DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogcm9sbC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIHJvbGwgaXNz dWUgdHJhY2tlcg0KRW52b3nDqcKgOiBqZXVkaSA1IGF2cmlsIDIwMTIgMTM6MDINCsOAwqA6IG11 a3VsQFVXTS5FRFU7IGpwdkBjaXNjby5jb20NCkNjwqA6IHJvbGxAaWV0Zi5vcmcNCk9iamV0wqA6 IFtSb2xsXSBbcm9sbF0gIzk1OiBXaHkgbmVlZCBzdG9wIGZsYWc/IElzIHRoZSByZWNlaXB0IG9m IERSTyBub3Qgc3VmZmljaWVudCB0byBpbmRpY2F0ZSBjb21wbGV0aW9uIG9mIHJvdXRlIGRpc2Nv dmVyeT8NCg0KIzk1OiBXaHkgbmVlZCBzdG9wIGZsYWc/IElzIHRoZSByZWNlaXB0IG9mIERSTyBu b3Qgc3VmZmljaWVudCB0byBpbmRpY2F0ZSBjb21wbGV0aW9uIG9mIHJvdXRlIGRpc2NvdmVyeT8N Cg0KIFJlc29sdXRpb246IE5vIGJlY2F1c2UgbXVsdGlwbGUgRFJPcyB3b3VsZCBiZSBnZW5lcmF0 ZWQgaWYgbXVsdGlwbGUgc291cmNlICByb3V0ZXMgYXJlIGJlaW5nIGRpc2NvdmVyZWQuDQoNCiBE aXNjdXNzaW9uOg0KDQogcDE1IDogIFN0b3AgKFMpOiBUaGlzIGZsYWcsIHdoZW4gc2V0IHRvIG9u ZSBieSBhIHRhcmdldCwgaW5kaWNhdGVzIHRoYXQgIHRoZSBQMlAtUlBMIHJvdXRlIGRpc2NvdmVy eSBpcyBvdmVyLg0KDQogW0NlZHJpY10NCiBJcyB0aGlzIGJpdCByZWFsbHkgdXNlZnVsbCA/IE15 IGd1ZXNzIGlzIHRoYXQgaXQgd2lsbCBiZSBhbHdheXMgc2V0IHRvIDEuDQogSWYgeW91IGhlYXIg YSBEUk8sIHRoaXMgaW5kZWVkIG1lYW5zIHRoYXQgdGhlIFJETyBoYXMgcmVhY2hlZCB0aGUgdGFy Z2V0LCAgc28geW91IGNvdWxkIGp1c3Qgc3RvcCBwcm9jZXNzaW5nIFJETyB3aGVuIHlvdSBoZWFy IGEgRFJPLg0KIERvIHdlIHJlYWxseSBuZWVkIGEgZmxhZyB0byBzdG9wIFJETyBwcm9jZXNzaW5n IG9yIHRoZSBoZWFyaW5nIG9mIGEgRFJPICB0eXBlIG1lc3NhZ2UgY291bGQgZG8gdGhlIGpvYiA/ DQoNCiBbTXVrdWxdDQogQSBQMlAtUlBMIGludm9jYXRpb24gbWlnaHQgaW52b2x2ZSBkaXNjb3Zl cnkgb2YgbXVsdGlwbGUgc291cmNlIHJvdXRlcy4gSW4gIHRoYXQgY2FzZSwgcmVjZWlwdCBvZiBh IERSTyBkb2VzIG5vdCBtZWFuIHJvdXRlIGRpc2NvdmVyeSBpcyBvdmVyLiBPbmx5ICB3aGVuIHRo ZSB0YXJnZXQgc2V0cyB0aGUgc3RvcCBmbGFnIGluIHRoZSBEUk8sIGEgbm9kZSBjb3VsZCBiZSBz dXJlIHRoYXQgIHRoZSByb3V0ZSBkaXNjb3ZlcnkgaXMgb3Zlci4NCg0KW0NlZHJpYzJdDQpPSyBm byBtdWx0aXBsZSBkaXNjb3ZlcnkuDQpCdXQgaWYgSSB3YW50IHRvIGRpc2NvdmVyIGEgcm91dGUg dG8gYSBtdWx0aWNhc3QgZ3JvdXAgb2YgdGFyZ2V0LiBJIHNldCBhIG11bHRpY2FzdCBhZHJlc3Mg aW4gdGhlIHRhcmdldCBmaWVsZCBvZiB0aGUgUkRPLiBUaGVuLCBkbyBJIHJlY2VpdmVkIGFzIG1h bnkgRFJPIG1lc3NhZ2UgYXMgdGhlIG51bWJlciBvZiB0YXJnZXQgcmVhY2hlZCA/IEluIHRoYXQg Y2FzZSwgd291bGQgdGhlIGZpcnN0IERSTyB3aXRoIGEgIlMiIGZsYWcgc3RvcCB0aGUgUkRPIHBy b3BhZ2F0aW9uIHRvIHJlYWNoIGFsbCB0aGUgdGFyZ2V0IGluY2x1ZGVkIGluIHRoZSBtdWx0aWNh c3QgZ3JvdXAgPw0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGpwdkDigKYgICAgICAgICAgICAgICAgICB8 ICAgICAgT3duZXI6ICBtdWt1bEDigKYNCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAgICAg ICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAg IHwgIE1pbGVzdG9uZToNCkNvbXBvbmVudDogIHAycC1ycGwgICAgICAgICAgICAgICAgfCAgICBW ZXJzaW9uOg0KIFNldmVyaXR5OiAgU3VibWl0dGVkIFdHIERvY3VtZW50ICB8ICAgS2V5d29yZHM6 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3JvbGwvdHJh Yy90aWNrZXQvOTU+DQpyb2xsIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC8+DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxp bmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9yb2xsDQo= From c.chauvenet@watteco.com Thu Apr 5 07:48:05 2012 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 6A98021F86CA for ; Thu, 5 Apr 2012 07:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vEyXuiIOdN6 for ; Thu, 5 Apr 2012 07:48:04 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id ACF0721F86D3 for ; Thu, 5 Apr 2012 07:48:04 -0700 (PDT) Received: from mail120-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Apr 2012 14:48:04 +0000 Received: from mail120-ch1 (localhost [127.0.0.1]) by mail120-ch1-R.bigfish.com (Postfix) with ESMTP id 60D3F200226; Thu, 5 Apr 2012 14:48:04 +0000 (UTC) X-SpamScore: -70 X-BigFish: VPS-70(zzc89bh15caKJzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h93fhd25h) X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail120-ch1 (localhost.localdomain [127.0.0.1]) by mail120-ch1 (MessageSwitch) id 1333637282173428_24688; Thu, 5 Apr 2012 14:48:02 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail120-ch1.bigfish.com (Postfix) with ESMTP id 2608CE00A6; Thu, 5 Apr 2012 14:48:02 +0000 (UTC) Received: from AMXPRD0510HT005.eurprd05.prod.outlook.com (157.56.248.181) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Apr 2012 14:48:01 +0000 Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.57.40]) with mapi id 14.16.0135.002; Thu, 5 Apr 2012 14:47:35 +0000 From: C Chauvenet To: 'Mukul Goyal' Thread-Topic: [Roll] [roll] #91: Is it possible for an origin to get an error message in case the P2P-RPL route discovery fails. Thread-Index: AQHNExs8Cb9i217zFE+hTC4RxCYWnpaMOSrwgAAHaoCAAA7KIA== Date: Thu, 5 Apr 2012 14:47:34 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D02216703@AMXPRD0510MB390.eurprd05.prod.outlook.com> References: <97B69B30E0EF244B940B65EA541E3F2D02216366@AMXPRD0510MB390.eurprd05.prod.outlook.com> <1248145519.1824721.1333633973075.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1248145519.1824721.1333633973075.JavaMail.root@mail17.pantherlink.uwm.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] [roll] #91: Is it possible for an origin to get an error message in case the P2P-RPL route discovery fails. 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, 05 Apr 2012 14:48:05 -0000 DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogTXVrdWwgR295YWwgW21haWx0 bzptdWt1bEB1d20uZWR1XSANCkVudm95w6nCoDogamV1ZGkgNSBhdnJpbCAyMDEyIDE1OjUzDQrD gMKgOiBDIENoYXV2ZW5ldA0KQ2PCoDogcm9sbEBpZXRmLm9yZzsganB2QGNpc2NvLmNvbQ0KT2Jq ZXTCoDogUmU6IFtSb2xsXSBbcm9sbF0gIzkxOiBJcyBpdCBwb3NzaWJsZSBmb3IgYW4gb3JpZ2lu IHRvIGdldCBhbiBlcnJvciBtZXNzYWdlIGluIGNhc2UgdGhlIFAyUC1SUEwgcm91dGUgZGlzY292 ZXJ5IGZhaWxzLg0KDQoNCiM5MTogSXMgaXQgcG9zc2libGUgZm9yIGFuIG9yaWdpbiB0byBnZXQg YW4gZXJyb3IgbWVzc2FnZSBpbiBjYXNlIHRoZSBQMlAtUlBMIHJvdXRlIGRpc2NvdmVyeSBmYWls cy4NCg0KIERpc2N1c3Npb246DQogW0NlZHJpY10NCiBPbiBiaWcgcXVlc3Rpb24gdGhhdCByaXNl IG15IG1pbmQgaXMsIHdoYXQgaGFwcGVuZWQgaWYgdGhlIHJvdXRlIGRpc2NvdmVyeSAgZmFpbCA/ DQogU29tZSBwcm90b2NvbHMgc2VuZHMgb3V0IGFuIGVycm9yIG1lc3NhZ2Ugd2hlbiB0aGUgcm91 dGUgZGlzY292ZXJ5IGZhaWxzICBvciBnZXQgc3R1Y2suDQogRG8gYXV0aG9ycyB0aGluayB0aGF0 IGl0IGNvdWxkIGJlIHJlbGV2YW50IHRvIGFkZCBhICJkaXNjb3ZlcnktZXJyb3IiDQogbWVzc2Fn ZSBhcyBkZWZpbmVkIGluIG90aGVyIHJvdXRlIGRpc2NvdmVyeSBwcm90b2NvbHMgPw0KDQogW011 a3VsXQ0KIEkgZG9udCB0aGluayBpdCBpcyBwb3NzaWJsZSB0byBkZXRlY3QgdGhlIGZhaWx1cmUg b2YgYSBQMlAtUlBMIHJvdXRlICBkaXNjb3ZlcnkuIE5vIG5vZGUga25vd3MgaWYgYSBQMlAtUlBM IHJvdXRlIGRpc2NvdmVyeSBoYXMgZmFpbGVkLg0KDQogUDJQLVJQTCBmb3JtcyBhIHRlbXBvcmFy eSBEQUcgYW5kIHRoZSByb3V0ZSBkaXNjb3ZlcnkgKHdlbGwsIGF0IGxlYXN0IHRoZSAgZmlyc3Qg aGFsZikgc3VjY2VlZHMgd2hlbiBhIHRhcmdldCBqb2lucyB0aGUgREFHLiBPbmx5IHRoZSB0YXJn ZXQga25vd3MgIHdoZXRoZXIgaXQgam9pbmVkIHRoZSBEQUcgb3Igbm90LiBTbywgbm8gbm9kZSBr bm93cyBpZiB0aGUgKGZpcnN0IGhhbGYgb2YNCiB0aGUpIHJvdXRlIGRpc2NvdmVyeSBmYWlsZWQu DQoNCiBTZWNvbmQgaGFsZiBpbnZvbHZlcyB0aGUgdGFyZ2V0IHNlbmRpbmcgRFJPIHRvIHRoZSBv cmlnaW4uIElmIHRoZSBEUk8gZG9lcyAgbm90IHJlYWNoIHRoZSBvcmlnaW4sICh0aGUgc2Vjb25k IGhhbGYgb2YpIHRoZSByb3V0ZSBkaXNjb3ZlcnkgZmFpbHMuIFRoZSAgdGFyZ2V0IGNhbiBlbnN1 cmUgKG9yIGF0IGxlYXN0IGluY3JlYXNlIHRoZSBwcm9iYWJpbGl0eSBvZikgc3VjY2VzcyBieSAg YXNraW5nIGZvciBEUk8tQUNLIGFuZCByZXRyYW5zbWl0dGluZyB0aGUgRFJPIGlmIHRoZSBEUk8t QUNLIGlzIG5vdCAgcmVjZWl2ZWQgd2l0aGluIGNlcnRhaW4gdGltZSBkdXJhdGlvbi4gRFJPIG1l c3NhZ2UgdHJhdmVscyBieSBtdWx0aWNhc3QsICBzbyBhbiBpbnRlcm1lZGlhdGUgcm91dGVyLCB0 aGF0IGZvcndhcmRzIGEgRFJPIGZ1cnRoZXIsIGhhcyBubyBpZGVhICB3aGV0aGVyIHRoZSBuZXh0 IGhvcCBvbiB0aGUgcm91dGUgcmVjZWl2ZWQgdGhlIERSTyBvciBub3QuIEFnYWluLCBubyBub2Rl ICBrbm93cyBpZiB0aGUgKHNlY29uZCBoYWxmIG9mIHRoZSkgdGhlcmUgaXMgbm8gb25lIHRvIGdl bmVyYXRlIHRoZSAgZGlzY292ZXJ5LWVycm9yIG1lc3NhZ2UuDQoNCiBJIHRoaW5rIGFuIG9yaWdp biBtaWdodCBpbmZlciB0aGUgcm91dGUgZGlzY292ZXJ5IHRvIGhhdmUgZmFpbGVkLCBpZiB0aGUg IERBRydzIGxpZmUgdGltZSBoYXMgZXhwaXJlZCBidXQgbm8gRFJPIGlzIHJlY2VpdmVkLiBCdXQg SSBhbSBub3Qgc3VyZSB3ZSAgc2hvdWxkIG1hbmRhdGUgdGhpcyB0byBiZSB0aGUgd2F5IGZhaWx1 cmUgaXMgaW5mZXJyZWQuIFdlIGhhdmUganVzdCA0ICB2YWx1ZXMgZm9yIHRoZSBEQUcgbGlmZSB0 aW1lLiBTbywgSSB0aGluayB3ZSBzaG91bGQgbGVhdmUgaXQgdG8gb3JpZ2luIGhvdyAgbXVjaCB0 byB3YWl0IGZvciBhIERSTyBiZWZvcmUgYWRtaXR0aW5nIGZhaWx1cmUuDQoNCltDZWRyaWMyXQ0K DQpJIHdhcyB0aGlua2luZyBhYm91dCBhbiBlcnJvciBtZXNzYWdlIGlmIHRoZSBkZWxpdmVyeSBv ZiBhIG1lc3NhZ2UgZmFpbHMgd2hlbiB1c2luZyBhIHJvdXRlIGVzdGFibGlzaGVkIGJ5IHRoZSBQ MlAtUlBMIG1lY2hhbmlzbS4NCldoZW4gYSBub2RlIGluY2x1ZGVkIGluIHRoZSBkaXNjb3ZlcmVk IHJvdXRlIGNhbm5vdCBiZSByZWFjaGVkLCB0aGVuIGFuIGVycm9yIG1lc3NhZ2UgY291bGQgaW5p dGlhdGUgYSBuZXcgcm91dGUgZGlzY292ZXJ5IHVzaW5nIHRoZSBQMlAtUlBMIG1lY2hhbmlzbS4N Cg0KW011a3VsMl0NClAyUC1SUEwgcm91dGVzIGFyZSB1c2VkIGluIGV4YWN0bHkgdGhlIHNhbWUg bWFubmVyIGFzIGNvcmUgUlBMIHJvdXRlcywgdGhhdCBpcyB5b3UgdXNlIGFuIFJQTCBTb3VyY2Ug Um91dGluZyBIZWFkZXIgKFJGQzY1NTQpIG9yIGFuIFJQTCBPcHRpb24gKFJGQzY1NTMpIHRvIHNl bmQgYSBwYWNrZXQgdG8gaXRzIGRlc3RpbmF0aW9uLiBUaGVzZSBSRkNzIHNwZWNpZnkgd2hhdCBJ Q01QIGVycm9yIG1lc3NhZ2VzIGNvdWxkIGJlIGdlbmVyYXRlZCBpZiB0aGUgcm91dGUgaXMgYnJv a2VuLg0KDQpbQ2VkcmljM10NCk9rLg0KSWYgdGhlIHJvdXRlIGVycm9yIGRldGVjdGlvbiBpcyBh bHJlZHkgaGFuZGxlZCwgSSB0aGluayBhbiBhZGRpdGlvbmFsIGVycm9yIG1lc3NhZ2UgaXMgbm90 IG5lY2Vzc2FyeS4NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGpwdkDigKYgICAgICAgICAgICAgICAg ICB8ICAgICAgT3duZXI6ICBtdWt1bEDigKYNCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAg ICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAg ICAgIHwgIE1pbGVzdG9uZToNCkNvbXBvbmVudDogIHAycC1ycGwgICAgICAgICAgICAgICAgfCAg ICBWZXJzaW9uOg0KIFNldmVyaXR5OiAgU3VibWl0dGVkIFdHIERvY3VtZW50ICB8ICAgS2V5d29y ZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3JvbGwv dHJhYy90aWNrZXQvOTE+DQpyb2xsIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC8+DQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1h aWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9yb2xsDQoNCg== From matteo@ember.com Thu Apr 5 08:43:42 2012 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 CF44A21F8712 for ; Thu, 5 Apr 2012 08:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.834 X-Spam-Level: X-Spam-Status: No, score=-3.834 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, MANGLED_NAIL=2.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 yaVMTmI6jMhz for ; Thu, 5 Apr 2012 08:43:42 -0700 (PDT) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAFF21F864F for ; Thu, 5 Apr 2012 08:43:41 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c11o142.mxlogic.net(mxl_mta-6.13.0-3) over TLS secured channel with ESMTP id dadbd7f4.0.154534.00-327.332796.p01c11o142.mxlogic.net (envelope-from ); Thu, 05 Apr 2012 09:43:42 -0600 (MDT) X-MXL-Hash: 4f7dbdae7dd1d1e6-66600ff8766194c62ae0d54c4c2c8b193074b233 Received: from USMAIL.hq.ember.com ([fe80::414:51ae:1b16:3f29]) by USMail.hq.ember.com ([fe80::414:51ae:1b16:3f29%10]) with mapi id 14.01.0355.002; Thu, 5 Apr 2012 11:45:09 -0400 From: Matteo Paris To: "" Thread-Topic: Do parents have lower rank or DAGRank? Thread-Index: AQHNE0MUKv9qi0K2IECPr4RIX2VrSg== Date: Thu, 5 Apr 2012 15:45:08 +0000 Message-ID: <03C4AB89-938B-4499-B081-68488B60A613@ember.com> References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com> <0500582D-1326-4033-9A82-FD42BB47A29D@ember.com> <4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu> In-Reply-To: <4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.81.69] Content-Type: text/plain; charset="us-ascii" Content-ID: <10118225EEED244CB5F009E0C02BE6E9@ember.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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=f-O475ulcV8A:10 a=7pl5XsYBbb4A:10 a=saA6nF2ZJa] X-AnalysisOut: [AA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:1] X-AnalysisOut: [0 a=MYqPJgym4Kx47q1P90kooQ==:17 a=OQ_ktunLAAAA:8 a=48vgC7m] X-AnalysisOut: [UAAAA:8 a=pL8bI-nlIOky_DbUkmQA:9 a=CjuIK1q_8ugA:10 a=AuRza] X-AnalysisOut: [0os8rYA:10 a=lZB815dzVvQA:10] Subject: [Roll] Do parents have lower rank or DAGRank? 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, 05 Apr 2012 15:43:42 -0000 Does anybody know whether RPL parents of a node N must have lower rank than= N or lower DAGRank? The RFC text is unclear (see below). Thanks, Matteo > From: Matteo Paris > Date: April 3, 2012 9:46:28 AM EDT > To: Philip Levis > Cc: "roll@ietf.org" > Subject: Re: [Roll] New Version Notification - draft-ietf-roll-minrank-hy= steresis-of-07.txt >=20 >=20 > Hi Phil, >=20 > my question boils down to whether RPL requires members of the parent set = to have lower DAGRank, or merely lower rank. My reading of the RPL draft i= s that all parents must have lower DAGRank. >=20 > I get this from two clauses in the RPL draft that I quoted below. Unfort= unately both are confusingly worded. >=20 > RPL Section 3.5.1 says: "A node A has a rank less than the rank of a node= B if DAGRank(A) is less than DAGRank(B)." I believe the intention here wa= s to say "if and only if", otherwise the clause is pointless (trivially tru= e). >=20 > RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG parent s= et must be of rank less than DAGRank(N)." Here, a rank is being compared w= ith a DAGRank, which is nonsensical, unless "rank" actually means "DAGRank"= . It would be much clearer if it said so explicitly, ie "must be of DAGRan= k less than DAGRank(N)." =20 >=20 > What is your interpretation -- are parents required to have lower rank or= lower DAGRank? Perhaps the confusion is a result of some text accidentally= left over from an older version of the draft. >=20 > Thanks, > Matteo From pthubert@cisco.com Thu Apr 5 09:01:18 2012 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 F03D421F86B5 for ; Thu, 5 Apr 2012 09:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.66 X-Spam-Level: X-Spam-Status: No, score=-9.66 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNjdf5e8UCCS for ; Thu, 5 Apr 2012 09:01:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 405E621F86B6 for ; Thu, 5 Apr 2012 09:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=10490; q=dns/txt; s=iport; t=1333641676; x=1334851276; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=5M+KJ/epPRMVcDhG2WejiB5ptSMjqoJDGrGBtogOUMI=; b=jsMfPydfQXkcDyMHKswpnHdtfxs3bHFz4oy4Xb5i5Xx3CcDBL0HR0kBq 4dWf+fbbYaPDHb+d6n1+u4A0vseXTK1ihPOwyEpSTxZL8GUQYVI7ml511 J3PHYFCgrHb9Ds1urJLJyfdnzKjefKuyiwKCG1c5YHI4eXhwjOVxMluD0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFHBfU+Q/khL/2dsb2JhbABFDoVhsgJ/gQeCCQEBAQMBAQEBDwEQDQQ6CwUHBAIBCBEDAQEBAwIGBhcBAgICAQElHwkIAQEEEwgah2cFC5sCjQiSYwSBL44TNWMEpDaBaYIwOYFSFw X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="134416770" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2012 16:01:13 +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 q35G1Cem002494; Thu, 5 Apr 2012 16:01:13 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); Thu, 5 Apr 2012 18:01:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 5 Apr 2012 18:00:22 +0200 Message-ID: In-Reply-To: <1815328858.1823623.1333627706907.JavaMail.root@mail17.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #86: G flag: do we need that text? Thread-Index: Ac0TJQPEYVpUCjTdQ7KwqeD/1bBkCAAG+u0A References: <1815328858.1823623.1333627706907.JavaMail.root@mail17.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 05 Apr 2012 16:01:03.0790 (UTC) FILETIME=[4D85D4E0:01CD1345] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? 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, 05 Apr 2012 16:01:18 -0000 DQpIZWxsbyBNdWt1bDoNCg0KPjEpIEZvciBhIGxvY2FsIGluc3RhbmNlIHRoZXJlIGNhbiBiZSBv bmx5IG9uZSByb290IGFuZCBvbmUgRE9EQUcuIEcgYml0IGNhbm5vdCBhbmQgaXMgbm90IHVzZWQg Zm9yIERPREFHIHNlbGVjdGlvbiB3aXRoaW4gYW4gaW5zdGFuY2UuIA0KDQpUaGUgc3RhdGVtZW50 IGFib3ZlIHNlZW1zIHRvIGJlIGF0IG9kZHMgd2l0aCBmb2xsb3dpbmcgdHdvIHN0YXRlbWVudHMN Cg0KPjIpIEluIGEgZ2l2ZW4gZGVwbG95bWVudCwgYSBnb2FsIGNhbiBiZSBkZWZpbmVkIHRoYXQg c29tZSBQMlAgRE9EQUdzIGFjaGlldmUgYW5kIG90aGVycyBkbyBub3QuIFRoZSByb290cyB0aGF0 IGFjaGlldmUgdGhhdCBnb2FsIHdpbGwgc2V0IHRoZSBHIGJpdCBpbiB0aGVpciBQMlAgREFHcy4N CjMpIHRoZSBkZWZhdWx0IGdvYWwgaXMgdG8gY3JlYXRlIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIG9y aWdpbiBhbmQgdGFyZ2V0LiBTbyBieSBkZWZhdWx0IEcgc2hvdWxkIGJlIHNldCB0byAxLg0KDQpB cyBwZXIgc3RhdGVtZW50IDEsIHRoZSBHIGZsYWcgY2FuIG5ldmVyIGJlIDEgZm9yIFAyUC1SUEwg REFHcyBiZWNhdXNlIHRoZXkgdXNlIGxvY2FsIGluc3RhbmNlIGlkcy4NCltQYXNjYWxdIFN0YXRl bWVudCAxIGRvZXMgbm90IHNheSB0aGF0IGF0IGFsbC4gQ2FuJ3QgZmF0aG9tIGhvdyB5b3UgY29u Y2x1ZGVkIHRoYXQuLi4gTGV0IG1lIHRyeSB0byByZXdvcmQ6IFRoZXJlIGlzIG9ubHkgd2hhdCBE T0RBRyBmb3IgYSBnaXZlbiBsb2NhbCBpbnN0YW5jZSBzbyB0aGVyZSBjYW5ub3QgYmUgYSBzZWxl Y3Rpb24gPT4gRyBjYW5ub3QgYmUgdXNlZCBmb3IgYSBzZWxlY3Rpb24gdGhhdCBjYW5ub3QgaGFw cGVuLg0KDQotLS0NCg0KQXMgcGVyIHN0YXRlbWVudCAyLzMsIHRoZSBHIGZsYWcgY291bGQgYmUg MSBhbmQgaXMgMSBieSBkZWZhdWx0Lg0KDQpbUGFzY2FsXSBZZXMuIEkgYWRkZWQgYW4gaXRlbSB0 byBoZWxwIHRoZSBkZXZpY2UgcHJpb3JpdGl6ZSB3aGVuIGl0IGlzIGFza2VyIHRvIHBhcnRpY2lw YXRlIHRvIG1hbnkgRE9EQUdzIChmb3IgbWFueSBQMlAgZmxvd3MgdGhhdCBpdCBoYXBwZW5zIHRv IGJlIG9uIHRoZSBwYXRoIG9mKS4gSW4gdGhhdCBjYXNlLCBhbmQgaWYgdGhlIGRldmljZSBjYW5u b3QgcGFydGljcGF0ZXIgdG8gYWxsIHRoZSBQMlAgRE9EQUdzLCB0aGVuIHRoZSBHIGJpdCBjb3Vs ZCBiZSB1c2UgdG8gZGVjaWRlIHdoaWNoIGFyZSB0aGUgbW9zdCBpbXBvcnRhbnQuIA0KDQotLS0N Cg0KSSBhbSBPSyB3aXRoIHNldHRpbmcgRyBmbGFnIHRvIDEgYWx3YXlzIChhcyB5b3UsIFJpY2hh cmQgYW5kIFBoaWwgc2VlbSB0byBwcmVmZXIpIGJ1dCBJIGRvbnQga25vdyBob3cgdG8gcmVhc29u IHRoaXMuIERvIHdlIG5lZWQgdG8gcHJvdmlkZSBhIHJlYXNvbiBhdCBhbGw/DQoNCltQYXNjYWxd IElmIHlvdSBkZWZpbmUgYSBkZWZhdWx0IGdvYWwgdGhhdCB0aGUgRE9EQUcgZmlsbHMsIHRoZW4g eW91IHNldCBHIHRvIG9uZS4gRm9yIGluc3RhbmNlLCBHIGNvdWxkIG1lYW4gJ2ltcG9ydGFudCBz dHVmZicgbGlrZSBzd2l0aGluZyBhIGxpZ2h0IG9uLiBZb3UnZCBzZXQgaXQgZm9yIHN3aXRjaGlu ZyBsaWdodHMgYnV0IG5vdCBmb3IgcmVwb3J0aW5nIHRoZSBoeWdyb21ldHJ5IG9mIHlvdXIgb3Jj aGlkcywgd2hpY2ggYW55d2F5IHdpbGwgYmUgcmV0cmllZCBpbiBhIGhhbGYgaG91ci4gQXMgYSBy ZXN1bHQsIGlmIHRoZSAyIERBRyBmb3JtYXRpb25zIGNvbGxpZGUsIHRoZSBsaWdodCBvbiB3aWxs IGhhdmUgcHJlY2VkZW5jZS4uLg0KDQotLS0tLS0tLS0NCg0KOikgdG9vIC4uLg0KDQogUGFzY2Fs DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJQYXNjYWwgVGh1YmVydCAo cHRodWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPg0KVG86ICJNdWt1bCBHb3lhbCIgPG11a3Vs QHV3bS5lZHU+DQpDYzogcm9sbEBpZXRmLm9yZywgIlJpY2hhcmQgS2Vsc2V5IiA8cmljaGFyZC5r ZWxzZXlAZW1iZXIuY29tPiwgIlBoaWxpcCBMZXZpcyIgPHBhbEBjcy5zdGFuZm9yZC5lZHU+DQpT ZW50OiBUaHVyc2RheSwgQXByaWwgNSwgMjAxMiAxOjExOjQyIEFNDQpTdWJqZWN0OiBSRTogW1Jv bGxdIFtyb2xsXSAjODY6IEcgZmxhZzogZG8gd2UgbmVlZCB0aGF0IHRleHQ/DQoNCkhlbGxvIE11 a3VsOg0KDQpJIHN1Z2dlc3QgYSBzZW50ZW5jZSB0aGF0IHNheXMgdGhhdDoNCg0KMSkgRm9yIGEg bG9jYWwgaW5zdGFuY2UgdGhlcmUgY2FuIGJlIG9ubHkgb25lIHJvb3QgYW5kIG9uZSBET0RBRy4g RyBiaXQgY2Fubm90IGFuZCBpcyBub3QgdXNlZCBmb3IgRE9EQUcgc2VsZWN0aW9uIHdpdGhpbiBh biBpbnN0YW5jZS4gDQoyKSBJbiBhIGdpdmVuIGRlcGxveW1lbnQsIGEgZ29hbCBjYW4gYmUgZGVm aW5lZCB0aGF0IHNvbWUgUDJQIERPREFHcyBhY2hpZXZlIGFuZCBvdGhlcnMgZG8gbm90LiBUaGUg cm9vdHMgdGhhdCBhY2hpZXZlIHRoYXQgZ29hbCB3aWxsIHNldCB0aGUgRyBiaXQgaW4gdGhlaXIg UDJQIERBR3MuDQozKSB0aGUgZGVmYXVsdCBnb2FsIGlzIHRvIGNyZWF0ZSBjb25uZWN0aXZpdHkg YmV0d2VlbiBvcmlnaW4gYW5kIHRhcmdldC4gU28gYnkgZGVmYXVsdCBHIHNob3VsZCBiZSBzZXQg dG8gMS4NCjQpIGlmIGFuIGludGVybWVkaWF0ZSByb3V0ZXIgZG9lcyBub3QgaGF2ZSBlbm91Z2gg cmVzb3VyY2VzIHRvIHBhcnRpY2lwYXRlIHRvIGFsbCBET0RBR3MgdGhlbiBpdCBzaG91bGQgZmF2 b3IgRE9EQUdzIHdpdGggdGhlIEcgYml0IG9uLg0KDQpUaGUgZXhhY3Qgd29yZGluZyBpcyB5b3Vy cy4uLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogTXVrdWwgR295YWwgW21haWx0bzptdWt1bEB1d20uZWR1XQ0KU2VudDogbWVyY3JlZGkg NCBhdnJpbCAyMDEyIDE4OjQ3DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KQ2M6IHJv bGxAaWV0Zi5vcmc7IFJpY2hhcmQgS2Vsc2V5DQpTdWJqZWN0OiBSZTogW1JvbGxdIFtyb2xsXSAj ODY6IEcgZmxhZzogZG8gd2UgbmVlZCB0aGF0IHRleHQ/DQoNClBhc2NhbA0KDQo+SW4gYW55IGNh c2UsIGFzIEkgc3VnZ2VzdGVkIGVhcmxpZXIgYW5kIGFzIFJpY2hhcmQgYWxzbyBzdWdnZXN0IG5v dywgRyBTSE9VTEQgcHJvYmFibHkgYmUgMSBieSBkZWZhdWx0IGJ1dCBNQVkgYmUgc2V0IG90aGVy d2lzZS4NCg0KUmljaGFyZCB3YW50cyB0aGUgZmxhZyB0byBhbHdheXMgYmUgZWl0aGVyIDAgb3Ig MS4gSGUgcHJlZmVycyBpdCB0byBiZSBhbHdheXMgMSBidXQgd291bGQgc2V0dGxlIGZvciBpdCBi ZWluZyBhbHdheXMgemVyby4NCg0KSSB0aGluayB0aGlzIGlzIG5vdCBhIGNyaXRpY2FsIHBvaW50 LiBJIGFtIE9LIHdpdGggd2hhdGV2ZXIgcmVzb2x1dGlvbiB5b3UgYW5kIFJpY2hhcmQgYXJyaXZl IGF0LiBLaW5kbHkgcHJvdmlkZSBtZSB0aGUgcmVzb2x1dGlvbiB0ZXh0IEkgc2hvdWxkIHB1dCBp biB0aGUgZHJhZnQuDQoNClRoYW5rcw0KTXVrdWwNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLQ0KRnJvbTogIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVydEBjaXNjby5j b20+DQpUbzogIk11a3VsIEdveWFsIiA8bXVrdWxAdXdtLmVkdT4NCkNjOiByb2xsQGlldGYub3Jn LCAiUmljaGFyZCBLZWxzZXkiIDxyaWNoYXJkLmtlbHNleUBlbWJlci5jb20+DQpTZW50OiBXZWRu ZXNkYXksIEFwcmlsIDQsIDIwMTIgMTE6MDU6NTAgQU0NClN1YmplY3Q6IFJFOiBbUm9sbF0gW3Jv bGxdICM4NjogRyBmbGFnOiBkbyB3ZSBuZWVkIHRoYXQgdGV4dD8NCg0KTXVrdWw6DQoNCkkgdGhp bmsgd2UgZGlzYWdyZWUgYmVjYXVzZSBvZiB0aGUgZGVmaW5pdGlvbiBvZiBnb2FsIGl0c2VsZi4g VGhlIGdvYWwgaXMgYW4gYWJzdHJhY3Rpb24uIFNhbWUgZ29lcyBmb3IgdGhlIHRlcm0gT2JqZWN0 aXZlIGluIE9GLiBSRkMgNjU1MCBvbmx5IGdpdmVzIGV4YW1wbGVzIG9mIHdoYXQgRyBjb3VsZCBi ZSB1c2VkIGZvciBidXQgdGhhdCBpcyBub3QgbGltaXRpbmcuIENlcnRhaW5seSB0aGUgYWJzdHJh Y3Rpb24gbWF5IGZvciBpbnN0YW5jZSBtZWFuIHRoYXQgZXh0ZXJuYWwgbm9kZXMgYXJlIHJlYWNo YWJsZSB2aWEgdGhlIHJvb3QuIEJ1dCBpdCBjb3VsZCBiZSBzb21ldGhpbmcgZWxzZSBlbnRpcmVs eS4gRm9yIGluc3RhbmNlIGl0IGNvdWxkIGRlc2lnbmF0ZSBhIHJvb3QgdGhhdCBjYW4gYWdncmVn YXRlIGRhdGEuDQoNCkluIHByYWN0aWNlLCBHIGlzIHVzZWQgdG8gZmF2b3IgYSByb290IHRoYXQg cmVhY2hlcyB0aGUgZ29hbCB2cy4gb25lIHRoYXQgZG9lcyBub3QuIEJ1dCB0aGF0J3Mgc2Vuc2Vs ZXNzIGZvciBsb2NhbCBpbnN0YW5jZXMgdGhhdCBoYXZlIGJ5IGRlZmluaXRpb24gYSBzaW5nbGUg cm9vdC4NCg0KU28gd2hhdGV2ZXIgeW91IHNldCBpdCB0byBkb2VzIG5vdCBtYWtlIGEgZGlmZmVy ZW5jZSBmb3IgUkZDIDY1NTAgb3BlcmF0aW9ucy4gSSBmaWd1cmUgaXQgY291bGQgYmUgdXNlZCBm b3Igc2lnbmFsaW5nIGEgInRyYW5zaWVudCBnb2FsIiBpbmZvcm1hdGlvbiB0byBhbiBPRiB0aGF0 IGNvdWxkIHVzZSBpdCBmb3IgYSBwdXJwb3NlIEkgY2FuJ3QgZmF0aG9tLg0KDQpJbiBhbnkgY2Fz ZSwgYXMgSSBzdWdnZXN0ZWQgZWFybGllciBhbmQgYXMgUmljaGFyZCBhbHNvIHN1Z2dlc3Qgbm93 LCBHIFNIT1VMRCBwcm9iYWJseSBiZSAxIGJ5IGRlZmF1bHQgYnV0IE1BWSBiZSBzZXQgb3RoZXJ3 aXNlLg0KDQpQYXNjYWwNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBN dWt1bCBHb3lhbCBbbWFpbHRvOm11a3VsQHV3bS5lZHVdDQpTZW50OiBtZXJjcmVkaSA0IGF2cmls IDIwMTIgMTY6MTYNClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpDYzogcm9sbEBpZXRm Lm9yZzsgUmljaGFyZCBLZWxzZXkNClN1YmplY3Q6IFJlOiBbUm9sbF0gW3JvbGxdICM4NjogRyBm bGFnOiBkbyB3ZSBuZWVkIHRoYXQgdGV4dD8NCg0KUGFzY2FsDQoNCj5JZiB0aGUgZ29hbCBpcyB0 byByZWFjaCB0aGUgcm9vdCwgdGhlbiBHIGlzIDEuLi4NCg0KSSBoYXZlIHRvbGQgeW91IG11bHRp cGxlIHRpbWVzIHRoYXQgam9pbmluZyBhIFAyUC1SUEwgREFHIGRvZXMgbm90IGdpdmUgYW55IHNv cnQgb2YgY29ubmVjdGl2aXR5IHRvIHRoZSBub2RlLg0KDQpUaGFua3MNCk11a3VsDQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJQYXNjYWwgVGh1YmVydCAocHRodWJlcnQp IiA8cHRodWJlcnRAY2lzY28uY29tPg0KVG86ICJNdWt1bCBHb3lhbCIgPG11a3VsQHV3bS5lZHU+ LCAiUmljaGFyZCBLZWxzZXkiIDxyaWNoYXJkLmtlbHNleUBlbWJlci5jb20+DQpDYzogcm9sbEBp ZXRmLm9yZw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDEyIDk6MDU6MjggQU0NClN1Ympl Y3Q6IFJFOiBbUm9sbF0gW3JvbGxdICM4NjogRyBmbGFnOiBkbyB3ZSBuZWVkIHRoYXQgdGV4dD8N Cg0KSGVsbG8gTXVrdWwNCg0KRmxvYXRpbmcgdnMuIEdyb3VuZGVkIGRlcGVuZHMgb24gdGhlIGdv YWwgb2YgdGhlIERPREFHLiBJIGFza2VkIHlvdSBhbmQgd2lsbCBhc2sgYWdhaW4gd2hhdCBpcyB5 b3VyIGdvYWw/DQpJZiB0aGUgZ29hbCBpcyB0byByZWFjaCB0aGUgcm9vdCwgdGhlbiBHIGlzIDEu Li4gSWYgeW91IHdhbnQgdG8gc2lnbmFsIHNvbWV0aGluZyB0byB0aGUgT0YgdXNpbmcgdGhlIEcg Yml0LCBsZWF2ZSBpdCAgb3Blbi4NCg0KQ2hlZXJzLA0KUGFzY2FsDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE11a3VsIEdveWFsDQpTZW50OiBtZXJjcmVk aSA0IGF2cmlsIDIwMTIgMTU6NTUNClRvOiBSaWNoYXJkIEtlbHNleQ0KQ2M6IHJvbGxAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbUm9sbF0gW3JvbGxdICM4NjogRyBmbGFnOiBkbyB3ZSBuZWVkIHRo YXQgdGV4dD8NCg0KPlRoZSBHIGZsYWcgaXMgMCBpZiBhbmQgb25seSBpZiB0aGUgRE9EQUcgaXMg ZmxvYXRpbmcuDQoNCkkgdGhpbmsgdGhhdCB0aGUgRyBmbGFnIGlzIDEgaWYgYW5kIG9ubHkgaWYg dGhlIERPREFHIGlzIGdyb3VuZGVkLiBUaGUgdGVtcG9yYXJ5IERBR3MgdXNlZCBpbiBQMlAtUlBM IGFyZSBub3QgZ3JvdW5kZWQsIHRoZXkgYXJlIHRlbXBvcmFyeS4gSSB0aGluayB0aGF0IGFsbCB0 cmFuc2llbnQvdGVtcG9yYXJ5IERBR3MgYXJlIGZsb2F0aW5nIGJ5IHRoZWlyIHZlcnkgbmF0dXJl Lg0KDQpUaGFua3MNCk11a3VsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206 ICJSaWNoYXJkIEtlbHNleSIgPHJpY2hhcmQua2Vsc2V5QGVtYmVyLmNvbT4NClRvOiByb2xsQGll dGYub3JnDQpDYzogbXVrdWxAVVdNLkVEVSwganB2QGNpc2NvLmNvbSwgcm9sbEBpZXRmLm9yZw0K U2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDEyIDg6MzY6NTAgQU0NClN1YmplY3Q6IFJlOiBb Um9sbF0gW3JvbGxdICM4NjogRyBmbGFnOiBkbyB3ZSBuZWVkIHRoYXQgdGV4dD8NCg0KPiBGcm9t OiByb2xsIGlzc3VlIHRyYWNrZXIgPHRyYWMrcm9sbEB0cmFjLnRvb2xzLmlldGYub3JnPg0KPiBE YXRlOiBXZWQsIDQgQXByIDIwMTIgMTM6MDg6NTAgKzAwMDANCj4gDQo+ICM4NjogRyBmbGFnOiBk byB3ZSBuZWVkIHRoYXQgdGV4dD8NCj4gDQo+ICBQcm9ibGVtIChyZXNvbGl0aW9uIGlzIHByb3Bv c2VkKQ0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICBEaXNhZ3JlZW1lbnQg b24gdGhlIG1lYW5pbmcgb2YgJ0cnIGJpdCBhbmQgaW1wb3NlZCBzZXR0aW5nIHRvIDA7DQo+IA0K PiAgUHJvcG9zZWQgcmVzb2x1dGlvbg0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ICBUaGUgb3JpZ2luIHNldHMgdGhlIEcgZmxhZyBiYXNlZCBvbiBpdHMgcGVyY2VwdGlvbiBvZiB3 aGV0aGVyIGpvaW5pbmcNCg0KPiBob3cgdGhlIGZsYWcncyB2YWx1ZSB3b3VsZCBhZmZlY3QgdGhl IHJhbmsgY2FsY3VsYXRpb24gdW5kZXIgdGhlIE9GIA0KPiBiZWluZyB1c2VkLiBCeSBkZWZhdWx0 LCB0aGUgRyBmbGFnIGlzIHNldCB0byB6ZXJvIGdpdmVuIHRoZSB0ZW1wb3JhcnkNCg0KPiBuYXR1 cmUgb2YgdGhlIERBRyBiZWluZyBjcmVhdGVkLg0KDQpJIGRpc2FncmVlIHdpdGggdGhlIHByb3Bv c2VkIHJlc29sdXRpb24uICBJdCBhZGRzIG5lZWRsZXNzIGNvbmZ1c2lvbi4NClRoZSBHIGZsYWcg aXMgMCBpZiBhbmQgb25seSBpZiB0aGUgRE9EQUcgaXMgZmxvYXRpbmcuDQpUaGVyZSBpcyBubyBw b2ludCB0byBhbGxvd2luZyBmbG9hdGluZyBET0RBR3Mgd2l0aCBhIFAyUC1SRE8gb3B0aW9uLiAg SSBzdWdnZXN0IHRoYXQgdGhlIEcgYml0IGJlIHNldCB0byAxIGFuZCB0aGF0IHJvdXRlcnMgYmUg ZXhwbGljaXRseSBwcm9oaWJpdGVkIGZyb20gY3JlYXRpbmcgZmxvYXRpbmcgRE9EQUdzIHdpdGgg YSBQMlAtUkRPIG9wdGlvbi4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLVJp Y2hhcmQgS2Vsc2V5IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From pal@cs.stanford.edu Thu Apr 5 09:08:07 2012 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 8423F21F86E5 for ; Thu, 5 Apr 2012 09:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_NAIL=2.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 gxsqr7x05QBo for ; Thu, 5 Apr 2012 09:08:07 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0565B21F86D4 for ; Thu, 5 Apr 2012 09:08:06 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SFpED-0003pY-Jx; Thu, 05 Apr 2012 09:08:06 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: Date: Thu, 5 Apr 2012 09:08:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com> <0500582D-1326-4033-9A82-FD42BB47A29D@ember.com> <4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu> To: Matteo Paris X-Mailer: Apple Mail (2.1257) X-Scan-Signature: ee5a8a2ba51c5094c3d10c175eb088a4 Cc: "roll@ietf.org" Subject: Re: [Roll] New Version Notification - draft-ietf-roll-minrank-hysteresis-of-07.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: Thu, 05 Apr 2012 16:08:07 -0000 Comments inline On Apr 3, 2012, at 6:46 AM, Matteo Paris wrote: >=20 > Hi Phil, >=20 > my question boils down to whether RPL requires members of the parent = set to have lower DAGRank, or merely lower rank. My reading of the RPL = draft is that all parents must have lower DAGRank. I think this reading is correct, but not because of the confusing text = you cite. >=20 > I get this from two clauses in the RPL draft that I quoted below. = Unfortunately both are confusingly worded. >=20 > RPL Section 3.5.1 says: "A node A has a rank less than the rank of a = node B if DAGRank(A) is less than DAGRank(B)." I believe the intention = here was to say "if and only if", otherwise the clause is pointless = (trivially true). I don't think you want to interpret this sentence as a definition of = what "lower rank" means. I have no doubt that many portions of the RPL = (or other) specifications do not use the phrase in this way. So it = should be interpreted as "if", not "if and only if." Really, this = sentence shouldn't be in there. >=20 > RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG = parent set must be of rank less than DAGRank(N)." Here, a rank is being = compared with a DAGRank, which is nonsensical, unless "rank" actually = means "DAGRank". It would be much clearer if it said so explicitly, ie = "must be of DAGRank less than DAGRank(N)." =20 Eh=85 I think interpreting it as DAGRank conflicts with the DIO = processing rules. If you interpret this phrase as all parents must have = a lower DAGRank, this strengthens bullet number 5 of 8.2.2.1 from 5. A node's Rank MUST be greater than all elements of its DODAG parent set. to 5. A node's Rank MUST be greater than all elements of its DODAG parent set by at least MinHopRankIncrease. or 5. A node's DAGRank MUST be greater than all elements of its DODAG parent set. It's important to note that 3.5.2 says "When Rank is compared, e.g., for determination of parent relationships or loop detection, the integer portion of the Rank is to be used." not "When Rank is compared, e.g., for determination of parent relationships or loop detection, the integer portion of the Rank MUST be used.=20 > What is your interpretation -- are parents required to have lower rank = or lower DAGRank? Perhaps the confusion is a result of some text = accidentally left over from an older version of the draft. I suspect Pascal and I are going to disagree on this, but my = interpretation is that 3.5.2 doesn't mandate that a node advertise a = Rank which is at least MinHopRankIncrease greater than all of its = parents. 8.2.2.1 was written pretty carefully so that a node with a = preferred parent of Rank a and a backup parent of Rank b (b>a) would not = have to always advertise b + MinHopRankIncrease, but rather at least = b+1. It is useful to note that the MRHOF Rank calculation algorithm *does* = cause a node to advertise a Rank which is at least MinHopRankIncrease = greater than all of its parents. But I don't think RPL should mandate = that behavior. Phil= From pthubert@cisco.com Thu Apr 5 09:19:39 2012 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 94A5F21F8710 for ; Thu, 5 Apr 2012 09:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.794 X-Spam-Level: X-Spam-Status: No, score=-9.794 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h5r+pTb2CC3 for ; Thu, 5 Apr 2012 09:19:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7566A21F8707 for ; Thu, 5 Apr 2012 09:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1457; q=dns/txt; s=iport; t=1333642778; x=1334852378; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=vjEFJto4Oh2YFHGeLEa1fdukMe1jiSIcUv41nfBeZCU=; b=ccC4Wo9lQJqMRTjtRKNBYIxPJv+QOt/I/SnLKHE/XhMSOpQzo2999nbx zrF2ZJJhcSr3x3BKS0UD4oGtbyRPo6N1zIMNDJQk3KKoe3dHFK1SxoSIP R9/oFF4DTU7lvk6qFtbxyiIPCaGa9hLavL+gUAvwAtYFdxWaMETV4C1DW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOTEfU+Q/khR/2dsb2JhbABFDrhigQeCCQEBAQMBAQEBDwEdCjQJAgULAgEIDhQGGAYBJjABAQQBEggah2cFC5sMn2cEj3djBKQ2gWmCMDk X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="134418811" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2012 16:19:37 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q35GJb4i015132; Thu, 5 Apr 2012 16:19:37 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); Thu, 5 Apr 2012 18:19:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Apr 2012 18:18:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt Thread-Index: Ac0TRk2lT88+uG3bT3G++Am2GarSEgAALc/g References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com><0500582D-1326-4033-9A82-FD42BB47A29D@ember.com><4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Matteo Paris" X-OriginalArrivalTime: 05 Apr 2012 16:19:37.0601 (UTC) FILETIME=[E567E710:01CD1347] Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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: Thu, 05 Apr 2012 16:19:39 -0000 Hello Matteo and Phil > What is your interpretation -- are parents required to have lower rank or lower DAGRank? Perhaps the confusion is a result of some text accidentally left over from an older version of the draft. I suspect Pascal and I are going to disagree on this, but my interpretation is that 3.5.2 doesn't mandate that a node advertise a Rank which is at least MinHopRankIncrease greater than all of its parents. 8.2.2.1 was written pretty carefully so that a node with a preferred parent of Rank a and a backup parent of Rank b (b>a) would not have to always advertise b + MinHopRankIncrease, but rather at least b+1. It is useful to note that the MRHOF Rank calculation algorithm *does* cause a node to advertise a Rank which is at least MinHopRankIncrease greater than all of its parents. But I don't think RPL should mandate that behavior. [Pascal] The intent in that example was that the node should advertise a rank that is both more than (b+1) and more than (a + MinHopRankIncrease).=20 The reasons is that the preferred parent is the reference for Rank computation (to stay true to the metrics), but all parents must has a rank that is more than that of the node (to build DAGs which is the way RPL uses to avoid loops).=20 So I think we agree in fact.... Cheers, =20 Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Thu Apr 5 09:21:06 2012 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 990FA21F870E for ; Thu, 5 Apr 2012 09:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, 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 ZRbgcf-wt87K for ; Thu, 5 Apr 2012 09:21:06 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 24E2321F8700 for ; Thu, 5 Apr 2012 09:21:06 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SFpQn-0004ok-Or; Thu, 05 Apr 2012 09:21:06 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Thu, 5 Apr 2012 09:21:18 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com><0500582D-1326-4033-9A82-FD42BB47A29D@ember.com><4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 4c7a780eb20f40a19c8376fd8d8b00d5 Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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: Thu, 05 Apr 2012 16:21:06 -0000 On Apr 5, 2012, at 9:18 AM, Pascal Thubert (pthubert) wrote: > [Pascal] The intent in that example was that the node should advertise a > rank that is both more than (b+1) and more than (a + > MinHopRankIncrease). > The reasons is that the preferred parent is the reference for Rank > computation (to stay true to the metrics), but all parents must has a > rank that is more than that of the node (to build DAGs which is the way > RPL uses to avoid loops). OK, sounds like we agree. Matteo, does this answer your question? Phil From jpv@cisco.com Thu Apr 5 15:16:21 2012 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 BBC1821F8478 for ; Thu, 5 Apr 2012 15:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkqqD1nDRJ8N for ; Thu, 5 Apr 2012 15:16:20 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E3C7721F85D4 for ; Thu, 5 Apr 2012 15:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=6940; q=dns/txt; s=iport; t=1333664181; x=1334873781; h=from:subject:date:references:to:message-id:mime-version; bh=DqTn+pzco4mt6iA+NVYptSu1XWWpj+g5CgMSowwo12o=; b=AAe5TLOS8K8qWLM3SsgRa/wdR+RmbeLQ2c5NURx16dAzdb02ncokJ48N fN/g5hUXUsI3FKL5SOsKjyfH4r4MhjrMvsOe8SbJ8m/yoUMleDjhBAPj/ a0R2JQiNlMErPv/9PdsHFdQXBCPw/ycc3B8UIRjMDzRyeTU058f5kmw5T s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG8Yfk+rRDoH/2dsb2JhbABFuHOBB4IJAQEBAwEBAQEPAVsQCxwDAQIvJx8HAggGEwkLDodnBAELmkifYI93YwSIWY0SizqDEYFpgwc X-IronPort-AV: E=Sophos;i="4.75,378,1330905600"; d="scan'208,217";a="39187797" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 05 Apr 2012 22:16:20 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q35MGKAA001116 for ; Thu, 5 Apr 2012 22:16:20 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); Thu, 5 Apr 2012 15:16:20 -0700 Received: from dhcp-171-68-123-41.cisco.com ([171.68.123.41]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 15:16:20 -0700 From: JP Vasseur Content-Type: multipart/alternative; boundary="Apple-Mail=_009E1CBF-8FAC-415C-919E-5C44BF756ED2" Date: Thu, 5 Apr 2012 15:09:50 -0700 References: <20120405171116.19043.3710.idtracker@ietfa.amsl.com> To: ROLL WG Message-Id: <81382A34-7F37-4028-88E5-A8963EF68036@cisco.com> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 05 Apr 2012 22:16:20.0430 (UTC) FILETIME=[BA7C6EE0:01CD1379] Subject: [Roll] Fwd: I-D Action: draft-polk-ipr-disclosure-02.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: Thu, 05 Apr 2012 22:16:21 -0000 --Apple-Mail=_009E1CBF-8FAC-415C-919E-5C44BF756ED2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii fyi Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-polk-ipr-disclosure-02.txt > Date: April 5, 2012 10:11:16 AM PDT > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Promoting Compliance with Intellectual = Property Rights (IPR) Disclosure Rules > Author(s) : Tim Polk > Peter Saint-Andre > Filename : draft-polk-ipr-disclosure-02.txt > Pages : 13 > Date : 2012-04-05 >=20 > The disclosure process for intellectual property rights (IPR) in = IETF > stream documents is essential to the accurate development of > community consensus. However, this process is not always followed = by > participants during IETF standardization. Regardless of the cause = or > motivation, noncompliance with IPR disclosure rules can derail or > delay completion of standards documents. This document describes > strategies for promoting compliance with the IPR disclosure rules. > The strategies are primarily intended for area directors, working > group chairs, and working group secretaries. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-polk-ipr-disclosure-02.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-polk-ipr-disclosure-02.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_009E1CBF-8FAC-415C-919E-5C44BF756ED2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Subject: I-D Action: = draft-polk-ipr-disclosure-02.txt
Date: April 5, 2012 = 10:11:16 AM PDT
Reply-To: = internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.

Title =           : Promoting = Compliance with Intellectual Property Rights (IPR) Disclosure = Rules
= Author(s)       : Tim Polk
=             &n= bsp;           &nbs= p;Peter Saint-Andre
Filename =        : = draft-polk-ipr-disclosure-02.txt
Pages =           : = 13
= Date =            : = 2012-04-05

  The disclosure process for intellectual = property rights (IPR) in IETF
  stream documents is = essential to the accurate development of
  community = consensus.  However, this process is not always followed by
=   participants during IETF standardization.  Regardless = of the cause or
  motivation, noncompliance with IPR = disclosure rules can derail or
  delay completion of = standards documents.  This document describes
=   strategies for promoting compliance with the IPR disclosure = rules.
  The strategies are primarily intended for area = directors, working
  group chairs, and working group = secretaries.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-polk-ipr-disclosure-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

This Internet-Draft can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-polk-ipr-disclosure-02.txt=

_______________________________________________
I-D-Announce = mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

= = --Apple-Mail=_009E1CBF-8FAC-415C-919E-5C44BF756ED2-- From matteo@ember.com Fri Apr 6 06:56:40 2012 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 BE2F821F84C8 for ; Fri, 6 Apr 2012 06:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.989 X-Spam-Level: X-Spam-Status: No, score=-3.989 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, MANGLED_NAIL=2.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 X43irt-aAGPo for ; Fri, 6 Apr 2012 06:56:40 -0700 (PDT) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) by ietfa.amsl.com (Postfix) with ESMTP id D245E21F84BF for ; Fri, 6 Apr 2012 06:56:39 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO p01c11o144.mxlogic.net) by p01c11o144.mxlogic.net(mxl_mta-6.13.0-3) with ESMTP id 716fe7f4.4ad6d940.75714.00-578.142865.p01c11o144.mxlogic.net (envelope-from ); Fri, 06 Apr 2012 07:56:39 -0600 (MDT) X-MXL-Hash: 4f7ef6173bf48e14-f7cde3ed580a0a5e2f0e785f45dbef45be63a980 Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c11o144.mxlogic.net(mxl_mta-6.13.0-3) over TLS secured channel with ESMTP id 8f5fe7f4.0.75541.00-325.142511.p01c11o144.mxlogic.net (envelope-from ); Fri, 06 Apr 2012 07:56:10 -0600 (MDT) X-MXL-Hash: 4f7ef5fa401eeb3e-176e589109252df0afb4c0169cb4051ba064556b Received: from USMAIL.hq.ember.com ([fe80::414:51ae:1b16:3f29]) by USMail.hq.ember.com ([fe80::414:51ae:1b16:3f29%10]) with mapi id 14.01.0355.002; Fri, 6 Apr 2012 09:57:32 -0400 From: Matteo Paris To: Philip Levis Thread-Topic: [Roll] New Version Notification - draft-ietf-roll-minrank-hysteresis-of-07.txt Thread-Index: AQHNA7v6JbPKPVP/ZUe2ufcTZJGhzZaJe3oAgANMvACAAW1ngA== Date: Fri, 6 Apr 2012 13:57:32 +0000 Message-ID: <9A3B9F20-4F81-4E02-8BB2-5BDEFD63FF2A@ember.com> References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com> <0500582D-1326-4033-9A82-FD42BB47A29D@ember.com> <4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.81.68] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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=PvnVXCDccy0A:10 a=0lGxxKK5Fb8A:10 a=saA6nF2ZJa] X-AnalysisOut: [AA:10 a=BLceEmwcHowA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:1] X-AnalysisOut: [0 a=MYqPJgym4Kx47q1P90kooQ==:17 a=CtA9dLnX8hIz6-T0uA4A:9 a] X-AnalysisOut: [=FIQMXBjE_4mRNb4mLVwA:7 a=pILNOxqGKmIA:10] Cc: "roll@ietf.org" Subject: Re: [Roll] New Version Notification - draft-ietf-roll-minrank-hysteresis-of-07.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: Fri, 06 Apr 2012 13:56:40 -0000 Hi Phil. Thanks for the reply. I too would prefer if parents were only re= quired to have lower rank, not lower interger portion of rank. Unfortunate= ly that is not how the RFC reads. All of 3.5.1 "Rank Comparison" and 3.5.2= "Rank Relationships" are devoted to explaining that ranks should be compar= ed using only their integer portions. You quoted another excellent example= below. As another example, 3.5.2 also spends a paragraph clarifying that = nodes should not route through a node with equal DAGRank (equal integer por= tion of rank), which is to say that parents must have lower integer part. = =20 As it stands, I think the only logically consistent way to read the spec is= to compare ranks as prescribed in 3.5.1 and 3.5.2. Note that doing so doe= s not logically conflict with 8.2.1 case 5, it simply modifies its meaning.= Only if we entirely ignore those two sections, can we then compare ranks = in the more sensible way that we all prefer. If that is the desire, we sho= uld submit an RFC errata. In its current state I do not believe a first ti= me reader of the RFC can know that 3.5.1 and 3.5.2 do not apply. > It is useful to note that the MRHOF Rank calculation algorithm *does* cau= se a node to advertise a Rank which is at least MinHopRankIncrease greater = than all of its parents. But I don't think RPL should mandate that behavior= . Case 2 of 3.3 in MRHOF says: 2. The Rank of the member of the parent set with the highest advertised Rank plus one In order for the MRHOF algorithm to cause a node to advertise a rank which = is at least MinHopRankIncrease greater than all of its parents, this senten= ce must be changed to say "The Rank of the member of the parent set with th= e highest advertised Rank plus MinHopRankIncrease." Matteo On Apr 5, 2012, at 12:08 PM, Philip Levis wrote: > Comments inline >=20 > On Apr 3, 2012, at 6:46 AM, Matteo Paris wrote: >=20 >>=20 >> Hi Phil, >>=20 >> my question boils down to whether RPL requires members of the parent set= to have lower DAGRank, or merely lower rank. My reading of the RPL draft = is that all parents must have lower DAGRank. >=20 > I think this reading is correct, but not because of the confusing text yo= u cite. >=20 >=20 >=20 >>=20 >> I get this from two clauses in the RPL draft that I quoted below. Unfor= tunately both are confusingly worded. >>=20 >> RPL Section 3.5.1 says: "A node A has a rank less than the rank of a nod= e B if DAGRank(A) is less than DAGRank(B)." I believe the intention here w= as to say "if and only if", otherwise the clause is pointless (trivially tr= ue). >=20 > I don't think you want to interpret this sentence as a definition of what= "lower rank" means. I have no doubt that many portions of the RPL (or othe= r) specifications do not use the phrase in this way. So it should be interp= reted as "if", not "if and only if." Really, this sentence shouldn't be in = there. >=20 >>=20 >> RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG parent = set must be of rank less than DAGRank(N)." Here, a rank is being compared = with a DAGRank, which is nonsensical, unless "rank" actually means "DAGRank= ". It would be much clearer if it said so explicitly, ie "must be of DAGRa= nk less than DAGRank(N)." =20 >=20 > Eh=85 I think interpreting it as DAGRank conflicts with the DIO processin= g rules. If you interpret this phrase as all parents must have a lower DAGR= ank, this strengthens bullet number 5 of 8.2.2.1 from >=20 > 5. A node's Rank MUST be greater than all elements of its DODAG > parent set. >=20 > to >=20 > 5. A node's Rank MUST be greater than all elements of its DODAG > parent set by at least MinHopRankIncrease. >=20 > or >=20 > 5. A node's DAGRank MUST be greater than all elements of its DODAG > parent set. >=20 > It's important to note that 3.5.2 says >=20 > "When Rank is > compared, e.g., for determination of parent relationships or loop > detection, the integer portion of the Rank is to be used." >=20 > not >=20 > "When Rank is > compared, e.g., for determination of parent relationships or loop > detection, the integer portion of the Rank MUST be used.=20 >=20 >> What is your interpretation -- are parents required to have lower rank o= r lower DAGRank? Perhaps the confusion is a result of some text accidentall= y left over from an older version of the draft. >=20 > I suspect Pascal and I are going to disagree on this, but my interpretati= on is that 3.5.2 doesn't mandate that a node advertise a Rank which is at l= east MinHopRankIncrease greater than all of its parents. 8.2.2.1 was writte= n pretty carefully so that a node with a preferred parent of Rank a and a b= ackup parent of Rank b (b>a) would not have to always advertise b + MinHopR= ankIncrease, but rather at least b+1. >=20 > It is useful to note that the MRHOF Rank calculation algorithm *does* cau= se a node to advertise a Rank which is at least MinHopRankIncrease greater = than all of its parents. But I don't think RPL should mandate that behavior= . >=20 > Phil From pal@cs.stanford.edu Fri Apr 6 07:42:15 2012 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 08DAB21F84E1 for ; Fri, 6 Apr 2012 07:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_NAIL=2.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 PkR8JW0LHVCG for ; Fri, 6 Apr 2012 07:42:14 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5499D21F84D6 for ; Fri, 6 Apr 2012 07:42:13 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.111]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SGAMe-0003Kf-RM; Fri, 06 Apr 2012 07:42:13 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <9A3B9F20-4F81-4E02-8BB2-5BDEFD63FF2A@ember.com> Date: Fri, 6 Apr 2012 07:42:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <096F0191-8A81-42DE-BAC1-B0620D8A7F84@cs.stanford.edu> References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com> <0500582D-1326-4033-9A82-FD42BB47A29D@ember.com> <4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu> <9A3B9F20-4F81-4E02-8BB2-5BDEFD63FF2A@ember.com> To: Matteo Paris X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 68b71d4cdf0c69f77def38598aa9caf5 Cc: "roll@ietf.org" Subject: Re: [Roll] New Version Notification - draft-ietf-roll-minrank-hysteresis-of-07.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: Fri, 06 Apr 2012 14:42:15 -0000 Pascal wrote the text in 3.5, and it seems like he doesn't agree with = your interpretation... Phil On Apr 6, 2012, at 6:57 AM, Matteo Paris wrote: >=20 > Hi Phil. Thanks for the reply. I too would prefer if parents were = only required to have lower rank, not lower interger portion of rank. = Unfortunately that is not how the RFC reads. All of 3.5.1 "Rank = Comparison" and 3.5.2 "Rank Relationships" are devoted to explaining = that ranks should be compared using only their integer portions. You = quoted another excellent example below. As another example, 3.5.2 also = spends a paragraph clarifying that nodes should not route through a node = with equal DAGRank (equal integer portion of rank), which is to say that = parents must have lower integer part. =20 >=20 > As it stands, I think the only logically consistent way to read the = spec is to compare ranks as prescribed in 3.5.1 and 3.5.2. Note that = doing so does not logically conflict with 8.2.1 case 5, it simply = modifies its meaning. Only if we entirely ignore those two sections, = can we then compare ranks in the more sensible way that we all prefer. = If that is the desire, we should submit an RFC errata. In its current = state I do not believe a first time reader of the RFC can know that = 3.5.1 and 3.5.2 do not apply. >=20 >> It is useful to note that the MRHOF Rank calculation algorithm *does* = cause a node to advertise a Rank which is at least MinHopRankIncrease = greater than all of its parents. But I don't think RPL should mandate = that behavior. >=20 > Case 2 of 3.3 in MRHOF says: >=20 > 2. The Rank of the member of the parent set with the highest > advertised Rank plus one >=20 > In order for the MRHOF algorithm to cause a node to advertise a rank = which is at least MinHopRankIncrease greater than all of its parents, = this sentence must be changed to say "The Rank of the member of the = parent set with the highest advertised Rank plus MinHopRankIncrease." >=20 > Matteo >=20 >=20 > On Apr 5, 2012, at 12:08 PM, Philip Levis wrote: >=20 >> Comments inline >>=20 >> On Apr 3, 2012, at 6:46 AM, Matteo Paris wrote: >>=20 >>>=20 >>> Hi Phil, >>>=20 >>> my question boils down to whether RPL requires members of the parent = set to have lower DAGRank, or merely lower rank. My reading of the RPL = draft is that all parents must have lower DAGRank. >>=20 >> I think this reading is correct, but not because of the confusing = text you cite. >>=20 >>=20 >>=20 >>>=20 >>> I get this from two clauses in the RPL draft that I quoted below. = Unfortunately both are confusingly worded. >>>=20 >>> RPL Section 3.5.1 says: "A node A has a rank less than the rank of a = node B if DAGRank(A) is less than DAGRank(B)." I believe the intention = here was to say "if and only if", otherwise the clause is pointless = (trivially true). >>=20 >> I don't think you want to interpret this sentence as a definition of = what "lower rank" means. I have no doubt that many portions of the RPL = (or other) specifications do not use the phrase in this way. So it = should be interpreted as "if", not "if and only if." Really, this = sentence shouldn't be in there. >>=20 >>>=20 >>> RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG = parent set must be of rank less than DAGRank(N)." Here, a rank is being = compared with a DAGRank, which is nonsensical, unless "rank" actually = means "DAGRank". It would be much clearer if it said so explicitly, ie = "must be of DAGRank less than DAGRank(N)." =20 >>=20 >> Eh=85 I think interpreting it as DAGRank conflicts with the DIO = processing rules. If you interpret this phrase as all parents must have = a lower DAGRank, this strengthens bullet number 5 of 8.2.2.1 from >>=20 >> 5. A node's Rank MUST be greater than all elements of its DODAG >> parent set. >>=20 >> to >>=20 >> 5. A node's Rank MUST be greater than all elements of its DODAG >> parent set by at least MinHopRankIncrease. >>=20 >> or >>=20 >> 5. A node's DAGRank MUST be greater than all elements of its DODAG >> parent set. >>=20 >> It's important to note that 3.5.2 says >>=20 >> "When Rank is >> compared, e.g., for determination of parent relationships or loop >> detection, the integer portion of the Rank is to be used." >>=20 >> not >>=20 >> "When Rank is >> compared, e.g., for determination of parent relationships or loop >> detection, the integer portion of the Rank MUST be used.=20 >>=20 >>> What is your interpretation -- are parents required to have lower = rank or lower DAGRank? Perhaps the confusion is a result of some text = accidentally left over from an older version of the draft. >>=20 >> I suspect Pascal and I are going to disagree on this, but my = interpretation is that 3.5.2 doesn't mandate that a node advertise a = Rank which is at least MinHopRankIncrease greater than all of its = parents. 8.2.2.1 was written pretty carefully so that a node with a = preferred parent of Rank a and a backup parent of Rank b (b>a) would not = have to always advertise b + MinHopRankIncrease, but rather at least = b+1. >>=20 >> It is useful to note that the MRHOF Rank calculation algorithm *does* = cause a node to advertise a Rank which is at least MinHopRankIncrease = greater than all of its parents. But I don't think RPL should mandate = that behavior. >>=20 >> Phil >=20 >=20 From pthubert@cisco.com Fri Apr 6 08:14:05 2012 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 1959621F85B9 for ; Fri, 6 Apr 2012 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.745 X-Spam-Level: X-Spam-Status: No, score=-8.745 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599, MANGLED_NAIL=2.3, 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 VePaJUCJn+Ls for ; Fri, 6 Apr 2012 08:14:04 -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 7BDCB21F85B6 for ; Fri, 6 Apr 2012 08:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=7070; q=dns/txt; s=iport; t=1333725243; x=1334934843; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=GSO7M1dybIffYV9Lc3J+ta/G7NoBGl02/+AEVPWen7U=; b=f7NTXISkpxciXX0iKC4EyrT4DDi1+HN5+p2t3qJPytSDQSbNMZ1bmume nMQIHHxWu8npqgwXQNSo/2KwoOE7UixQ27vwHtyL0lC4VvMcayOQs15RS TWWuo/vjABEXgL11JHI+Kkds+/ABPz8X2/TTAM9EK7BePwZwf1Fb6jqtx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD4Gf0+Q/khM/2dsb2JhbABFDrkPgQeCCQEBAQMBAQEBDwEdCjQEBQIMBAIBCA4DBAEBAQoGFwEGASYfCQgBAQQBEggah2cFC5pjn3cEj21jBIs9hkmKRIdvgWmCMDk X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="70293872" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 06 Apr 2012 15:14:02 +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 q36FE299021070; Fri, 6 Apr 2012 15:14:02 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); Fri, 6 Apr 2012 17:14:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Apr 2012 17:12:12 +0200 Message-ID: In-Reply-To: <096F0191-8A81-42DE-BAC1-B0620D8A7F84@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt Thread-Index: Ac0UA4NX8BpJBWe8SmSy8dwbg5FLOgAAV/ZA References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com><0500582D-1326-4033-9A82-FD42BB47A29D@ember.com><4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu><9A3B9F20-4F81-4E02-8BB2-5BDEFD63FF2A@ember.com> <096F0191-8A81-42DE-BAC1-B0620D8A7F84@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Matteo Paris" X-OriginalArrivalTime: 06 Apr 2012 15:14:02.0562 (UTC) FILETIME=[E65A5A20:01CD1407] Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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: Fri, 06 Apr 2012 15:14:05 -0000 So maybe that's the +1 that's unclear. Let's dig a bit: Initially the Rank was one octet and things were simple. We extended it to 2 octets to allow for a better truthfulness for some metrics when we add ranks up.=20 Trouble, that could make the rank very sensitive and the structure unstable. To avoid that we defined a rough comparison and to do so we picked a decimal part and a floor.=20 With that rough comparison, a 2 bytes rank would slightly fluctuate without changing the nodes relationship. Unless it fluctuates at the decimal boundary and that's when the hysteresis helps you. So in the end we end up with a decimal part to play additions with, but the integral part of the rank is the piece used for orienting the DAG. That's the whole point of having a decimal part and all those macros. So a node can have a parent that has its rank +1 but not all nodes with rank+1 can be parent. You need to reach the next floor. What's needed is less than min increase but usually more than 1. Until late in the process we could use nodes of same integral floor for forwarding, but that was removed from the spec. This is something that is dearly missed in the environment I'm familiar with. Cheers; Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: vendredi 6 avril 2012 16:42 To: Matteo Paris Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt Pascal wrote the text in 3.5, and it seems like he doesn't agree with your interpretation... Phil On Apr 6, 2012, at 6:57 AM, Matteo Paris wrote: >=20 > Hi Phil. Thanks for the reply. I too would prefer if parents were only required to have lower rank, not lower interger portion of rank. Unfortunately that is not how the RFC reads. All of 3.5.1 "Rank Comparison" and 3.5.2 "Rank Relationships" are devoted to explaining that ranks should be compared using only their integer portions. You quoted another excellent example below. As another example, 3.5.2 also spends a paragraph clarifying that nodes should not route through a node with equal DAGRank (equal integer portion of rank), which is to say that parents must have lower integer part. =20 >=20 > As it stands, I think the only logically consistent way to read the spec is to compare ranks as prescribed in 3.5.1 and 3.5.2. Note that doing so does not logically conflict with 8.2.1 case 5, it simply modifies its meaning. Only if we entirely ignore those two sections, can we then compare ranks in the more sensible way that we all prefer. If that is the desire, we should submit an RFC errata. In its current state I do not believe a first time reader of the RFC can know that 3.5.1 and 3.5.2 do not apply. >=20 >> It is useful to note that the MRHOF Rank calculation algorithm *does* cause a node to advertise a Rank which is at least MinHopRankIncrease greater than all of its parents. But I don't think RPL should mandate that behavior. >=20 > Case 2 of 3.3 in MRHOF says: >=20 > 2. The Rank of the member of the parent set with the highest > advertised Rank plus one >=20 > In order for the MRHOF algorithm to cause a node to advertise a rank which is at least MinHopRankIncrease greater than all of its parents, this sentence must be changed to say "The Rank of the member of the parent set with the highest advertised Rank plus MinHopRankIncrease." >=20 > Matteo >=20 >=20 > On Apr 5, 2012, at 12:08 PM, Philip Levis wrote: >=20 >> Comments inline >>=20 >> On Apr 3, 2012, at 6:46 AM, Matteo Paris wrote: >>=20 >>>=20 >>> Hi Phil, >>>=20 >>> my question boils down to whether RPL requires members of the parent set to have lower DAGRank, or merely lower rank. My reading of the RPL draft is that all parents must have lower DAGRank. >>=20 >> I think this reading is correct, but not because of the confusing text you cite. >>=20 >>=20 >>=20 >>>=20 >>> I get this from two clauses in the RPL draft that I quoted below. Unfortunately both are confusingly worded. >>>=20 >>> RPL Section 3.5.1 says: "A node A has a rank less than the rank of a node B if DAGRank(A) is less than DAGRank(B)." I believe the intention here was to say "if and only if", otherwise the clause is pointless (trivially true). >>=20 >> I don't think you want to interpret this sentence as a definition of what "lower rank" means. I have no doubt that many portions of the RPL (or other) specifications do not use the phrase in this way. So it should be interpreted as "if", not "if and only if." Really, this sentence shouldn't be in there. >>=20 >>>=20 >>> RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG parent set must be of rank less than DAGRank(N)." Here, a rank is being compared with a DAGRank, which is nonsensical, unless "rank" actually means "DAGRank". It would be much clearer if it said so explicitly, ie "must be of DAGRank less than DAGRank(N)." =20 >>=20 >> Eh... I think interpreting it as DAGRank conflicts with the DIO=20 >> processing rules. If you interpret this phrase as all parents must=20 >> have a lower DAGRank, this strengthens bullet number 5 of 8.2.2.1=20 >> from >>=20 >> 5. A node's Rank MUST be greater than all elements of its DODAG >> parent set. >>=20 >> to >>=20 >> 5. A node's Rank MUST be greater than all elements of its DODAG >> parent set by at least MinHopRankIncrease. >>=20 >> or >>=20 >> 5. A node's DAGRank MUST be greater than all elements of its DODAG >> parent set. >>=20 >> It's important to note that 3.5.2 says >>=20 >> "When Rank is >> compared, e.g., for determination of parent relationships or loop =20 >> detection, the integer portion of the Rank is to be used." >>=20 >> not >>=20 >> "When Rank is >> compared, e.g., for determination of parent relationships or loop =20 >> detection, the integer portion of the Rank MUST be used. >>=20 >>> What is your interpretation -- are parents required to have lower rank or lower DAGRank? Perhaps the confusion is a result of some text accidentally left over from an older version of the draft. >>=20 >> I suspect Pascal and I are going to disagree on this, but my interpretation is that 3.5.2 doesn't mandate that a node advertise a Rank which is at least MinHopRankIncrease greater than all of its parents. 8.2.2.1 was written pretty carefully so that a node with a preferred parent of Rank a and a backup parent of Rank b (b>a) would not have to always advertise b + MinHopRankIncrease, but rather at least b+1. >>=20 >> It is useful to note that the MRHOF Rank calculation algorithm *does* cause a node to advertise a Rank which is at least MinHopRankIncrease greater than all of its parents. But I don't think RPL should mandate that behavior. >>=20 >> Phil >=20 >=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From matteo@ember.com Fri Apr 6 08:23:15 2012 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 5BDC121F855F for ; Fri, 6 Apr 2012 08:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.067 X-Spam-Level: X-Spam-Status: No, score=-4.067 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, MANGLED_NAIL=2.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 ResdAhf7BBzR for ; Fri, 6 Apr 2012 08:23:14 -0700 (PDT) Received: from p01c12o147.mxlogic.net (p01c12o147.mxlogic.net [208.65.145.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC2D21F8525 for ; Fri, 6 Apr 2012 08:23:14 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO p01c12o147.mxlogic.net) by p01c12o147.mxlogic.net(mxl_mta-6.13.0-3) with ESMTP id 26a0f7f4.5da88940.72233.00-538.170448.p01c12o147.mxlogic.net (envelope-from ); Fri, 06 Apr 2012 09:23:14 -0600 (MDT) X-MXL-Hash: 4f7f0a621b7aa7a7-17692f38836eadb58b6f0cff8e927b7f5d1506a6 Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c12o147.mxlogic.net(mxl_mta-6.13.0-3) over TLS secured channel with ESMTP id 06a0f7f4.0.72224.00-385.170434.p01c12o147.mxlogic.net (envelope-from ); Fri, 06 Apr 2012 09:23:13 -0600 (MDT) X-MXL-Hash: 4f7f0a613f1b9829-5bfe9e2c4ce388e3046bd6a6cd8e058c3b2d71fc Received: from USMAIL.hq.ember.com ([fe80::414:51ae:1b16:3f29]) by USMail.hq.ember.com ([fe80::414:51ae:1b16:3f29%10]) with mapi id 14.01.0355.002; Fri, 6 Apr 2012 11:24:36 -0400 From: Matteo Paris To: "Pascal Thubert (pthubert)" Thread-Topic: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt Thread-Index: AQHNFAgaw4zWw2hRN06QpM9f634A3paOLVaA Date: Fri, 6 Apr 2012 15:24:35 +0000 Message-ID: <91F498D5-17DF-4E09-946B-B1A1482B52B1@ember.com> References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com><0500582D-1326-4033-9A82-FD42BB47A29D@ember.com><4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu><9A3B9F20-4F81-4E02-8BB2-5BDEFD63FF2A@ember.com> <096F0191-8A81-42DE-BAC1-B0620D8A7F84@cs.stanford.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.81.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <980728350C890749AF3BFB84D1B075F3@ember.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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=PvnVXCDccy0A:10 a=5z0JwrYOEKUA:10 a=saA6nF2ZJa] X-AnalysisOut: [AA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:1] X-AnalysisOut: [0 a=MYqPJgym4Kx47q1P90kooQ==:17 a=48vgC7mUAAAA:8 a=M83n4-6] X-AnalysisOut: [ZIb_FTrT4f5IA:9 a=cieT38mFdQTKDgP_LzsA:7 a=CjuIK1q_8ugA:10] X-AnalysisOut: [ a=lZB815dzVvQA:10 a=YqOfCPvunYs6s-1-:21 a=7L9GVteuvQqFh9M] X-AnalysisOut: [U:21] Cc: "" Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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: Fri, 06 Apr 2012 15:23:15 -0000 Hi Pascal, > Until late in the process we could use nodes of same integral floor for > forwarding, but that was removed from the spec. This is something that > is dearly missed in the environment I'm familiar with. So you agree that sections 3.5.1 and 3.5.2 prohibit using a parent of the s= ame integral floor for forwarding? Matteo On Apr 6, 2012, at 11:12 AM, Pascal Thubert (pthubert) wrote: > So maybe that's the +1 that's unclear. Let's dig a bit: >=20 > Initially the Rank was one octet and things were simple. >=20 > We extended it to 2 octets to allow for a better truthfulness for some > metrics when we add ranks up.=20 >=20 > Trouble, that could make the rank very sensitive and the structure > unstable. To avoid that we defined a rough comparison and to do so we > picked a decimal part and a floor.=20 >=20 > With that rough comparison, a 2 bytes rank would slightly fluctuate > without changing the nodes relationship. Unless it fluctuates at the > decimal boundary and that's when the hysteresis helps you. >=20 > So in the end we end up with a decimal part to play additions with, but > the integral part of the rank is the piece used for orienting the DAG. > That's the whole point of having a decimal part and all those macros. >=20 > So a node can have a parent that has its rank +1 but not all nodes with > rank+1 can be parent. You need to reach the next floor. What's needed is > less than min increase but usually more than 1. >=20 > Until late in the process we could use nodes of same integral floor for > forwarding, but that was removed from the spec. This is something that > is dearly missed in the environment I'm familiar with. >=20 > Cheers; >=20 > Pascal >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: vendredi 6 avril 2012 16:42 > To: Matteo Paris > Cc: roll@ietf.org > Subject: Re: [Roll] New Version Notification > -draft-ietf-roll-minrank-hysteresis-of-07.txt >=20 > Pascal wrote the text in 3.5, and it seems like he doesn't agree with > your interpretation... >=20 > Phil >=20 > On Apr 6, 2012, at 6:57 AM, Matteo Paris wrote: >=20 >>=20 >> Hi Phil. Thanks for the reply. I too would prefer if parents were > only required to have lower rank, not lower interger portion of rank. > Unfortunately that is not how the RFC reads. All of 3.5.1 "Rank > Comparison" and 3.5.2 "Rank Relationships" are devoted to explaining > that ranks should be compared using only their integer portions. You > quoted another excellent example below. As another example, 3.5.2 also > spends a paragraph clarifying that nodes should not route through a node > with equal DAGRank (equal integer portion of rank), which is to say that > parents must have lower integer part. =20 >>=20 >> As it stands, I think the only logically consistent way to read the > spec is to compare ranks as prescribed in 3.5.1 and 3.5.2. Note that > doing so does not logically conflict with 8.2.1 case 5, it simply > modifies its meaning. Only if we entirely ignore those two sections, > can we then compare ranks in the more sensible way that we all prefer. > If that is the desire, we should submit an RFC errata. In its current > state I do not believe a first time reader of the RFC can know that > 3.5.1 and 3.5.2 do not apply. >>=20 >>> It is useful to note that the MRHOF Rank calculation algorithm *does* > cause a node to advertise a Rank which is at least MinHopRankIncrease > greater than all of its parents. But I don't think RPL should mandate > that behavior. >>=20 >> Case 2 of 3.3 in MRHOF says: >>=20 >> 2. The Rank of the member of the parent set with the highest >> advertised Rank plus one >>=20 >> In order for the MRHOF algorithm to cause a node to advertise a rank > which is at least MinHopRankIncrease greater than all of its parents, > this sentence must be changed to say "The Rank of the member of the > parent set with the highest advertised Rank plus MinHopRankIncrease." >>=20 >> Matteo >>=20 >>=20 >> On Apr 5, 2012, at 12:08 PM, Philip Levis wrote: >>=20 >>> Comments inline >>>=20 >>> On Apr 3, 2012, at 6:46 AM, Matteo Paris wrote: >>>=20 >>>>=20 >>>> Hi Phil, >>>>=20 >>>> my question boils down to whether RPL requires members of the parent > set to have lower DAGRank, or merely lower rank. My reading of the RPL > draft is that all parents must have lower DAGRank. >>>=20 >>> I think this reading is correct, but not because of the confusing > text you cite. >>>=20 >>>=20 >>>=20 >>>>=20 >>>> I get this from two clauses in the RPL draft that I quoted below. > Unfortunately both are confusingly worded. >>>>=20 >>>> RPL Section 3.5.1 says: "A node A has a rank less than the rank of a > node B if DAGRank(A) is less than DAGRank(B)." I believe the intention > here was to say "if and only if", otherwise the clause is pointless > (trivially true). >>>=20 >>> I don't think you want to interpret this sentence as a definition of > what "lower rank" means. I have no doubt that many portions of the RPL > (or other) specifications do not use the phrase in this way. So it > should be interpreted as "if", not "if and only if." Really, this > sentence shouldn't be in there. >>>=20 >>>>=20 >>>> RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG > parent set must be of rank less than DAGRank(N)." Here, a rank is being > compared with a DAGRank, which is nonsensical, unless "rank" actually > means "DAGRank". It would be much clearer if it said so explicitly, ie > "must be of DAGRank less than DAGRank(N)." =20 >>>=20 >>> Eh... I think interpreting it as DAGRank conflicts with the DIO=20 >>> processing rules. If you interpret this phrase as all parents must=20 >>> have a lower DAGRank, this strengthens bullet number 5 of 8.2.2.1=20 >>> from >>>=20 >>> 5. A node's Rank MUST be greater than all elements of its DODAG >>> parent set. >>>=20 >>> to >>>=20 >>> 5. A node's Rank MUST be greater than all elements of its DODAG >>> parent set by at least MinHopRankIncrease. >>>=20 >>> or >>>=20 >>> 5. A node's DAGRank MUST be greater than all elements of its DODAG >>> parent set. >>>=20 >>> It's important to note that 3.5.2 says >>>=20 >>> "When Rank is >>> compared, e.g., for determination of parent relationships or loop =20 >>> detection, the integer portion of the Rank is to be used." >>>=20 >>> not >>>=20 >>> "When Rank is >>> compared, e.g., for determination of parent relationships or loop =20 >>> detection, the integer portion of the Rank MUST be used. >>>=20 >>>> What is your interpretation -- are parents required to have lower > rank or lower DAGRank? Perhaps the confusion is a result of some text > accidentally left over from an older version of the draft. >>>=20 >>> I suspect Pascal and I are going to disagree on this, but my > interpretation is that 3.5.2 doesn't mandate that a node advertise a > Rank which is at least MinHopRankIncrease greater than all of its > parents. 8.2.2.1 was written pretty carefully so that a node with a > preferred parent of Rank a and a backup parent of Rank b (b>a) would not > have to always advertise b + MinHopRankIncrease, but rather at least > b+1. >>>=20 >>> It is useful to note that the MRHOF Rank calculation algorithm *does* > cause a node to advertise a Rank which is at least MinHopRankIncrease > greater than all of its parents. But I don't think RPL should mandate > that behavior. >>>=20 >>> Phil >>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Fri Apr 6 10:12:39 2012 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 2A1D721F85CC for ; Fri, 6 Apr 2012 10:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.395 X-Spam-Level: X-Spam-Status: No, score=-8.395 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MANGLED_NAIL=2.3, 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 G8w1qvS10JB0 for ; Fri, 6 Apr 2012 10:12:38 -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 A57F321F8585 for ; Fri, 6 Apr 2012 10:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=8794; q=dns/txt; s=iport; t=1333732357; x=1334941957; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=fmy9YoHG7ufHSuVktXRFLX+QPXtD3UGDJ/VNHESaArs=; b=XPQ7JcocMQjVuVfi9hZELUKgBvNyI3nR88gS0GPF6nvKmX2kfe4RIYfj 3jSHg5aL40CtneahaGalYGtH6MmPEE/KBwSBmea5Xmjby7LFcNOFR36sV rd8W7L4+QGVY3PWXLhURTN9ST2KJ46KOKDR67OzoYyDWw/z5yfkZUIZ7d c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMQif0+Q/khM/2dsb2JhbABDuSqBB4IJAQEBAwEBAQEPAR0KNAQFAgUHBAIBCBEEAQEBCgYXAQYBJh8JCAIEEwgah2cFC55bmAYEj21jBIs9hkmKRIdvgWmCaQ X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="70298837" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 06 Apr 2012 17:12:30 +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 q36HCUaa004973; Fri, 6 Apr 2012 17:12:30 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); Fri, 6 Apr 2012 19:12:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Apr 2012 19:11:39 +0200 Message-ID: In-Reply-To: <91F498D5-17DF-4E09-946B-B1A1482B52B1@ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt Thread-Index: AQHNFAgaw4zWw2hRN06QpM9f634A3paOLVaA///ZpDA= References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com><0500582D-1326-4033-9A82-FD42BB47A29D@ember.com><4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu><9A3B9F20-4F81-4E02-8BB2-5BDEFD63FF2A@ember.com> <096F0191-8A81-42DE-BAC1-B0620D8A7F84@cs.stanford.edu> <91F498D5-17DF-4E09-946B-B1A1482B52B1@ember.com> From: "Pascal Thubert (pthubert)" To: "Matteo Paris" X-OriginalArrivalTime: 06 Apr 2012 17:12:30.0468 (UTC) FILETIME=[72FEBC40:01CD1418] Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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: Fri, 06 Apr 2012 17:12:39 -0000 Hi Matteo: I agree that sections 3.5.1 and 3.5.2 prohibit using a parent of the same integral floor for forwarding. This is the state of the spec and there is no erratum in there. We lost that capability late in the process. You might find the history associated to the word "sibling". We removed siblings to seek maximum simplicity. For nodes more capable, they could be reintroduced.=20 The point is that for siblings, we'll have to define something new to avoid long loops.=20 Maybe we could write an experimental addition? Cheers, Pascal -----Original Message----- From: Matteo Paris [mailto:matteo@ember.com]=20 Sent: vendredi 6 avril 2012 17:25 To: Pascal Thubert (pthubert) Cc: Philip Levis; Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt Hi Pascal, > Until late in the process we could use nodes of same integral floor=20 > for forwarding, but that was removed from the spec. This is something=20 > that is dearly missed in the environment I'm familiar with. So you agree that sections 3.5.1 and 3.5.2 prohibit using a parent of the same integral floor for forwarding? Matteo On Apr 6, 2012, at 11:12 AM, Pascal Thubert (pthubert) wrote: > So maybe that's the +1 that's unclear. Let's dig a bit: >=20 > Initially the Rank was one octet and things were simple. >=20 > We extended it to 2 octets to allow for a better truthfulness for some > metrics when we add ranks up. >=20 > Trouble, that could make the rank very sensitive and the structure=20 > unstable. To avoid that we defined a rough comparison and to do so we=20 > picked a decimal part and a floor. >=20 > With that rough comparison, a 2 bytes rank would slightly fluctuate=20 > without changing the nodes relationship. Unless it fluctuates at the=20 > decimal boundary and that's when the hysteresis helps you. >=20 > So in the end we end up with a decimal part to play additions with,=20 > but the integral part of the rank is the piece used for orienting the DAG. > That's the whole point of having a decimal part and all those macros. >=20 > So a node can have a parent that has its rank +1 but not all nodes=20 > with > rank+1 can be parent. You need to reach the next floor. What's needed=20 > rank+is > less than min increase but usually more than 1. >=20 > Until late in the process we could use nodes of same integral floor=20 > for forwarding, but that was removed from the spec. This is something=20 > that is dearly missed in the environment I'm familiar with. >=20 > Cheers; >=20 > Pascal >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Philip Levis > Sent: vendredi 6 avril 2012 16:42 > To: Matteo Paris > Cc: roll@ietf.org > Subject: Re: [Roll] New Version Notification=20 > -draft-ietf-roll-minrank-hysteresis-of-07.txt >=20 > Pascal wrote the text in 3.5, and it seems like he doesn't agree with=20 > your interpretation... >=20 > Phil >=20 > On Apr 6, 2012, at 6:57 AM, Matteo Paris wrote: >=20 >>=20 >> Hi Phil. Thanks for the reply. I too would prefer if parents were > only required to have lower rank, not lower interger portion of rank. > Unfortunately that is not how the RFC reads. All of 3.5.1 "Rank=20 > Comparison" and 3.5.2 "Rank Relationships" are devoted to explaining=20 > that ranks should be compared using only their integer portions. You=20 > quoted another excellent example below. As another example, 3.5.2=20 > also spends a paragraph clarifying that nodes should not route through > a node with equal DAGRank (equal integer portion of rank), which is to > say that parents must have lower integer part. >>=20 >> As it stands, I think the only logically consistent way to read the > spec is to compare ranks as prescribed in 3.5.1 and 3.5.2. Note that=20 > doing so does not logically conflict with 8.2.1 case 5, it simply=20 > modifies its meaning. Only if we entirely ignore those two sections,=20 > can we then compare ranks in the more sensible way that we all prefer. > If that is the desire, we should submit an RFC errata. In its current > state I do not believe a first time reader of the RFC can know that > 3.5.1 and 3.5.2 do not apply. >>=20 >>> It is useful to note that the MRHOF Rank calculation algorithm=20 >>> *does* > cause a node to advertise a Rank which is at least MinHopRankIncrease=20 > greater than all of its parents. But I don't think RPL should mandate=20 > that behavior. >>=20 >> Case 2 of 3.3 in MRHOF says: >>=20 >> 2. The Rank of the member of the parent set with the highest >> advertised Rank plus one >>=20 >> In order for the MRHOF algorithm to cause a node to advertise a rank > which is at least MinHopRankIncrease greater than all of its parents,=20 > this sentence must be changed to say "The Rank of the member of the=20 > parent set with the highest advertised Rank plus MinHopRankIncrease." >>=20 >> Matteo >>=20 >>=20 >> On Apr 5, 2012, at 12:08 PM, Philip Levis wrote: >>=20 >>> Comments inline >>>=20 >>> On Apr 3, 2012, at 6:46 AM, Matteo Paris wrote: >>>=20 >>>>=20 >>>> Hi Phil, >>>>=20 >>>> my question boils down to whether RPL requires members of the=20 >>>> parent > set to have lower DAGRank, or merely lower rank. My reading of the=20 > RPL draft is that all parents must have lower DAGRank. >>>=20 >>> I think this reading is correct, but not because of the confusing > text you cite. >>>=20 >>>=20 >>>=20 >>>>=20 >>>> I get this from two clauses in the RPL draft that I quoted below. > Unfortunately both are confusingly worded. >>>>=20 >>>> RPL Section 3.5.1 says: "A node A has a rank less than the rank of=20 >>>> a > node B if DAGRank(A) is less than DAGRank(B)." I believe the=20 > intention here was to say "if and only if", otherwise the clause is=20 > pointless (trivially true). >>>=20 >>> I don't think you want to interpret this sentence as a definition of > what "lower rank" means. I have no doubt that many portions of the RPL > (or other) specifications do not use the phrase in this way. So it=20 > should be interpreted as "if", not "if and only if." Really, this=20 > sentence shouldn't be in there. >>>=20 >>>>=20 >>>> RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG > parent set must be of rank less than DAGRank(N)." Here, a rank is=20 > being compared with a DAGRank, which is nonsensical, unless "rank"=20 > actually means "DAGRank". It would be much clearer if it said so=20 > explicitly, ie "must be of DAGRank less than DAGRank(N)." >>>=20 >>> Eh... I think interpreting it as DAGRank conflicts with the DIO=20 >>> processing rules. If you interpret this phrase as all parents must=20 >>> have a lower DAGRank, this strengthens bullet number 5 of 8.2.2.1=20 >>> from >>>=20 >>> 5. A node's Rank MUST be greater than all elements of its DODAG >>> parent set. >>>=20 >>> to >>>=20 >>> 5. A node's Rank MUST be greater than all elements of its DODAG >>> parent set by at least MinHopRankIncrease. >>>=20 >>> or >>>=20 >>> 5. A node's DAGRank MUST be greater than all elements of its DODAG >>> parent set. >>>=20 >>> It's important to note that 3.5.2 says >>>=20 >>> "When Rank is >>> compared, e.g., for determination of parent relationships or loop=20 >>> detection, the integer portion of the Rank is to be used." >>>=20 >>> not >>>=20 >>> "When Rank is >>> compared, e.g., for determination of parent relationships or loop=20 >>> detection, the integer portion of the Rank MUST be used. >>>=20 >>>> What is your interpretation -- are parents required to have lower > rank or lower DAGRank? Perhaps the confusion is a result of some text=20 > accidentally left over from an older version of the draft. >>>=20 >>> I suspect Pascal and I are going to disagree on this, but my > interpretation is that 3.5.2 doesn't mandate that a node advertise a=20 > Rank which is at least MinHopRankIncrease greater than all of its=20 > parents. 8.2.2.1 was written pretty carefully so that a node with a=20 > preferred parent of Rank a and a backup parent of Rank b (b>a) would=20 > not have to always advertise b + MinHopRankIncrease, but rather at=20 > least > b+1. >>>=20 >>> It is useful to note that the MRHOF Rank calculation algorithm=20 >>> *does* > cause a node to advertise a Rank which is at least MinHopRankIncrease=20 > greater than all of its parents. But I don't think RPL should mandate=20 > that behavior. >>>=20 >>> Phil >>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From matteo@ember.com Fri Apr 6 12:02:28 2012 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 1CDC921F855B for ; Fri, 6 Apr 2012 12:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MANGLED_NAIL=2.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 9CQ1sL97SJkK for ; Fri, 6 Apr 2012 12:02:26 -0700 (PDT) Received: from p01c11o145.mxlogic.net (p01c11o145.mxlogic.net [208.65.144.68]) by ietfa.amsl.com (Postfix) with ESMTP id E881721F8565 for ; Fri, 6 Apr 2012 12:02:25 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO p01c11o145.mxlogic.net) by p01c11o145.mxlogic.net(mxl_mta-6.13.0-3) with ESMTP id 1cd3f7f4.60839940.65635.00-577.138415.p01c11o145.mxlogic.net (envelope-from ); Fri, 06 Apr 2012 13:02:25 -0600 (MDT) X-MXL-Hash: 4f7f3dc135f3b67b-a0e93b368902fceb2b708e6b0993fd78aa566735 Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c11o145.mxlogic.net(mxl_mta-6.13.0-3) over TLS secured channel with ESMTP id cbd3f7f4.0.65612.00-321.138329.p01c11o145.mxlogic.net (envelope-from ); Fri, 06 Apr 2012 13:02:22 -0600 (MDT) X-MXL-Hash: 4f7f3dbe10fdde80-fa95fb3d1ec70681dbccfff5bb183c2284f35118 Received: from USMAIL.hq.ember.com ([fe80::414:51ae:1b16:3f29]) by USMail.hq.ember.com ([fe80::414:51ae:1b16:3f29%10]) with mapi id 14.01.0355.002; Fri, 6 Apr 2012 15:03:43 -0400 From: Matteo Paris To: "Pascal Thubert (pthubert)" Thread-Topic: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt Thread-Index: AQHNFAgaw4zWw2hRN06QpM9f634A3paOLVaA///ZpDCAAGOSAA== Date: Fri, 6 Apr 2012 19:03:42 +0000 Message-ID: <0CBC03E3-6E9D-4CBC-AF4D-172A6D0FC5EB@ember.com> References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com><0500582D-1326-4033-9A82-FD42BB47A29D@ember.com><4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu><9A3B9F20-4F81-4E02-8BB2-5BDEFD63FF2A@ember.com> <096F0191-8A81-42DE-BAC1-B0620D8A7F84@cs.stanford.edu> <91F498D5-17DF-4E09-946B-B1A1482B52B1@ember.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.81.69] Content-Type: multipart/alternative; boundary="_000_0CBC03E36E9D4CBCAF4D172A6D0FC5EBembercom_" MIME-Version: 1.0 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=f-O475ulcV8A:10 a=5z0JwrYOEKUA:10 a=saA6nF2ZJa] X-AnalysisOut: [AA:10 a=BLceEmwcHowA:10 a=xqWC_Br6kY4A:10 a=MYqPJgym4Kx47q] X-AnalysisOut: [1P90kooQ==:17 a=OQ_ktunLAAAA:8 a=48vgC7mUAAAA:8 a=hyDy-jrm] X-AnalysisOut: [c7Ut29KBhMEA:9 a=Tcr1gyO4QAg0eDCgQa4A:7 a=CjuIK1q_8ugA:10 ] X-AnalysisOut: [a=AuRza0os8rYA:10 a=lZB815dzVvQA:10 a=m1Uf_wYYc9UJbwMV:21 ] X-AnalysisOut: [a=Y4WZiGsRB4lmphWq:21 a=YdAvOJjoJnlaUb_z8KIA:9 a=Ipov9xhey] X-AnalysisOut: [GAY1XB-lTAA:7 a=_W_S_7VecoQA:10 a=-N2ADOc4ZtEA29m_:21 a=uq] X-AnalysisOut: [GQX89B2JdwlGLM:21] Cc: "" Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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: Fri, 06 Apr 2012 19:02:28 -0000 --_000_0CBC03E36E9D4CBCAF4D172A6D0FC5EBembercom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Pascal. Back to the original subject, this requires a change to MRHOF section 3.3 c= ase 2 to ensure that a node's rank does not have the same integral floor as= any of its parents: 2. The Rank of the member of the parent set with the highest advertised Rank plus one I can think of three possible changes, listed in increasing order of the am= ount added to the highest advertised Rank: 2a. The Rank of the member of the parent set with the highest advertised Ra= nk, rounded to the next higher integral Rank, ie, to MinHopRankIncrease * (= 1 + floor(Rank/MinHopRankIncrease)). 2b. The Rank of the member of the parent set with the highest advertised Ra= nk plus MinHopRankIncrease. 2c. The Rank associated with the path through the member of the parent set = with the highest advertised Rank. Matteo On Apr 6, 2012, at 1:11 PM, Pascal Thubert (pthubert) wrote: Hi Matteo: I agree that sections 3.5.1 and 3.5.2 prohibit using a parent of the same integral floor for forwarding. This is the state of the spec and there is no erratum in there. We lost that capability late in the process. You might find the history associated to the word "sibling". We removed siblings to seek maximum simplicity. For nodes more capable, they could be reintroduced. The point is that for siblings, we'll have to define something new to avoid long loops. Maybe we could write an experimental addition? Cheers, Pascal -----Original Message----- From: Matteo Paris [mailto:matteo@ember.com] Sent: vendredi 6 avril 2012 17:25 To: Pascal Thubert (pthubert) Cc: Philip Levis; > Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt Hi Pascal, Until late in the process we could use nodes of same integral floor for forwarding, but that was removed from the spec. This is something that is dearly missed in the environment I'm familiar with. So you agree that sections 3.5.1 and 3.5.2 prohibit using a parent of the same integral floor for forwarding? Matteo On Apr 6, 2012, at 11:12 AM, Pascal Thubert (pthubert) wrote: So maybe that's the +1 that's unclear. Let's dig a bit: Initially the Rank was one octet and things were simple. We extended it to 2 octets to allow for a better truthfulness for some metrics when we add ranks up. Trouble, that could make the rank very sensitive and the structure unstable. To avoid that we defined a rough comparison and to do so we picked a decimal part and a floor. With that rough comparison, a 2 bytes rank would slightly fluctuate without changing the nodes relationship. Unless it fluctuates at the decimal boundary and that's when the hysteresis helps you. So in the end we end up with a decimal part to play additions with, but the integral part of the rank is the piece used for orienting the DAG. That's the whole point of having a decimal part and all those macros. So a node can have a parent that has its rank +1 but not all nodes with rank+1 can be parent. You need to reach the next floor. What's needed rank+is less than min increase but usually more than 1. Until late in the process we could use nodes of same integral floor for forwarding, but that was removed from the spec. This is something that is dearly missed in the environment I'm familiar with. Cheers; Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-boun= ces@ietf.org] On Behalf Of Philip Levis Sent: vendredi 6 avril 2012 16:42 To: Matteo Paris Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt Pascal wrote the text in 3.5, and it seems like he doesn't agree with your interpretation... Phil On Apr 6, 2012, at 6:57 AM, Matteo Paris wrote: Hi Phil. Thanks for the reply. I too would prefer if parents were only required to have lower rank, not lower interger portion of rank. Unfortunately that is not how the RFC reads. All of 3.5.1 "Rank Comparison" and 3.5.2 "Rank Relationships" are devoted to explaining that ranks should be compared using only their integer portions. You quoted another excellent example below. As another example, 3.5.2 also spends a paragraph clarifying that nodes should not route through a node with equal DAGRank (equal integer portion of rank), which is to say that parents must have lower integer part. As it stands, I think the only logically consistent way to read the spec is to compare ranks as prescribed in 3.5.1 and 3.5.2. Note that doing so does not logically conflict with 8.2.1 case 5, it simply modifies its meaning. Only if we entirely ignore those two sections, can we then compare ranks in the more sensible way that we all prefer. If that is the desire, we should submit an RFC errata. In its current state I do not believe a first time reader of the RFC can know that 3.5.1 and 3.5.2 do not apply. It is useful to note that the MRHOF Rank calculation algorithm *does* cause a node to advertise a Rank which is at least MinHopRankIncrease greater than all of its parents. But I don't think RPL should mandate that behavior. Case 2 of 3.3 in MRHOF says: 2. The Rank of the member of the parent set with the highest advertised Rank plus one In order for the MRHOF algorithm to cause a node to advertise a rank which is at least MinHopRankIncrease greater than all of its parents, this sentence must be changed to say "The Rank of the member of the parent set with the highest advertised Rank plus MinHopRankIncrease." Matteo On Apr 5, 2012, at 12:08 PM, Philip Levis wrote: Comments inline On Apr 3, 2012, at 6:46 AM, Matteo Paris wrote: Hi Phil, my question boils down to whether RPL requires members of the parent set to have lower DAGRank, or merely lower rank. My reading of the RPL draft is that all parents must have lower DAGRank. I think this reading is correct, but not because of the confusing text you cite. I get this from two clauses in the RPL draft that I quoted below. Unfortunately both are confusingly worded. RPL Section 3.5.1 says: "A node A has a rank less than the rank of a node B if DAGRank(A) is less than DAGRank(B)." I believe the intention here was to say "if and only if", otherwise the clause is pointless (trivially true). I don't think you want to interpret this sentence as a definition of what "lower rank" means. I have no doubt that many portions of the RPL (or other) specifications do not use the phrase in this way. So it should be interpreted as "if", not "if and only if." Really, this sentence shouldn't be in there. RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG parent set must be of rank less than DAGRank(N)." Here, a rank is being compared with a DAGRank, which is nonsensical, unless "rank" actually means "DAGRank". It would be much clearer if it said so explicitly, ie "must be of DAGRank less than DAGRank(N)." Eh... I think interpreting it as DAGRank conflicts with the DIO processing rules. If you interpret this phrase as all parents must have a lower DAGRank, this strengthens bullet number 5 of 8.2.2.1 from 5. A node's Rank MUST be greater than all elements of its DODAG parent set. to 5. A node's Rank MUST be greater than all elements of its DODAG parent set by at least MinHopRankIncrease. or 5. A node's DAGRank MUST be greater than all elements of its DODAG parent set. It's important to note that 3.5.2 says "When Rank is compared, e.g., for determination of parent relationships or loop detection, the integer portion of the Rank is to be used." not "When Rank is compared, e.g., for determination of parent relationships or loop detection, the integer portion of the Rank MUST be used. What is your interpretation -- are parents required to have lower rank or lower DAGRank? Perhaps the confusion is a result of some text accidentally left over from an older version of the draft. I suspect Pascal and I are going to disagree on this, but my interpretation is that 3.5.2 doesn't mandate that a node advertise a Rank which is at least MinHopRankIncrease greater than all of its parents. 8.2.2.1 was written pretty carefully so that a node with a preferred parent of Rank a and a backup parent of Rank b (b>a) would not have to always advertise b + MinHopRankIncrease, but rather at least b+1. It is useful to note that the MRHOF Rank calculation algorithm *does* cause a node to advertise a Rank which is at least MinHopRankIncrease greater than all of its parents. But I don't think RPL should mandate that behavior. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_0CBC03E36E9D4CBCAF4D172A6D0FC5EBembercom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Thanks Pascal.

Back to the original subject, this requires a change to MRHOF section = 3.3 case 2 to ensure that a node's rank does not have the same integral flo= or as any of its parents:

2.  The Rank of the member of the parent set with the highest
    advertised Rank plus one

I can think of three possible changes, listed in increasing order of t= he amount added to the highest advertised Rank:

2a. The Rank of the member of the parent set with the highest advertis= ed Rank, rounded to the next higher integral Rank, ie, to MinHopRankIncreas= e * (1 + floor(Rank/MinHopRankIncrease)).

2b. The Rank of the member of the parent set with the highest&nbs= p;advertised Rank plus MinHopRankIncrease.

2c. The Rank associated with the path through the member of the parent= set with the highest advertised Rank.

Matteo

On Apr 6, 2012, at 1:11 PM, Pascal Thubert (pthubert) wrote:

Hi Matteo:

I agree that sections 3.5.1 and 3.5.2 prohibit using a parent of the
same integral floor for forwarding.
This is the state of the spec and there is no erratum in there.

We lost that capability late in the process. You might find the history
associated to the word "sibling".
We removed siblings to seek maximum simplicity. For nodes more capable,
they could be reintroduced.
The point is that for siblings, we'll have to define something new to
avoid long loops.

Maybe we could write an experimental addition?

Cheers,

Pascal


-----Original Message-----
From: Matteo Paris [mailto:matteo@ember.com]
Sent: vendredi 6 avril 2012 17:25
To: Pascal Thubert (pthubert)
Cc: Philip Levis; <roll@ietf.org>= ;
Subject: Re: [Roll] New Version Notification
-draft-ietf-roll-minrank-hysteresis-of-07.txt

Hi Pascal,

Until late in the process we could use nodes of s= ame integral floor
for forwarding, but that was removed from the spe= c. This is something
that is dearly missed in the environment I'm fami= liar with.

So you agree that sections 3.5.1 and 3.5.2 prohibit using a parent of
the same integral floor for forwarding?

Matteo

On Apr 6, 2012, at 11:12 AM, Pascal Thubert (pthubert) wrote:

So maybe that's the +1 that's unclear. Let's = dig a bit:

Initially the Rank was one octet and things were = simple.

We extended it to 2 octets to allow for a better = truthfulness for some

metrics when we add ranks up.

Trouble, that could make the rank very sensitive = and the structure
unstable. To avoid that we defined a rough compar= ison and to do so we
picked a decimal part and a floor.

With that rough comparison, a 2 bytes rank would = slightly fluctuate
without changing the nodes relationship. Unless i= t fluctuates at the
decimal boundary and that's when the hysteresis h= elps you.

So in the end we end up with a decimal part to pl= ay additions with,
but the integral part of the rank is the piece us= ed for orienting the
DAG.
That's the whole point of having a decimal part a= nd all those macros.

So a node can have a parent that has its rank = 3;1 but not all nodes
with
rank+1 can be parent. You need to reach the n= ext floor. What's needed
rank+is
less than min increase but usually more than 1.

Until late in the process we could use nodes of s= ame integral floor
for forwarding, but that was removed from the spe= c. This is something
that is dearly missed in the environment I'm fami= liar with.

Cheers;

Pascal


-----Original Message-----
From: ro= ll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of Philip Levis
Sent: vendredi 6 avril 2012 16:42
To: Matteo Paris
Cc: roll@ietf.or= g
Subject: Re: [Roll] New Version Notification
-draft-ietf-roll-minrank-hysteresis-of-07.txt

Pascal wrote the text in 3.5, and it seems like h= e doesn't agree with
your interpretation...

Phil

On Apr 6, 2012, at 6:57 AM, Matteo Paris wrote:


Hi Phil.  Thanks for the reply.  I too = would prefer if parents were
only required to have lower rank, not lower inter= ger portion of rank.
Unfortunately that is not how the RFC reads. &nbs= p;All of 3.5.1 "Rank
Comparison" and 3.5.2 "Rank Relationshi= ps" are devoted to explaining
that ranks should be compared using only their in= teger portions.  You
quoted another excellent example below.  As = another example, 3.5.2
also spends a paragraph clarifying that nodes sho= uld not route through

a node with equal DAGRank (equal integer portion = of rank), which is to

say that parents must have lower integer part.

As it stands, I think the only logically consiste= nt way to read the
spec is to compare ranks as prescribed in 3.5.1 a= nd 3.5.2.  Note that
doing so does not logically conflict with 8.2.1 c= ase 5, it simply
modifies its meaning.  Only if we entirely i= gnore those two sections,
can we then compare ranks in the more sensible wa= y that we all prefer.
If that is the desire, we should submit an RFC er= rata.  In its current

state I do not believe a first time reader of the= RFC can know that
3.5.1 and 3.5.2 do not apply.

It is useful to note that the MRHOF Rank calculat= ion algorithm
*does*
cause a node to advertise a Rank which is at leas= t MinHopRankIncrease
greater than all of its parents. But I don't thin= k RPL should mandate
that behavior.

Case 2 of 3.3 in MRHOF says:

2.  The Rank of the member of the parent set= with the highest
   advertised Rank plus one

In order for the MRHOF algorithm to cause a node = to advertise a rank
which is at least MinHopRankIncrease greater than= all of its parents,
this sentence must be changed to say "The Ra= nk of the member of the
parent set with the highest advertised Rank plus = MinHopRankIncrease."

Matteo


On Apr 5, 2012, at 12:08 PM, Philip Levis wrote:<= br>

Comments inline

On Apr 3, 2012, at 6:46 AM, Matteo Paris wrote:


Hi Phil,

my question boils down to whether RPL requires me= mbers of the
parent
set to have lower DAGRank, or merely lower rank. =  My reading of the
RPL draft is that all parents must have lower DAG= Rank.

I think this reading is correct, but not because = of the confusing
text you cite.




I get this from two clauses in the RPL draft that= I quoted below.
Unfortunately both are confusingly worded.

RPL Section 3.5.1 says: "A node A has a rank= less than the rank of
a
node B if DAGRank(A) is less than DAGRank(B).&quo= t;  I believe the
intention here was to say "if and only if&qu= ot;, otherwise the clause is
pointless (trivially true).

I don't think you want to interpret this sentence= as a definition of
what "lower rank" means. I have no doub= t that many portions of the RPL

(or other) specifications do not use the phrase i= n this way. So it
should be interpreted as "if", not &quo= t;if and only if." Really, this
sentence shouldn't be in there.


RPL Section 3.5.2 says "[F]or a node N, all = parents in the DODAG
parent set must be of rank less than DAGRank(N).&= quot;  Here, a rank is
being compared with a DAGRank, which is nonsensic= al, unless "rank"
actually means "DAGRank".  It woul= d be much clearer if it said so
explicitly, ie "must be of DAGRank less than= DAGRank(N)."

Eh... I think interpreting it as DAGRank conflict= s with the DIO
processing rules. If you interpret this phrase as= all parents must
have a lower DAGRank, this strengthens bullet num= ber 5 of 8.2.2.1
from

5.  A node's Rank MUST be greater than all e= lements of its DODAG
   parent set.

to

5.  A node's Rank MUST be greater than all e= lements of its DODAG
   parent set by at least MinHopRa= nkIncrease.

or

5.  A node's DAGRank MUST be greater than al= l elements of its DODAG
   parent set.

It's important to note that 3.5.2 says

"When Rank is
compared, e.g., for determination of parent relat= ionships or loop
detection, the integer portion of the Rank is to = be used."

not

"When Rank is
compared, e.g., for determination of parent relat= ionships or loop
detection, the integer portion of the Rank MUST b= e used.

What is your interpretation -- are parents requir= ed to have lower
rank or lower DAGRank? Perhaps the confusion is a= result of some text
accidentally left over from an older version of t= he draft.

I suspect Pascal and I are going to disagree on t= his, but my
interpretation is that 3.5.2 doesn't mandate that= a node advertise a
Rank which is at least MinHopRankIncrease greater= than all of its
parents. 8.2.2.1 was written pretty carefully so = that a node with a
preferred parent of Rank a and a backup parent of= Rank b (b>a) would
not have to always advertise b + MinHopRankIn= crease, but rather at
least
b+1.

It is useful to note that the MRHOF Rank calculat= ion algorithm
*does*
cause a node to advertise a Rank which is at leas= t MinHopRankIncrease
greater than all of its parents. But I don't thin= k RPL should mandate
that behavior.

Phil



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


--_000_0CBC03E36E9D4CBCAF4D172A6D0FC5EBembercom_-- From pal@cs.stanford.edu Fri Apr 6 14:15:14 2012 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 E41D911E80CF for ; Fri, 6 Apr 2012 14:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.574 X-Spam-Level: X-Spam-Status: No, score=-4.574 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MANGLED_NAIL=2.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 K0B+srHY-FKh for ; Fri, 6 Apr 2012 14:15:13 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id DC5A811E80AE for ; Fri, 6 Apr 2012 14:15:13 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SGGUy-00062A-LP; Fri, 06 Apr 2012 14:15:13 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <0CBC03E3-6E9D-4CBC-AF4D-172A6D0FC5EB@ember.com> Date: Fri, 6 Apr 2012 14:15:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3728A27D-17E5-43C9-9445-FDA0FEEACC71@cs.stanford.edu> References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com><0500582D-1326-4033-9A82-FD42BB47A29D@ember.com><4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu><9A3B9F20-4F81-4E02-8BB2-5BDEFD63FF2A@ember.com> <096F0191-8A81-42DE-BAC1-B0620D8A7F84@cs.stanford.edu> <91F498D5-17DF-4E09-946B-B1A1482B52B1@ember.com> <0CBC03E3-6E9D-4CBC-AF4D-172A6D0FC5EB@ember.com> To: Matteo Paris X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 30e5b277ff0463ee7f5a98b9b9ae82db Cc: "" Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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: Fri, 06 Apr 2012 21:15:15 -0000 Of the three, 2a is closest to the intention of the original text in = 8.2.1, 2b is the simplest. I think 2c is a bad idea. I'd argue for 2a. Ugh -- can't believe leftover text from siblings is getting us like = this, defining terms outside of terminology. Given that 3.5 gives you no = way to talk about the full floating point Rank, I wonder if there are = other gotchas in the text. The intention of 8.2.1 point 5 was to be for = the Rank value, not DAGRank. But if any reasonable reading of the RFC = says otherwise=85. Phil On Apr 6, 2012, at 12:03 PM, Matteo Paris wrote: >=20 > Thanks Pascal. >=20 > Back to the original subject, this requires a change to MRHOF section = 3.3 case 2 to ensure that a node's rank does not have the same integral = floor as any of its parents: >=20 > 2. The Rank of the member of the parent set with the highest > advertised Rank plus one >=20 > I can think of three possible changes, listed in increasing order of = the amount added to the highest advertised Rank: >=20 > 2a. The Rank of the member of the parent set with the highest = advertised Rank, rounded to the next higher integral Rank, ie, to = MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)). >=20 > 2b. The Rank of the member of the parent set with the highest = advertised Rank plus MinHopRankIncrease. >=20 > 2c. The Rank associated with the path through the member of the parent = set with the highest advertised Rank. >=20 > Matteo >=20 > On Apr 6, 2012, at 1:11 PM, Pascal Thubert (pthubert) wrote: >=20 >> Hi Matteo: >>=20 >> I agree that sections 3.5.1 and 3.5.2 prohibit using a parent of the >> same integral floor for forwarding. >> This is the state of the spec and there is no erratum in there. >>=20 >> We lost that capability late in the process. You might find the = history >> associated to the word "sibling". >> We removed siblings to seek maximum simplicity. For nodes more = capable, >> they could be reintroduced.=20 >> The point is that for siblings, we'll have to define something new to >> avoid long loops.=20 >>=20 >> Maybe we could write an experimental addition? >>=20 >> Cheers, >>=20 >> Pascal >>=20 >>=20 >> -----Original Message----- >> From: Matteo Paris [mailto:matteo@ember.com]=20 >> Sent: vendredi 6 avril 2012 17:25 >> To: Pascal Thubert (pthubert) >> Cc: Philip Levis; >> Subject: Re: [Roll] New Version Notification >> -draft-ietf-roll-minrank-hysteresis-of-07.txt >>=20 >> Hi Pascal, >>=20 >>> Until late in the process we could use nodes of same integral floor=20= >>> for forwarding, but that was removed from the spec. This is = something=20 >>> that is dearly missed in the environment I'm familiar with. >>=20 >> So you agree that sections 3.5.1 and 3.5.2 prohibit using a parent of >> the same integral floor for forwarding? >>=20 >> Matteo >>=20 >> On Apr 6, 2012, at 11:12 AM, Pascal Thubert (pthubert) wrote: >>=20 >>> So maybe that's the +1 that's unclear. Let's dig a bit: >>>=20 >>> Initially the Rank was one octet and things were simple. >>>=20 >>> We extended it to 2 octets to allow for a better truthfulness for = some >>=20 >>> metrics when we add ranks up. >>>=20 >>> Trouble, that could make the rank very sensitive and the structure=20= >>> unstable. To avoid that we defined a rough comparison and to do so = we=20 >>> picked a decimal part and a floor. >>>=20 >>> With that rough comparison, a 2 bytes rank would slightly fluctuate=20= >>> without changing the nodes relationship. Unless it fluctuates at the=20= >>> decimal boundary and that's when the hysteresis helps you. >>>=20 >>> So in the end we end up with a decimal part to play additions with,=20= >>> but the integral part of the rank is the piece used for orienting = the >> DAG. >>> That's the whole point of having a decimal part and all those = macros. >>>=20 >>> So a node can have a parent that has its rank +1 but not all nodes=20= >>> with >>> rank+1 can be parent. You need to reach the next floor. What's = needed=20 >>> rank+is >>> less than min increase but usually more than 1. >>>=20 >>> Until late in the process we could use nodes of same integral floor=20= >>> for forwarding, but that was removed from the spec. This is = something=20 >>> that is dearly missed in the environment I'm familiar with. >>>=20 >>> Cheers; >>>=20 >>> Pascal >>>=20 >>>=20 >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20= >>> Of Philip Levis >>> Sent: vendredi 6 avril 2012 16:42 >>> To: Matteo Paris >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] New Version Notification=20 >>> -draft-ietf-roll-minrank-hysteresis-of-07.txt >>>=20 >>> Pascal wrote the text in 3.5, and it seems like he doesn't agree = with=20 >>> your interpretation... >>>=20 >>> Phil >>>=20 >>> On Apr 6, 2012, at 6:57 AM, Matteo Paris wrote: >>>=20 >>>>=20 >>>> Hi Phil. Thanks for the reply. I too would prefer if parents were >>> only required to have lower rank, not lower interger portion of = rank. >>> Unfortunately that is not how the RFC reads. All of 3.5.1 "Rank=20 >>> Comparison" and 3.5.2 "Rank Relationships" are devoted to explaining=20= >>> that ranks should be compared using only their integer portions. = You=20 >>> quoted another excellent example below. As another example, 3.5.2=20= >>> also spends a paragraph clarifying that nodes should not route = through >>=20 >>> a node with equal DAGRank (equal integer portion of rank), which is = to >>=20 >>> say that parents must have lower integer part. >>>>=20 >>>> As it stands, I think the only logically consistent way to read the >>> spec is to compare ranks as prescribed in 3.5.1 and 3.5.2. Note = that=20 >>> doing so does not logically conflict with 8.2.1 case 5, it simply=20 >>> modifies its meaning. Only if we entirely ignore those two = sections,=20 >>> can we then compare ranks in the more sensible way that we all = prefer. >>> If that is the desire, we should submit an RFC errata. In its = current >>=20 >>> state I do not believe a first time reader of the RFC can know that >>> 3.5.1 and 3.5.2 do not apply. >>>>=20 >>>>> It is useful to note that the MRHOF Rank calculation algorithm=20 >>>>> *does* >>> cause a node to advertise a Rank which is at least = MinHopRankIncrease=20 >>> greater than all of its parents. But I don't think RPL should = mandate=20 >>> that behavior. >>>>=20 >>>> Case 2 of 3.3 in MRHOF says: >>>>=20 >>>> 2. The Rank of the member of the parent set with the highest >>>> advertised Rank plus one >>>>=20 >>>> In order for the MRHOF algorithm to cause a node to advertise a = rank >>> which is at least MinHopRankIncrease greater than all of its = parents,=20 >>> this sentence must be changed to say "The Rank of the member of the=20= >>> parent set with the highest advertised Rank plus = MinHopRankIncrease." >>>>=20 >>>> Matteo >>>>=20 >>>>=20 >>>> On Apr 5, 2012, at 12:08 PM, Philip Levis wrote: >>>>=20 >>>>> Comments inline >>>>>=20 >>>>> On Apr 3, 2012, at 6:46 AM, Matteo Paris wrote: >>>>>=20 >>>>>>=20 >>>>>> Hi Phil, >>>>>>=20 >>>>>> my question boils down to whether RPL requires members of the=20 >>>>>> parent >>> set to have lower DAGRank, or merely lower rank. My reading of the=20= >>> RPL draft is that all parents must have lower DAGRank. >>>>>=20 >>>>> I think this reading is correct, but not because of the confusing >>> text you cite. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> I get this from two clauses in the RPL draft that I quoted below. >>> Unfortunately both are confusingly worded. >>>>>>=20 >>>>>> RPL Section 3.5.1 says: "A node A has a rank less than the rank = of=20 >>>>>> a >>> node B if DAGRank(A) is less than DAGRank(B)." I believe the=20 >>> intention here was to say "if and only if", otherwise the clause is=20= >>> pointless (trivially true). >>>>>=20 >>>>> I don't think you want to interpret this sentence as a definition = of >>> what "lower rank" means. I have no doubt that many portions of the = RPL >>=20 >>> (or other) specifications do not use the phrase in this way. So it=20= >>> should be interpreted as "if", not "if and only if." Really, this=20 >>> sentence shouldn't be in there. >>>>>=20 >>>>>>=20 >>>>>> RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG >>> parent set must be of rank less than DAGRank(N)." Here, a rank is=20= >>> being compared with a DAGRank, which is nonsensical, unless "rank"=20= >>> actually means "DAGRank". It would be much clearer if it said so=20 >>> explicitly, ie "must be of DAGRank less than DAGRank(N)." >>>>>=20 >>>>> Eh... I think interpreting it as DAGRank conflicts with the DIO=20 >>>>> processing rules. If you interpret this phrase as all parents must=20= >>>>> have a lower DAGRank, this strengthens bullet number 5 of 8.2.2.1=20= >>>>> from >>>>>=20 >>>>> 5. A node's Rank MUST be greater than all elements of its DODAG >>>>> parent set. >>>>>=20 >>>>> to >>>>>=20 >>>>> 5. A node's Rank MUST be greater than all elements of its DODAG >>>>> parent set by at least MinHopRankIncrease. >>>>>=20 >>>>> or >>>>>=20 >>>>> 5. A node's DAGRank MUST be greater than all elements of its = DODAG >>>>> parent set. >>>>>=20 >>>>> It's important to note that 3.5.2 says >>>>>=20 >>>>> "When Rank is >>>>> compared, e.g., for determination of parent relationships or loop=20= >>>>> detection, the integer portion of the Rank is to be used." >>>>>=20 >>>>> not >>>>>=20 >>>>> "When Rank is >>>>> compared, e.g., for determination of parent relationships or loop=20= >>>>> detection, the integer portion of the Rank MUST be used. >>>>>=20 >>>>>> What is your interpretation -- are parents required to have lower >>> rank or lower DAGRank? Perhaps the confusion is a result of some = text=20 >>> accidentally left over from an older version of the draft. >>>>>=20 >>>>> I suspect Pascal and I are going to disagree on this, but my >>> interpretation is that 3.5.2 doesn't mandate that a node advertise a=20= >>> Rank which is at least MinHopRankIncrease greater than all of its=20 >>> parents. 8.2.2.1 was written pretty carefully so that a node with a=20= >>> preferred parent of Rank a and a backup parent of Rank b (b>a) would=20= >>> not have to always advertise b + MinHopRankIncrease, but rather at=20= >>> least >>> b+1. >>>>>=20 >>>>> It is useful to note that the MRHOF Rank calculation algorithm=20 >>>>> *does* >>> cause a node to advertise a Rank which is at least = MinHopRankIncrease=20 >>> greater than all of its parents. But I don't think RPL should = mandate=20 >>> that behavior. >>>>>=20 >>>>> Phil >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 From pthubert@cisco.com Fri Apr 6 23:19:57 2012 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 8350521F8522 for ; Fri, 6 Apr 2012 23:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MANGLED_NAIL=2.3, 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 z-ucoGcSMste for ; Fri, 6 Apr 2012 23:19:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7A621F851E for ; Fri, 6 Apr 2012 23:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=13288; q=dns/txt; s=iport; t=1333779595; x=1334989195; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BIUbjdwKYYAlqH7M36sSjFhACNy3d5osd8Iguqgt8Aw=; b=di3Hnz1e92zoEguWsA0EpqPt0SobCWESCYxvmrOttgL3ZgBgXZWjXYas VEBK7qjmhCNWGibVng/BfSkP1S47oUd97PK8FeYGg6RyYz3m39LLtFCzi WQUzkSQTS7N9L4S3eZyYwPSRQcOxYYErF8T12PASb8h12MvfmY1gvP3tI Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPrbf0+Q/khR/2dsb2JhbABEDrkZgQeCCQEBAQMBAQEBDwEdCjQEBQIMBAIBCA4DBAEBAQoGFwEGASYfCQgBAQQBEggTB4dnBQuaPJ9WBI93YwSLPYZJikSHb4FpgjA5 X-IronPort-AV: E=Sophos;i="4.75,384,1330905600"; d="scan'208";a="134521343" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 07 Apr 2012 06:19:53 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q376Jr0W025146; Sat, 7 Apr 2012 06:19:53 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); Sat, 7 Apr 2012 08:19:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 7 Apr 2012 08:18:15 +0200 Message-ID: In-Reply-To: <3728A27D-17E5-43C9-9445-FDA0FEEACC71@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt Thread-Index: Ac0UOlzZuRU9rlSKR06fm4xMIeomvAAR0bKA References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com><0500582D-1326-4033-9A82-FD42BB47A29D@ember.com><4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu><9A3B9F20-4F81-4E02-8BB2-5BDEFD63FF2A@ember.com> <096F0191-8A81-42DE-BAC1-B0620D8A7F84@cs.stanford.edu> <91F498D5-17DF-4E09-946B-B1A1482B52B1@ember.com> <0CBC03E3-6E9D-4CBC-AF4D-172A6D0FC5EB@ember.com> <3728A27D-17E5-43C9-9445-FDA0FEEACC71@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Matteo Paris" X-OriginalArrivalTime: 07 Apr 2012 06:19:54.0282 (UTC) FILETIME=[7280A8A0:01CD1486] Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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, 07 Apr 2012 06:19:57 -0000 Hi Phil I agree that 2.a is closest to the intent that I read there. OTOH I do not necessarily agree with that intent.=20 The point is that with this clause the node selects its parents first and its Rank second. The spec recommends picking a preferred parent first, computing the Rank based on the preferred parent, and then only consider any node with a lower floor as an acceptable parent. I understand that want to allow reversing that operation, but then that should be an option and text should indicate that using it may augment the parent set for some nodes but end up reducing it for others. Reversing the chicken and an egg leads to a Rank that is not true to the preferred path metric, and greedy behaviors in general. This has been discussed at length in the mailing list. Till late in the process, siblings were the way to 1) augment the parent set and 2) allow more solutions for more nodes.=20 There are use cases in the real world that demand 2 forwarding solutions for all nodes, so one way or another we'll have to introduce something like siblings to serve them with RPL. As we are at it , shouldn't: " The largest calculated Rank among paths through the parent set, minus MaxRankIncrease"=20 be " The smallest calculated Rank among paths through the parent set, minus MaxRankIncrease"=20 At which point I would also indicate for clarity that this rule ends up pruning parents from the original set. Finally RFC 6550 does not come on your way to talk about the full floating point Rank. RFC 6550 says: "When an Objective Function computes Rank, the Objective Function operates on the entire (i.e., 16-bit) Rank quantity. When Rank is compared, e.g., for determination of parent relationships or loop detection, the integer portion of the Rank is to be used. " So all the discussion/additions etc... about Rank value in an OF is on the full 16 bits and we do not make any rounding error there. This is true till we get to compare Ranks for parent relationship.=20 Pascal -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: vendredi 6 avril 2012 23:15 To: Matteo Paris Cc: Pascal Thubert (pthubert); Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt Of the three, 2a is closest to the intention of the original text in 8.2.1, 2b is the simplest. I think 2c is a bad idea. I'd argue for 2a. Ugh -- can't believe leftover text from siblings is getting us like this, defining terms outside of terminology. Given that 3.5 gives you no way to talk about the full floating point Rank, I wonder if there are other gotchas in the text. The intention of 8.2.1 point 5 was to be for the Rank value, not DAGRank. But if any reasonable reading of the RFC says otherwise.... Phil On Apr 6, 2012, at 12:03 PM, Matteo Paris wrote: >=20 > Thanks Pascal. >=20 > Back to the original subject, this requires a change to MRHOF section 3.3 case 2 to ensure that a node's rank does not have the same integral floor as any of its parents: >=20 > 2. The Rank of the member of the parent set with the highest > advertised Rank plus one >=20 > I can think of three possible changes, listed in increasing order of the amount added to the highest advertised Rank: >=20 > 2a. The Rank of the member of the parent set with the highest advertised Rank, rounded to the next higher integral Rank, ie, to MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)). >=20 > 2b. The Rank of the member of the parent set with the highest advertised Rank plus MinHopRankIncrease. >=20 > 2c. The Rank associated with the path through the member of the parent set with the highest advertised Rank. >=20 > Matteo >=20 > On Apr 6, 2012, at 1:11 PM, Pascal Thubert (pthubert) wrote: >=20 >> Hi Matteo: >>=20 >> I agree that sections 3.5.1 and 3.5.2 prohibit using a parent of the=20 >> same integral floor for forwarding. >> This is the state of the spec and there is no erratum in there. >>=20 >> We lost that capability late in the process. You might find the=20 >> history associated to the word "sibling". >> We removed siblings to seek maximum simplicity. For nodes more=20 >> capable, they could be reintroduced. >> The point is that for siblings, we'll have to define something new to >> avoid long loops. >>=20 >> Maybe we could write an experimental addition? >>=20 >> Cheers, >>=20 >> Pascal >>=20 >>=20 >> -----Original Message----- >> From: Matteo Paris [mailto:matteo@ember.com] >> Sent: vendredi 6 avril 2012 17:25 >> To: Pascal Thubert (pthubert) >> Cc: Philip Levis; >> Subject: Re: [Roll] New Version Notification=20 >> -draft-ietf-roll-minrank-hysteresis-of-07.txt >>=20 >> Hi Pascal, >>=20 >>> Until late in the process we could use nodes of same integral floor=20 >>> for forwarding, but that was removed from the spec. This is=20 >>> something that is dearly missed in the environment I'm familiar with. >>=20 >> So you agree that sections 3.5.1 and 3.5.2 prohibit using a parent of >> the same integral floor for forwarding? >>=20 >> Matteo >>=20 >> On Apr 6, 2012, at 11:12 AM, Pascal Thubert (pthubert) wrote: >>=20 >>> So maybe that's the +1 that's unclear. Let's dig a bit: >>>=20 >>> Initially the Rank was one octet and things were simple. >>>=20 >>> We extended it to 2 octets to allow for a better truthfulness for=20 >>> some >>=20 >>> metrics when we add ranks up. >>>=20 >>> Trouble, that could make the rank very sensitive and the structure=20 >>> unstable. To avoid that we defined a rough comparison and to do so=20 >>> we picked a decimal part and a floor. >>>=20 >>> With that rough comparison, a 2 bytes rank would slightly fluctuate=20 >>> without changing the nodes relationship. Unless it fluctuates at the >>> decimal boundary and that's when the hysteresis helps you. >>>=20 >>> So in the end we end up with a decimal part to play additions with,=20 >>> but the integral part of the rank is the piece used for orienting=20 >>> the >> DAG. >>> That's the whole point of having a decimal part and all those macros. >>>=20 >>> So a node can have a parent that has its rank +1 but not all nodes=20 >>> with >>> rank+1 can be parent. You need to reach the next floor. What's=20 >>> rank+needed is >>> less than min increase but usually more than 1. >>>=20 >>> Until late in the process we could use nodes of same integral floor=20 >>> for forwarding, but that was removed from the spec. This is=20 >>> something that is dearly missed in the environment I'm familiar with. >>>=20 >>> Cheers; >>>=20 >>> Pascal >>>=20 >>>=20 >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>> Of Philip Levis >>> Sent: vendredi 6 avril 2012 16:42 >>> To: Matteo Paris >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] New Version Notification=20 >>> -draft-ietf-roll-minrank-hysteresis-of-07.txt >>>=20 >>> Pascal wrote the text in 3.5, and it seems like he doesn't agree=20 >>> with your interpretation... >>>=20 >>> Phil >>>=20 >>> On Apr 6, 2012, at 6:57 AM, Matteo Paris wrote: >>>=20 >>>>=20 >>>> Hi Phil. Thanks for the reply. I too would prefer if parents were >>> only required to have lower rank, not lower interger portion of rank. >>> Unfortunately that is not how the RFC reads. All of 3.5.1 "Rank=20 >>> Comparison" and 3.5.2 "Rank Relationships" are devoted to explaining >>> that ranks should be compared using only their integer portions. =20 >>> You quoted another excellent example below. As another example,=20 >>> 3.5.2 also spends a paragraph clarifying that nodes should not route >>> through >>=20 >>> a node with equal DAGRank (equal integer portion of rank), which is=20 >>> to >>=20 >>> say that parents must have lower integer part. >>>>=20 >>>> As it stands, I think the only logically consistent way to read the >>> spec is to compare ranks as prescribed in 3.5.1 and 3.5.2. Note=20 >>> that doing so does not logically conflict with 8.2.1 case 5, it=20 >>> simply modifies its meaning. Only if we entirely ignore those two=20 >>> sections, can we then compare ranks in the more sensible way that we all prefer. >>> If that is the desire, we should submit an RFC errata. In its=20 >>> current >>=20 >>> state I do not believe a first time reader of the RFC can know that >>> 3.5.1 and 3.5.2 do not apply. >>>>=20 >>>>> It is useful to note that the MRHOF Rank calculation algorithm >>>>> *does* >>> cause a node to advertise a Rank which is at least=20 >>> MinHopRankIncrease greater than all of its parents. But I don't=20 >>> think RPL should mandate that behavior. >>>>=20 >>>> Case 2 of 3.3 in MRHOF says: >>>>=20 >>>> 2. The Rank of the member of the parent set with the highest >>>> advertised Rank plus one >>>>=20 >>>> In order for the MRHOF algorithm to cause a node to advertise a=20 >>>> rank >>> which is at least MinHopRankIncrease greater than all of its=20 >>> parents, this sentence must be changed to say "The Rank of the=20 >>> member of the parent set with the highest advertised Rank plus MinHopRankIncrease." >>>>=20 >>>> Matteo >>>>=20 >>>>=20 >>>> On Apr 5, 2012, at 12:08 PM, Philip Levis wrote: >>>>=20 >>>>> Comments inline >>>>>=20 >>>>> On Apr 3, 2012, at 6:46 AM, Matteo Paris wrote: >>>>>=20 >>>>>>=20 >>>>>> Hi Phil, >>>>>>=20 >>>>>> my question boils down to whether RPL requires members of the=20 >>>>>> parent >>> set to have lower DAGRank, or merely lower rank. My reading of the=20 >>> RPL draft is that all parents must have lower DAGRank. >>>>>=20 >>>>> I think this reading is correct, but not because of the confusing >>> text you cite. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> I get this from two clauses in the RPL draft that I quoted below. >>> Unfortunately both are confusingly worded. >>>>>>=20 >>>>>> RPL Section 3.5.1 says: "A node A has a rank less than the rank=20 >>>>>> of a >>> node B if DAGRank(A) is less than DAGRank(B)." I believe the=20 >>> intention here was to say "if and only if", otherwise the clause is=20 >>> pointless (trivially true). >>>>>=20 >>>>> I don't think you want to interpret this sentence as a definition=20 >>>>> of >>> what "lower rank" means. I have no doubt that many portions of the=20 >>> RPL >>=20 >>> (or other) specifications do not use the phrase in this way. So it=20 >>> should be interpreted as "if", not "if and only if." Really, this=20 >>> sentence shouldn't be in there. >>>>>=20 >>>>>>=20 >>>>>> RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG >>> parent set must be of rank less than DAGRank(N)." Here, a rank is=20 >>> being compared with a DAGRank, which is nonsensical, unless "rank" >>> actually means "DAGRank". It would be much clearer if it said so=20 >>> explicitly, ie "must be of DAGRank less than DAGRank(N)." >>>>>=20 >>>>> Eh... I think interpreting it as DAGRank conflicts with the DIO=20 >>>>> processing rules. If you interpret this phrase as all parents must >>>>> have a lower DAGRank, this strengthens bullet number 5 of 8.2.2.1=20 >>>>> from >>>>>=20 >>>>> 5. A node's Rank MUST be greater than all elements of its DODAG >>>>> parent set. >>>>>=20 >>>>> to >>>>>=20 >>>>> 5. A node's Rank MUST be greater than all elements of its DODAG >>>>> parent set by at least MinHopRankIncrease. >>>>>=20 >>>>> or >>>>>=20 >>>>> 5. A node's DAGRank MUST be greater than all elements of its DODAG >>>>> parent set. >>>>>=20 >>>>> It's important to note that 3.5.2 says >>>>>=20 >>>>> "When Rank is >>>>> compared, e.g., for determination of parent relationships or loop=20 >>>>> detection, the integer portion of the Rank is to be used." >>>>>=20 >>>>> not >>>>>=20 >>>>> "When Rank is >>>>> compared, e.g., for determination of parent relationships or loop=20 >>>>> detection, the integer portion of the Rank MUST be used. >>>>>=20 >>>>>> What is your interpretation -- are parents required to have lower >>> rank or lower DAGRank? Perhaps the confusion is a result of some=20 >>> text accidentally left over from an older version of the draft. >>>>>=20 >>>>> I suspect Pascal and I are going to disagree on this, but my >>> interpretation is that 3.5.2 doesn't mandate that a node advertise a >>> Rank which is at least MinHopRankIncrease greater than all of its=20 >>> parents. 8.2.2.1 was written pretty carefully so that a node with a=20 >>> preferred parent of Rank a and a backup parent of Rank b (b>a) would >>> not have to always advertise b + MinHopRankIncrease, but rather at=20 >>> least >>> b+1. >>>>>=20 >>>>> It is useful to note that the MRHOF Rank calculation algorithm >>>>> *does* >>> cause a node to advertise a Rank which is at least=20 >>> MinHopRankIncrease greater than all of its parents. But I don't=20 >>> think RPL should mandate that behavior. >>>>>=20 >>>>> Phil >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 From pal@cs.stanford.edu Sat Apr 7 07:57:36 2012 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 C9A6F21F851C for ; Sat, 7 Apr 2012 07:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, 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 6stIB8vxu0Xj for ; Sat, 7 Apr 2012 07:57:36 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4067121F8507 for ; Sat, 7 Apr 2012 07:57:36 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.111]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SGX53-0000Vj-Er; Sat, 07 Apr 2012 07:57:33 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Sat, 7 Apr 2012 07:57:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120309180454.27147.28601.idtracker@ietfa.amsl.com><0500582D-1326-4033-9A82-FD42BB47A29D@ember.com><4FEF776A-4562-4FE1-9973-7627B12EDD43@cs.stanford.edu><9A3B9F20-4F81-4E02-8BB2-5BDEFD63FF2A@ember.com> <096F0191-8A81-42DE-BAC1-B0620D8A7F84@cs.stanford.edu> <91F498D5-17DF-4E09-946B-B1A1482B52B1@ember.com> <0CBC03E3-6E9D-4CBC-AF4D-172A6D0FC5EB@ember.com> <3728A27D-17E5-43C9-9445-FDA0FEEACC71@cs.stanford.edu> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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, 07 Apr 2012 14:57:36 -0000 On Apr 6, 2012, at 11:18 PM, Pascal Thubert (pthubert) wrote: > The point is that with this clause the node selects its parents first > and its Rank second. The spec recommends picking a preferred parent > first, computing the Rank based on the preferred parent, and then only > consider any node with a lower floor as an acceptable parent. I > understand that want to allow reversing that operation, but then that > should be an option and text should indicate that using it may augment > the parent set for some nodes but end up reducing it for others. Don't you think this is an implementation decision? I tried to write the = specification text to be completely neutral on this matter (as some of = the MRHOF discussions have gone into). The input to DIO generation is a = preferred parent and a parent set; how those two are selected is = complete outside the specification with the caveat that it places some = constraints (MaxRankIncrease). Phil= From pal@cs.stanford.edu Sat Apr 7 15:46:52 2012 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 7A40921F84AA for ; Sat, 7 Apr 2012 15:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 5uhTzB+rWhLq for ; Sat, 7 Apr 2012 15:46:52 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 40D3521F843F for ; Sat, 7 Apr 2012 15:46:31 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SGeOr-0006hT-Us; Sat, 07 Apr 2012 15:46:30 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <000101cd0597$5c29b450$147d1cf0$@uni-bremen.de> Date: Sat, 7 Apr 2012 15:46:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120311013418.13049.33067.idtracker@ietfa.amsl.com> <000901cd01a1$52418340$f6c489c0$@uni-bremen.de> <000101cd0597$5c29b450$147d1cf0$@uni-bremen.de> To: Koojana Kuladinithi X-Mailer: Apple Mail (2.1084) X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Cc: 'ROLL WG' Subject: Re: [Roll] New Version Notification for draft-gnawali-roll-rpl-recommendations-03.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, 07 Apr 2012 22:46:52 -0000 On Mar 18, 2012, at 11:13 PM, Koojana Kuladinithi wrote: > Hi John, >=20 >>=20 >> Koojana, >>=20 >> In terms of why the DIS is sent at different intervals is rather = simple >> to explain. A Trickle Timer is typically used when the network is >> stable and nothing needs to happen. At least this is the philosophy I >> tried to follow when implementing TinyRPL. However, when a node is = NOT >> connected, this indicates that the network is not stable AT ALL. >> Therefore, it should try to aggressively find a next hop node rather >> than to save power. The goal of the node should be, at this point, to >> connect to a DODAG. >>=20 >=20 > [koo] Yes >=20 >> Furthermore, it is not really necessary to install the root last in a >> RPL deployment. I don't see why this HAS TO be the case.=20 >=20 > [koo] Unfortunately, this is not the case for our scenario in reality. = E.g., > Fruits will be placed in boxes together with sensor nodes (at the = field) and > will be loaded to a container (at the harbor) later. The DODAG root = (the BR) > will be attached to the container. Until the sensor nodes see any = reachable > DODAG root, it may takes 1 - 2 days.=20 > Therefore, the sending of DIS messages periodically is not a good = option > . It sounds like you don't want RPL to operate until the fruits are in the = container -- so you want an out-of-band mechanism to wake the network up = and start RPL. I'd argue that a routing protocol shouldn't be = responsible for this application-specific requirement. Phil= From prvs=4385599de=mukul@uwm.edu Sun Apr 8 06:37:59 2012 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 3956E21F84FD for ; Sun, 8 Apr 2012 06:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 M6u242BA1wTO for ; Sun, 8 Apr 2012 06:37:58 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id ED67F21F8512 for ; Sun, 8 Apr 2012 06:37:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAImTgU9/AAAB/2dsb2JhbABFhWa2UAEBAQMBAQEBIEsLBQcPEQMBAQEDAg0WAwIpHwkIBhOICQULpzqIfYkFBIEvjhOBGASIWo0SkDaDBYE2Fw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id B4D0A2FB85; Sun, 8 Apr 2012 08:37:55 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1vZ+H+NP9UH; Sun, 8 Apr 2012 08:37:55 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 39B072FB83; Sun, 8 Apr 2012 08:37:55 -0500 (CDT) Date: Sun, 8 Apr 2012 08:37:55 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1654025443.1850775.1333892275053.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.91] 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] #86: G flag: do we need that text? 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, 08 Apr 2012 13:37:59 -0000 Hi Pascal, How about the following text: "The origin sets the G flag to indicate the relative importance of the route discovery it is initiating. The G flag is set to one if this particular route discovery is more important from application's perspective than some other route discovery. In other words, the origin sets the G flag to one if this particular route discovery helps meet the application defined goal \cite{rpl}. Thus, the G flag setting helps an intermediate router choose which route discoveries to participate in if it cannot participate in all route discoveries. An intermediate router SHOULD participate in route discoveries with G flag set to one (in preference to ones with G flag set to zero)." Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: roll@ietf.org, "Richard Kelsey" , "Philip Levis" Sent: Thursday, April 5, 2012 11:00:22 AM Subject: RE: [Roll] [roll] #86: G flag: do we need that text? Hello Mukul: >1) For a local instance there can be only one root and one DODAG. G bit cannot and is not used for DODAG selection within an instance. The statement above seems to be at odds with following two statements >2) In a given deployment, a goal can be defined that some P2P DODAGs achieve and others do not. The roots that achieve that goal will set the G bit in their P2P DAGs. 3) the default goal is to create connectivity between origin and target. So by default G should be set to 1. As per statement 1, the G flag can never be 1 for P2P-RPL DAGs because they use local instance ids. [Pascal] Statement 1 does not say that at all. Can't fathom how you concluded that... Let me try to reword: There is only what DODAG for a given local instance so there cannot be a selection => G cannot be used for a selection that cannot happen. --- As per statement 2/3, the G flag could be 1 and is 1 by default. [Pascal] Yes. I added an item to help the device prioritize when it is asker to participate to many DODAGs (for many P2P flows that it happens to be on the path of). In that case, and if the device cannot particpater to all the P2P DODAGs, then the G bit could be use to decide which are the most important. --- I am OK with setting G flag to 1 always (as you, Richard and Phil seem to prefer) but I dont know how to reason this. Do we need to provide a reason at all? [Pascal] If you define a default goal that the DODAG fills, then you set G to one. For instance, G could mean 'important stuff' like swithing a light on. You'd set it for switching lights but not for reporting the hygrometry of your orchids, which anyway will be retried in a half hour. As a result, if the 2 DAG formations collide, the light on will have precedence... --------- :) too ... Pascal ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: roll@ietf.org, "Richard Kelsey" , "Philip Levis" Sent: Thursday, April 5, 2012 1:11:42 AM Subject: RE: [Roll] [roll] #86: G flag: do we need that text? Hello Mukul: I suggest a sentence that says that: 1) For a local instance there can be only one root and one DODAG. G bit cannot and is not used for DODAG selection within an instance. 2) In a given deployment, a goal can be defined that some P2P DODAGs achieve and others do not. The roots that achieve that goal will set the G bit in their P2P DAGs. 3) the default goal is to create connectivity between origin and target. So by default G should be set to 1. 4) if an intermediate router does not have enough resources to participate to all DODAGs then it should favor DODAGs with the G bit on. The exact wording is yours... Cheers, Pascal -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu] Sent: mercredi 4 avril 2012 18:47 To: Pascal Thubert (pthubert) Cc: roll@ietf.org; Richard Kelsey Subject: Re: [Roll] [roll] #86: G flag: do we need that text? Pascal >In any case, as I suggested earlier and as Richard also suggest now, G SHOULD probably be 1 by default but MAY be set otherwise. Richard wants the flag to always be either 0 or 1. He prefers it to be always 1 but would settle for it being always zero. I think this is not a critical point. I am OK with whatever resolution you and Richard arrive at. Kindly provide me the resolution text I should put in the draft. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: roll@ietf.org, "Richard Kelsey" Sent: Wednesday, April 4, 2012 11:05:50 AM Subject: RE: [Roll] [roll] #86: G flag: do we need that text? Mukul: I think we disagree because of the definition of goal itself. The goal is an abstraction. Same goes for the term Objective in OF. RFC 6550 only gives examples of what G could be used for but that is not limiting. Certainly the abstraction may for instance mean that external nodes are reachable via the root. But it could be something else entirely. For instance it could designate a root that can aggregate data. In practice, G is used to favor a root that reaches the goal vs. one that does not. But that's senseless for local instances that have by definition a single root. So whatever you set it to does not make a difference for RFC 6550 operations. I figure it could be used for signaling a "transient goal" information to an OF that could use it for a purpose I can't fathom. In any case, as I suggested earlier and as Richard also suggest now, G SHOULD probably be 1 by default but MAY be set otherwise. Pascal -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu] Sent: mercredi 4 avril 2012 16:16 To: Pascal Thubert (pthubert) Cc: roll@ietf.org; Richard Kelsey Subject: Re: [Roll] [roll] #86: G flag: do we need that text? Pascal >If the goal is to reach the root, then G is 1... I have told you multiple times that joining a P2P-RPL DAG does not give any sort of connectivity to the node. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Richard Kelsey" Cc: roll@ietf.org Sent: Wednesday, April 4, 2012 9:05:28 AM Subject: RE: [Roll] [roll] #86: G flag: do we need that text? Hello Mukul Floating vs. Grounded depends on the goal of the DODAG. I asked you and will ask again what is your goal? If the goal is to reach the root, then G is 1... If you want to signal something to the OF using the G bit, leave it open. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: mercredi 4 avril 2012 15:55 To: Richard Kelsey Cc: roll@ietf.org Subject: Re: [Roll] [roll] #86: G flag: do we need that text? >The G flag is 0 if and only if the DODAG is floating. I think that the G flag is 1 if and only if the DODAG is grounded. The temporary DAGs used in P2P-RPL are not grounded, they are temporary. I think that all transient/temporary DAGs are floating by their very nature. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: roll@ietf.org Cc: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org Sent: Wednesday, April 4, 2012 8:36:50 AM Subject: Re: [Roll] [roll] #86: G flag: do we need that text? > From: roll issue tracker > Date: Wed, 4 Apr 2012 13:08:50 +0000 > > #86: G flag: do we need that text? > > Problem (resolition is proposed) > ------------------------------ > Disagreement on the meaning of 'G' bit and imposed setting to 0; > > Proposed resolution > --------------------------- > The origin sets the G flag based on its perception of whether joining > how the flag's value would affect the rank calculation under the OF > being used. By default, the G flag is set to zero given the temporary > nature of the DAG being created. I disagree with the proposed resolution. It adds needless confusion. The G flag is 0 if and only if the DODAG is floating. There is no point to allowing floating DODAGs with a P2P-RDO option. I suggest that the G bit be set to 1 and that routers be explicitly prohibited from creating floating DODAGs with a P2P-RDO option. -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=4385599de=mukul@uwm.edu Sun Apr 8 08:57:20 2012 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 4640021F84FF for ; Sun, 8 Apr 2012 08:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 QZSFakugFRN4 for ; Sun, 8 Apr 2012 08:57:19 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id A0CC921F84F4 for ; Sun, 8 Apr 2012 08:57:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAHa0gU9/AAAB/2dsb2JhbABEhWa2TwEBBSNWDA8RBAEBAwINGQJRCBmIDgunRIh2iQmBL4wHggyBGASIWo0SgRGPJYMF Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 3E8DB2FB8F; Sun, 8 Apr 2012 10:56:19 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BKXo6-sqA7u; Sun, 8 Apr 2012 10:56:18 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id E68042FB87; Sun, 8 Apr 2012 10:56:18 -0500 (CDT) Date: Sun, 8 Apr 2012 10:56:18 -0500 (CDT) From: Mukul Goyal To: roll@ietf.org Message-ID: <273988926.1851128.1333900578888.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <055.f551806bbfcbaa57b44d89571c962af8@trac.tools.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] [roll] #87: Can't we split the target from the RDO ? 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, 08 Apr 2012 15:57:20 -0000 Hi JP Please mark this ticket as closed. Thanks Mukul ----- Original Message ----- From: "roll issue tracker" To: mukul@UWM.EDU, jpv@cisco.com Cc: roll@ietf.org Sent: Wednesday, April 4, 2012 8:09:56 AM Subject: [roll] #87: Can't we split the target from the RDO ? #87: Can't we split the target from the RDO ? Problem (proposed resolution) ------------------------------ The RDO is a garbage option will all sorts of data in it. The advocated reason for that is conciseness since separate options mean overhead. OTOH, it makes more sense to have all the targets expresses as target options as opposed to having one target in the DRO and then all other targets listed after. Having the target separate would allow for a DIO with no RDO but only a target, which would be useful to poll a device on an existing DAG. Currently the draft MUST a RDO and MAY and target option. The suggestion is to allow for a target in DIO without a RDO. Proposed resolution ------------------------- Keep it at that since 1) there are implementations and 2) it's experimental . This resolution implies that the issue will be reopened should the work go for standard track Discussion ------------- [Pascal]" MAY carry one or more RPL Target Options to specify additional unicast/multicast addresses for the target." Now here I would have a MUST carry at least one target. That is indeed what makes is a lookup DIO... [Mukul] As I stated in the previous message, we need to include the target in the P2P-RDO to save bytes for the common case (discover route to one unicast/multicast target). So, we cannot make using the target option a MUST. [Pascal2] Certainly. I prefer the split, in which case the MUST IMHO goes to the target as opposed to the RDO. In a case where the RDO is not needed, the target only message is actually shorter... [Mukul2] As I said before, I think a P2P mode DIO always needs to have one P2P-RDO. I guess, in this case, we agree to disagree! [Pascal3] Certainly. And there's nothing blocking with that disagreement, mostly if the draft targets experimental. I think it's OK to keep your response as the proposed resolution for the issue. Still I'd like advice from others so exposing the issue as LC will help. Let's see on which side the coin falls. [Mukul3] OK. I will be happy to hear additional opinions. [Pascal4] Fine, let's keep that as the proposed resolution [Mukul4] OK. Pascal --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From prvs=4385599de=mukul@uwm.edu Sun Apr 8 08:59:13 2012 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 0D5A721F85B4 for ; Sun, 8 Apr 2012 08:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.99 X-Spam-Level: X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=0.609, 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 EQLLF53xW50M for ; Sun, 8 Apr 2012 08:59:12 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 619C421F851E for ; Sun, 8 Apr 2012 08:59:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAIO1gU9/AAAB/2dsb2JhbABEhWa2TwEBBSNWDA8RBAEBAwINGQJRCBmIDgunQIh1iQmBL4wHggyBGASIWo0SgRGPJYMF Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 63B63E6AAC; Sun, 8 Apr 2012 10:58:00 -0500 (CDT) 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 EX0o98URK9oq; Sun, 8 Apr 2012 10:57:59 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 3FBD1E6A72; Sun, 8 Apr 2012 10:57:59 -0500 (CDT) Date: Sun, 8 Apr 2012 10:57:59 -0500 (CDT) From: Mukul Goyal To: roll@ietf.org Message-ID: <984808904.1851138.1333900679203.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <055.6ee5f9af0660881f34d198ae081e0ce4@trac.tools.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] [roll] #88: Data option and ULP 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, 08 Apr 2012 15:59:13 -0000 Hi JP, Richard Please mark this ticket as closed. Or would it be done when I submit the ne= w version of the draft with this change in? Thanks Mukul ----- Original Message ----- From: "roll issue tracker" To: mukul@UWM.EDU, jpv@cisco.com Cc: roll@ietf.org Sent: Wednesday, April 4, 2012 8:10:34 AM Subject: [roll] #88: Data option and ULP #88: Data option and ULP Problem (proposed resolution exists) ------------------------------ An option exists for carrying payload. The use of the option (tunnel, transport?) is not described properly. Proposed resolution ------------------------ Add a next header and a sequence to the data option so upper layers can be determined. Discussion ------------- [Pascal] Can the data option be different from one DIO to the next? [Mukul] The contents of the data option are specified by the origin (for the DIO) or the target (for the DRO). In theory, an origin can send different data options in different DIOs it generates for a particular route discovery (assuming that it does generate multiple DIOs; it is very much possible that the origin generates just one DIO and then sits silent). But, then the origin is taking the risk that some of the data options would never each the target(s). I guess the origin might do this if the data sent earlier is now stale and the origin would like the target(s) to receive newer data. [Pascal2] This should be discussed in the draft. You need to set the expectation for the upper layer(s). Is there a way to differentiate different data sets? Eg instance or sequence nb? My suggestion so far is that the data should have 3 bits of next header and 5 bits of sequence. [Mukul2] This sounds good to me. I will incorporate this in the draft unless I hear a better proposal. [Pascal3] Cool. Please make that another LC issue and the proposed resolution, see if there is anyone adding anything to it. [Mukul3] Actually, I would like the next header to be 4 bits and the sequence number to be 4 bits. 4-bit sequence number will still allow up to 16 different messages to be sent during a P2P-RPL discovery. 4 bit next header will allow 16 different possibilities. We can have so many different ways to compress UDP/TCP headers. I think 3 bit next header may not be sufficient. [Pascal4] Cool. Let's use that as the proposed resolution [Mukul4] OK. Pascal --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From prvs=4385599de=mukul@uwm.edu Sun Apr 8 09:09:30 2012 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 49A3221F851D for ; Sun, 8 Apr 2012 09:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.025 X-Spam-Level: X-Spam-Status: No, score=-6.025 tagged_above=-999 required=5 tests=[AWL=0.574, 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 Wjed46404GO2 for ; Sun, 8 Apr 2012 09:09:29 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC5321F8518 for ; Sun, 8 Apr 2012 09:09:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EANm3gU9/AAAB/2dsb2JhbABEhWa2TwEBBSNWDA8RBAEBAwINGQJRCBkZh3ULp0GId4kJgS+JboQlgRgEiFqNEoERjyWDBYE2Fw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 6963E2B3F37; Sun, 8 Apr 2012 11:08:58 -0500 (CDT) 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 NKM9BZDp1pyY; Sun, 8 Apr 2012 11:08:58 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 293552B3F2C; Sun, 8 Apr 2012 11:08:58 -0500 (CDT) Date: Sun, 8 Apr 2012 11:08:58 -0500 (CDT) From: Mukul Goyal To: roll@ietf.org Message-ID: <535571420.1851174.1333901338010.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <055.61fcc856b7b35899da82ce224df8d83b@trac.tools.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] [roll] #90: use of transient instance ID 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, 08 Apr 2012 16:09:30 -0000 Hi Pascal Re-read your proposed resolution text. I am not sure that the draft should = suggest rotating the instance ids. My proposed resolution is to simply sugg= est not using instance id that might be in use. " [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD NOT) against reusing instance ids for which the stale state might exist in the nodes." Thanks Mukul ----- Original Message ----- From: "roll issue tracker" To: mukul@UWM.EDU, jpv@cisco.com Cc: roll@ietf.org Sent: Wednesday, April 4, 2012 8:11:44 AM Subject: [roll] #90: use of transient instance ID #90: use of transient instance ID Problem (resolution agreed upon) ------------------------------ P2P creates temporary states in the transient DAG with a transient instance ID. The protocol must ensure that if the instance ID is reused then the new operation it is not confused with states resulting from the previous use of the same instance ID. Suggestion is to propose a rotation. Discussion ------------- [Pascal] "RPLInstanceID: RPLInstanceID MUST be a local value as described in Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the same RPLInstanceID in two or more concurrent route discoveries." I'd suggest that you enforce a round robin or an opaque circulation so that the new instanceID is the least recently used one out of the 64 possible. [Mukul] I think we should leave it to the origin to decide which value it wants to use for RPLInstanceID. I know some implementations are planning to use a fixed RPLInstanceID value for all route discoveries. [Pascal2] Changing the instance ID will help debug the network and avoid conflicts with stale states. What's really up to the device is the initial sequence. Leaving it up to the origin may help the origin defeat some attacks to some degree. OTOH, after all the instances have been played, LRU forces to replay the same sequence again so the shield drops. My preferred approach would be a SHOULD that would say that the next instance ID SHOULD NOT be one of the (16?) most recently used and MUST NOT be one for which states might still exist in the network. IOW either the states deletion was acknowledged, or all pending lifetimes are exhausted. [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD NOT) against reusing instance ids for which the stale state might exist in the nodes. Using a "MUST NOT" may not be OK since a node may never be 100% sure about non-existence of stale state with a particular instance id (thus, all possible instance id values will become suspect and hence unusable after a while). [Pascal3] Agreed. Note that a circulation is a bonus to defeat replays. And now we're back to the issue above. How does the device know that there is no state left? A lifetime definition would be very useful. That lifetime is different from the DAG's one in RDO. I think we have an open issue here. [Mukul3] As I mentioned above, the life time parameters inside the DODAG configuration option specify the life time of the hop-by-hop routing state for the routes discovered using P2P-RPL. [Pascal4] This boils down to the thread above. Only one issue really, which lifetime is which? So IMHO no need to log anything for this thread. [Mukul4] OK. Pascal --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From prvs=4385599de=mukul@uwm.edu Sun Apr 8 09:10:36 2012 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 C722721F851D for ; Sun, 8 Apr 2012 09:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.057 X-Spam-Level: X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=0.542, 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 YqIYEu1+9POu for ; Sun, 8 Apr 2012 09:10:36 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF7521F8557 for ; Sun, 8 Apr 2012 09:10:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EANm3gU9/AAAB/2dsb2JhbABEhWa2TwEBAQQBAQEgSwsMDxEEAQEDAg0SBAMCKR8JCAYTGYd1C6dBiHeJCYEvjhOBGASIWo0SgRGPJYMFgTYX Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id E48A52FB9E; Sun, 8 Apr 2012 11:10:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk-ILLfeR-PI; Sun, 8 Apr 2012 11:10:13 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 5DD7F2FBB3; Sun, 8 Apr 2012 11:10:13 -0500 (CDT) Date: Sun, 8 Apr 2012 11:10:13 -0500 (CDT) From: Mukul Goyal To: C Chauvenet Message-ID: <1729392135.1851179.1333901413319.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D02216703@AMXPRD0510MB390.eurprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.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] #91: Is it possible for an origin to get an error message in case the P2P-RPL route discovery fails. 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, 08 Apr 2012 16:10:36 -0000 Hi JP, Richard Kindly mark this ticket as closed. Thanks Mukul ----- Original Message ----- From: "C Chauvenet" To: "Mukul Goyal" Cc: roll@ietf.org, jpv@cisco.com Sent: Thursday, April 5, 2012 9:47:34 AM Subject: RE: [Roll] [roll] #91: Is it possible for an origin to get an erro= r message in case the P2P-RPL route discovery fails. -----Message d'origine----- De=C2=A0: Mukul Goyal [mailto:mukul@uwm.edu]=20 Envoy=C3=A9=C2=A0: jeudi 5 avril 2012 15:53 =C3=80=C2=A0: C Chauvenet Cc=C2=A0: roll@ietf.org; jpv@cisco.com Objet=C2=A0: Re: [Roll] [roll] #91: Is it possible for an origin to get an = error message in case the P2P-RPL route discovery fails. #91: Is it possible for an origin to get an error message in case the P2P-R= PL route discovery fails. Discussion: [Cedric] On big question that rise my mind is, what happened if the route discovery= fail ? Some protocols sends out an error message when the route discovery fails = or get stuck. Do authors think that it could be relevant to add a "discovery-error" message as defined in other route discovery protocols ? [Mukul] I dont think it is possible to detect the failure of a P2P-RPL route disc= overy. No node knows if a P2P-RPL route discovery has failed. P2P-RPL forms a temporary DAG and the route discovery (well, at least the = first half) succeeds when a target joins the DAG. Only the target knows w= hether it joined the DAG or not. So, no node knows if the (first half of the) route discovery failed. Second half involves the target sending DRO to the origin. If the DRO does= not reach the origin, (the second half of) the route discovery fails. The= target can ensure (or at least increase the probability of) success by a= sking for DRO-ACK and retransmitting the DRO if the DRO-ACK is not receive= d within certain time duration. DRO message travels by multicast, so an in= termediate router, that forwards a DRO further, has no idea whether the ne= xt hop on the route received the DRO or not. Again, no node knows if the (= second half of the) there is no one to generate the discovery-error messag= e. I think an origin might infer the route discovery to have failed, if the = DAG's life time has expired but no DRO is received. But I am not sure we s= hould mandate this to be the way failure is inferred. We have just 4 value= s for the DAG life time. So, I think we should leave it to origin how much= to wait for a DRO before admitting failure. [Cedric2] I was thinking about an error message if the delivery of a message fails wh= en using a route established by the P2P-RPL mechanism. When a node included in the discovered route cannot be reached, then an err= or message could initiate a new route discovery using the P2P-RPL mechanism= . [Mukul2] P2P-RPL routes are used in exactly the same manner as core RPL routes, that= is you use an RPL Source Routing Header (RFC6554) or an RPL Option (RFC655= 3) to send a packet to its destination. These RFCs specify what ICMP error = messages could be generated if the route is broken. [Cedric3] Ok. If the route error detection is alredy handled, I think an additional error= message is not necessary. --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=4385599de=mukul@uwm.edu Sun Apr 8 09:21:29 2012 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 913DB21F8557 for ; Sun, 8 Apr 2012 09:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.086 X-Spam-Level: X-Spam-Status: No, score=-6.086 tagged_above=-999 required=5 tests=[AWL=0.513, 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 SP7SXPKCsMm5 for ; Sun, 8 Apr 2012 09:21:28 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id C893321F8523 for ; Sun, 8 Apr 2012 09:21:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAFG6gU9/AAAB/2dsb2JhbABChXO2TwEBAQQBAQEgSwsMDxEEAQEDAg0WAwIpHwkIBhOIDgusCYh5gSGBL44TgRgEiFqNEoERjyWDBYE2Fw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4E01C1FD0D6; Sun, 8 Apr 2012 11:11:14 -0500 (CDT) 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 9O9Bpoj2YLP3; Sun, 8 Apr 2012 11:11:14 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 1A2571FD0D5; Sun, 8 Apr 2012 11:11:14 -0500 (CDT) Date: Sun, 8 Apr 2012 11:11:13 -0500 (CDT) From: Mukul Goyal To: C Chauvenet Message-ID: <287665186.1851186.1333901473996.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D0221638D@AMXPRD0510MB390.eurprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.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] #92: Is it possible to make P2P-RPL independent of trickle algorithm 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, 08 Apr 2012 16:21:29 -0000 Hi JP, Richard Please mark this ticket as closed. Thanks Mukul ----- Original Message ----- From: "C Chauvenet" To: roll@ietf.org, mukul@UWM.EDU, jpv@cisco.com Sent: Thursday, April 5, 2012 8:33:14 AM Subject: RE: [Roll] [roll] #92: Is it possible to make P2P-RPL independent = of trickle algorithm See inline. -----Message d'origine----- De=C2=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part d= e roll issue tracker Envoy=C3=A9=C2=A0: jeudi 5 avril 2012 13:00 =C3=80=C2=A0: mukul@UWM.EDU; jpv@cisco.com Cc=C2=A0: roll@ietf.org Objet=C2=A0: [Roll] [roll] #92: Is it possible to make P2P-RPL independent = of trickle algorithm #92: Is it possible to make P2P-RPL independent of trickle algorithm Discussion: [Cedric] Another point that has been discussed today during the ROLL meeting, is t= hat some people may find other mechanisms than trickle more efficient to f= lood the RDO. Could we let the door opened to other flooding optimization mechanism, or = explicitly say that the trickle mechanism MUST be used ? [Mukul] I think inherent dependence on the trickle mechanism is apparent because = of the fact that the route discovery takes place by forming a temporary DA= G. DAG creation (or DIO generation) depends on trickle algorithm. So, P2P-= RPL also depends on trickle algorithm. P2P-RPL being an extension of core = RPL, I dont think there is a way to separate P2P-RPL from trickle algorith= m. [Cedric2] Fine. If this is needed for RPL compliancy, then I agree. --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Sun Apr 8 10:02:53 2012 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 CDC3A21F852C for ; Sun, 8 Apr 2012 10:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.719 X-Spam-Level: X-Spam-Status: No, score=-9.719 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5jVZtlF5OM4 for ; Sun, 8 Apr 2012 10:02:53 -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 D8FDF21F8513 for ; Sun, 8 Apr 2012 10:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2427; q=dns/txt; s=iport; t=1333904573; x=1335114173; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=9pph45I9lVinwZKbTU/69V6lwFVkrrvXHncVqNWlb1U=; b=WBpLbwOc7Cnbov3dO1j5oruWAVfQRpEsHf7pnIYXJzo8pLKokO4oMLkK h6l5HGdH5euKpU9qdU1+oPMy4L5kt9WypCdYcmQbOWXtNvZ2F8tqWaXxo ZeckqeehNZGJbBjavtL3aXwVWtGAMLH44DRrjeEVwVe6IJjLbm6zzn3Pp 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALzDgU+Q/khM/2dsb2JhbABEDrkXgQeCCQEBAQMBEgEdCj0CBQcGAQgOAwQBAQsGFwEHRQkJAQQTCBqHZwWaOZ8Ij3djBKQ5gWmCMDk X-IronPort-AV: E=Sophos;i="4.75,390,1330905600"; d="scan'208";a="70358307" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 08 Apr 2012 17:02:51 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q38H2pXY027439; Sun, 8 Apr 2012 17:02:51 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); Sun, 8 Apr 2012 19:02:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Apr 2012 19:00:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt Thread-Index: Ac0VqSh24ekRYIOCSk2kyKBd4XXMFA== From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 08 Apr 2012 17:02:51.0686 (UTC) FILETIME=[6ED71C60:01CD15A9] Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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: Sun, 08 Apr 2012 17:02:53 -0000 Phil: It is an implementation decision as long as it does not lead to interop issue or unwanted behavior, which is probably the case here. RFC 6550 demands that a node can't stray from the best Rank as computed amongst parents by more than MaxRankIncrease. This 3 clauses do not seem to capture this that we are discussing do not seem to capture this.=20 With (my reading of) the text as it stands, it seems that the implementation has all freedom to select parents and then is given rules to compute a Rank.=20 The resulting Rank could be anything if the parent set as no constraint. In particular " The largest calculated Rank among paths through the parent set, minus MaxRankIncrease" must be less that the Rank obtained from the preferred parent, not the final computed Rank. The node should: 1) Compute the Ranks form its parent set.=20 2) Determine a preferred parent as resulting with the lowest Rank (using the computation described in the previous paragraph) 3) Determine which parents generate a Rank that is between that lowest Rank and MaxRankIncrease 4) Pick a set of parents between those=20 What do you think? Pascal -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: samedi 7 avril 2012 16:58 To: Pascal Thubert (pthubert) Cc: Matteo Paris; roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt On Apr 6, 2012, at 11:18 PM, Pascal Thubert (pthubert) wrote: > The point is that with this clause the node selects its parents first=20 > and its Rank second. The spec recommends picking a preferred parent=20 > first, computing the Rank based on the preferred parent, and then only > consider any node with a lower floor as an acceptable parent. I=20 > understand that want to allow reversing that operation, but then that=20 > should be an option and text should indicate that using it may augment > the parent set for some nodes but end up reducing it for others. Don't you think this is an implementation decision? I tried to write the specification text to be completely neutral on this matter (as some of the MRHOF discussions have gone into). The input to DIO generation is a preferred parent and a parent set; how those two are selected is complete outside the specification with the caveat that it places some constraints (MaxRankIncrease). Phil From prvs=4385599de=mukul@uwm.edu Sun Apr 8 13:45:37 2012 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 BD2EB21F852E for ; Sun, 8 Apr 2012 13:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 KpQjZsNdLM14 for ; Sun, 8 Apr 2012 13:45:37 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id D688121F852A for ; Sun, 8 Apr 2012 13:45:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAGz4gU9/AAAB/2dsb2JhbABEhWa2UgUBAQEgSwYFGxoCDRkCKTAGE4gOC6cUiGmJCYEvjhOBGASIWo0SgRGPJYMFgTYX Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 4F86112E3C1; Sun, 8 Apr 2012 15:45:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0zSSejASsgC; Sun, 8 Apr 2012 15:45:35 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id DD58012E3BC; Sun, 8 Apr 2012 15:45:35 -0500 (CDT) Date: Sun, 8 Apr 2012 15:45:35 -0500 (CDT) From: Mukul Goyal To: C Chauvenet Message-ID: <1380616773.1851920.1333917935800.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D02216532@AMXPRD0510MB390.eurprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.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] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4? 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, 08 Apr 2012 20:45:37 -0000 Please see inline (note the changed title of this ticket) Thanks Mukul #93: Whether P2P-RPL should support establishment of a backward hop-by-hop = route? Resolution: Open Discussion: p12 : This specification does not allow for the establishment of hop-by- = hop routes in the backward direction. [Cedric] Why ? This would enable to establish 2 routes within a single route reque= st. Furthermore, you stipulates in the draft that links have to be bidirectio= nal to propagates RDO, in order to be able to send back the DRO. So if I understand it correctly you ensure that you have a reliable path = in both ways. Why using it in a single way only ? [Mukul] Suppose a DRO establishing a forward hop-by-hop route fails to make it to = the origin. In this case, all we have is some nodes storing the hop-by-hop= state for a broken route but that route is never used since the origin n= ever gets the DRO. On the other hand, if the DRO establishing a backward h= op-by-hop route fails to make it to the origin, we have a broken route tha= t the target is likely to use (to reach the origin). So, if we want P2P-RP= L to establish a backward hop-by-hop route, the target MUST ask for a DRO-= ACK from the origin (to make sure that the DRO does reach the origin and h= ence the backward route is not broken). This can be done if you think it w= ill be useful. We did not include this in P2P-RPL because we did not have = a usecase for backward hop-by-hop routes and we wanted to avoid the additi= onal complexity. This is how we can implement this functionality: we will let the target d= ecide whether it wants the DRO to establish a backward hop-by-hop route. In that case: 1) the target will set a new flag, the B flag (B for backward hop-by-hop = route), inside the DRO to let intermediate routers know that backward rout= e state needs to be established as well; 2) the target will set the A flag to require a DRO-ACK from the origin; 3) the target will specify (inside a new field in the DRO), an RPLInstanc= eID under which the hop-by-hop state for the backward route will be stored= . Note that the RPLInstanceID of the forward route (selected by the origin= ) may not be OK for use in backward route (because the target may have alr= eady used this RPLInstanceID for another hop-by-hop route, using different= routing-metrics/constraints/OF, to the origin). When the intermediate routers receive this DRO, they will store the hop- = by-hop state for the backward route. This hop-by-hop state will consist of: 1) Target address (taken from P2P-RDO inside the DRO). 2) RPLInstanceID specified by the target 3) The destination, i.e., the origin address (same as DODAGID inside the = DRO). Do you want this functionality? [Cedric2]=20 The group has to discuss and decide wether it is usefull or not. I personna= ly think that RPL-P2P draft may be used for binding devices, so it could be= valuable to create a 2 way path between the origin and the target. So I wo= uld vote in favor of such a mechanism.=20 Though, I don't think we should create a new DAG (i.e. select a new RPLInst= anceID) for the backward route. What I would like is just the ability for 2= devices to exchange packet in both ways using the same temporary DAG creat= ed by RPL-P2P. Let me explain the use case with an example : For instance, = if you have nodes deployed in a building or a city, and you want to configu= re some of them. An operator could go in the area where devices to be progr= ammed are installed (or in the neighborhood at least) with a "configurator = node", and need to established a P2P route between this configurator node a= nd the node(s) to be configurated. They create a temporary DAG (possibly th= rough several hops) and exchange configuration frames. Because such message= s are critically important, you often need application layer acknowledgmen= ts, so a backward route is needed. Is the actual specification compliant with such a use case without modifica= tion ? (using piggybacked DATA inside RDO and DRO messages) ? Or do wee nee= d an additional mechanism such as the one you described ? [Mukul2] The target can always use the route inside a received P2P-RDO to source-rou= te a message (e.g. an application level ack) back to the origin. Also, as y= ou noticed, the target can place one or more data options inside the DRO to= send an application level message back to the origin. So, the use case you= have mentioned (which is, by the way, a common use case in commercial buil= ding environment) is supported by current P2P-RPL specification. In my view= , no additional mechanism is required if the intent is to just support the = usecase you described. Infact, we could not come up with a usecase where ba= ckward hop-by-hop routes are absolutely must. So, we decided to keep the sp= ecs simple by not allowing establishment of such routes. Also, currently we= are shooting for an experimental RFC. If, at a later stage, we realize tha= t backward hop-by-hop routes are necessary, we could support them in standa= rds track RFC.=20 =20 --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=4385599de=mukul@uwm.edu Sun Apr 8 14:38:28 2012 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 31BA121F853B for ; Sun, 8 Apr 2012 14:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 aBD2Hr1EMRyD for ; Sun, 8 Apr 2012 14:38:27 -0700 (PDT) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 92C0021F8537 for ; Sun, 8 Apr 2012 14:38:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EACYEgk9/AAAB/2dsb2JhbABEhWa2UgUBAQEgSwsbGgINEgcCKTAGE4gOC6caiG2JCYEvjhOBGASIWo0SgRGPJYMF Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 1D5ACE6A90; Sun, 8 Apr 2012 16:38:27 -0500 (CDT) 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 zONQC+B8te17; Sun, 8 Apr 2012 16:38:26 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id B665FE6A72; Sun, 8 Apr 2012 16:38:26 -0500 (CDT) Date: Sun, 8 Apr 2012 16:38:26 -0500 (CDT) From: Mukul Goyal To: C Chauvenet Message-ID: <1278156449.1852161.1333921106641.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D022166C5@AMXPRD0510MB390.eurprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.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] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery? 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, 08 Apr 2012 21:38:28 -0000 Hi Cedric Please see the response inline. Thanks Mukul #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate c= ompletion of route discovery? Resolution: No because multiple DROs would be generated if multiple source= routes are being discovered. Discussion: p15 : Stop (S): This flag, when set to one by a target, indicates that t= he P2P-RPL route discovery is over. [Cedric] Is this bit really usefull ? My guess is that it will be always set to 1. If you hear a DRO, this indeed means that the RDO has reached the target, = so you could just stop processing RDO when you hear a DRO. Do we really need a flag to stop RDO processing or the hearing of a DRO t= ype message could do the job ? [Mukul] A P2P-RPL invocation might involve discovery of multiple source routes. In= that case, receipt of a DRO does not mean route discovery is over. Only = when the target sets the stop flag in the DRO, a node could be sure that t= he route discovery is over. [Cedric2] OK fo multiple discovery. But if I want to discover a route to a multicast group of target. I set a m= ulticast adress in the target field of the RDO. Then, do I received as many= DRO message as the number of target reached ? In that case, would the firs= t DRO with a "S" flag stop the RDO propagation to reach all the target incl= uded in the multicast group ? [Mukul2] A target cannot set the S flag to one in the DRO if the target address in t= he P2P-RDO specified a multicast address. See the following text at the end= of page 21 in P2P-RPL-9: "The target MAY set the stop flag inside the DRO message to one if Goyal, et al. Expires September 7, 2012 [Page 21] =20 Internet-Draft draft-ietf-roll-p2p-rpl-09 March 2012 o this router is the only target specified in the corresponding DIO, i.e., the corresponding DIO specified a unicast address of the router as the Target inside the P2P-RDO with no additional targets specified via RPL Target Options; and "=20 --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=4385599de=mukul@uwm.edu Sun Apr 8 14:46:05 2012 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 699D821F8557 for ; Sun, 8 Apr 2012 14:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.443, 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 TSG0HRN3OEW1 for ; Sun, 8 Apr 2012 14:46:04 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id A653821F853D for ; Sun, 8 Apr 2012 14:46:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAJQGgk9/AAAB/2dsb2JhbABEhWa2UAEBBSNLCwwPEQQBAQMCDWwIBoghpx6IbokFBIEviXgBhTIEiFqNEpA2gwWBNgE Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 622F7E6A72; Sun, 8 Apr 2012 11:13:06 -0500 (CDT) 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 gN5CxfjnGCdk; Sun, 8 Apr 2012 11:13:06 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 090A6E6A8F; Sun, 8 Apr 2012 11:13:06 -0500 (CDT) Date: Sun, 8 Apr 2012 11:13:05 -0500 (CDT) From: Mukul Goyal To: Ulrich Herberg Message-ID: <1882104471.1851190.1333901585942.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1974009367.1822935.1333602077084.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.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Scalability of P2P-RPL 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, 08 Apr 2012 21:46:05 -0000 Hi JP, Richard Should this be made a ticket? This is the only comment for which we dont have a ticket yet. Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "Ulrich Herberg" Cc: "roll WG" Sent: Thursday, April 5, 2012 12:01:17 AM Subject: Re: [Roll] Scalability of P2P-RPL Hi Ulrich [cedric] > > As discussed today during the meeting, numbers need to be placed given a > particular context. > So, if we put explicitly "4-5 hops" in the requirements, this has to be in > regards to the total number of nodes, the topology, the technology used, the > environment, and other numerous parameters that could justify this "4-5" > value for a particular case. [Ulrich] I am aware that the precise number of hops depends on a number of things. However, I think it should be spelled out that the draft has limitations in terms of scope and is not always applicable in general LLNs of thousands of nodes (at least that's what I infer from the talk yesterday). [Mukul] I dont think what you are suggesting is correct. P2P routes are likely to be better than global DAG based routes when origin and target are only few hops away. As the distance between origin and target increases, P2P routes are likely to be only marginally better than global-DAG-based routes (P2P routes possibly have the advantage that they avoid congested region near the DAG root). But, P2P-RPL can certainly be used in an LLN of thousands of nodes. Just limit the scope of discovery appropriately. Infact, I would argue that P2P-RPL would work very well in an LLN of thousands of nodes because: 1) you can limit the scope of discovery; 2) trickle based propagation of discovery messages allows you to control the pace of spread of discovery messages. [Cedric] > So people working over the 2.4 Ghz may use the 4-5 hops boundary, whereas > people running over sub Ghz may be happy within a single hop boundary. [Ulrich] Sure, I never doubted that depending on the link layer / the topology / the traffic patterns etc there are differences in scope. I just request to add one sentence to make it clear to the reader what the applicability of the draft is. [Mukul] The draft's applicability is certainly not restricted by the size of the network. It is reactive route discovery protocol with a great level of control over how you want to discover routes. [cedric] > > There is a section in the P2P draft that is quite generic, so applicable to > most of the use case, > and shed some light on the tradeoff regarding using > or not the P2P extension, and limit the scope of the flooding : > > A network designer may take into consideration both the benefits > (potentially better routes; > no need to maintain routes proactively) and costs (control messages > generated during the route discovery process) when using P2P-RPL. > > > We may expand this sentence to be more precise on the flooding region. > > What do you think ? [Ulrich] That can be done. But I also think that the Use Cases section should be more specific in which scenarios the draft can be used. [Mukul] What do you have in mind? The use cases section already lists the key scenarios we had in mind while designing this protocol. [cedric] > > I think numbers are always dangerous in documents that need to be frozen at > some point. [Ulrich] I do not insist on fixed numbers, I am aware that the number 4 or 5 was just named as example. But it was clear from them that the draft is limited to small-size networks ... [Mukul] I certainly object to this characterization. [Ulrich] (or at least close peers in a larger network). [Mukul] Look, there are two different questions: 1) can P2P-RPL be used to discover route to a far away target? 2) would such route be much better than the route along a global dag? The answer to first question is "absolutely yes" and that to second question is "probably not (if the root's neighborhood is not congested) and probably yes (if the root's neighborhood is congested)". Thanks Mukul _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=4385599de=mukul@uwm.edu Sun Apr 8 15:13:00 2012 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 DE9A521F84B6 for ; Sun, 8 Apr 2012 15:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=0.424, 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 aQFF2tbq5CM4 for ; Sun, 8 Apr 2012 15:13:00 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 141B721F84B3 for ; Sun, 8 Apr 2012 15:13:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAFsMgk9/AAAB/2dsb2JhbABEhWa2UgUBAQEgSwsbGgINEgcCKTAGE4gOC6cUiHGJCYEvjhOBGASIWo0SgRGPJYMF Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 9088E2B3F0A; Sun, 8 Apr 2012 17:12:59 -0500 (CDT) 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 lDvTrtxAO9Lb; Sun, 8 Apr 2012 17:12:59 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 1C0A62B3EF6; Sun, 8 Apr 2012 17:12:59 -0500 (CDT) Date: Sun, 8 Apr 2012 17:12:59 -0500 (CDT) From: Mukul Goyal To: C Chauvenet Message-ID: <1226828832.1852306.1333923179020.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D02216681@AMXPRD0510MB390.eurprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.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] #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs? 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, 08 Apr 2012 22:13:01 -0000 Hi Cedric Please see inline. Thanks Mukul #96: Can the draft recommend how much to wait before a target selects route= s to be sent back in DROs? Resolution: This is purely a local decision at the target. The draft shou= ld not make any recommendation in this regard. Discussion: p21 : Example methods include selecting each route that meets the specif= ied routing constraints until the desired number have been selected or selecting the best routes discovered over a certain time period. [Cedric] How could we know the time to wait until we get all the RDO ? Is there a way to evaluate it according to some parameters related to the = network (diameter of the network for instance) ? [Mukul] This has to be a local decision. Perhaps, the target can look at = the aggregated values of the routing metrics from the origin and determine = its distance from the origin. This distance estimate, along with trickle = parameters, could perhaps give it a better idea of how much to wait. I don= t think that the draft should talk about this. [Cedric2] OK, let's say it is up to the implementation and should be deterinied accor= ding to the specific set of metric/contraints in use. A target from a DAG based on a latency metric could wait just a few ms afte= r receiving the first RDO and select the best path according to the latenc= y metric. A target from a DAG based on a energy metric could wait much more time afte= r receiving the first RDO to be sure to use an energy efficient path, that = could be discovered after some time, because of duty cycling nodes for inst= ance. [Mukul2] Choosing the wait time on the basis of specific metrics being used= in route discovery could be one option. However, when an origin wants to d= iscover low latency routes, it does not necessarily mean that the latency o= f the route discovery process has to be low as well. :) So, in general, I t= hink that the time a target waits before sending DROs (which determines to = some extent the latency of the route discovery process) is independent of t= he specific metrics/constraints being used in route discovery process. As I= said before, I think the target should decide for itself how much should i= t wait before sending DRO(s). It may not be wise to make any suggestions in= this regard in the P2P-RPL specs beyond what the draft already says - the = draft does suggest two sample methods: 1) select routes on FCFS basis 2) ch= oose the best routes discovered over an interval.=20 =20 --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: applicability-ami | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=4385599de=mukul@uwm.edu Sun Apr 8 15:16:42 2012 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 98C4A21F846A for ; Sun, 8 Apr 2012 15:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.406, 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 RVuPqNneypa2 for ; Sun, 8 Apr 2012 15:16:42 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 10B5821F8468 for ; Sun, 8 Apr 2012 15:16:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EALgNgk9/AAAB/2dsb2JhbABDhXO2UAEBAQQBAQEgSwsMDxEEAQEDAg0WAwIpHwkIBhOIDgusBIh1gSGBL44TgRgEiFqNEoERiEWGYIMF Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 83B58E6A8E; Sun, 8 Apr 2012 17:16:41 -0500 (CDT) 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 8RDM7kttht1Z; Sun, 8 Apr 2012 17:16:41 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 3130AE6A72; Sun, 8 Apr 2012 17:16:41 -0500 (CDT) Date: Sun, 8 Apr 2012 17:16:41 -0500 (CDT) From: Mukul Goyal To: C Chauvenet Message-ID: <820013775.1852322.1333923401124.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D022165D6@AMXPRD0510MB390.eurprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.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] #97: A fixed value for DRO_ACK_WAIT_TIME not OK for all P2P-RPL 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: Sun, 08 Apr 2012 22:16:42 -0000 Hi JP, Michael Kindly close this ticket. Thanks Mukul ----- Original Message ----- From: "C Chauvenet" To: roll@ietf.org, mukul@UWM.EDU, jpv@cisco.com Sent: Thursday, April 5, 2012 9:21:38 AM Subject: RE: [Roll] [roll] #97: A fixed value for DRO_ACK_WAIT_TIME not OK = for all P2P-RPL deployments. -----Message d'origine----- De=C2=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part d= e roll issue tracker Envoy=C3=A9=C2=A0: jeudi 5 avril 2012 13:03 =C3=80=C2=A0: mukul@UWM.EDU; jpv@cisco.com Cc=C2=A0: roll@ietf.org Objet=C2=A0: [Roll] [roll] #97: A fixed value for DRO_ACK_WAIT_TIME not OK = for all P2P-RPL deployments. #97: A fixed value for DRO_ACK_WAIT_TIME not OK for all P2P-RPL deployments= . Resolution: Make DRO_ACK_WAIT_TIME as well as MAX_DRO_RETRANSMISSIONS con= figurable parameters. Discussion: p25 : o DRO_ACK_WAIT_TIME: The time duration a target waits for the DRO- = ACK before retransmitting a DRO message. DRO_ACK_WAIT_TIME has a value of 1 second. [Cedric] I'm not sure it is compliant with all RPL deployments. Could we adapt it to the characteristics of the network used ? [Mukul] I am OK with making DRO_ACK_WAIT_TIME as well as MAX_DRO_RETRANSMISSIONS = configurable parameters. [Cedric2] Safe enough. --=20 -----------------------------------+--------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: new Priority: major | Milestone: Component: applicability-ami | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From admin@ipv6it.org Mon Apr 9 00:49:57 2012 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 CFBF221F863F for ; Mon, 9 Apr 2012 00:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 f3QjCOPFq4rG for ; Mon, 9 Apr 2012 00:49:57 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 71C2D21F858D for ; Mon, 9 Apr 2012 00:49:52 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so1888908wib.13 for ; Mon, 09 Apr 2012 00:49:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=778KrJzGl8Fs6svxV/s+q2dB+ZcM3OFppLvoen+QszU=; b=fi5nBqt9xx2OpgGYCcan5p5vUAfU6jFQFijh3S9LBhwsjGnxpUqA+5HkJ7LTzqdrvl DrJ9fV/Z2aTPyksXYqWczsjtDdJnoaeZFKDztA8zeCvIw07fOxJHVrASNqdVsmt/6ICp 3Oq8sfZf4DQzOrxNa0wJmtsehq8HqT9Vw5/drRLDGhbsSn2XkAjXWiPAHewX3NQ65F6c 5jH1bpUi5deAG0Eeelm1olBfFzQOMG3PNaegNuTq4kbYdujvpzmC4ZW50EBBxlenKRWR kRpg6Z7xRRDKn4aT13ZZDfY3jygky3bjUR5+N8aAH+gHE7k56SiKkfucsTsmuSvjVluK nyBA== Received: by 10.180.104.231 with SMTP id gh7mr13850692wib.10.1333957791394; Mon, 09 Apr 2012 00:49:51 -0700 (PDT) Received: from [127.0.0.1] (host136-59-dynamic.56-82-r.retail.telecomitalia.it. [82.56.59.136]) by mx.google.com with ESMTPS id ev10sm7846019wid.10.2012.04.09.00.49.49 (version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 00:49:50 -0700 (PDT) Message-ID: <4F829499.7090902@ipv6it.org> Date: Mon, 09 Apr 2012 09:49:45 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000306000109090809000600" X-Gm-Message-State: ALoCoQnHYII6t6C/Smi2M6f0RP0PTD9msGDrn1ynsvUUHkiZbhed696gCXAzR0vNDoiNLHLMp5p6 Cc: Roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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, 09 Apr 2012 07:49:57 -0000 This is a multi-part message in MIME format. --------------000306000109090809000600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, IMHO I think that if you use MaxRankIncrease it's because you *want* a particular behavior of RPLand especially you *want *that: "If a node's Rank were to be higher than allowed by L + DAGMaxRankIncrease, when it advertises Rank, it MUST advertise its Rank as INFINITE_RANK." If you calculate the parent setas you wrote in step 3 you simply avoid this (wanted) behavior; in fact I can also say: "If you use MaxRankIncrease this relation MAXRankIncrease>MAX_PATH_COST+MAX_LINK_METRIC must be true." and I "fixed" the problem. I think that if you want to put a constraint on the parent-set it can not be MaxRankIncrease but it should be another variable/constraint. -- Regards Consoli Federico > Phil: > > It is an implementation decision as long as it does not lead to interop > issue or unwanted behavior, which is probably the case here. > RFC 6550 demands that a node can't stray from the best Rank as computed > amongst parents by more than MaxRankIncrease. > This 3 clauses do not seem to capture this that we are discussing do not > seem to capture this. > With (my reading of) the text as it stands, it seems that the > implementation has all freedom to select parents and then is given rules > to compute a Rank. > The resulting Rank could be anything if the parent set as no constraint. > > > In particular " The largest calculated Rank among paths through the > parent set, minus MaxRankIncrease" must be less that the Rank obtained > from the preferred parent, not the final computed Rank. > > > The node should: > 1) Compute the Ranks form its parent set. > 2) Determine a preferred parent as resulting with the lowest Rank (using > the computation described in the previous paragraph) > 3) Determine which parents generate a Rank that is between that lowest > Rank and MaxRankIncrease > 4) Pick a set of parents between those > > What do you think? > > Pascal > > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: samedi 7 avril 2012 16:58 > To: Pascal Thubert (pthubert) > Cc: Matteo Paris; roll@ietf.org > Subject: Re: [Roll] New Version Notification > -draft-ietf-roll-minrank-hysteresis-of-07.txt > > > On Apr 6, 2012, at 11:18 PM, Pascal Thubert (pthubert) wrote: > >> The point is that with this clause the node selects its parents first >> and its Rank second. The spec recommends picking a preferred parent >> first, computing the Rank based on the preferred parent, and then only >> consider any node with a lower floor as an acceptable parent. I >> understand that want to allow reversing that operation, but then that >> should be an option and text should indicate that using it may augment >> the parent set for some nodes but end up reducing it for others. > Don't you think this is an implementation decision? I tried to write the > specification text to be completely neutral on this matter (as some of > the MRHOF discussions have gone into). The input to DIO generation is a > preferred parent and a parent set; how those two are selected is > complete outside the specification with the caveat that it places some > constraints (MaxRankIncrease). > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------000306000109090809000600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, IMHO I think that if you use MaxRankIncrease it's because you want a particular behavior of RPL and especially you want that:

"If a node's Rank were to be higher than allowed by L + DAGMaxRankIncrease,
when it advertises Rank, it MUST advertise its Rank as INFINITE_RANK."

If you calculate the  parent set as you wrote in step 3 you simply avoid this (wanted) behavior; in fact I can also say:
"If you use MaxRankIncrease this relation MAXRankIncrease>MAX_PATH_COST+MAX_LINK_METRIC must be true." and I "fixed" the problem.

I think that if you want to put a constraint on the parent-set it can not be MaxRankIncrease but it should be another variable/constraint.

-- 
Regards
Consoli Federico

Phil:

It is an implementation decision as long as it does not lead to interop
issue or unwanted behavior, which is probably the case here.
RFC 6550 demands that a node can't stray from the best Rank as computed
amongst parents by more than MaxRankIncrease.
This 3 clauses do not seem to capture this that we are discussing do not
seem to capture this. 
With (my reading of) the text as it stands, it seems that the
implementation has all freedom to select parents and then is given rules
to compute a Rank. 
The resulting Rank could be anything if the parent set as no constraint.


In particular  " The largest  calculated Rank among paths through the
parent set, minus MaxRankIncrease" must be less that the Rank obtained
from the preferred parent, not the final computed Rank.


The node should:
1) Compute the Ranks form its parent set. 
2) Determine a preferred parent as resulting with the lowest Rank (using
the computation described in the previous paragraph)
3) Determine which parents generate a Rank that is between that lowest
Rank and MaxRankIncrease
4) Pick a set of parents between those 

What do you think?

Pascal

-----Original Message-----
From: Philip Levis [mailto:pal@cs.stanford.edu] 
Sent: samedi 7 avril 2012 16:58
To: Pascal Thubert (pthubert)
Cc: Matteo Paris; roll@ietf.org
Subject: Re: [Roll] New Version Notification
-draft-ietf-roll-minrank-hysteresis-of-07.txt


On Apr 6, 2012, at 11:18 PM, Pascal Thubert (pthubert) wrote:


The point is that with this clause the node selects its parents first 
and its Rank second. The spec recommends picking a preferred parent 
first, computing the Rank based on the preferred parent, and then only


      

        
consider any node with a lower floor as an acceptable parent. I 
understand that want to allow reversing that operation, but then that 
should be an option and text should indicate that using it may augment


      

      

      

        
the parent set for some nodes but end up reducing it for others.


      

      
Don't you think this is an implementation decision? I tried to write the
specification text to be completely neutral on this matter (as some of
the MRHOF discussions have gone into). The input to DIO generation is a
preferred parent and a parent set; how those two are selected is
complete outside the specification with the caveat that it places some
constraints (MaxRankIncrease).

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


    

    

    

    

  


--------------000306000109090809000600--

From pal@cs.stanford.edu  Mon Apr  9 09:03:54 2012
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 ADC4321F8763 for ; Mon,  9 Apr 2012 09:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.516
X-Spam-Level: 
X-Spam-Status: No, score=-5.516 tagged_above=-999 required=5 tests=[AWL=1.083,  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 wK6Fv0cnuOeP for ; Mon,  9 Apr 2012 09:03:54 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 46C0321F8754 for ; Mon,  9 Apr 2012 09:03:54 -0700 (PDT)
Received: from dn0a210221.sunet ([10.33.2.33]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SHH4L-0000Pz-EN; Mon, 09 Apr 2012 09:03:53 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: 
Date: Mon, 9 Apr 2012 08:46:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B42E04B-7DFB-4C42-83C5-4ED72B3AC8A6@cs.stanford.edu>
References: 
To: Pascal Thubert (pthubert) 
X-Mailer: Apple Mail (2.1257)
X-Scan-Signature: 6214ac49f2cb083a0c8190805312a710
Cc: roll@ietf.org
Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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, 09 Apr 2012 16:03:54 -0000

On Apr 8, 2012, at 10:00 AM, Pascal Thubert (pthubert) wrote:

> Phil:
>=20
> It is an implementation decision as long as it does not lead to =
interop
> issue or unwanted behavior, which is probably the case here.
> RFC 6550 demands that a node can't stray from the best Rank as =
computed
> amongst parents by more than MaxRankIncrease.
> This 3 clauses do not seem to capture this that we are discussing do =
not
> seem to capture this.=20
> With (my reading of) the text as it stands, it seems that the
> implementation has all freedom to select parents and then is given =
rules
> to compute a Rank.=20
> The resulting Rank could be anything if the parent set as no =
constraint.
>=20
>=20
> In particular  " The largest  calculated Rank among paths through the
> parent set, minus MaxRankIncrease" must be less that the Rank obtained
> from the preferred parent, not the final computed Rank.
>=20
>=20
> The node should:
> 1) Compute the Ranks form its parent set.=20
> 2) Determine a preferred parent as resulting with the lowest Rank =
(using
> the computation described in the previous paragraph)
> 3) Determine which parents generate a Rank that is between that lowest
> Rank and MaxRankIncrease
> 4) Pick a set of parents between those=20
>=20
> What do you think?

This is an implementation decision. I can imagine other algorithms, =
e.g., where if the best Rank and next best Rank differ by more than =
MaxRankIncrease, the node chooses to advertise a worse Rank than the =
preferred parent provides.

Phil=

From pthubert@cisco.com  Mon Apr  9 23:11:46 2012
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 AD4DB21F84F6 for ; Mon,  9 Apr 2012 23:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.792
X-Spam-Level: 
X-Spam-Status: No, score=-9.792 tagged_above=-999 required=5 tests=[AWL=0.807,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrTBzChrnJa0 for ; Mon,  9 Apr 2012 23:11:46 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B6D6C21F848E for ; Mon,  9 Apr 2012 23:11:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2297; q=dns/txt; s=iport; t=1334038305; x=1335247905; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ZsY7o/Xcu6yAtmnTKqVRg/6bSydsUTih0/D1tKMN3AU=; b=PT3wn8m0YIFzBacMhxb+G1YF0usNpEx6PmBFrBleTWfbESYX5v0SwQ7y NGwB7GkewrFIVsH6vLf19dNEMd90CukIJ/K6+KW25fSIBE+5Hs0gBmfVm irrPDaOpPpVdwNFIOLqHPZSl8Q7OMeZFnVE+DcjEabhiu6XG0T3fxW/2m I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAE7Og0+Q/khN/2dsb2JhbABEDrlFgQeCCQEBAQMBEgEdCj0CBQcEAgEIDgMEAQELBhcBBgFFCQgBAQQTCBqHZwWaLaApj35jBKQ5gWmCMDk
X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208";a="134656021"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 Apr 2012 06:11:44 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3A6BiZS029215; Tue, 10 Apr 2012 06:11:44 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);  Tue, 10 Apr 2012 08:11:44 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 Apr 2012 08:10:29 +0200
Message-ID: 
In-Reply-To: <3B42E04B-7DFB-4C42-83C5-4ED72B3AC8A6@cs.stanford.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt
Thread-Index: Ac0Wal3lZFHU8XUwQnuggZ2Lt9w6DwAdbA9w
References:  <3B42E04B-7DFB-4C42-83C5-4ED72B3AC8A6@cs.stanford.edu>
From: "Pascal Thubert (pthubert)" 
To: "Philip Levis" 
X-OriginalArrivalTime: 10 Apr 2012 06:11:44.0564 (UTC) FILETIME=[CDD8DF40:01CD16E0]
Cc: roll@ietf.org
Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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: Tue, 10 Apr 2012 06:11:46 -0000

Phil:

It's not.=20
If I switch a device with another from a different vendor I should
expect the new device to interact properly with existing devices and I
should expect globally a similar behavior in my network.=20
That's what standards are for.

RPL 3.7.1 gives strong directions to avoid greediness. You may allow to
stray from that but that must be under control of the admin and you must
give strong recommendations for the default behavior.

Cheers,

Pascal

-----Original Message-----
From: Philip Levis [mailto:pal@cs.stanford.edu]=20
Sent: lundi 9 avril 2012 17:46
To: Pascal Thubert (pthubert)
Cc: roll@ietf.org
Subject: Re: [Roll] New Version Notification
-draft-ietf-roll-minrank-hysteresis-of-07.txt

On Apr 8, 2012, at 10:00 AM, Pascal Thubert (pthubert) wrote:

> Phil:
>=20
> It is an implementation decision as long as it does not lead to=20
> interop issue or unwanted behavior, which is probably the case here.
> RFC 6550 demands that a node can't stray from the best Rank as=20
> computed amongst parents by more than MaxRankIncrease.
> This 3 clauses do not seem to capture this that we are discussing do=20
> not seem to capture this.
> With (my reading of) the text as it stands, it seems that the=20
> implementation has all freedom to select parents and then is given=20
> rules to compute a Rank.
> The resulting Rank could be anything if the parent set as no
constraint.
>=20
>=20
> In particular  " The largest  calculated Rank among paths through the=20
> parent set, minus MaxRankIncrease" must be less that the Rank obtained

> from the preferred parent, not the final computed Rank.
>=20
>=20
> The node should:
> 1) Compute the Ranks form its parent set.=20
> 2) Determine a preferred parent as resulting with the lowest Rank=20
> (using the computation described in the previous paragraph)
> 3) Determine which parents generate a Rank that is between that lowest

> Rank and MaxRankIncrease
> 4) Pick a set of parents between those
>=20
> What do you think?

This is an implementation decision. I can imagine other algorithms,
e.g., where if the best Rank and next best Rank differ by more than
MaxRankIncrease, the node chooses to advertise a worse Rank than the
preferred parent provides.

Phil

From pthubert@cisco.com  Tue Apr 10 00:07:58 2012
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 49A6F21F86D4 for ; Tue, 10 Apr 2012 00:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.854
X-Spam-Level: 
X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.744,  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 G322FHQ9dKsU for ; Tue, 10 Apr 2012 00:07:54 -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 95A1F21F86D0 for ; Tue, 10 Apr 2012 00:07:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=24621; q=dns/txt; s=iport; t=1334041673; x=1335251273; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=NqcWBN2ProWY33H9x82hucDYGOVGxhUvzeA+u/2njSs=; b=j9PD7W/Nd5qbMAXxt6fs2XR2cPTDhRmsdbWLKmO2fiMmMfuxIBY/ei2k d+w/szEYbgAJOcMsbd7f++KBGywpmH0lo9m1/NsHnFR6O+TQlXzKlSmys 6zp9cgxiTkRAFGpTBb5Z6FGc0DW4WqwRwkcOLWXNkAzLqKrbXTm/Lltu+ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAODbg0+Q/khN/2dsb2JhbABEgka3B4EHggkBAQEDAQEBAQ8BCREDPgQFAgUHBAIBCA4DBAEBCwYQBwEGASYfCQgBAQQTCBqHZwULmiigMgSPfmMEpDmBaYJp
X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208,217";a="70437147"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 10 Apr 2012 07:07:51 +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 q3A77oDh007248; Tue, 10 Apr 2012 07:07:50 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);  Tue, 10 Apr 2012 09:07:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD16E8.A48B3739"
Date: Tue, 10 Apr 2012 09:06:46 +0200
Message-ID: 
In-Reply-To: <4F829499.7090902@ipv6it.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt
Thread-Index: Ac0WJV5n6LEHmcKjRXm9sr3W5ZknZwAuhQQw
References:  <4F829499.7090902@ipv6it.org>
From: "Pascal Thubert (pthubert)" 
To: "Federico Consoli" 
X-OriginalArrivalTime: 10 Apr 2012 07:07:51.0756 (UTC) FILETIME=[A4D998C0:01CD16E8]
Cc: Roll@ietf.org
Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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: Tue, 10 Apr 2012 07:07:58 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD16E8.A48B3739
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Frederico :

=20

My scenario is just a high level direction and does not intend to be
Phil's final text. I used that to illustrate the difference between my
expected behavior and my reading of the current text.=20

You'll also note that my text mandates that the preferred parent it the
one that results with the lowest resulting rank, which is an OF decision
and could be done differently here.


> I think that if you want to put a constraint on the parent-set it can
not be MaxRankIncrease but it should be another variable/constraint.

=20

Semantically speaking, you're probably right. It will be cleaner if the
OF cares to define the max Rank stretch between the least and worst
parent when computing the initial value for L.

I assumed it was simpler to just define the initial computation of L and
then live by the rules. But that could be confusing.

=20

And I agree with your wanted behavior. That's the spirit of section
8.2.2.4 item 3 in RPL. A next sentence could be that if the node is
unhappy with the resulting parent set it may advertise infinite and pick
any parent.=20

But that must be exceptional, like for nodes that do not want to be a
router anyway. I trust that if this is generalized then the greedy
misbehavior (see section 3.7.1) will become apparent.

For instance, if we add a router that sees 2 existing routers, with
Ranks far apart, what do we expect?  Does that depend on the metric?=20

If the new node bases its Rank on the worst of the 2 existing routers,
it will be mostly unusable as a parent =3D> adding a new node will fail =
to
improve connectivity for others.

=20

RPL provides hints for that and indicates that the preferred parent
gives the sense of the position in the graph. Though it's up to the OF,
L is naturally the calculated Rank via the preferred parent:

=20

8.2.3.1. DIO Message Processing

<...>

The most preferred parent should be used to restrict which other

nodes may become DODAG parents.

=20

You'll note that the preferred parent does not necessarily mean that it
has the lowest resulting Rank, so it is up to the OF to define something
more complex than my scenario.

=20

Cheers,

=20

Pascal

=20

From: Federico Consoli [mailto:admin@ipv6it.org]=20
Sent: lundi 9 avril 2012 09:50
To: Pascal Thubert (pthubert)
Cc: Roll@ietf.org
Subject: Re: [Roll] New Version Notification
-draft-ietf-roll-minrank-hysteresis-of-07.txt

=20

Hi, IMHO I think that if you use MaxRankIncrease it's because you want a
particular behavior of RPL and especially you want that:=20

"If a node's Rank were to be higher than allowed by L +
DAGMaxRankIncrease,=20
when it advertises Rank, it MUST advertise its Rank as INFINITE_RANK."

If you calculate the  parent set as you wrote in step 3 you simply avoid
this (wanted) behavior; in fact I can also say:=20
"If you use MaxRankIncrease this relation
MAXRankIncrease>MAX_PATH_COST+MAX_LINK_METRIC must be true." and I
"fixed" the problem.

I think that if you want to put a constraint on the parent-set it can
not be MaxRankIncrease but it should be another variable/constraint.




--=20
Regards
Consoli Federico





Phil:
=20
It is an implementation decision as long as it does not lead to interop
issue or unwanted behavior, which is probably the case here.
RFC 6550 demands that a node can't stray from the best Rank as computed
amongst parents by more than MaxRankIncrease.
This 3 clauses do not seem to capture this that we are discussing do not
seem to capture this.=20
With (my reading of) the text as it stands, it seems that the
implementation has all freedom to select parents and then is given rules
to compute a Rank.=20
The resulting Rank could be anything if the parent set as no constraint.
=20
=20
In particular  " The largest  calculated Rank among paths through the
parent set, minus MaxRankIncrease" must be less that the Rank obtained
from the preferred parent, not the final computed Rank.
=20
=20
The node should:
1) Compute the Ranks form its parent set.=20
2) Determine a preferred parent as resulting with the lowest Rank (using
the computation described in the previous paragraph)
3) Determine which parents generate a Rank that is between that lowest
Rank and MaxRankIncrease
4) Pick a set of parents between those=20
=20
What do you think?
=20
Pascal
=20
-----Original Message-----
From: Philip Levis [mailto:pal@cs.stanford.edu]=20
Sent: samedi 7 avril 2012 16:58
To: Pascal Thubert (pthubert)
Cc: Matteo Paris; roll@ietf.org
Subject: Re: [Roll] New Version Notification
-draft-ietf-roll-minrank-hysteresis-of-07.txt
=20
=20
On Apr 6, 2012, at 11:18 PM, Pascal Thubert (pthubert) wrote:
=20

	The point is that with this clause the node selects its parents
first=20
	and its Rank second. The spec recommends picking a preferred
parent=20
	first, computing the Rank based on the preferred parent, and
then only

=20

	consider any node with a lower floor as an acceptable parent. I=20
	understand that want to allow reversing that operation, but then
that=20
	should be an option and text should indicate that using it may
augment

=20

	the parent set for some nodes but end up reducing it for others.

=20
Don't you think this is an implementation decision? I tried to write the
specification text to be completely neutral on this matter (as some of
the MRHOF discussions have gone into). The input to DIO generation is a
preferred parent and a parent set; how those two are selected is
complete outside the specification with the caveat that it places some
constraints (MaxRankIncrease).
=20
Phil
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll






=20

------_=_NextPart_001_01CD16E8.A48B3739
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Frederico :
 
My scenario is just a high level direction and does not intend to be =
Phil’s final text. I used that to illustrate the difference =
between my expected behavior and my reading of the current text. =

You’ll also note that my text mandates that the preferred =
parent it the one that results with the lowest resulting rank, which is =
an OF decision and could be done differently =
here.

> I think that if you want to put a constraint on =
the parent-set it can =
not be MaxRankIncrease but it should be another variable/constraint.
 
Semantically speaking, you’re probably right. It will be =
cleaner if the OF cares to define the max Rank stretch between the least =
and worst parent when computing the initial value for =
L.
I assumed it was simpler to just define the initial computation of L =
and then live by the rules. But that could be =
confusing.
 
And I agree with your wanted behavior. That’s the spirit of =
section 8.2.2.4 item 3 in RPL. A next sentence could be that if the node =
is unhappy with the resulting parent set it may advertise infinite and =
pick any parent. 
But that must be exceptional, like for nodes that do not want to be a =
router anyway. I trust that if this is generalized then the greedy =
misbehavior (see section 3.7.1) will become =
apparent.
For instance, if we add a router that sees 2 existing routers, with =
Ranks far apart, what do we expect?  Does that depend on the =
metric? 
If the new node bases its Rank on the worst of the 2 existing =
routers, it will be mostly unusable as a parent =3D> adding a new =
node will fail to improve connectivity for =
others.
 
RPL provides hints for that and indicates that the preferred parent =
gives the sense of the position in the graph. Though it’s up to =
the OF, L is naturally the calculated Rank via the preferred =
parent:
 
8.2.3.1<=
span style=3D'font-size:10.5pt;font-family:Courier'>. DIO Message =
Processing
<...>
The most =
preferred parent should be used to restrict which =
other
nodes =
may become DODAG parents.
 
You’ll note that the preferred parent does not necessarily mean =
that it has the lowest resulting Rank, so it is up to the OF to define =
something more complex than my scenario.
 
Cheers,
 
Pascal
 
From: Federico Consoli [mailto:admin@ipv6it.org] 
Sent: lundi =
9 avril 2012 09:50
To: Pascal Thubert (pthubert)
Cc: =
Roll@ietf.org
Subject: Re: [Roll] New Version Notification =
-draft-ietf-roll-minrank-hysteresis-of-07.txt
=

 
Hi, =
IMHO I think that if you use MaxRankIncrease it's because you =
want a =
particular =
behavior =
of =
RPL and especially =
you want that: 

"If a node's Rank were to be higher =
than allowed by L + DAGMaxRankIncrease, 
when it advertises Rank, it =
MUST advertise its Rank as INFINITE_RANK."

If you calculate the  parent =
set as you =
wrote in step 3 you =
simply avoid this =
(wanted) behavior; in fact I can also say: 
"If you use =
MaxRankIncrease this relation =
MAXRankIncrease>MAX_PATH_COST+MAX_LINK_METRIC must be true." and =
I "fixed" the problem.

I think that if you want to =
put a constraint on the parent-set it can not be MaxRankIncrease but it should be another =
variable/constraint.


-- =

Regards
Consoli =
Federico


Phil:
=
 
It is an implementation decision as long as =
it does not lead to interop
issue or unwanted =
behavior, which is probably the case here.
RFC 6550 =
demands that a node can't stray from the best Rank as =
computed
amongst parents by more than =
MaxRankIncrease.
This 3 clauses do not seem to =
capture this that we are discussing do not
seem to =
capture this. 
With (my reading of) the text as it =
stands, it seems that the
implementation has all =
freedom to select parents and then is given =
rules
to compute a Rank. 
The =
resulting Rank could be anything if the parent set as no =
constraint.
 
 <=
/o:p>
In particular  " The largest  calculated =
Rank among paths through the
parent set, minus =
MaxRankIncrease" must be less that the Rank =
obtained
from the preferred parent, not the final =
computed =
Rank.
 
 <=
/pre>
The node should:
1) Compute the Ranks =
form its parent set. 
2) Determine a preferred =
parent as resulting with the lowest Rank (using
the =
computation described in the previous paragraph)
3) =
Determine which parents generate a Rank that is between that =
lowest
Rank and =
MaxRankIncrease
4) Pick a set of parents between =
those 
 
What do you =
think?
 
Pascal=

 
-----Original =
Message-----
From: Philip Levis [mailto:pal@cs.stanford.edu] =

Sent: samedi 7 avril 2012 =
16:58
To: Pascal Thubert =
(pthubert)
Cc: Matteo Paris; roll@ietf.org
Subj=
ect: Re: [Roll] New Version =
Notification
-draft-ietf-roll-minrank-hysteresis-of-=
07.txt
 
 =

On Apr 6, 2012, at 11:18 PM, Pascal Thubert (pthubert) =
wrote:
 
The point is that =
with this clause the node selects its parents first =

and its Rank second. The spec recommends picking a =
preferred parent 
first, computing the Rank based =
on the preferred parent, and then =
only
 
consider any node =
with a lower floor as an acceptable parent. I =

understand that want to allow reversing that =
operation, but then that 
should be an option and =
text should indicate that using it may =
augment
 
the parent set =
for some nodes but end up reducing it for =
others.
 
Don=
't you think this is an implementation decision? I tried to write =
the
specification text to be completely neutral on =
this matter (as some of
the MRHOF discussions have =
gone into). The input to DIO generation is =
a
preferred parent and a parent set; how those two =
are selected is
complete outside the specification =
with the caveat that it places some
constraints =
(MaxRankIncrease).
 
Phil<=
o:p>
_______________________________________________=

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



 
=


------_=_NextPart_001_01CD16E8.A48B3739--

From B06063@freescale.com  Tue Apr 10 01:21:40 2012
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 9C43521F842F for ; Tue, 10 Apr 2012 01:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 mNQM3ypDrJiF for ; Tue, 10 Apr 2012 01:21:32 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id B898421F87D2 for ; Tue, 10 Apr 2012 01:21:28 -0700 (PDT)
Received: from mail26-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 08:21:27 +0000
Received: from mail26-am1 (localhost [127.0.0.1])	by mail26-am1-R.bigfish.com (Postfix) with ESMTP id 680AD260259	for ; Tue, 10 Apr 2012 08:21:27 +0000 (UTC)
X-SpamScore: -5
X-BigFish: VS-5(zzc85fh1418M4015Izz1202hzz8275bh8275dhz2dh2a8h668h839h8e2h8e3hd25hbe9i)
X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI; H:mail.freescale.net; RD:none; EFVD:NLI
Received: from mail26-am1 (localhost.localdomain [127.0.0.1]) by mail26-am1 (MessageSwitch) id 1334046085477517_20332; Tue, 10 Apr 2012 08:21:25 +0000 (UTC)
Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.231])	by mail26-am1.bigfish.com (Postfix) with ESMTP id 7093F20011D	for ; Tue, 10 Apr 2012 08:21:25 +0000 (UTC)
Received: from mail.freescale.net (70.37.183.190) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 08:21:25 +0000
Received: from 039-SN2MPN1-022.039d.mgd.msft.net ([169.254.2.244]) by 039-SN1MMR1-003.039d.mgd.msft.net ([10.84.1.16]) with mapi id 14.01.0355.003; Tue, 10 Apr 2012 03:21:21 -0500
From: Costin Michaela Catalina-B06063 
To: "roll@ietf.org" 
Thread-Topic: Path control for non storing nodes
Thread-Index: Ac0W8ufcO0XB3UaPRJeqnor6fQCSFA==
Date: Tue, 10 Apr 2012 08:21:20 +0000
Message-ID: <6B6AF64303C21343BF760595E1DF15FF061CB7@039-SN2MPN1-022.039d.mgd.msft.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.171.73.81]
Content-Type: multipart/alternative; boundary="_000_6B6AF64303C21343BF760595E1DF15FF061CB7039SN2MPN1022039d_"
MIME-Version: 1.0
X-OriginatorOrg: freescale.com
Subject: [Roll] Path control for non storing nodes
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, 10 Apr 2012 08:21:41 -0000

--_000_6B6AF64303C21343BF760595E1DF15FF061CB7039SN2MPN1022039d_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In RFC 6550, the path control field is generally associated with storing no=
des.
In my understanding the path control is only used for preference on non sto=
ring nodes.

Consider the following scenario (DODAG), where the PARENT_SET_SIZE is set t=
o 3 and PCS is set to 0:
                         RPL DODAG root
                             /        |            \
                          /           |              \
                       /              |                \
              NodeA     NodeB       Node C
                         \           |              /
                           \         |            /
                               NodeD

NodeD selects nodeA as preferred parent and NodeB and NodeC as parents. Nod=
eD sends to RPL DODAG root a single DAO message containing the following:

*         RPL target option with NodeD global IPv6 address

*         3 Transit information options (sent exactly in this order over th=
e air):

o   Transit information option containing the IPv6 global address for NodeB=
 and path control set to 0x20 (medium preference)

o   Transit information option containing the IPv6 global address for NodeA=
 and path control set to 0x80 (maximum preference)

o   Transit information option containing the IPv6 global address for NodeC=
 and path control set to 0x20 (medium preference)

Now, my questions are:

1.       what is the RPL DODAG root going to do if PCS is set to any value =
smaller than 2 and it receives a DAO request with 3 Transit information opt=
ions inside?

2.       Must NodeD send to RPL DODAG root a number of Transit information =
options equal to (PCS + 1)?

In my opinion:

1.       the RPL DODAG root should save all 3 routes to nodeD (no matter wh=
at the PCS value is set to). I think that for non storing nodes any PCS is =
valid as long as for each Transit information option at least one bit is se=
t for path control.

2.       NodeD will always include in a DAO message all nodes in the parent=
 set, no matter what value is set to PCS.

Do you have any comments on this?

Thanks,
Catalina

--_000_6B6AF64303C21343BF760595E1DF15FF061CB7039SN2MPN1022039d_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











In RFC 6550, the path control field is generally ass=
ociated with storing nodes.


In my understanding the path control is only used fo=
r preference on non storing nodes.



 


Consider the following scenario (DODAG), where the P=
ARENT_SET_SIZE is set to 3 and PCS is set to 0:



        &nbs=
p;            &=
nbsp;   RPL DODAG root


        &nbs=
p;            &=
nbsp;       /      &=
nbsp; |           &n=
bsp;\


        &nbs=
p;            &=
nbsp;    /         &=
nbsp; |          &nb=
sp;   \


        &nbs=
p;            &=
nbsp; /            &=
nbsp; |          &nb=
sp;     \


        &nbs=
p;     NodeA     NodeB  =
;     Node C


        &nbs=
p;             =
   \          &=
nbsp;|            &n=
bsp; /


        &nbs=
p;             =
     \        &=
nbsp;|            /<=
o:p>


        &nbs=
p;            &=
nbsp;         NodeD


 


NodeD selects nodeA as preferred parent and NodeB an=
d NodeC as parents. NodeD sends to RPL DODAG root a single DAO message cont=
aining the following:



·        
RPL target option with NodeD global IPv6 add=
ress



·        
3 Transit information options (sent exactly =
in this order over the air):



o  
Transit information option containing the IP=
v6 global address for NodeB and path control set to 0x20 (medium preference=
)



o  
Transit information option containing the IP=
v6 global address for NodeA and path control set to 0x80 (maximum preferenc=
e)



o  
Transit information option containing the IP=
v6 global address for NodeC and path control set to 0x20 (medium preference=
)


 


Now, my questions are: 


1.     &=
nbsp;
what is the RPL DODAG root going to do if PCS is se=
t to any value smaller than 2 and it receives a DAO request with 3 Transit =
information options inside?


2.     &=
nbsp;
Must NodeD send to RPL DODAG root a number of Trans=
it information options equal to (PCS + 1)?


 


In my opinion:


1.     &=
nbsp;
the RPL DODAG root should save all 3 routes to node=
D (no matter what the PCS value is set to). I think that for non storing no=
des any PCS is valid as long as for each Transit information option at leas=
t one bit is set for path control.


2.     &=
nbsp;
NodeD will always include in a DAO message all node=
s in the parent set, no matter what value is set to PCS.



 


Do you have any comments on this?


 


Thanks,


Catalina






--_000_6B6AF64303C21343BF760595E1DF15FF061CB7039SN2MPN1022039d_--

From pthubert@cisco.com  Tue Apr 10 02:41:54 2012
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 AB04121F860B for ; Tue, 10 Apr 2012 02:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.907
X-Spam-Level: 
X-Spam-Status: No, score=-9.907 tagged_above=-999 required=5 tests=[AWL=0.692,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxkWfOh9y0a2 for ; Tue, 10 Apr 2012 02:41:53 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0312D21F8661 for ; Tue, 10 Apr 2012 02:41:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=12420; q=dns/txt; s=iport; t=1334050913; x=1335260513; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=E6razqhLfi6rhZpD2XHAfv/Cz5QvIH3W7bCbwozQHJU=; b=ZV4mrjVJAiwo3rSOQusfDtaSK1Mo1Sb4ofJ1K1WF1EdO/mSd9yY5eOSg 7XNsRdkhe0bQurGwaZPNgKra3UeSBYT8XJaskwqcyGg8o6jl3gyh2xSM0 8/62Pw2BAK5ul3MpdvsKORiLEj1Rf+2qOPtgfxwlR912AcnAHg0Ndyc+q 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAM3/g0+Q/khL/2dsb2JhbABDDoVYskl5gQeCCQEBAQMBAQEBDwEQDQQ6CwUHBAIBCBEDAQEBAwIGBhcBAgICAQElHwkIAQEEEwgah2cFC5otjQuTMwSBL44aNWMEpDmBaYIwOYFSFw
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="134680853"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 10 Apr 2012 09:41:51 +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 q3A9fpLv014218; Tue, 10 Apr 2012 09:41:51 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);  Tue, 10 Apr 2012 11:41:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Tue, 10 Apr 2012 11:40:21 +0200
Message-ID: 
In-Reply-To: <1654025443.1850775.1333892275053.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] [roll] #86: G flag: do we need that text?
Thread-Index: Ac0VjM/jaMdQ647tRZiD0PBwxuLBAQBcOWFw
References:  <1654025443.1850775.1333892275053.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
X-OriginalArrivalTime: 10 Apr 2012 09:41:51.0694 (UTC) FILETIME=[28483EE0:01CD16FE]
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #86: G flag: do we need that text?
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, 10 Apr 2012 09:41:54 -0000

QXMgZmFyIGFzIEknbSBjb25jZXJuZWQgeW91J3ZlIGNhcHR1cmVkIGl0IGFuZCBJJ20gaGFwcHkg
d2l0aCB0aGlzIHRleHQuDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3VsQHV3bS5lZHVdIA0KU2VudDogZGltYW5j
aGUgOCBhdnJpbCAyMDEyIDE1OjM4DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KQ2M6
IHJvbGxAaWV0Zi5vcmc7IFJpY2hhcmQgS2Vsc2V5OyBQaGlsaXAgTGV2aXMNClN1YmplY3Q6IFJl
OiBbUm9sbF0gW3JvbGxdICM4NjogRyBmbGFnOiBkbyB3ZSBuZWVkIHRoYXQgdGV4dD8NCg0KSGkg
UGFzY2FsLA0KDQpIb3cgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQoiVGhlIG9yaWdpbiBz
ZXRzIHRoZSBHIGZsYWcgdG8gaW5kaWNhdGUgdGhlIHJlbGF0aXZlIGltcG9ydGFuY2Ugb2YgdGhl
IHJvdXRlIGRpc2NvdmVyeSBpdCBpcyBpbml0aWF0aW5nLiBUaGUgRyBmbGFnIGlzIHNldCB0byBv
bmUgaWYgdGhpcyBwYXJ0aWN1bGFyIHJvdXRlIGRpc2NvdmVyeSBpcyBtb3JlIGltcG9ydGFudCBm
cm9tIGFwcGxpY2F0aW9uJ3MgcGVyc3BlY3RpdmUgdGhhbiBzb21lIG90aGVyIHJvdXRlIGRpc2Nv
dmVyeS4gSW4gb3RoZXIgd29yZHMsIHRoZSBvcmlnaW4gc2V0cyB0aGUgRyBmbGFnIHRvIG9uZSBp
ZiB0aGlzIHBhcnRpY3VsYXIgcm91dGUgZGlzY292ZXJ5IGhlbHBzIG1lZXQgdGhlIGFwcGxpY2F0
aW9uIGRlZmluZWQgZ29hbCBcY2l0ZXtycGx9LiBUaHVzLCB0aGUgRyBmbGFnIHNldHRpbmcgaGVs
cHMgYW4gaW50ZXJtZWRpYXRlIHJvdXRlciBjaG9vc2Ugd2hpY2ggcm91dGUgZGlzY292ZXJpZXMg
dG8gcGFydGljaXBhdGUgaW4gaWYgaXQgY2Fubm90IHBhcnRpY2lwYXRlIGluIGFsbCByb3V0ZSBk
aXNjb3Zlcmllcy4gQW4gaW50ZXJtZWRpYXRlIHJvdXRlciBTSE9VTEQgcGFydGljaXBhdGUgaW4g
cm91dGUgZGlzY292ZXJpZXMgd2l0aCBHIGZsYWcgc2V0IHRvIG9uZSAoaW4gcHJlZmVyZW5jZSB0
byBvbmVzIHdpdGggRyBmbGFnIHNldCB0byB6ZXJvKS4iDQoNClRoYW5rcw0KTXVrdWwNCg0KLS0t
LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVy
dCkiIDxwdGh1YmVydEBjaXNjby5jb20+DQpUbzogIk11a3VsIEdveWFsIiA8bXVrdWxAdXdtLmVk
dT4NCkNjOiByb2xsQGlldGYub3JnLCAiUmljaGFyZCBLZWxzZXkiIDxyaWNoYXJkLmtlbHNleUBl
bWJlci5jb20+LCAiUGhpbGlwIExldmlzIiA8cGFsQGNzLnN0YW5mb3JkLmVkdT4NClNlbnQ6IFRo
dXJzZGF5LCBBcHJpbCA1LCAyMDEyIDExOjAwOjIyIEFNDQpTdWJqZWN0OiBSRTogW1JvbGxdIFty
b2xsXSAjODY6IEcgZmxhZzogZG8gd2UgbmVlZCB0aGF0IHRleHQ/DQoNCg0KSGVsbG8gTXVrdWw6
DQoNCj4xKSBGb3IgYSBsb2NhbCBpbnN0YW5jZSB0aGVyZSBjYW4gYmUgb25seSBvbmUgcm9vdCBh
bmQgb25lIERPREFHLiBHIGJpdCBjYW5ub3QgYW5kIGlzIG5vdCB1c2VkIGZvciBET0RBRyBzZWxl
Y3Rpb24gd2l0aGluIGFuIGluc3RhbmNlLiANCg0KVGhlIHN0YXRlbWVudCBhYm92ZSBzZWVtcyB0
byBiZSBhdCBvZGRzIHdpdGggZm9sbG93aW5nIHR3byBzdGF0ZW1lbnRzDQoNCj4yKSBJbiBhIGdp
dmVuIGRlcGxveW1lbnQsIGEgZ29hbCBjYW4gYmUgZGVmaW5lZCB0aGF0IHNvbWUgUDJQIERPREFH
cyBhY2hpZXZlIGFuZCBvdGhlcnMgZG8gbm90LiBUaGUgcm9vdHMgdGhhdCBhY2hpZXZlIHRoYXQg
Z29hbCB3aWxsIHNldCB0aGUgRyBiaXQgaW4gdGhlaXIgUDJQIERBR3MuDQozKSB0aGUgZGVmYXVs
dCBnb2FsIGlzIHRvIGNyZWF0ZSBjb25uZWN0aXZpdHkgYmV0d2VlbiBvcmlnaW4gYW5kIHRhcmdl
dC4gU28gYnkgZGVmYXVsdCBHIHNob3VsZCBiZSBzZXQgdG8gMS4NCg0KQXMgcGVyIHN0YXRlbWVu
dCAxLCB0aGUgRyBmbGFnIGNhbiBuZXZlciBiZSAxIGZvciBQMlAtUlBMIERBR3MgYmVjYXVzZSB0
aGV5IHVzZSBsb2NhbCBpbnN0YW5jZSBpZHMuDQpbUGFzY2FsXSBTdGF0ZW1lbnQgMSBkb2VzIG5v
dCBzYXkgdGhhdCBhdCBhbGwuIENhbid0IGZhdGhvbSBob3cgeW91IGNvbmNsdWRlZCB0aGF0Li4u
IExldCBtZSB0cnkgdG8gcmV3b3JkOiBUaGVyZSBpcyBvbmx5IHdoYXQgRE9EQUcgZm9yIGEgZ2l2
ZW4gbG9jYWwgaW5zdGFuY2Ugc28gdGhlcmUgY2Fubm90IGJlIGEgc2VsZWN0aW9uID0+IEcgY2Fu
bm90IGJlIHVzZWQgZm9yIGEgc2VsZWN0aW9uIHRoYXQgY2Fubm90IGhhcHBlbi4NCg0KLS0tDQoN
CkFzIHBlciBzdGF0ZW1lbnQgMi8zLCB0aGUgRyBmbGFnIGNvdWxkIGJlIDEgYW5kIGlzIDEgYnkg
ZGVmYXVsdC4NCg0KW1Bhc2NhbF0gWWVzLiBJIGFkZGVkIGFuIGl0ZW0gdG8gaGVscCB0aGUgZGV2
aWNlIHByaW9yaXRpemUgd2hlbiBpdCBpcyBhc2tlciB0byBwYXJ0aWNpcGF0ZSB0byBtYW55IERP
REFHcyAoZm9yIG1hbnkgUDJQIGZsb3dzIHRoYXQgaXQgaGFwcGVucyB0byBiZSBvbiB0aGUgcGF0
aCBvZikuIEluIHRoYXQgY2FzZSwgYW5kIGlmIHRoZSBkZXZpY2UgY2Fubm90IHBhcnRpY3BhdGVy
IHRvIGFsbCB0aGUgUDJQIERPREFHcywgdGhlbiB0aGUgRyBiaXQgY291bGQgYmUgdXNlIHRvIGRl
Y2lkZSB3aGljaCBhcmUgdGhlIG1vc3QgaW1wb3J0YW50LiANCg0KLS0tDQoNCkkgYW0gT0sgd2l0
aCBzZXR0aW5nIEcgZmxhZyB0byAxIGFsd2F5cyAoYXMgeW91LCBSaWNoYXJkIGFuZCBQaGlsIHNl
ZW0gdG8gcHJlZmVyKSBidXQgSSBkb250IGtub3cgaG93IHRvIHJlYXNvbiB0aGlzLiBEbyB3ZSBu
ZWVkIHRvIHByb3ZpZGUgYSByZWFzb24gYXQgYWxsPw0KDQpbUGFzY2FsXSBJZiB5b3UgZGVmaW5l
IGEgZGVmYXVsdCBnb2FsIHRoYXQgdGhlIERPREFHIGZpbGxzLCB0aGVuIHlvdSBzZXQgRyB0byBv
bmUuIEZvciBpbnN0YW5jZSwgRyBjb3VsZCBtZWFuICdpbXBvcnRhbnQgc3R1ZmYnIGxpa2Ugc3dp
dGhpbmcgYSBsaWdodCBvbi4gWW91J2Qgc2V0IGl0IGZvciBzd2l0Y2hpbmcgbGlnaHRzIGJ1dCBu
b3QgZm9yIHJlcG9ydGluZyB0aGUgaHlncm9tZXRyeSBvZiB5b3VyIG9yY2hpZHMsIHdoaWNoIGFu
eXdheSB3aWxsIGJlIHJldHJpZWQgaW4gYSBoYWxmIGhvdXIuIEFzIGEgcmVzdWx0LCBpZiB0aGUg
MiBEQUcgZm9ybWF0aW9ucyBjb2xsaWRlLCB0aGUgbGlnaHQgb24gd2lsbCBoYXZlIHByZWNlZGVu
Y2UuLi4NCg0KLS0tLS0tLS0tDQoNCjopIHRvbyAuLi4NCg0KIFBhc2NhbA0KDQotLS0tLSBPcmln
aW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0
aHViZXJ0QGNpc2NvLmNvbT4NClRvOiAiTXVrdWwgR295YWwiIDxtdWt1bEB1d20uZWR1Pg0KQ2M6
IHJvbGxAaWV0Zi5vcmcsICJSaWNoYXJkIEtlbHNleSIgPHJpY2hhcmQua2Vsc2V5QGVtYmVyLmNv
bT4sICJQaGlsaXAgTGV2aXMiIDxwYWxAY3Muc3RhbmZvcmQuZWR1Pg0KU2VudDogVGh1cnNkYXks
IEFwcmlsIDUsIDIwMTIgMToxMTo0MiBBTQ0KU3ViamVjdDogUkU6IFtSb2xsXSBbcm9sbF0gIzg2
OiBHIGZsYWc6IGRvIHdlIG5lZWQgdGhhdCB0ZXh0Pw0KDQpIZWxsbyBNdWt1bDoNCg0KSSBzdWdn
ZXN0IGEgc2VudGVuY2UgdGhhdCBzYXlzIHRoYXQ6DQoNCjEpIEZvciBhIGxvY2FsIGluc3RhbmNl
IHRoZXJlIGNhbiBiZSBvbmx5IG9uZSByb290IGFuZCBvbmUgRE9EQUcuIEcgYml0IGNhbm5vdCBh
bmQgaXMgbm90IHVzZWQgZm9yIERPREFHIHNlbGVjdGlvbiB3aXRoaW4gYW4gaW5zdGFuY2UuIA0K
MikgSW4gYSBnaXZlbiBkZXBsb3ltZW50LCBhIGdvYWwgY2FuIGJlIGRlZmluZWQgdGhhdCBzb21l
IFAyUCBET0RBR3MgYWNoaWV2ZSBhbmQgb3RoZXJzIGRvIG5vdC4gVGhlIHJvb3RzIHRoYXQgYWNo
aWV2ZSB0aGF0IGdvYWwgd2lsbCBzZXQgdGhlIEcgYml0IGluIHRoZWlyIFAyUCBEQUdzLg0KMykg
dGhlIGRlZmF1bHQgZ29hbCBpcyB0byBjcmVhdGUgY29ubmVjdGl2aXR5IGJldHdlZW4gb3JpZ2lu
IGFuZCB0YXJnZXQuIFNvIGJ5IGRlZmF1bHQgRyBzaG91bGQgYmUgc2V0IHRvIDEuDQo0KSBpZiBh
biBpbnRlcm1lZGlhdGUgcm91dGVyIGRvZXMgbm90IGhhdmUgZW5vdWdoIHJlc291cmNlcyB0byBw
YXJ0aWNpcGF0ZSB0byBhbGwgRE9EQUdzIHRoZW4gaXQgc2hvdWxkIGZhdm9yIERPREFHcyB3aXRo
IHRoZSBHIGJpdCBvbi4NCg0KVGhlIGV4YWN0IHdvcmRpbmcgaXMgeW91cnMuLi4NCg0KQ2hlZXJz
LA0KDQpQYXNjYWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE11a3VsIEdv
eWFsIFttYWlsdG86bXVrdWxAdXdtLmVkdV0NClNlbnQ6IG1lcmNyZWRpIDQgYXZyaWwgMjAxMiAx
ODo0Nw0KVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCkNjOiByb2xsQGlldGYub3JnOyBS
aWNoYXJkIEtlbHNleQ0KU3ViamVjdDogUmU6IFtSb2xsXSBbcm9sbF0gIzg2OiBHIGZsYWc6IGRv
IHdlIG5lZWQgdGhhdCB0ZXh0Pw0KDQpQYXNjYWwNCg0KPkluIGFueSBjYXNlLCBhcyBJIHN1Z2dl
c3RlZCBlYXJsaWVyIGFuZCBhcyBSaWNoYXJkIGFsc28gc3VnZ2VzdCBub3csIEcgU0hPVUxEIHBy
b2JhYmx5IGJlIDEgYnkgZGVmYXVsdCBidXQgTUFZIGJlIHNldCBvdGhlcndpc2UuDQoNClJpY2hh
cmQgd2FudHMgdGhlIGZsYWcgdG8gYWx3YXlzIGJlIGVpdGhlciAwIG9yIDEuIEhlIHByZWZlcnMg
aXQgdG8gYmUgYWx3YXlzIDEgYnV0IHdvdWxkIHNldHRsZSBmb3IgaXQgYmVpbmcgYWx3YXlzIHpl
cm8uDQoNCkkgdGhpbmsgdGhpcyBpcyBub3QgYSBjcml0aWNhbCBwb2ludC4gSSBhbSBPSyB3aXRo
IHdoYXRldmVyIHJlc29sdXRpb24geW91IGFuZCBSaWNoYXJkIGFycml2ZSBhdC4gS2luZGx5IHBy
b3ZpZGUgbWUgdGhlIHJlc29sdXRpb24gdGV4dCBJIHNob3VsZCBwdXQgaW4gdGhlIGRyYWZ0Lg0K
DQpUaGFua3MNCk11a3VsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJQ
YXNjYWwgVGh1YmVydCAocHRodWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPg0KVG86ICJNdWt1
bCBHb3lhbCIgPG11a3VsQHV3bS5lZHU+DQpDYzogcm9sbEBpZXRmLm9yZywgIlJpY2hhcmQgS2Vs
c2V5IiA8cmljaGFyZC5rZWxzZXlAZW1iZXIuY29tPg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0
LCAyMDEyIDExOjA1OjUwIEFNDQpTdWJqZWN0OiBSRTogW1JvbGxdIFtyb2xsXSAjODY6IEcgZmxh
ZzogZG8gd2UgbmVlZCB0aGF0IHRleHQ/DQoNCk11a3VsOg0KDQpJIHRoaW5rIHdlIGRpc2FncmVl
IGJlY2F1c2Ugb2YgdGhlIGRlZmluaXRpb24gb2YgZ29hbCBpdHNlbGYuIFRoZSBnb2FsIGlzIGFu
IGFic3RyYWN0aW9uLiBTYW1lIGdvZXMgZm9yIHRoZSB0ZXJtIE9iamVjdGl2ZSBpbiBPRi4gUkZD
IDY1NTAgb25seSBnaXZlcyBleGFtcGxlcyBvZiB3aGF0IEcgY291bGQgYmUgdXNlZCBmb3IgYnV0
IHRoYXQgaXMgbm90IGxpbWl0aW5nLiBDZXJ0YWlubHkgdGhlIGFic3RyYWN0aW9uIG1heSBmb3Ig
aW5zdGFuY2UgbWVhbiB0aGF0IGV4dGVybmFsIG5vZGVzIGFyZSByZWFjaGFibGUgdmlhIHRoZSBy
b290LiBCdXQgaXQgY291bGQgYmUgc29tZXRoaW5nIGVsc2UgZW50aXJlbHkuIEZvciBpbnN0YW5j
ZSBpdCBjb3VsZCBkZXNpZ25hdGUgYSByb290IHRoYXQgY2FuIGFnZ3JlZ2F0ZSBkYXRhLg0KDQpJ
biBwcmFjdGljZSwgRyBpcyB1c2VkIHRvIGZhdm9yIGEgcm9vdCB0aGF0IHJlYWNoZXMgdGhlIGdv
YWwgdnMuIG9uZSB0aGF0IGRvZXMgbm90LiBCdXQgdGhhdCdzIHNlbnNlbGVzcyBmb3IgbG9jYWwg
aW5zdGFuY2VzIHRoYXQgaGF2ZSBieSBkZWZpbml0aW9uIGEgc2luZ2xlIHJvb3QuDQoNClNvIHdo
YXRldmVyIHlvdSBzZXQgaXQgdG8gZG9lcyBub3QgbWFrZSBhIGRpZmZlcmVuY2UgZm9yIFJGQyA2
NTUwIG9wZXJhdGlvbnMuIEkgZmlndXJlIGl0IGNvdWxkIGJlIHVzZWQgZm9yIHNpZ25hbGluZyBh
ICJ0cmFuc2llbnQgZ29hbCIgaW5mb3JtYXRpb24gdG8gYW4gT0YgdGhhdCBjb3VsZCB1c2UgaXQg
Zm9yIGEgcHVycG9zZSBJIGNhbid0IGZhdGhvbS4NCg0KSW4gYW55IGNhc2UsIGFzIEkgc3VnZ2Vz
dGVkIGVhcmxpZXIgYW5kIGFzIFJpY2hhcmQgYWxzbyBzdWdnZXN0IG5vdywgRyBTSE9VTEQgcHJv
YmFibHkgYmUgMSBieSBkZWZhdWx0IGJ1dCBNQVkgYmUgc2V0IG90aGVyd2lzZS4NCg0KUGFzY2Fs
DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTXVrdWwgR295YWwgW21h
aWx0bzptdWt1bEB1d20uZWR1XQ0KU2VudDogbWVyY3JlZGkgNCBhdnJpbCAyMDEyIDE2OjE2DQpU
bzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KQ2M6IHJvbGxAaWV0Zi5vcmc7IFJpY2hhcmQg
S2Vsc2V5DQpTdWJqZWN0OiBSZTogW1JvbGxdIFtyb2xsXSAjODY6IEcgZmxhZzogZG8gd2UgbmVl
ZCB0aGF0IHRleHQ/DQoNClBhc2NhbA0KDQo+SWYgdGhlIGdvYWwgaXMgdG8gcmVhY2ggdGhlIHJv
b3QsIHRoZW4gRyBpcyAxLi4uDQoNCkkgaGF2ZSB0b2xkIHlvdSBtdWx0aXBsZSB0aW1lcyB0aGF0
IGpvaW5pbmcgYSBQMlAtUlBMIERBRyBkb2VzIG5vdCBnaXZlIGFueSBzb3J0IG9mIGNvbm5lY3Rp
dml0eSB0byB0aGUgbm9kZS4NCg0KVGhhbmtzDQpNdWt1bA0KDQotLS0tLSBPcmlnaW5hbCBNZXNz
YWdlIC0tLS0tDQpGcm9tOiAiUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0aHViZXJ0QGNp
c2NvLmNvbT4NClRvOiAiTXVrdWwgR295YWwiIDxtdWt1bEB1d20uZWR1PiwgIlJpY2hhcmQgS2Vs
c2V5IiA8cmljaGFyZC5rZWxzZXlAZW1iZXIuY29tPg0KQ2M6IHJvbGxAaWV0Zi5vcmcNClNlbnQ6
IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxMiA5OjA1OjI4IEFNDQpTdWJqZWN0OiBSRTogW1JvbGxd
IFtyb2xsXSAjODY6IEcgZmxhZzogZG8gd2UgbmVlZCB0aGF0IHRleHQ/DQoNCkhlbGxvIE11a3Vs
DQoNCkZsb2F0aW5nIHZzLiBHcm91bmRlZCBkZXBlbmRzIG9uIHRoZSBnb2FsIG9mIHRoZSBET0RB
Ry4gSSBhc2tlZCB5b3UgYW5kIHdpbGwgYXNrIGFnYWluIHdoYXQgaXMgeW91ciBnb2FsPw0KSWYg
dGhlIGdvYWwgaXMgdG8gcmVhY2ggdGhlIHJvb3QsIHRoZW4gRyBpcyAxLi4uIElmIHlvdSB3YW50
IHRvIHNpZ25hbCBzb21ldGhpbmcgdG8gdGhlIE9GIHVzaW5nIHRoZSBHIGJpdCwgbGVhdmUgaXQg
IG9wZW4uDQoNCkNoZWVycywNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiByb2xsLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBNdWt1bCBHb3lhbA0KU2VudDogbWVyY3JlZGkgNCBhdnJpbCAyMDEy
IDE1OjU1DQpUbzogUmljaGFyZCBLZWxzZXkNCkNjOiByb2xsQGlldGYub3JnDQpTdWJqZWN0OiBS
ZTogW1JvbGxdIFtyb2xsXSAjODY6IEcgZmxhZzogZG8gd2UgbmVlZCB0aGF0IHRleHQ/DQoNCj5U
aGUgRyBmbGFnIGlzIDAgaWYgYW5kIG9ubHkgaWYgdGhlIERPREFHIGlzIGZsb2F0aW5nLg0KDQpJ
IHRoaW5rIHRoYXQgdGhlIEcgZmxhZyBpcyAxIGlmIGFuZCBvbmx5IGlmIHRoZSBET0RBRyBpcyBn
cm91bmRlZC4gVGhlIHRlbXBvcmFyeSBEQUdzIHVzZWQgaW4gUDJQLVJQTCBhcmUgbm90IGdyb3Vu
ZGVkLCB0aGV5IGFyZSB0ZW1wb3JhcnkuIEkgdGhpbmsgdGhhdCBhbGwgdHJhbnNpZW50L3RlbXBv
cmFyeSBEQUdzIGFyZSBmbG9hdGluZyBieSB0aGVpciB2ZXJ5IG5hdHVyZS4NCg0KVGhhbmtzDQpN
dWt1bA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiUmljaGFyZCBLZWxz
ZXkiIDxyaWNoYXJkLmtlbHNleUBlbWJlci5jb20+DQpUbzogcm9sbEBpZXRmLm9yZw0KQ2M6IG11
a3VsQFVXTS5FRFUsIGpwdkBjaXNjby5jb20sIHJvbGxAaWV0Zi5vcmcNClNlbnQ6IFdlZG5lc2Rh
eSwgQXByaWwgNCwgMjAxMiA4OjM2OjUwIEFNDQpTdWJqZWN0OiBSZTogW1JvbGxdIFtyb2xsXSAj
ODY6IEcgZmxhZzogZG8gd2UgbmVlZCB0aGF0IHRleHQ/DQoNCj4gRnJvbTogcm9sbCBpc3N1ZSB0
cmFja2VyIDx0cmFjK3JvbGxAdHJhYy50b29scy5pZXRmLm9yZz4NCj4gRGF0ZTogV2VkLCA0IEFw
ciAyMDEyIDEzOjA4OjUwICswMDAwDQo+IA0KPiAjODY6IEcgZmxhZzogZG8gd2UgbmVlZCB0aGF0
IHRleHQ/DQo+IA0KPiAgUHJvYmxlbSAocmVzb2xpdGlvbiBpcyBwcm9wb3NlZCkNCj4gIC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgRGlzYWdyZWVtZW50IG9uIHRoZSBtZWFuaW5n
IG9mICdHJyBiaXQgYW5kIGltcG9zZWQgc2V0dGluZyB0byAwOw0KPiANCj4gIFByb3Bvc2VkIHJl
c29sdXRpb24NCj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgVGhlIG9yaWdpbiBz
ZXRzIHRoZSBHIGZsYWcgYmFzZWQgb24gaXRzIHBlcmNlcHRpb24gb2Ygd2hldGhlciBqb2luaW5n
DQoNCj4gaG93IHRoZSBmbGFnJ3MgdmFsdWUgd291bGQgYWZmZWN0IHRoZSByYW5rIGNhbGN1bGF0
aW9uIHVuZGVyIHRoZSBPRiANCj4gYmVpbmcgdXNlZC4gQnkgZGVmYXVsdCwgdGhlIEcgZmxhZyBp
cyBzZXQgdG8gemVybyBnaXZlbiB0aGUgdGVtcG9yYXJ5DQoNCj4gbmF0dXJlIG9mIHRoZSBEQUcg
YmVpbmcgY3JlYXRlZC4NCg0KSSBkaXNhZ3JlZSB3aXRoIHRoZSBwcm9wb3NlZCByZXNvbHV0aW9u
LiAgSXQgYWRkcyBuZWVkbGVzcyBjb25mdXNpb24uDQpUaGUgRyBmbGFnIGlzIDAgaWYgYW5kIG9u
bHkgaWYgdGhlIERPREFHIGlzIGZsb2F0aW5nLg0KVGhlcmUgaXMgbm8gcG9pbnQgdG8gYWxsb3dp
bmcgZmxvYXRpbmcgRE9EQUdzIHdpdGggYSBQMlAtUkRPIG9wdGlvbi4gIEkgc3VnZ2VzdCB0aGF0
IHRoZSBHIGJpdCBiZSBzZXQgdG8gMSBhbmQgdGhhdCByb3V0ZXJzIGJlIGV4cGxpY2l0bHkgcHJv
aGliaXRlZCBmcm9tIGNyZWF0aW5nIGZsb2F0aW5nIERPREFHcyB3aXRoIGEgUDJQLVJETyBvcHRp
b24uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC1SaWNoYXJkIEtlbHNleSBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWls
aW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vcm9sbA0K

From pthubert@cisco.com  Tue Apr 10 02:48:32 2012
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 18EE721F87F4 for ; Tue, 10 Apr 2012 02:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.953
X-Spam-Level: 
X-Spam-Status: No, score=-9.953 tagged_above=-999 required=5 tests=[AWL=0.646,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDJQoe7+chCT for ; Tue, 10 Apr 2012 02:48:31 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 051B221F8621 for ; Tue, 10 Apr 2012 02:48:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4824; q=dns/txt; s=iport; t=1334051310; x=1335260910; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=T+p/0BhOWhMYM5MlvPWaElxJNUB2Mbi9f5CpNgOPle8=; b=fE/1rzA5D2Bdx7fTwTa519T7huY//bSzSzR/esHFJolYHQJBCcING/bo 6Z6DzTOcip3n0S0MvnZo5NpvQn+Q+mmeVVimOdPSFJYmwmlZPc+Y175mT cy7/6y0cfx31MlVgEMKWcligSP6ytkwgtEIBDL2eLEgtJ60s9RdgLt/Nf Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAOcAhE+Q/khN/2dsb2JhbABDhWaySXmBB4IJAQEBBAEBAQ8BEA0EOgsMBAIBCBEEAQEDAgYGFwECAgIBASUfCQgBAQQBEggah2wLmi6NC5M3gS+OGjVjBJZ9jTyBaYJp
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="134681947"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 Apr 2012 09:48:27 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3A9mReT016718; Tue, 10 Apr 2012 09:48:27 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);  Tue, 10 Apr 2012 11:48:27 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Tue, 10 Apr 2012 11:47:39 +0200
Message-ID: 
In-Reply-To: <273988926.1851128.1333900578888.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] [roll] #87: Can't we split the target from the RDO ?
Thread-Index: Ac0VoEuylTkEsoMPSaaZP61Kj2R9wABXnBjg
References: <055.f551806bbfcbaa57b44d89571c962af8@trac.tools.ietf.org> <273988926.1851128.1333900578888.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "JP Vasseur (jvasseur)" , 
X-OriginalArrivalTime: 10 Apr 2012 09:48:27.0825 (UTC) FILETIME=[14650A10:01CD16FF]
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #87: Can't we split the target from the RDO ?
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, 10 Apr 2012 09:48:32 -0000

SlANCg0KSSBBZ3JlZSB0byBjbG9zZSBmb3IgYW4gZXhwZXJpbWVudGFsIGFuZCBJIHN1Z2dlc3Qg
d2UgcmV2aXNpdCBzaG91bGQgdGhlIHdvcmsgZ28gc3RhbmRhcmQgdHJhY2suDQoNCkNoZWVycw0K
UGFzY2FsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJvbGwtYm91bmNl
c0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE11
a3VsIEdveWFsDQpTZW50OiBkaW1hbmNoZSA4IGF2cmlsIDIwMTIgMTc6NTYNClRvOiByb2xsQGll
dGYub3JnDQpTdWJqZWN0OiBSZTogW1JvbGxdIFtyb2xsXSAjODc6IENhbid0IHdlIHNwbGl0IHRo
ZSB0YXJnZXQgZnJvbSB0aGUgUkRPID8NCg0KSGkgSlANCg0KUGxlYXNlIG1hcmsgdGhpcyB0aWNr
ZXQgYXMgY2xvc2VkLg0KDQpUaGFua3MNCk11a3VsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug
LS0tLS0NCkZyb206ICJyb2xsIGlzc3VlIHRyYWNrZXIiIDx0cmFjK3JvbGxAdHJhYy50b29scy5p
ZXRmLm9yZz4NClRvOiBtdWt1bEBVV00uRURVLCBqcHZAY2lzY28uY29tDQpDYzogcm9sbEBpZXRm
Lm9yZw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDEyIDg6MDk6NTYgQU0NClN1YmplY3Q6
IFtyb2xsXSAjODc6IENhbid0IHdlIHNwbGl0IHRoZSB0YXJnZXQgZnJvbSB0aGUgUkRPID8NCg0K
Izg3OiBDYW4ndCB3ZSBzcGxpdCB0aGUgdGFyZ2V0IGZyb20gdGhlIFJETyA/DQoNCiBQcm9ibGVt
IChwcm9wb3NlZCByZXNvbHV0aW9uKQ0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
IFRoZSBSRE8gaXMgYSBnYXJiYWdlIG9wdGlvbiB3aWxsIGFsbCBzb3J0cyBvZiBkYXRhIGluIGl0
LiBUaGUgYWR2b2NhdGVkICByZWFzb24gZm9yIHRoYXQgaXMgY29uY2lzZW5lc3Mgc2luY2Ugc2Vw
YXJhdGUgb3B0aW9ucyBtZWFuIG92ZXJoZWFkLg0KIE9UT0gsIGl0IG1ha2VzIG1vcmUgc2Vuc2Ug
dG8gaGF2ZSBhbGwgdGhlIHRhcmdldHMgZXhwcmVzc2VzIGFzIHRhcmdldCAgb3B0aW9ucyBhcyBv
cHBvc2VkIHRvIGhhdmluZyBvbmUgdGFyZ2V0IGluIHRoZSBEUk8gYW5kIHRoZW4gYWxsIG90aGVy
ICB0YXJnZXRzIGxpc3RlZCBhZnRlci4gSGF2aW5nIHRoZSB0YXJnZXQgc2VwYXJhdGUgd291bGQg
YWxsb3cgZm9yIGEgRElPICB3aXRoIG5vIFJETyBidXQgb25seSBhIHRhcmdldCwgd2hpY2ggd291
bGQgYmUgdXNlZnVsIHRvIHBvbGwgYSBkZXZpY2Ugb24gIGFuIGV4aXN0aW5nIERBRy4gQ3VycmVu
dGx5IHRoZSBkcmFmdCBNVVNUIGEgUkRPIGFuZCBNQVkgYW5kIHRhcmdldCAgb3B0aW9uLiBUaGUg
c3VnZ2VzdGlvbiBpcyB0byBhbGxvdyBmb3IgYSB0YXJnZXQgaW4gRElPIHdpdGhvdXQgYSBSRE8u
DQoNCiBQcm9wb3NlZCByZXNvbHV0aW9uDQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIEtl
ZXAgaXQgYXQgdGhhdCBzaW5jZSAxKSB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIGFuZCAyKSBp
dCdzICBleHBlcmltZW50YWwgLiBUaGlzIHJlc29sdXRpb24gaW1wbGllcyB0aGF0IHRoZSBpc3N1
ZSB3aWxsIGJlIHJlb3BlbmVkICBzaG91bGQgdGhlIHdvcmsgZ28gZm9yIHN0YW5kYXJkIHRyYWNr
DQoNCiBEaXNjdXNzaW9uDQogLS0tLS0tLS0tLS0tLQ0KDQogW1Bhc2NhbF0iIE1BWSBjYXJyeSBv
bmUgb3IgbW9yZSBSUEwgVGFyZ2V0IE9wdGlvbnMgdG8gc3BlY2lmeSBhZGRpdGlvbmFsICB1bmlj
YXN0L211bHRpY2FzdCBhZGRyZXNzZXMgZm9yIHRoZSB0YXJnZXQuIg0KIE5vdyBoZXJlIEkgd291
bGQgaGF2ZSBhIE1VU1QgY2FycnkgYXQgbGVhc3Qgb25lIHRhcmdldC4gVGhhdCBpcyBpbmRlZWQg
IHdoYXQgbWFrZXMgaXMgYSBsb29rdXAgRElPLi4uDQoNCiBbTXVrdWxdDQogQXMgSSBzdGF0ZWQg
aW4gdGhlIHByZXZpb3VzIG1lc3NhZ2UsIHdlIG5lZWQgdG8gaW5jbHVkZSB0aGUgdGFyZ2V0IGlu
ICB0aGUgUDJQLVJETyB0byBzYXZlIGJ5dGVzIGZvciB0aGUgY29tbW9uIGNhc2UgKGRpc2NvdmVy
IHJvdXRlIHRvIG9uZSAgdW5pY2FzdC9tdWx0aWNhc3QgdGFyZ2V0KS4gU28sIHdlIGNhbm5vdCBt
YWtlIHVzaW5nIHRoZSB0YXJnZXQgb3B0aW9uIGEgIE1VU1QuDQoNCiBbUGFzY2FsMl0gQ2VydGFp
bmx5LiBJIHByZWZlciB0aGUgc3BsaXQsIGluIHdoaWNoIGNhc2UgdGhlIE1VU1QgSU1ITyAgZ29l
cyB0byB0aGUgdGFyZ2V0IGFzIG9wcG9zZWQgdG8gdGhlIFJETy4gSW4gYSBjYXNlIHdoZXJlIHRo
ZSBSRE8gaXMgbm90ICBuZWVkZWQsIHRoZSB0YXJnZXQgb25seSBtZXNzYWdlIGlzIGFjdHVhbGx5
IHNob3J0ZXIuLi4NCg0KIFtNdWt1bDJdIEFzIEkgc2FpZCBiZWZvcmUsIEkgdGhpbmsgYSBQMlAg
bW9kZSBESU8gYWx3YXlzIG5lZWRzIHRvIGhhdmUgIG9uZSBQMlAtUkRPLiBJIGd1ZXNzLCBpbiB0
aGlzIGNhc2UsIHdlIGFncmVlIHRvIGRpc2FncmVlIQ0KDQogW1Bhc2NhbDNdIENlcnRhaW5seS4g
QW5kIHRoZXJlJ3Mgbm90aGluZyBibG9ja2luZyB3aXRoIHRoYXQgIGRpc2FncmVlbWVudCwgbW9z
dGx5IGlmIHRoZSBkcmFmdCB0YXJnZXRzIGV4cGVyaW1lbnRhbC4NCiBJIHRoaW5rIGl0J3MgT0sg
dG8ga2VlcCB5b3VyIHJlc3BvbnNlIGFzIHRoZSBwcm9wb3NlZCByZXNvbHV0aW9uIGZvciAgdGhl
IGlzc3VlLiBTdGlsbCBJJ2QgbGlrZSBhZHZpY2UgZnJvbSBvdGhlcnMgc28gZXhwb3NpbmcgdGhl
IGlzc3VlIGFzIExDICB3aWxsIGhlbHAuIExldCdzIHNlZSBvbiB3aGljaCBzaWRlIHRoZSBjb2lu
IGZhbGxzLg0KDQogW011a3VsM10gT0suIEkgd2lsbCBiZSBoYXBweSB0byBoZWFyIGFkZGl0aW9u
YWwgb3BpbmlvbnMuDQoNCiBbUGFzY2FsNF0gRmluZSwgbGV0J3Mga2VlcCB0aGF0IGFzIHRoZSBw
cm9wb3NlZCByZXNvbHV0aW9uDQoNCiBbTXVrdWw0XSBPSy4NCiBQYXNjYWwNCg0KLS0gDQotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBS
ZXBvcnRlcjogIGpwdkDigKYgICAgICAgICAgICAgICAgICB8ICAgICAgT3duZXI6ICBtdWt1bEDi
gKYNCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3
DQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAgIHwgIE1pbGVzdG9uZToNCkNvbXBv
bmVudDogIHAycC1ycGwgICAgICAgICAgICAgICAgfCAgICBWZXJzaW9uOg0KIFNldmVyaXR5OiAg
U3VibWl0dGVkIFdHIERvY3VtZW50ICB8ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0
dHBzOi8vc3ZuLnRvb2xzLmlldGYub3JnL3dnL3JvbGwvdHJhYy90aWNrZXQvODc+DQpyb2xsIDxo
dHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9y
Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo=

From pthubert@cisco.com  Tue Apr 10 02:53:08 2012
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 E96A111E8072 for ; Tue, 10 Apr 2012 02:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.994
X-Spam-Level: 
X-Spam-Status: No, score=-9.994 tagged_above=-999 required=5 tests=[AWL=0.605,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voNjl14qhZ6H for ; Tue, 10 Apr 2012 02:53:08 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE3F21F86DE for ; Tue, 10 Apr 2012 02:53:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=6512; q=dns/txt; s=iport; t=1334051587; x=1335261187; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=pQNAuxBZXPB60+P/aFeOYvHtQfnkwswWhDMYwNdGugI=; b=FD7SgEWmDujZPszo+fkBsInO751HIeerm1YEb5HB1dQXWoh1JjbnMyDb bgFZzqMgtQ+SxQ22bpeHXCsW0vd+iHIUpJL32oo43ItcjzhqUjOGftTYR kSfYWw80ZIYWrPSmnNSBpzh+pyR8N1Zrf3Gfn269tNgSxHOntKBoyFMEF Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAOcBhE+Q/khM/2dsb2JhbABDDoVYskl5gQeCCQEBAQQBAQEPARANBDoXBAIBCBEEAQEDAgYGFwECAgIBASUfCQgBAQQBEggRCYdsC5otjQuTN4EviWSENjVjBJZ9jTyBaYIwOYFSFw
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="134682572"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 10 Apr 2012 09:53:06 +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 q3A9r6Q8017627; Tue, 10 Apr 2012 09:53:06 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);  Tue, 10 Apr 2012 11:53:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Tue, 10 Apr 2012 11:52:50 +0200
Message-ID: 
In-Reply-To: <535571420.1851174.1333901338010.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] [roll] #90: use of transient instance ID
Thread-Index: Ac0Vof4x3Pqwjs5MSOSMfmzhGKSdwgBXRWRQ
References: <055.61fcc856b7b35899da82ce224df8d83b@trac.tools.ietf.org> <535571420.1851174.1333901338010.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" , 
X-OriginalArrivalTime: 10 Apr 2012 09:53:06.0428 (UTC) FILETIME=[BA747BC0:01CD16FF]
Subject: Re: [Roll] [roll] #90: use of transient instance ID
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, 10 Apr 2012 09:53:09 -0000

TXVrdWw6DQoNCkkgbWVhbnQgYSBzdWdnZXN0aW9uLCBub3QgYSBjYXBpdGFsaXplZCB3b3JkLiBJ
IHByZWZlciB0aGUgc3VnZ2VzdGlvbiBidXQgSSdtIHN0aWxsIE9LIHdpdGggeW91ciBwcm9wb3Nh
bC4gSWYgd2UgZ2V0IGluIGFncmVlbWVudCBvbiB0aGUgbGlmZXRpbWUgb2YgdGhlIHN0YXRlcyAo
aXNzdWUgIzg1KSwgdGhlbiB5b3UgY2FuIGluZGljYXRlIHRoYXQgbGlmZXRpbWUgaXMgb25lIHdh
eSB0byBkZXRlcm1pbmUgd2hlbiBhbGwgc3RhbGUgc3RhdGVzIGNhbiBiZSBjb25zaWRlcmVkIGdv
bmUuIEFsc28sIHdoZW4gdGhlcmUgYXJlIG5vIHJvdXRpbmcgc3RhdGVzIGluIGludGVybWVkaWF0
ZSByb3V0ZXJzLCBhbiBpbmRpY2F0aW9uIGZyb20gdXBwZXIgbGF5ZXJzIGNhbiBiZSB1c2VkIGlu
IHRoZSBlbmQgcG9pbnRzIHRvIGNvbnNpZGVyIHRoYXQgYWxsIHN0YXRlcyBmb3IgYW4gaW5zdGFu
Y2VJRCBhcmUgbm93IGNsZWFuZWQgdXAuDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv
OnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE11a3VsIEdveWFsDQpTZW50OiBk
aW1hbmNoZSA4IGF2cmlsIDIwMTIgMTg6MDkNClRvOiByb2xsQGlldGYub3JnDQpTdWJqZWN0OiBS
ZTogW1JvbGxdIFtyb2xsXSAjOTA6IHVzZSBvZiB0cmFuc2llbnQgaW5zdGFuY2UgSUQNCg0KSGkg
UGFzY2FsDQoNClJlLXJlYWQgeW91ciBwcm9wb3NlZCByZXNvbHV0aW9uIHRleHQuIEkgYW0gbm90
IHN1cmUgdGhhdCB0aGUgZHJhZnQgc2hvdWxkIHN1Z2dlc3Qgcm90YXRpbmcgdGhlIGluc3RhbmNl
IGlkcy4gTXkgcHJvcG9zZWQgcmVzb2x1dGlvbiBpcyB0byBzaW1wbHkgc3VnZ2VzdCBub3QgdXNp
bmcgaW5zdGFuY2UgaWQgdGhhdCBtaWdodCBiZSBpbiB1c2UuDQoNCiIgW011a3VsMl0gTWFrZXMg
c2Vuc2UuIEkgdGhpbmsgaXQgaXMgc3VmZmljaWVudCB0byBjYXV0aW9uICh3aXRoIGEgU0hPVUxE
DQogTk9UKSBhZ2FpbnN0IHJldXNpbmcgaW5zdGFuY2UgaWRzIGZvciB3aGljaCB0aGUgc3RhbGUg
c3RhdGUgbWlnaHQgZXhpc3QgIGluIHRoZSBub2Rlcy4iDQoNClRoYW5rcw0KTXVrdWwNCg0KLS0t
LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogInJvbGwgaXNzdWUgdHJhY2tlciIgPHRy
YWMrcm9sbEB0cmFjLnRvb2xzLmlldGYub3JnPg0KVG86IG11a3VsQFVXTS5FRFUsIGpwdkBjaXNj
by5jb20NCkNjOiByb2xsQGlldGYub3JnDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTIg
ODoxMTo0NCBBTQ0KU3ViamVjdDogW3JvbGxdICM5MDogdXNlIG9mIHRyYW5zaWVudCBpbnN0YW5j
ZSBJRA0KDQojOTA6IHVzZSBvZiB0cmFuc2llbnQgaW5zdGFuY2UgSUQNCg0KIFByb2JsZW0gKHJl
c29sdXRpb24gYWdyZWVkIHVwb24pDQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog
UDJQIGNyZWF0ZXMgdGVtcG9yYXJ5IHN0YXRlcyBpbiB0aGUgdHJhbnNpZW50IERBRyB3aXRoIGEg
dHJhbnNpZW50ICBpbnN0YW5jZSBJRC4gVGhlIHByb3RvY29sIG11c3QgZW5zdXJlIHRoYXQgaWYg
dGhlIGluc3RhbmNlIElEIGlzIHJldXNlZCAgdGhlbiB0aGUgbmV3IG9wZXJhdGlvbiBpdCBpcyBu
b3QgY29uZnVzZWQgd2l0aCBzdGF0ZXMgcmVzdWx0aW5nIGZyb20gdGhlICBwcmV2aW91cyB1c2Ug
b2YgdGhlIHNhbWUgaW5zdGFuY2UgSUQuIFN1Z2dlc3Rpb24gaXMgdG8gcHJvcG9zZSBhICByb3Rh
dGlvbi4NCg0KIERpc2N1c3Npb24NCiAtLS0tLS0tLS0tLS0tDQoNCiBbUGFzY2FsXQ0KICJSUExJ
bnN0YW5jZUlEOiBSUExJbnN0YW5jZUlEIE1VU1QgYmUgYSBsb2NhbCB2YWx1ZSBhcyBkZXNjcmli
ZWQgaW4gIFNlY3Rpb24gNS4xIG9mIFtJLUQuaWV0Zi1yb2xsLXJwbF0uIFRoZSBvcmlnaW4gTVVT
VCBOT1QgdXNlIHRoZSBzYW1lICBSUExJbnN0YW5jZUlEIGluIHR3byBvciBtb3JlIGNvbmN1cnJl
bnQgcm91dGUgZGlzY292ZXJpZXMuIg0KDQogSSdkIHN1Z2dlc3QgdGhhdCB5b3UgZW5mb3JjZSBh
IHJvdW5kIHJvYmluIG9yIGFuIG9wYXF1ZSBjaXJjdWxhdGlvbiBzbyAgdGhhdCB0aGUgbmV3IGlu
c3RhbmNlSUQgaXMgdGhlIGxlYXN0IHJlY2VudGx5IHVzZWQgb25lIG91dCBvZiB0aGUgNjQgIHBv
c3NpYmxlLg0KDQogW011a3VsXQ0KIEkgdGhpbmsgd2Ugc2hvdWxkIGxlYXZlIGl0IHRvIHRoZSBv
cmlnaW4gdG8gZGVjaWRlIHdoaWNoIHZhbHVlIGl0IHdhbnRzICB0byB1c2UgZm9yIFJQTEluc3Rh
bmNlSUQuIEkga25vdyBzb21lIGltcGxlbWVudGF0aW9ucyBhcmUgcGxhbm5pbmcgdG8gIHVzZSBh
IGZpeGVkIFJQTEluc3RhbmNlSUQgdmFsdWUgZm9yIGFsbCByb3V0ZSBkaXNjb3Zlcmllcy4NCg0K
IFtQYXNjYWwyXSBDaGFuZ2luZyB0aGUgaW5zdGFuY2UgSUQgd2lsbCBoZWxwIGRlYnVnIHRoZSBu
ZXR3b3JrIGFuZCBhdm9pZCAgY29uZmxpY3RzIHdpdGggc3RhbGUgc3RhdGVzLiBXaGF0J3MgcmVh
bGx5IHVwIHRvIHRoZSBkZXZpY2UgaXMgdGhlICBpbml0aWFsIHNlcXVlbmNlLiBMZWF2aW5nIGl0
IHVwIHRvIHRoZSBvcmlnaW4gbWF5IGhlbHAgdGhlIG9yaWdpbiBkZWZlYXQgIHNvbWUgYXR0YWNr
cyB0byBzb21lIGRlZ3JlZS4gT1RPSCwgYWZ0ZXIgYWxsIHRoZSBpbnN0YW5jZXMgaGF2ZSBiZWVu
ICBwbGF5ZWQsIExSVSBmb3JjZXMgdG8gcmVwbGF5IHRoZSBzYW1lIHNlcXVlbmNlIGFnYWluIHNv
IHRoZSBzaGllbGQgIGRyb3BzLiBNeSBwcmVmZXJyZWQgYXBwcm9hY2ggd291bGQgYmUgYSBTSE9V
TEQgdGhhdCB3b3VsZCBzYXkgdGhhdCB0aGUgIG5leHQgaW5zdGFuY2UgSUQgU0hPVUxEIE5PVCBi
ZSBvbmUgb2YgdGhlICgxNj8pIG1vc3QgcmVjZW50bHkgdXNlZCBhbmQgIE1VU1QgTk9UIGJlIG9u
ZSBmb3Igd2hpY2ggc3RhdGVzIG1pZ2h0IHN0aWxsIGV4aXN0IGluIHRoZSBuZXR3b3JrLiBJT1cg
IGVpdGhlciB0aGUgc3RhdGVzIGRlbGV0aW9uIHdhcyBhY2tub3dsZWRnZWQsIG9yIGFsbCBwZW5k
aW5nIGxpZmV0aW1lcyAgYXJlIGV4aGF1c3RlZC4NCg0KIFtNdWt1bDJdIE1ha2VzIHNlbnNlLiBJ
IHRoaW5rIGl0IGlzIHN1ZmZpY2llbnQgdG8gY2F1dGlvbiAod2l0aCBhIFNIT1VMRA0KIE5PVCkg
YWdhaW5zdCByZXVzaW5nIGluc3RhbmNlIGlkcyBmb3Igd2hpY2ggdGhlIHN0YWxlIHN0YXRlIG1p
Z2h0IGV4aXN0ICBpbiB0aGUgbm9kZXMuIFVzaW5nIGEgIk1VU1QgTk9UIiBtYXkgbm90IGJlIE9L
IHNpbmNlIGEgbm9kZSBtYXkgbmV2ZXIgYmUgIDEwMCUgc3VyZSBhYm91dCBub24tZXhpc3RlbmNl
IG9mIHN0YWxlIHN0YXRlIHdpdGggYSBwYXJ0aWN1bGFyIGluc3RhbmNlICBpZCAodGh1cywgYWxs
IHBvc3NpYmxlIGluc3RhbmNlIGlkIHZhbHVlcyB3aWxsIGJlY29tZSBzdXNwZWN0IGFuZCBoZW5j
ZSAgdW51c2FibGUgYWZ0ZXIgYSB3aGlsZSkuDQoNCiBbUGFzY2FsM10gQWdyZWVkLiBOb3RlIHRo
YXQgYSBjaXJjdWxhdGlvbiBpcyBhIGJvbnVzIHRvIGRlZmVhdCByZXBsYXlzLg0KIEFuZCBub3cg
d2UncmUgYmFjayB0byB0aGUgaXNzdWUgYWJvdmUuIEhvdyBkb2VzIHRoZSBkZXZpY2Uga25vdyB0
aGF0ICB0aGVyZSBpcyBubyBzdGF0ZSBsZWZ0PyBBIGxpZmV0aW1lIGRlZmluaXRpb24gd291bGQg
YmUgdmVyeSB1c2VmdWwuIFRoYXQgIGxpZmV0aW1lIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBEQUcn
cyBvbmUgaW4gUkRPLiBJIHRoaW5rIHdlIGhhdmUgYW4gb3BlbiAgaXNzdWUgaGVyZS4NCg0KIFtN
dWt1bDNdIEFzIEkgbWVudGlvbmVkIGFib3ZlLCB0aGUgbGlmZSB0aW1lIHBhcmFtZXRlcnMgaW5z
aWRlIHRoZSBET0RBRyAgY29uZmlndXJhdGlvbiBvcHRpb24gc3BlY2lmeSB0aGUgbGlmZSB0aW1l
IG9mIHRoZSBob3AtYnktaG9wIHJvdXRpbmcgIHN0YXRlIGZvciB0aGUgcm91dGVzIGRpc2NvdmVy
ZWQgdXNpbmcgUDJQLVJQTC4NCg0KIFtQYXNjYWw0XSBUaGlzIGJvaWxzIGRvd24gdG8gdGhlIHRo
cmVhZCBhYm92ZS4gT25seSBvbmUgaXNzdWUgcmVhbGx5LCAgd2hpY2ggbGlmZXRpbWUgaXMgd2hp
Y2g/IFNvIElNSE8gbm8gbmVlZCB0byBsb2cgYW55dGhpbmcgZm9yIHRoaXMgIHRocmVhZC4NCg0K
IFtNdWt1bDRdIE9LLg0KDQogUGFzY2FsDQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICBqcHZA4oCmICAg
ICAgICAgICAgICAgICAgfCAgICAgIE93bmVyOiAgbXVrdWxA4oCmDQogICAgIFR5cGU6ICBkZWZl
Y3QgICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3Ig
ICAgICAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBwMnAtcnBsICAgICAg
ICAgICAgICAgIHwgICAgVmVyc2lvbjoNCiBTZXZlcml0eTogIFN1Ym1pdHRlZCBXRyBEb2N1bWVu
dCAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwczovL3N2bi50b29scy5pZXRm
Lm9yZy93Zy9yb2xsL3RyYWMvdGlja2V0LzkwPg0Kcm9sbCA8aHR0cDovL3Rvb2xzLmlldGYub3Jn
L3dnL3JvbGwvPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K

From prvs=440167eea=mukul@uwm.edu  Tue Apr 10 05:50:34 2012
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 CF2B321F85CD for ; Tue, 10 Apr 2012 05:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.589
X-Spam-Level: 
X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
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 4R+RM0A9vk7n for ; Tue, 10 Apr 2012 05:50:32 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7236D21F85CC for ; Tue, 10 Apr 2012 05:50:32 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvkGAF8shE9/AAAB/2dsb2JhbABDhWaxVYR+AQEFI1YMDxEEAQEDAg0WAwJICQgGExmHdQunWYo0iQmBL4lvhCuBGASIWo0SgRGPJYMFgTYBFg
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 08DA012E3BA; Tue, 10 Apr 2012 07:50:17 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu
Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkM6uwgb4V8z; Tue, 10 Apr 2012 07:50:16 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 8AFF312E3B9; Tue, 10 Apr 2012 07:50:16 -0500 (CDT)
Date: Tue, 10 Apr 2012 07:50:16 -0500 (CDT)
From: Mukul Goyal 
To: "Pascal Thubert (pthubert)" 
Message-ID: <4439245.1873082.1334062216458.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.91]
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] [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
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, 10 Apr 2012 12:50:34 -0000

Hi Pascal

Hopefully we are talking about the same thing.

>No, it's not closed. We are talking about a contract between lower layers =
in all nodes including the source and origin to maintain necessary resource=
s and all contracts must have a lifetime.

1. A node that joins a temporary P2P-RPL DAG maintains state for the DAG fo=
r the time duration specified as DAG life time.
2. A node that establishes hop-by-hop routing state for a route discovered =
using P2P-RPL maintains this state for the time duration specified in DODAG=
 configuration option.

Origin and target need to exchange DROs and DRO-ACKs. I could specify a new=
 configurable parameter to specify the time limit on this exchange. This pa=
rameter's value  has to be more than DAG life time. One option is to specif=
y it in terms of existing parameters: DAG life time + (MAX_DRO_RETRANSMISSI=
ONS + 1)*DRO_ACK_WAIT_TIME.

Thanks
Mukul
----- Original Message -----
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
Cc: jpv@cisco.com
Sent: Tuesday, April 10, 2012 4:45:46 AM
Subject: RE: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Hi Mukul,

No, it's not closed. We are talking about a contract between lower layers i=
n all nodes including the source and origin to maintain necessary resources=
 and all contracts must have a lifetime.
I do not mind you overload the RPL lifetime of the routing for the states a=
t origin and target and if you have a sentence that makes it clear then we'=
ll be in agreement.

Cheers,

Pascal


-----Original Message-----
From: Mukul Goyal [mailto:mukul@uwm.edu]=20
Sent: dimanche 8 avril 2012 17:52
To: Pascal Thubert (pthubert)
Cc: jpv@cisco.com
Subject: Re: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Pascal

Can we consider this issue closed? Please see my last response.

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" 
To: mukul@UWM.EDU, jpv@cisco.com
Cc: roll@ietf.org
Sent: Wednesday, April 4, 2012 8:06:30 AM
Subject: [roll] #85: which lifetime is for the end points (origin and targe=
t) vs. intermediate nodes.

#85: which lifetime is for the end points (origin and target) vs. intermedi=
ate nodes.

 Problem (currently open)
 ------------------------------
 P2P creates temporary states in the transient DAG and less-but-still  temp=
orary states in the endpoints. These are 2 different lifetimes. The  spec h=
as 2 lifetimes, one in the config option and one in the RDO. The  spec is n=
ot sufficiently clear about which is which. In can appear to be  conflictin=
g since the config option is supposed to apply to all routers  on the path.=
 On the side, and in order to allow the reuse of instance  ID, the origin m=
ust be sure that all states for a previous usage of the  same value are gon=
e. So we need a clear control / negotiation of the  lifetimes on the states=
 that come with an instanceID. Again this is not  clear enough in the spec.



 [Pascal2]
 2) Same question if you want to create states at the target to route  back=
. How long does the target need to maintain the route? Who controls  that, =
the origin or the target? I'd expect to find a suggested lifetime  in the R=
DO with a confirmation in the DRO to let the target amend it.

 [Mukul2]
 If the target wants DRO-ACK it needs to maintain state until DRO-ACK is  r=
eceived. Otherwise, the target needs to remember things until it is  done s=
ending all the DROs. I will add the text to this effect.

 [Pascal3]
 If you are setting up a short term conversation, how long exactly is  that=
 before the origin has to refresh the route? What controls clean up  in bot=
h sides? Usually you want a lifetime (see MIP6 for instance)

 [Mukul3]
 Is it that you are talking about the lifetime of the hop-by-hop routing  s=
tate? That is specified in the life time parameters in the DODAG  configura=
tion option. The draft says that on page 9 while describing how  the DODAG =
configuration option should be set inside a P2P mode DIO:

 "The Default Lifetime and Lifetime Unit parameters in DODAG
      Configuration option indicate the life time of the state the
      routers maintain for a hop-by-hop route established using P2P-RPL
      and may be set as desired.
 "

 [Pascal4] Maybe that's so but then you need to reword a little bit cause  =
you got me qiute confused. I've been talking of the lifetime of the  states=
 at origin and target for one conversation. Since they might be  having a t=
ransient conversation, and the origin might reuse the instance  ID soon, yo=
u need to give a limit in time to the states that you are  creating. Still =
that conversation is longer than the states in the  intermediate routers. S=
o you have 2 lifetimes and you have to be very  clear which is which. Perso=
nally, I'd have used the lifetime in the  configuration option for all the =
routers on the way and I'd have used  the new lifetime in the RDO as the co=
nversation lifetime in the end  points because:
 1)  that is the new concept.
 2) This would allow the target to confirm exactly how long it locks  resou=
rces,
 3) and this would be more compatible with the description of the config  o=
ption in RFC 6550.

 [Mukul4]
 There are two lifetimes:
 1) Lifetime of the temporary DAG: this is specified inside P2P-RDO
 2) Lifetime of the routing state for the hop-by-hop route established  usi=
ng P2P-RPL: this is specified inside the DODAG configuration option.
 All routers on the established route (including the origin) maintain  stat=
e for this route for this much time. This time could very well be  infinity=
.

 Now, lets talk about the "states at origin and target". The origin and  th=
e target maintain the state about the temporary DAG for the DAG's life  tim=
e. This is true for all the nodes that join this DAG. All such nodes  maint=
ain state about the temporary DAG until the DAG's life time is  over. It is=
 true that the target and the origin exchange DROs and  DRO-ACKs and this e=
xchange could conceivably go on even after the  temporary DAG's demise. How=
 long should the origin and target indulge in  this exchange (and hence rem=
ember the possibly dead DAG)? I think it is  purely their choice and the dr=
aft need not impose any artificial time  limit on this.

 Pascal

--=20
-----------------------------------+---------------------
 Reporter:  jpv@=E2=80=A6                  |      Owner:  mukul@=E2=80=A6
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: 
roll 


From prvs=440167eea=mukul@uwm.edu  Tue Apr 10 05:55:10 2012
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 A722C21F85D5 for ; Tue, 10 Apr 2012 05:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.58
X-Spam-Level: 
X-Spam-Status: No, score=-5.58 tagged_above=-999 required=5 tests=[AWL=-0.221,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
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 PQGpHJQSEnUB for ; Tue, 10 Apr 2012 05:55:09 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBD521F85D7 for ; Tue, 10 Apr 2012 05:55:09 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvkGAJEshE9/AAAB/2dsb2JhbABChXOxVYR/AQEFI1YMDxEEAQEDAg0WAwJICQgGExmHdQurW4o2gSGBL4lvhCuBGASIWo0SgRGPJYMFgTYBFg
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 6730A12E3C0; Tue, 10 Apr 2012 07:55:08 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu
Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LkrQX1a-UFQ; Tue, 10 Apr 2012 07:55:07 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id B855B12E3BA; Tue, 10 Apr 2012 07:55:07 -0500 (CDT)
Date: Tue, 10 Apr 2012 07:55:07 -0500 (CDT)
From: Mukul Goyal 
To: "Pascal Thubert (pthubert)" 
Message-ID: <1730029959.1873111.1334062507637.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <4439245.1873082.1334062216458.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.91]
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] [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
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, 10 Apr 2012 12:55:10 -0000

OR the simpler option would be to require DRO/DRO-ACK exchange to complete =
within the DAG's life time? If we were to specify a new parameter for the t=
ime limit on DRO/DRO-ACK exchange, both target and origin would need to agr=
ee on the value of this parameter.

Mukul

----- Original Message -----
From: "Mukul Goyal" 
To: "Pascal Thubert (pthubert)" 
Cc: jpv@cisco.com, "roll" 
Sent: Tuesday, April 10, 2012 7:50:16 AM
Subject: Re: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Hi Pascal

Hopefully we are talking about the same thing.

>No, it's not closed. We are talking about a contract between lower layers =
in all nodes including the source and origin to maintain necessary resource=
s and all contracts must have a lifetime.

1. A node that joins a temporary P2P-RPL DAG maintains state for the DAG fo=
r the time duration specified as DAG life time.
2. A node that establishes hop-by-hop routing state for a route discovered =
using P2P-RPL maintains this state for the time duration specified in DODAG=
 configuration option.

Origin and target need to exchange DROs and DRO-ACKs. I could specify a new=
 configurable parameter to specify the time limit on this exchange. This pa=
rameter's value  has to be more than DAG life time. One option is to specif=
y it in terms of existing parameters: DAG life time + (MAX_DRO_RETRANSMISSI=
ONS + 1)*DRO_ACK_WAIT_TIME.

Thanks
Mukul
----- Original Message -----
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
Cc: jpv@cisco.com
Sent: Tuesday, April 10, 2012 4:45:46 AM
Subject: RE: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Hi Mukul,

No, it's not closed. We are talking about a contract between lower layers i=
n all nodes including the source and origin to maintain necessary resources=
 and all contracts must have a lifetime.
I do not mind you overload the RPL lifetime of the routing for the states a=
t origin and target and if you have a sentence that makes it clear then we'=
ll be in agreement.

Cheers,

Pascal


-----Original Message-----
From: Mukul Goyal [mailto:mukul@uwm.edu]=20
Sent: dimanche 8 avril 2012 17:52
To: Pascal Thubert (pthubert)
Cc: jpv@cisco.com
Subject: Re: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Pascal

Can we consider this issue closed? Please see my last response.

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" 
To: mukul@UWM.EDU, jpv@cisco.com
Cc: roll@ietf.org
Sent: Wednesday, April 4, 2012 8:06:30 AM
Subject: [roll] #85: which lifetime is for the end points (origin and targe=
t) vs. intermediate nodes.

#85: which lifetime is for the end points (origin and target) vs. intermedi=
ate nodes.

 Problem (currently open)
 ------------------------------
 P2P creates temporary states in the transient DAG and less-but-still  temp=
orary states in the endpoints. These are 2 different lifetimes. The  spec h=
as 2 lifetimes, one in the config option and one in the RDO. The  spec is n=
ot sufficiently clear about which is which. In can appear to be  conflictin=
g since the config option is supposed to apply to all routers  on the path.=
 On the side, and in order to allow the reuse of instance  ID, the origin m=
ust be sure that all states for a previous usage of the  same value are gon=
e. So we need a clear control / negotiation of the  lifetimes on the states=
 that come with an instanceID. Again this is not  clear enough in the spec.



 [Pascal2]
 2) Same question if you want to create states at the target to route  back=
. How long does the target need to maintain the route? Who controls  that, =
the origin or the target? I'd expect to find a suggested lifetime  in the R=
DO with a confirmation in the DRO to let the target amend it.

 [Mukul2]
 If the target wants DRO-ACK it needs to maintain state until DRO-ACK is  r=
eceived. Otherwise, the target needs to remember things until it is  done s=
ending all the DROs. I will add the text to this effect.

 [Pascal3]
 If you are setting up a short term conversation, how long exactly is  that=
 before the origin has to refresh the route? What controls clean up  in bot=
h sides? Usually you want a lifetime (see MIP6 for instance)

 [Mukul3]
 Is it that you are talking about the lifetime of the hop-by-hop routing  s=
tate? That is specified in the life time parameters in the DODAG  configura=
tion option. The draft says that on page 9 while describing how  the DODAG =
configuration option should be set inside a P2P mode DIO:

 "The Default Lifetime and Lifetime Unit parameters in DODAG
      Configuration option indicate the life time of the state the
      routers maintain for a hop-by-hop route established using P2P-RPL
      and may be set as desired.
 "

 [Pascal4] Maybe that's so but then you need to reword a little bit cause  =
you got me qiute confused. I've been talking of the lifetime of the  states=
 at origin and target for one conversation. Since they might be  having a t=
ransient conversation, and the origin might reuse the instance  ID soon, yo=
u need to give a limit in time to the states that you are  creating. Still =
that conversation is longer than the states in the  intermediate routers. S=
o you have 2 lifetimes and you have to be very  clear which is which. Perso=
nally, I'd have used the lifetime in the  configuration option for all the =
routers on the way and I'd have used  the new lifetime in the RDO as the co=
nversation lifetime in the end  points because:
 1)  that is the new concept.
 2) This would allow the target to confirm exactly how long it locks  resou=
rces,
 3) and this would be more compatible with the description of the config  o=
ption in RFC 6550.

 [Mukul4]
 There are two lifetimes:
 1) Lifetime of the temporary DAG: this is specified inside P2P-RDO
 2) Lifetime of the routing state for the hop-by-hop route established  usi=
ng P2P-RPL: this is specified inside the DODAG configuration option.
 All routers on the established route (including the origin) maintain  stat=
e for this route for this much time. This time could very well be  infinity=
.

 Now, lets talk about the "states at origin and target". The origin and  th=
e target maintain the state about the temporary DAG for the DAG's life  tim=
e. This is true for all the nodes that join this DAG. All such nodes  maint=
ain state about the temporary DAG until the DAG's life time is  over. It is=
 true that the target and the origin exchange DROs and  DRO-ACKs and this e=
xchange could conceivably go on even after the  temporary DAG's demise. How=
 long should the origin and target indulge in  this exchange (and hence rem=
ember the possibly dead DAG)? I think it is  purely their choice and the dr=
aft need not impose any artificial time  limit on this.

 Pascal

--=20
-----------------------------------+---------------------
 Reporter:  jpv@=E2=80=A6                  |      Owner:  mukul@=E2=80=A6
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: 
roll 


From prvs=440167eea=mukul@uwm.edu  Tue Apr 10 06:05:00 2012
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 2E8C321F861D for ; Tue, 10 Apr 2012 06:05:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.572
X-Spam-Level: 
X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
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 ngQjKEQxx0HK for ; Tue, 10 Apr 2012 06:04:59 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 14F3821F861B for ; Tue, 10 Apr 2012 06:04:59 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvkGANIuhE9/AAAB/2dsb2JhbABDhWaxVYR/AQEBBAEBASBLCwwPEQQBAQMCDRIEAwIpHwkIBhMZh3ULp2SKNIkJgS+Jb4QrgRgEiFqNEoERjyWDBYE2ARY
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 811AB2B3F0B; Tue, 10 Apr 2012 08:04:58 -0500 (CDT)
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 dhSaqnBtKO+q; Tue, 10 Apr 2012 08:04:58 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 067DD2B3EF6; Tue, 10 Apr 2012 08:04:58 -0500 (CDT)
Date: Tue, 10 Apr 2012 08:04:57 -0500 (CDT)
From: Mukul Goyal 
To: "Pascal Thubert (pthubert)" 
Message-ID: <760364492.1873220.1334063097969.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <1730029959.1873111.1334062507637.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.91]
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] [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
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, 10 Apr 2012 13:05:00 -0000

But, this would require DAG's life time to be set large enough to allow com=
pletion of DRO/DRO-ACK exchange. Intermediate routers would need to maintai=
n state for temporary DAG longer than necessary and they might end up gener=
ating many unnecessary DIOs. So, how about if we require DRO/DRO-ACK exchan=
ge to be completed within twice the DAG lifetime duration? Intermediate rou=
ters would leave the DAG after its lifetime is over. The origin and target =
would remember this DAG for one more lifetime to allow DRO/DRO-ACK exchange=
 to complete.

Thanks
Mukul=20

----- Original Message -----
From: "Mukul Goyal" 
To: "Pascal Thubert (pthubert)" 
Cc: "roll" 
Sent: Tuesday, April 10, 2012 7:55:07 AM
Subject: Re: [Roll] [roll] #85: which lifetime is for the end points (origi=
n and target) vs. intermediate nodes.

OR the simpler option would be to require DRO/DRO-ACK exchange to complete =
within the DAG's life time? If we were to specify a new parameter for the t=
ime limit on DRO/DRO-ACK exchange, both target and origin would need to agr=
ee on the value of this parameter.

Mukul

----- Original Message -----
From: "Mukul Goyal" 
To: "Pascal Thubert (pthubert)" 
Cc: jpv@cisco.com, "roll" 
Sent: Tuesday, April 10, 2012 7:50:16 AM
Subject: Re: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Hi Pascal

Hopefully we are talking about the same thing.

>No, it's not closed. We are talking about a contract between lower layers =
in all nodes including the source and origin to maintain necessary resource=
s and all contracts must have a lifetime.

1. A node that joins a temporary P2P-RPL DAG maintains state for the DAG fo=
r the time duration specified as DAG life time.
2. A node that establishes hop-by-hop routing state for a route discovered =
using P2P-RPL maintains this state for the time duration specified in DODAG=
 configuration option.

Origin and target need to exchange DROs and DRO-ACKs. I could specify a new=
 configurable parameter to specify the time limit on this exchange. This pa=
rameter's value  has to be more than DAG life time. One option is to specif=
y it in terms of existing parameters: DAG life time + (MAX_DRO_RETRANSMISSI=
ONS + 1)*DRO_ACK_WAIT_TIME.

Thanks
Mukul
----- Original Message -----
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
Cc: jpv@cisco.com
Sent: Tuesday, April 10, 2012 4:45:46 AM
Subject: RE: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Hi Mukul,

No, it's not closed. We are talking about a contract between lower layers i=
n all nodes including the source and origin to maintain necessary resources=
 and all contracts must have a lifetime.
I do not mind you overload the RPL lifetime of the routing for the states a=
t origin and target and if you have a sentence that makes it clear then we'=
ll be in agreement.

Cheers,

Pascal


-----Original Message-----
From: Mukul Goyal [mailto:mukul@uwm.edu]=20
Sent: dimanche 8 avril 2012 17:52
To: Pascal Thubert (pthubert)
Cc: jpv@cisco.com
Subject: Re: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Pascal

Can we consider this issue closed? Please see my last response.

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" 
To: mukul@UWM.EDU, jpv@cisco.com
Cc: roll@ietf.org
Sent: Wednesday, April 4, 2012 8:06:30 AM
Subject: [roll] #85: which lifetime is for the end points (origin and targe=
t) vs. intermediate nodes.

#85: which lifetime is for the end points (origin and target) vs. intermedi=
ate nodes.

 Problem (currently open)
 ------------------------------
 P2P creates temporary states in the transient DAG and less-but-still  temp=
orary states in the endpoints. These are 2 different lifetimes. The  spec h=
as 2 lifetimes, one in the config option and one in the RDO. The  spec is n=
ot sufficiently clear about which is which. In can appear to be  conflictin=
g since the config option is supposed to apply to all routers  on the path.=
 On the side, and in order to allow the reuse of instance  ID, the origin m=
ust be sure that all states for a previous usage of the  same value are gon=
e. So we need a clear control / negotiation of the  lifetimes on the states=
 that come with an instanceID. Again this is not  clear enough in the spec.



 [Pascal2]
 2) Same question if you want to create states at the target to route  back=
. How long does the target need to maintain the route? Who controls  that, =
the origin or the target? I'd expect to find a suggested lifetime  in the R=
DO with a confirmation in the DRO to let the target amend it.

 [Mukul2]
 If the target wants DRO-ACK it needs to maintain state until DRO-ACK is  r=
eceived. Otherwise, the target needs to remember things until it is  done s=
ending all the DROs. I will add the text to this effect.

 [Pascal3]
 If you are setting up a short term conversation, how long exactly is  that=
 before the origin has to refresh the route? What controls clean up  in bot=
h sides? Usually you want a lifetime (see MIP6 for instance)

 [Mukul3]
 Is it that you are talking about the lifetime of the hop-by-hop routing  s=
tate? That is specified in the life time parameters in the DODAG  configura=
tion option. The draft says that on page 9 while describing how  the DODAG =
configuration option should be set inside a P2P mode DIO:

 "The Default Lifetime and Lifetime Unit parameters in DODAG
      Configuration option indicate the life time of the state the
      routers maintain for a hop-by-hop route established using P2P-RPL
      and may be set as desired.
 "

 [Pascal4] Maybe that's so but then you need to reword a little bit cause  =
you got me qiute confused. I've been talking of the lifetime of the  states=
 at origin and target for one conversation. Since they might be  having a t=
ransient conversation, and the origin might reuse the instance  ID soon, yo=
u need to give a limit in time to the states that you are  creating. Still =
that conversation is longer than the states in the  intermediate routers. S=
o you have 2 lifetimes and you have to be very  clear which is which. Perso=
nally, I'd have used the lifetime in the  configuration option for all the =
routers on the way and I'd have used  the new lifetime in the RDO as the co=
nversation lifetime in the end  points because:
 1)  that is the new concept.
 2) This would allow the target to confirm exactly how long it locks  resou=
rces,
 3) and this would be more compatible with the description of the config  o=
ption in RFC 6550.

 [Mukul4]
 There are two lifetimes:
 1) Lifetime of the temporary DAG: this is specified inside P2P-RDO
 2) Lifetime of the routing state for the hop-by-hop route established  usi=
ng P2P-RPL: this is specified inside the DODAG configuration option.
 All routers on the established route (including the origin) maintain  stat=
e for this route for this much time. This time could very well be  infinity=
.

 Now, lets talk about the "states at origin and target". The origin and  th=
e target maintain the state about the temporary DAG for the DAG's life  tim=
e. This is true for all the nodes that join this DAG. All such nodes  maint=
ain state about the temporary DAG until the DAG's life time is  over. It is=
 true that the target and the origin exchange DROs and  DRO-ACKs and this e=
xchange could conceivably go on even after the  temporary DAG's demise. How=
 long should the origin and target indulge in  this exchange (and hence rem=
ember the possibly dead DAG)? I think it is  purely their choice and the dr=
aft need not impose any artificial time  limit on this.

 Pascal

--=20
-----------------------------------+---------------------
 Reporter:  jpv@=E2=80=A6                  |      Owner:  mukul@=E2=80=A6
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: 
roll 

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

From pthubert@cisco.com  Tue Apr 10 07:11:25 2012
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 75B1B21F8671 for ; Tue, 10 Apr 2012 07:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.409
X-Spam-Level: 
X-Spam-Status: No, score=-9.409 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24]
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 uhtpaTFVzVvz for ; Tue, 10 Apr 2012 07:11:24 -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 97D2121F8670 for ; Tue, 10 Apr 2012 07:11:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=11980; q=dns/txt; s=iport; t=1334067083; x=1335276683; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+vbDcSEbWXV9CI6R1p2WSfYLXDi6lxlc8RACXnZOqPY=; b=TgZ4jcWSUAI54JIrt3Fo4+V8sXHt9XFNgbc1nunTAjz6b+gxmGzQLdYw 54/baYnUW0u/SVD/r5+ZSWmSLgDykW6EFIwHH/9sUGpfJaWG/dbbXwE9X lyW7t3zQPhkN1mDuoYmpmrym6Kdvr0O2StQPZCExusIiYdMMDC5r6T9Mi I=;
X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="70487825"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 10 Apr 2012 14:11: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 q3AEBMpR020501; Tue, 10 Apr 2012 14:11: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);  Tue, 10 Apr 2012 16:11:22 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Tue, 10 Apr 2012 16:10:56 +0200
Message-ID: 
In-Reply-To: <1730029959.1873111.1334062507637.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
Thread-Index: Ac0XGTIhl+2d9tpCSNC9xgbKP/0lQgACVDWg
References: <4439245.1873082.1334062216458.JavaMail.root@mail17.pantherlink.uwm.edu> <1730029959.1873111.1334062507637.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
X-OriginalArrivalTime: 10 Apr 2012 14:11:22.0679 (UTC) FILETIME=[CEF0BC70:01CD1723]
Cc: roll 
Subject: Re: [Roll] [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
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, 10 Apr 2012 14:11:25 -0000

SGkgTXVrdWw6DQoNCkkgZG8gbm90IHdpc2ggdG8gY2hhbmdlIHRoZSBEQUcgbGlmZXRpbWUuDQoN
CkknbSBwb2ludGluZyBvdXQgdGhhdCB0aGUgY29udmVyc2F0aW9uIGJldHdlZW4gdGhlIG9yaWdp
biBhbmQgdGFyZ2V0IGNhbm5vdCB3b3JrIGxvbmdlciB0aGFuIHRoZSBsaWZldGltZSBvZiB0aGUg
aG9wLWJ5LWhvcCByb3V0aW5nIHN0YXRlcyB3aGljaCBpdCBkZXBlbmRzIG9uLiBTbyB3aHkgbm90
IHVzZSB0aGF0Pw0KDQpJIHN1Z2dlc3QgdGhhdCB3ZSBjb252ZXJnZSB0aGUgdGltZSBkdXJhdGlv
biBzcGVjaWZpZWQgaW4gRE9EQUcgY29uZmlndXJhdGlvbiBvcHRpb24gdG8gbWVhbiB0aGUgbWF4
aW11bSBkdXJhdGlvbiBvZiBzdGF0ZXMgaW4gYWxsIG5vZGVzIHRoYXQgbmVlZCB0byBrZWVwIHN0
YXRlcywgaW5jbHVkaW5nIG9yaWdpbiBhbmQgdGFyZ2V0LCBhbmQgaW4gc29tZSBjYXNlIGludGVy
bWVkaWF0ZSByb3V0ZXJzLg0KDQpJT1csIGlmIHRoZSBIYkggcm91dGUgaXMgdXNlZCwgdGhlIGxp
ZmV0aW1lIGluIHRoZSBjb25maWcgb3B0aW9uIGlzIGZvciBhbGwgc3RhdGVzIGluIGFsbCBub2Rl
cyBvbiB0aGUgcGF0aChzKSBpbmNsdWRpbmcgb3JpZ2lucyBhbmQgdGFyZ2V0KHMpLiBJZiBIYkgg
cm91dGluZyBpcyBub3QgdXNlZCwgdGhlIGxpZmV0aW1lIGluIHRoZSBjb25maWcgb3B0aW9uIGlz
IHN0aWxsIHZhbGlkIGZvciB0aGUgc291cmNlIGFuZCB0aGUgb3JpZ2luLiBZb3UgbWF5IGRlZmlu
ZSBhIGRlZmF1bHQgdmFsdWUgdGhhdCBzdWl0IGNsYXNzaWNhbCBQMlAgcm91dGVzIGluIHRoZSBj
YXNlIHdoZXJlIG5vIGNvbmZpZyBvZiBhbnkgc29ydCBpcyBwcm92aWRlZC4gDQoNCkFuZCB5ZXMs
IGdyZWF0IHBvaW50LCB5b3UnZCBuZWVkIHRvIHNwZWNpZnkgdGhhdCB0aGUgbGlmZXRpbWUgaW4g
dGhlIGNvbmZpZyBvcHRpb24gbXVzdCBiZSBsYXJnZSBlbm91Z2ggdG8gYWNjb21tb2RhdGUgdGhl
IHJldHJhbnNtaXNzaW9ucy4NCg0KRG8gd2UgY29udmVyZ2U/DQoNClBhc2NhbA0KDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3VsQHV3
bS5lZHVdIA0KU2VudDogbWFyZGkgMTAgYXZyaWwgMjAxMiAxNDo1NQ0KVG86IFBhc2NhbCBUaHVi
ZXJ0IChwdGh1YmVydCkNCkNjOiBqcHZAY2lzY28uY29tOyByb2xsDQpTdWJqZWN0OiBSZTogW3Jv
bGxdICM4NTogd2hpY2ggbGlmZXRpbWUgaXMgZm9yIHRoZSBlbmQgcG9pbnRzIChvcmlnaW4gYW5k
IHRhcmdldCkgdnMuIGludGVybWVkaWF0ZSBub2Rlcy4NCg0KT1IgdGhlIHNpbXBsZXIgb3B0aW9u
IHdvdWxkIGJlIHRvIHJlcXVpcmUgRFJPL0RSTy1BQ0sgZXhjaGFuZ2UgdG8gY29tcGxldGUgd2l0
aGluIHRoZSBEQUcncyBsaWZlIHRpbWU/IElmIHdlIHdlcmUgdG8gc3BlY2lmeSBhIG5ldyBwYXJh
bWV0ZXIgZm9yIHRoZSB0aW1lIGxpbWl0IG9uIERSTy9EUk8tQUNLIGV4Y2hhbmdlLCBib3RoIHRh
cmdldCBhbmQgb3JpZ2luIHdvdWxkIG5lZWQgdG8gYWdyZWUgb24gdGhlIHZhbHVlIG9mIHRoaXMg
cGFyYW1ldGVyLg0KDQpNdWt1bA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9t
OiAiTXVrdWwgR295YWwiIDxtdWt1bEB1d20uZWR1Pg0KVG86ICJQYXNjYWwgVGh1YmVydCAocHRo
dWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPg0KQ2M6IGpwdkBjaXNjby5jb20sICJyb2xsIiA8
cm9sbEBpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDEwLCAyMDEyIDc6NTA6MTYgQU0N
ClN1YmplY3Q6IFJlOiBbcm9sbF0gIzg1OiB3aGljaCBsaWZldGltZSBpcyBmb3IgdGhlIGVuZCBw
b2ludHMgKG9yaWdpbiBhbmQgdGFyZ2V0KSB2cy4gaW50ZXJtZWRpYXRlIG5vZGVzLg0KDQpIaSBQ
YXNjYWwNCg0KSG9wZWZ1bGx5IHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBzYW1lIHRoaW5nLg0K
DQo+Tm8sIGl0J3Mgbm90IGNsb3NlZC4gV2UgYXJlIHRhbGtpbmcgYWJvdXQgYSBjb250cmFjdCBi
ZXR3ZWVuIGxvd2VyIGxheWVycyBpbiBhbGwgbm9kZXMgaW5jbHVkaW5nIHRoZSBzb3VyY2UgYW5k
IG9yaWdpbiB0byBtYWludGFpbiBuZWNlc3NhcnkgcmVzb3VyY2VzIGFuZCBhbGwgY29udHJhY3Rz
IG11c3QgaGF2ZSBhIGxpZmV0aW1lLg0KDQoxLiBBIG5vZGUgdGhhdCBqb2lucyBhIHRlbXBvcmFy
eSBQMlAtUlBMIERBRyBtYWludGFpbnMgc3RhdGUgZm9yIHRoZSBEQUcgZm9yIHRoZSB0aW1lIGR1
cmF0aW9uIHNwZWNpZmllZCBhcyBEQUcgbGlmZSB0aW1lLg0KMi4gQSBub2RlIHRoYXQgZXN0YWJs
aXNoZXMgaG9wLWJ5LWhvcCByb3V0aW5nIHN0YXRlIGZvciBhIHJvdXRlIGRpc2NvdmVyZWQgdXNp
bmcgUDJQLVJQTCBtYWludGFpbnMgdGhpcyBzdGF0ZSBmb3IgdGhlIHRpbWUgZHVyYXRpb24gc3Bl
Y2lmaWVkIGluIERPREFHIGNvbmZpZ3VyYXRpb24gb3B0aW9uLg0KDQpPcmlnaW4gYW5kIHRhcmdl
dCBuZWVkIHRvIGV4Y2hhbmdlIERST3MgYW5kIERSTy1BQ0tzLiBJIGNvdWxkIHNwZWNpZnkgYSBu
ZXcgY29uZmlndXJhYmxlIHBhcmFtZXRlciB0byBzcGVjaWZ5IHRoZSB0aW1lIGxpbWl0IG9uIHRo
aXMgZXhjaGFuZ2UuIFRoaXMgcGFyYW1ldGVyJ3MgdmFsdWUgIGhhcyB0byBiZSBtb3JlIHRoYW4g
REFHIGxpZmUgdGltZS4gT25lIG9wdGlvbiBpcyB0byBzcGVjaWZ5IGl0IGluIHRlcm1zIG9mIGV4
aXN0aW5nIHBhcmFtZXRlcnM6IERBRyBsaWZlIHRpbWUgKyAoTUFYX0RST19SRVRSQU5TTUlTU0lP
TlMgKyAxKSpEUk9fQUNLX1dBSVRfVElNRS4NCg0KVGhhbmtzDQpNdWt1bA0KLS0tLS0gT3JpZ2lu
YWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1
YmVydEBjaXNjby5jb20+DQpUbzogIk11a3VsIEdveWFsIiA8bXVrdWxAdXdtLmVkdT4NCkNjOiBq
cHZAY2lzY28uY29tDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxMiA0OjQ1OjQ2IEFNDQpT
dWJqZWN0OiBSRTogW3JvbGxdICM4NTogd2hpY2ggbGlmZXRpbWUgaXMgZm9yIHRoZSBlbmQgcG9p
bnRzIChvcmlnaW4gYW5kIHRhcmdldCkgdnMuIGludGVybWVkaWF0ZSBub2Rlcy4NCg0KSGkgTXVr
dWwsDQoNCk5vLCBpdCdzIG5vdCBjbG9zZWQuIFdlIGFyZSB0YWxraW5nIGFib3V0IGEgY29udHJh
Y3QgYmV0d2VlbiBsb3dlciBsYXllcnMgaW4gYWxsIG5vZGVzIGluY2x1ZGluZyB0aGUgc291cmNl
IGFuZCBvcmlnaW4gdG8gbWFpbnRhaW4gbmVjZXNzYXJ5IHJlc291cmNlcyBhbmQgYWxsIGNvbnRy
YWN0cyBtdXN0IGhhdmUgYSBsaWZldGltZS4NCkkgZG8gbm90IG1pbmQgeW91IG92ZXJsb2FkIHRo
ZSBSUEwgbGlmZXRpbWUgb2YgdGhlIHJvdXRpbmcgZm9yIHRoZSBzdGF0ZXMgYXQgb3JpZ2luIGFu
ZCB0YXJnZXQgYW5kIGlmIHlvdSBoYXZlIGEgc2VudGVuY2UgdGhhdCBtYWtlcyBpdCBjbGVhciB0
aGVuIHdlJ2xsIGJlIGluIGFncmVlbWVudC4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTXVrdWwgR295YWwgW21haWx0bzptdWt1bEB1
d20uZWR1XSANClNlbnQ6IGRpbWFuY2hlIDggYXZyaWwgMjAxMiAxNzo1Mg0KVG86IFBhc2NhbCBU
aHViZXJ0IChwdGh1YmVydCkNCkNjOiBqcHZAY2lzY28uY29tDQpTdWJqZWN0OiBSZTogW3JvbGxd
ICM4NTogd2hpY2ggbGlmZXRpbWUgaXMgZm9yIHRoZSBlbmQgcG9pbnRzIChvcmlnaW4gYW5kIHRh
cmdldCkgdnMuIGludGVybWVkaWF0ZSBub2Rlcy4NCg0KUGFzY2FsDQoNCkNhbiB3ZSBjb25zaWRl
ciB0aGlzIGlzc3VlIGNsb3NlZD8gUGxlYXNlIHNlZSBteSBsYXN0IHJlc3BvbnNlLg0KDQpUaGFu
a3MNCk11a3VsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJyb2xsIGlz
c3VlIHRyYWNrZXIiIDx0cmFjK3JvbGxAdHJhYy50b29scy5pZXRmLm9yZz4NClRvOiBtdWt1bEBV
V00uRURVLCBqcHZAY2lzY28uY29tDQpDYzogcm9sbEBpZXRmLm9yZw0KU2VudDogV2VkbmVzZGF5
LCBBcHJpbCA0LCAyMDEyIDg6MDY6MzAgQU0NClN1YmplY3Q6IFtyb2xsXSAjODU6IHdoaWNoIGxp
ZmV0aW1lIGlzIGZvciB0aGUgZW5kIHBvaW50cyAob3JpZ2luIGFuZCB0YXJnZXQpIHZzLiBpbnRl
cm1lZGlhdGUgbm9kZXMuDQoNCiM4NTogd2hpY2ggbGlmZXRpbWUgaXMgZm9yIHRoZSBlbmQgcG9p
bnRzIChvcmlnaW4gYW5kIHRhcmdldCkgdnMuIGludGVybWVkaWF0ZSBub2Rlcy4NCg0KIFByb2Js
ZW0gKGN1cnJlbnRseSBvcGVuKQ0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFAy
UCBjcmVhdGVzIHRlbXBvcmFyeSBzdGF0ZXMgaW4gdGhlIHRyYW5zaWVudCBEQUcgYW5kIGxlc3Mt
YnV0LXN0aWxsICB0ZW1wb3Jhcnkgc3RhdGVzIGluIHRoZSBlbmRwb2ludHMuIFRoZXNlIGFyZSAy
IGRpZmZlcmVudCBsaWZldGltZXMuIFRoZSAgc3BlYyBoYXMgMiBsaWZldGltZXMsIG9uZSBpbiB0
aGUgY29uZmlnIG9wdGlvbiBhbmQgb25lIGluIHRoZSBSRE8uIFRoZSAgc3BlYyBpcyBub3Qgc3Vm
ZmljaWVudGx5IGNsZWFyIGFib3V0IHdoaWNoIGlzIHdoaWNoLiBJbiBjYW4gYXBwZWFyIHRvIGJl
ICBjb25mbGljdGluZyBzaW5jZSB0aGUgY29uZmlnIG9wdGlvbiBpcyBzdXBwb3NlZCB0byBhcHBs
eSB0byBhbGwgcm91dGVycyAgb24gdGhlIHBhdGguIE9uIHRoZSBzaWRlLCBhbmQgaW4gb3JkZXIg
dG8gYWxsb3cgdGhlIHJldXNlIG9mIGluc3RhbmNlICBJRCwgdGhlIG9yaWdpbiBtdXN0IGJlIHN1
cmUgdGhhdCBhbGwgc3RhdGVzIGZvciBhIHByZXZpb3VzIHVzYWdlIG9mIHRoZSAgc2FtZSB2YWx1
ZSBhcmUgZ29uZS4gU28gd2UgbmVlZCBhIGNsZWFyIGNvbnRyb2wgLyBuZWdvdGlhdGlvbiBvZiB0
aGUgIGxpZmV0aW1lcyBvbiB0aGUgc3RhdGVzIHRoYXQgY29tZSB3aXRoIGFuIGluc3RhbmNlSUQu
IEFnYWluIHRoaXMgaXMgbm90ICBjbGVhciBlbm91Z2ggaW4gdGhlIHNwZWMuDQoNCg0KDQogW1Bh
c2NhbDJdDQogMikgU2FtZSBxdWVzdGlvbiBpZiB5b3Ugd2FudCB0byBjcmVhdGUgc3RhdGVzIGF0
IHRoZSB0YXJnZXQgdG8gcm91dGUgIGJhY2suIEhvdyBsb25nIGRvZXMgdGhlIHRhcmdldCBuZWVk
IHRvIG1haW50YWluIHRoZSByb3V0ZT8gV2hvIGNvbnRyb2xzICB0aGF0LCB0aGUgb3JpZ2luIG9y
IHRoZSB0YXJnZXQ/IEknZCBleHBlY3QgdG8gZmluZCBhIHN1Z2dlc3RlZCBsaWZldGltZSAgaW4g
dGhlIFJETyB3aXRoIGEgY29uZmlybWF0aW9uIGluIHRoZSBEUk8gdG8gbGV0IHRoZSB0YXJnZXQg
YW1lbmQgaXQuDQoNCiBbTXVrdWwyXQ0KIElmIHRoZSB0YXJnZXQgd2FudHMgRFJPLUFDSyBpdCBu
ZWVkcyB0byBtYWludGFpbiBzdGF0ZSB1bnRpbCBEUk8tQUNLIGlzICByZWNlaXZlZC4gT3RoZXJ3
aXNlLCB0aGUgdGFyZ2V0IG5lZWRzIHRvIHJlbWVtYmVyIHRoaW5ncyB1bnRpbCBpdCBpcyAgZG9u
ZSBzZW5kaW5nIGFsbCB0aGUgRFJPcy4gSSB3aWxsIGFkZCB0aGUgdGV4dCB0byB0aGlzIGVmZmVj
dC4NCg0KIFtQYXNjYWwzXQ0KIElmIHlvdSBhcmUgc2V0dGluZyB1cCBhIHNob3J0IHRlcm0gY29u
dmVyc2F0aW9uLCBob3cgbG9uZyBleGFjdGx5IGlzICB0aGF0IGJlZm9yZSB0aGUgb3JpZ2luIGhh
cyB0byByZWZyZXNoIHRoZSByb3V0ZT8gV2hhdCBjb250cm9scyBjbGVhbiB1cCAgaW4gYm90aCBz
aWRlcz8gVXN1YWxseSB5b3Ugd2FudCBhIGxpZmV0aW1lIChzZWUgTUlQNiBmb3IgaW5zdGFuY2Up
DQoNCiBbTXVrdWwzXQ0KIElzIGl0IHRoYXQgeW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSBsaWZl
dGltZSBvZiB0aGUgaG9wLWJ5LWhvcCByb3V0aW5nICBzdGF0ZT8gVGhhdCBpcyBzcGVjaWZpZWQg
aW4gdGhlIGxpZmUgdGltZSBwYXJhbWV0ZXJzIGluIHRoZSBET0RBRyAgY29uZmlndXJhdGlvbiBv
cHRpb24uIFRoZSBkcmFmdCBzYXlzIHRoYXQgb24gcGFnZSA5IHdoaWxlIGRlc2NyaWJpbmcgaG93
ICB0aGUgRE9EQUcgY29uZmlndXJhdGlvbiBvcHRpb24gc2hvdWxkIGJlIHNldCBpbnNpZGUgYSBQ
MlAgbW9kZSBESU86DQoNCiAiVGhlIERlZmF1bHQgTGlmZXRpbWUgYW5kIExpZmV0aW1lIFVuaXQg
cGFyYW1ldGVycyBpbiBET0RBRw0KICAgICAgQ29uZmlndXJhdGlvbiBvcHRpb24gaW5kaWNhdGUg
dGhlIGxpZmUgdGltZSBvZiB0aGUgc3RhdGUgdGhlDQogICAgICByb3V0ZXJzIG1haW50YWluIGZv
ciBhIGhvcC1ieS1ob3Agcm91dGUgZXN0YWJsaXNoZWQgdXNpbmcgUDJQLVJQTA0KICAgICAgYW5k
IG1heSBiZSBzZXQgYXMgZGVzaXJlZC4NCiAiDQoNCiBbUGFzY2FsNF0gTWF5YmUgdGhhdCdzIHNv
IGJ1dCB0aGVuIHlvdSBuZWVkIHRvIHJld29yZCBhIGxpdHRsZSBiaXQgY2F1c2UgIHlvdSBnb3Qg
bWUgcWl1dGUgY29uZnVzZWQuIEkndmUgYmVlbiB0YWxraW5nIG9mIHRoZSBsaWZldGltZSBvZiB0
aGUgIHN0YXRlcyBhdCBvcmlnaW4gYW5kIHRhcmdldCBmb3Igb25lIGNvbnZlcnNhdGlvbi4gU2lu
Y2UgdGhleSBtaWdodCBiZSAgaGF2aW5nIGEgdHJhbnNpZW50IGNvbnZlcnNhdGlvbiwgYW5kIHRo
ZSBvcmlnaW4gbWlnaHQgcmV1c2UgdGhlIGluc3RhbmNlICBJRCBzb29uLCB5b3UgbmVlZCB0byBn
aXZlIGEgbGltaXQgaW4gdGltZSB0byB0aGUgc3RhdGVzIHRoYXQgeW91IGFyZSAgY3JlYXRpbmcu
IFN0aWxsIHRoYXQgY29udmVyc2F0aW9uIGlzIGxvbmdlciB0aGFuIHRoZSBzdGF0ZXMgaW4gdGhl
ICBpbnRlcm1lZGlhdGUgcm91dGVycy4gU28geW91IGhhdmUgMiBsaWZldGltZXMgYW5kIHlvdSBo
YXZlIHRvIGJlIHZlcnkgIGNsZWFyIHdoaWNoIGlzIHdoaWNoLiBQZXJzb25hbGx5LCBJJ2QgaGF2
ZSB1c2VkIHRoZSBsaWZldGltZSBpbiB0aGUgIGNvbmZpZ3VyYXRpb24gb3B0aW9uIGZvciBhbGwg
dGhlIHJvdXRlcnMgb24gdGhlIHdheSBhbmQgSSdkIGhhdmUgdXNlZCAgdGhlIG5ldyBsaWZldGlt
ZSBpbiB0aGUgUkRPIGFzIHRoZSBjb252ZXJzYXRpb24gbGlmZXRpbWUgaW4gdGhlIGVuZCAgcG9p
bnRzIGJlY2F1c2U6DQogMSkgIHRoYXQgaXMgdGhlIG5ldyBjb25jZXB0Lg0KIDIpIFRoaXMgd291
bGQgYWxsb3cgdGhlIHRhcmdldCB0byBjb25maXJtIGV4YWN0bHkgaG93IGxvbmcgaXQgbG9ja3Mg
IHJlc291cmNlcywNCiAzKSBhbmQgdGhpcyB3b3VsZCBiZSBtb3JlIGNvbXBhdGlibGUgd2l0aCB0
aGUgZGVzY3JpcHRpb24gb2YgdGhlIGNvbmZpZyAgb3B0aW9uIGluIFJGQyA2NTUwLg0KDQogW011
a3VsNF0NCiBUaGVyZSBhcmUgdHdvIGxpZmV0aW1lczoNCiAxKSBMaWZldGltZSBvZiB0aGUgdGVt
cG9yYXJ5IERBRzogdGhpcyBpcyBzcGVjaWZpZWQgaW5zaWRlIFAyUC1SRE8NCiAyKSBMaWZldGlt
ZSBvZiB0aGUgcm91dGluZyBzdGF0ZSBmb3IgdGhlIGhvcC1ieS1ob3Agcm91dGUgZXN0YWJsaXNo
ZWQgIHVzaW5nIFAyUC1SUEw6IHRoaXMgaXMgc3BlY2lmaWVkIGluc2lkZSB0aGUgRE9EQUcgY29u
ZmlndXJhdGlvbiBvcHRpb24uDQogQWxsIHJvdXRlcnMgb24gdGhlIGVzdGFibGlzaGVkIHJvdXRl
IChpbmNsdWRpbmcgdGhlIG9yaWdpbikgbWFpbnRhaW4gIHN0YXRlIGZvciB0aGlzIHJvdXRlIGZv
ciB0aGlzIG11Y2ggdGltZS4gVGhpcyB0aW1lIGNvdWxkIHZlcnkgd2VsbCBiZSAgaW5maW5pdHku
DQoNCiBOb3csIGxldHMgdGFsayBhYm91dCB0aGUgInN0YXRlcyBhdCBvcmlnaW4gYW5kIHRhcmdl
dCIuIFRoZSBvcmlnaW4gYW5kICB0aGUgdGFyZ2V0IG1haW50YWluIHRoZSBzdGF0ZSBhYm91dCB0
aGUgdGVtcG9yYXJ5IERBRyBmb3IgdGhlIERBRydzIGxpZmUgIHRpbWUuIFRoaXMgaXMgdHJ1ZSBm
b3IgYWxsIHRoZSBub2RlcyB0aGF0IGpvaW4gdGhpcyBEQUcuIEFsbCBzdWNoIG5vZGVzICBtYWlu
dGFpbiBzdGF0ZSBhYm91dCB0aGUgdGVtcG9yYXJ5IERBRyB1bnRpbCB0aGUgREFHJ3MgbGlmZSB0
aW1lIGlzICBvdmVyLiBJdCBpcyB0cnVlIHRoYXQgdGhlIHRhcmdldCBhbmQgdGhlIG9yaWdpbiBl
eGNoYW5nZSBEUk9zIGFuZCAgRFJPLUFDS3MgYW5kIHRoaXMgZXhjaGFuZ2UgY291bGQgY29uY2Vp
dmFibHkgZ28gb24gZXZlbiBhZnRlciB0aGUgIHRlbXBvcmFyeSBEQUcncyBkZW1pc2UuIEhvdyBs
b25nIHNob3VsZCB0aGUgb3JpZ2luIGFuZCB0YXJnZXQgaW5kdWxnZSBpbiAgdGhpcyBleGNoYW5n
ZSAoYW5kIGhlbmNlIHJlbWVtYmVyIHRoZSBwb3NzaWJseSBkZWFkIERBRyk/IEkgdGhpbmsgaXQg
aXMgIHB1cmVseSB0aGVpciBjaG9pY2UgYW5kIHRoZSBkcmFmdCBuZWVkIG5vdCBpbXBvc2UgYW55
IGFydGlmaWNpYWwgdGltZSAgbGltaXQgb24gdGhpcy4NCg0KIFBhc2NhbA0KDQotLSANCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJl
cG9ydGVyOiAganB2QOKApiAgICAgICAgICAgICAgICAgIHwgICAgICBPd25lcjogIG11a3VsQOKA
pg0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICB8ICAgICBTdGF0dXM6ICBuZXcN
CiBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICAgfCAgTWlsZXN0b25lOg0KQ29tcG9u
ZW50OiAgcDJwLXJwbCAgICAgICAgICAgICAgICB8ICAgIFZlcnNpb246DQogU2V2ZXJpdHk6ICBT
dWJtaXR0ZWQgV0cgRG9jdW1lbnQgIHwgICBLZXl3b3JkczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0
cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC90cmFjL3RpY2tldC84NT4NCnJvbGwgPGh0
dHA6Ly90b29scy5pZXRmLm9yZy93Zy9yb2xsLz4NCg0K

From c.chauvenet@watteco.com  Tue Apr 10 09:28:11 2012
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 7AF6E11E80EA for ; Tue, 10 Apr 2012 09:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvvfnhmxMNrz for ; Tue, 10 Apr 2012 09:28:10 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 281E811E80BE for ; Tue, 10 Apr 2012 09:28:09 -0700 (PDT)
Received: from mail119-am1-R.bigfish.com (10.3.201.231) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 16:28:08 +0000
Received: from mail119-am1 (localhost [127.0.0.1])	by mail119-am1-R.bigfish.com (Postfix) with ESMTP id 03FD94400FD; Tue, 10 Apr 2012 16:28:09 +0000 (UTC)
X-SpamScore: -75
X-BigFish: VPS-75(zzc89bh15caKJ1453Mzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h93fhd25h)
X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI
Received: from mail119-am1 (localhost.localdomain [127.0.0.1]) by mail119-am1 (MessageSwitch) id 1334075287416386_16182; Tue, 10 Apr 2012 16:28:07 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.230])	by mail119-am1.bigfish.com (Postfix) with ESMTP id 58F392A00CE; Tue, 10 Apr 2012 16:28:07 +0000 (UTC)
Received: from AMXPRD0510HT005.eurprd05.prod.outlook.com (157.56.248.181) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 16:28:06 +0000
Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.57.40]) with mapi id 14.16.0135.002; Tue, 10 Apr 2012 16:28:06 +0000
From: C Chauvenet 
To: 'Mukul Goyal' 
Thread-Topic: [Roll] [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4?
Thread-Index: AQHNExt2WB0Ei/9t6USXDGCl+MKLpJaMPEqwgAUul4CAAtuWQA==
Date: Tue, 10 Apr 2012 16:28:05 +0000
Message-ID: <97B69B30E0EF244B940B65EA541E3F2D0221AE47@AMXPRD0510MB390.eurprd05.prod.outlook.com>
References: <97B69B30E0EF244B940B65EA541E3F2D02216532@AMXPRD0510MB390.eurprd05.prod.outlook.com> <1380616773.1851920.1333917935800.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <1380616773.1851920.1333917935800.JavaMail.root@mail17.pantherlink.uwm.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.4.8]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: "roll@ietf.org" 
Subject: Re: [Roll] [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4?
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, 10 Apr 2012 16:28:11 -0000

U2VlIGlubGluZSwNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBNdWt1bCBH
b3lhbCBbbWFpbHRvOm11a3VsQHV3bS5lZHVdIA0KRW52b3nDqcKgOiBkaW1hbmNoZSA4IGF2cmls
IDIwMTIgMjI6NDYNCsOAwqA6IEMgQ2hhdXZlbmV0DQpDY8KgOiByb2xsQGlldGYub3JnOyBqcHZA
Y2lzY28uY29tDQpPYmpldMKgOiBSZTogW1JvbGxdIFtyb2xsXSAjOTM6IEEgc2luZ2xlIFAyUC1S
UEwgaW52b2NhdGlvbiBjYW4gZGlzY292ZXJ5IHVwdG8gNCBzb3VyY2Ugcm91dGVzLiBXaHkgND8N
Cg0KUGxlYXNlIHNlZSBpbmxpbmUgKG5vdGUgdGhlIGNoYW5nZWQgdGl0bGUgb2YgdGhpcyB0aWNr
ZXQpDQoNClRoYW5rcw0KTXVrdWwNCg0KDQojOTM6IFdoZXRoZXIgUDJQLVJQTCBzaG91bGQgc3Vw
cG9ydCBlc3RhYmxpc2htZW50IG9mIGEgYmFja3dhcmQgaG9wLWJ5LWhvcCByb3V0ZT8NCg0KIFJl
c29sdXRpb246IE9wZW4NCg0KIERpc2N1c3Npb246DQoNCiBwMTIgOiAgVGhpcyBzcGVjaWZpY2F0
aW9uIGRvZXMgbm90IGFsbG93IGZvciB0aGUgZXN0YWJsaXNobWVudCBvZiBob3AtYnktICBob3Ag
cm91dGVzIGluIHRoZSBiYWNrd2FyZCBkaXJlY3Rpb24uDQoNCiBbQ2VkcmljXQ0KIFdoeSA/IFRo
aXMgd291bGQgZW5hYmxlIHRvIGVzdGFibGlzaCAyIHJvdXRlcyB3aXRoaW4gYSBzaW5nbGUgcm91
dGUgIHJlcXVlc3QuDQogRnVydGhlcm1vcmUsIHlvdSBzdGlwdWxhdGVzIGluIHRoZSBkcmFmdCB0
aGF0IGxpbmtzIGhhdmUgdG8gYmUgIGJpZGlyZWN0aW9uYWwgdG8gcHJvcGFnYXRlcyBSRE8sIGlu
IG9yZGVyIHRvIGJlIGFibGUgdG8gc2VuZCBiYWNrIHRoZSBEUk8uDQogU28gaWYgSSB1bmRlcnN0
YW5kIGl0IGNvcnJlY3RseSB5b3UgZW5zdXJlIHRoYXQgeW91IGhhdmUgYSByZWxpYWJsZSBwYXRo
ICBpbiBib3RoIHdheXMuIFdoeSB1c2luZyBpdCBpbiBhIHNpbmdsZSB3YXkgb25seSA/DQoNCiBb
TXVrdWxdDQogU3VwcG9zZSBhIERSTyBlc3RhYmxpc2hpbmcgYSBmb3J3YXJkIGhvcC1ieS1ob3Ag
cm91dGUgZmFpbHMgdG8gbWFrZSBpdCB0byAgdGhlIG9yaWdpbi4gSW4gdGhpcyBjYXNlLCBhbGwg
d2UgaGF2ZSBpcyBzb21lIG5vZGVzIHN0b3JpbmcgdGhlIGhvcC1ieS1ob3AgIHN0YXRlIGZvciBh
IGJyb2tlbiByb3V0ZSBidXQgdGhhdCByb3V0ZSBpcyBuZXZlciB1c2VkIHNpbmNlIHRoZSBvcmln
aW4gIG5ldmVyIGdldHMgdGhlIERSTy4gT24gdGhlIG90aGVyIGhhbmQsIGlmIHRoZSBEUk8gZXN0
YWJsaXNoaW5nIGEgYmFja3dhcmQgIGhvcC1ieS1ob3Agcm91dGUgZmFpbHMgdG8gbWFrZSBpdCB0
byB0aGUgb3JpZ2luLCB3ZSBoYXZlIGEgYnJva2VuIHJvdXRlICB0aGF0IHRoZSB0YXJnZXQgaXMg
bGlrZWx5IHRvIHVzZSAodG8gcmVhY2ggdGhlIG9yaWdpbikuIFNvLCBpZiB3ZSB3YW50ICBQMlAt
UlBMIHRvIGVzdGFibGlzaCBhIGJhY2t3YXJkIGhvcC1ieS1ob3Agcm91dGUsIHRoZSB0YXJnZXQg
TVVTVCBhc2sgZm9yICBhIERSTy1BQ0sgZnJvbSB0aGUgb3JpZ2luICh0byBtYWtlIHN1cmUgdGhh
dCB0aGUgRFJPIGRvZXMgcmVhY2ggdGhlIG9yaWdpbiAgYW5kIGhlbmNlIHRoZSBiYWNrd2FyZCBy
b3V0ZSBpcyBub3QgYnJva2VuKS4gVGhpcyBjYW4gYmUgZG9uZSBpZiB5b3UgdGhpbmsgIGl0IHdp
bGwgYmUgdXNlZnVsLiBXZSBkaWQgbm90IGluY2x1ZGUgdGhpcyBpbiBQMlAtUlBMIGJlY2F1c2Ug
d2UgZGlkIG5vdCAgaGF2ZSBhIHVzZWNhc2UgZm9yIGJhY2t3YXJkIGhvcC1ieS1ob3Agcm91dGVz
IGFuZCB3ZSB3YW50ZWQgdG8gYXZvaWQgdGhlICBhZGRpdGlvbmFsIGNvbXBsZXhpdHkuDQoNCiBU
aGlzIGlzIGhvdyB3ZSBjYW4gaW1wbGVtZW50IHRoaXMgZnVuY3Rpb25hbGl0eTogd2Ugd2lsbCBs
ZXQgdGhlIHRhcmdldCAgZGVjaWRlIHdoZXRoZXIgaXQgd2FudHMgdGhlIERSTyB0byBlc3RhYmxp
c2ggYSBiYWNrd2FyZCBob3AtYnktaG9wIHJvdXRlLg0KIEluIHRoYXQgY2FzZToNCiAxKSB0aGUg
dGFyZ2V0IHdpbGwgc2V0IGEgbmV3IGZsYWcsIHRoZSBCIGZsYWcgKEIgZm9yIGJhY2t3YXJkIGhv
cC1ieS1ob3AgIHJvdXRlKSwgaW5zaWRlIHRoZSBEUk8gdG8gbGV0IGludGVybWVkaWF0ZSByb3V0
ZXJzIGtub3cgdGhhdCBiYWNrd2FyZCAgcm91dGUgc3RhdGUgbmVlZHMgdG8gYmUgZXN0YWJsaXNo
ZWQgYXMgd2VsbDsNCiAyKSB0aGUgdGFyZ2V0IHdpbGwgc2V0IHRoZSBBIGZsYWcgdG8gcmVxdWly
ZSBhIERSTy1BQ0sgZnJvbSB0aGUgb3JpZ2luOw0KIDMpIHRoZSB0YXJnZXQgd2lsbCBzcGVjaWZ5
IChpbnNpZGUgYSBuZXcgZmllbGQgaW4gdGhlIERSTyksIGFuICBSUExJbnN0YW5jZUlEIHVuZGVy
IHdoaWNoIHRoZSBob3AtYnktaG9wIHN0YXRlIGZvciB0aGUgYmFja3dhcmQgcm91dGUgd2lsbCAg
YmUgc3RvcmVkLiBOb3RlIHRoYXQgdGhlIFJQTEluc3RhbmNlSUQgb2YgdGhlIGZvcndhcmQgcm91
dGUgKHNlbGVjdGVkIGJ5ICB0aGUgb3JpZ2luKSBtYXkgbm90IGJlIE9LIGZvciB1c2UgaW4gYmFj
a3dhcmQgcm91dGUgKGJlY2F1c2UgdGhlIHRhcmdldCAgbWF5IGhhdmUgYWxyZWFkeSB1c2VkIHRo
aXMgUlBMSW5zdGFuY2VJRCBmb3IgYW5vdGhlciBob3AtYnktaG9wIHJvdXRlLCAgdXNpbmcgZGlm
ZmVyZW50IHJvdXRpbmctbWV0cmljcy9jb25zdHJhaW50cy9PRiwgdG8gdGhlIG9yaWdpbikuDQog
V2hlbiB0aGUgaW50ZXJtZWRpYXRlIHJvdXRlcnMgcmVjZWl2ZSB0aGlzIERSTywgdGhleSB3aWxs
IHN0b3JlIHRoZSBob3AtICBieS1ob3Agc3RhdGUgZm9yIHRoZSBiYWNrd2FyZCByb3V0ZS4gVGhp
cyBob3AtYnktaG9wIHN0YXRlIHdpbGwgY29uc2lzdA0KIG9mOg0KIDEpIFRhcmdldCBhZGRyZXNz
ICh0YWtlbiBmcm9tIFAyUC1SRE8gaW5zaWRlIHRoZSBEUk8pLg0KIDIpIFJQTEluc3RhbmNlSUQg
c3BlY2lmaWVkIGJ5IHRoZSB0YXJnZXQNCiAzKSBUaGUgZGVzdGluYXRpb24sIGkuZS4sIHRoZSBv
cmlnaW4gYWRkcmVzcyAoc2FtZSBhcyBET0RBR0lEIGluc2lkZSB0aGUgIERSTykuDQoNCiBEbyB5
b3Ugd2FudCB0aGlzIGZ1bmN0aW9uYWxpdHk/DQoNCltDZWRyaWMyXSANClRoZSBncm91cCBoYXMg
dG8gZGlzY3VzcyBhbmQgZGVjaWRlIHdldGhlciBpdCBpcyB1c2VmdWxsIG9yIG5vdC4gSSBwZXJz
b25uYWx5IHRoaW5rIHRoYXQgUlBMLVAyUCBkcmFmdCBtYXkgYmUgdXNlZCBmb3IgYmluZGluZyBk
ZXZpY2VzLCBzbyBpdCBjb3VsZCBiZSB2YWx1YWJsZSB0byBjcmVhdGUgYSAyIHdheSBwYXRoIGJl
dHdlZW4gdGhlIG9yaWdpbiBhbmQgdGhlIHRhcmdldC4gU28gSSB3b3VsZCB2b3RlIGluIGZhdm9y
IG9mIHN1Y2ggYSBtZWNoYW5pc20uIA0KVGhvdWdoLCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBj
cmVhdGUgYSBuZXcgREFHIChpLmUuIHNlbGVjdCBhIG5ldyBSUExJbnN0YW5jZUlEKSBmb3IgdGhl
IGJhY2t3YXJkIHJvdXRlLiBXaGF0IEkgd291bGQgbGlrZSBpcyBqdXN0IHRoZSBhYmlsaXR5IGZv
ciAyIGRldmljZXMgdG8gZXhjaGFuZ2UgcGFja2V0IGluIGJvdGggd2F5cyB1c2luZyB0aGUgc2Ft
ZSB0ZW1wb3JhcnkgREFHIGNyZWF0ZWQgYnkgUlBMLVAyUC4gTGV0IG1lIGV4cGxhaW4gdGhlIHVz
ZSBjYXNlIHdpdGggYW4gZXhhbXBsZSA6IEZvciBpbnN0YW5jZSwgaWYgeW91IGhhdmUgbm9kZXMg
ZGVwbG95ZWQgaW4gYSBidWlsZGluZyBvciBhIGNpdHksIGFuZCB5b3Ugd2FudCB0byBjb25maWd1
cmUgc29tZSBvZiB0aGVtLiBBbiBvcGVyYXRvciBjb3VsZCBnbyBpbiB0aGUgYXJlYSB3aGVyZSBk
ZXZpY2VzIHRvIGJlIHByb2dyYW1tZWQgYXJlIGluc3RhbGxlZCAob3IgaW4gdGhlIG5laWdoYm9y
aG9vZCBhdCBsZWFzdCkgd2l0aCBhICJjb25maWd1cmF0b3Igbm9kZSIsIGFuZCBuZWVkIHRvIGVz
dGFibGlzaGVkIGEgUDJQIHJvdXRlIGJldHdlZW4gdGhpcyBjb25maWd1cmF0b3Igbm9kZSBhbmQg
dGhlIG5vZGUocykgdG8gYmUgY29uZmlndXJhdGVkLiBUaGV5IGNyZWF0ZSBhIHRlbXBvcmFyeSBE
QUcgKHBvc3NpYmx5IHRocm91Z2ggc2V2ZXJhbCBob3BzKSBhbmQgZXhjaGFuZ2UgY29uZmlndXJh
dGlvbiBmcmFtZXMuIEJlY2F1c2Ugc3VjaCBtZXNzYWdlcyBhcmUgIGNyaXRpY2FsbHkgaW1wb3J0
YW50LCB5b3Ugb2Z0ZW4gbmVlZCBhcHBsaWNhdGlvbiBsYXllciBhY2tub3dsZWRnbWVudHMsIHNv
IGEgYmFja3dhcmQgcm91dGUgaXMgbmVlZGVkLg0KSXMgdGhlIGFjdHVhbCBzcGVjaWZpY2F0aW9u
IGNvbXBsaWFudCB3aXRoIHN1Y2ggYSB1c2UgY2FzZSB3aXRob3V0IG1vZGlmaWNhdGlvbiA/ICh1
c2luZyBwaWdneWJhY2tlZCBEQVRBIGluc2lkZSBSRE8gYW5kIERSTyBtZXNzYWdlcykgPyBPciBk
byB3ZWUgbmVlZCBhbiBhZGRpdGlvbmFsIG1lY2hhbmlzbSBzdWNoIGFzIHRoZSBvbmUgeW91IGRl
c2NyaWJlZCA/DQoNCltNdWt1bDJdDQpUaGUgdGFyZ2V0IGNhbiBhbHdheXMgdXNlIHRoZSByb3V0
ZSBpbnNpZGUgYSByZWNlaXZlZCBQMlAtUkRPIHRvIHNvdXJjZS1yb3V0ZSBhIG1lc3NhZ2UgKGUu
Zy4gYW4gYXBwbGljYXRpb24gbGV2ZWwgYWNrKSBiYWNrIHRvIHRoZSBvcmlnaW4uIEFsc28sIGFz
IHlvdSBub3RpY2VkLCB0aGUgdGFyZ2V0IGNhbiBwbGFjZSBvbmUgb3IgbW9yZSBkYXRhIG9wdGlv
bnMgaW5zaWRlIHRoZSBEUk8gdG8gc2VuZCBhbiBhcHBsaWNhdGlvbiBsZXZlbCBtZXNzYWdlIGJh
Y2sgdG8gdGhlIG9yaWdpbi4gU28sIHRoZSB1c2UgY2FzZSB5b3UgaGF2ZSBtZW50aW9uZWQgKHdo
aWNoIGlzLCBieSB0aGUgd2F5LCBhIGNvbW1vbiB1c2UgY2FzZSBpbiBjb21tZXJjaWFsIGJ1aWxk
aW5nIGVudmlyb25tZW50KSBpcyBzdXBwb3J0ZWQgYnkgY3VycmVudCBQMlAtUlBMIHNwZWNpZmlj
YXRpb24uIEluIG15IHZpZXcsIG5vIGFkZGl0aW9uYWwgbWVjaGFuaXNtIGlzIHJlcXVpcmVkIGlm
IHRoZSBpbnRlbnQgaXMgdG8ganVzdCBzdXBwb3J0IHRoZSB1c2VjYXNlIHlvdSBkZXNjcmliZWQu
IEluZmFjdCwgd2UgY291bGQgbm90IGNvbWUgdXAgd2l0aCBhIHVzZWNhc2Ugd2hlcmUgYmFja3dh
cmQgaG9wLWJ5LWhvcCByb3V0ZXMgYXJlIGFic29sdXRlbHkgbXVzdC4gU28sIHdlIGRlY2lkZWQg
dG8ga2VlcCB0aGUgc3BlY3Mgc2ltcGxlIGJ5IG5vdCBhbGxvd2luZyBlc3RhYmxpc2htZW50IG9m
IHN1Y2ggcm91dGVzLiBBbHNvLCBjdXJyZW50bHkgd2UgYXJlIHNob290aW5nIGZvciBhbiBleHBl
cmltZW50YWwgUkZDLiBJZiwgYXQgYSBsYXRlciBzdGFnZSwgd2UgcmVhbGl6ZSB0aGF0IGJhY2t3
YXJkIGhvcC1ieS1ob3Agcm91dGVzIGFyZSBuZWNlc3NhcnksIHdlIGNvdWxkIHN1cHBvcnQgdGhl
bSBpbiBzdGFuZGFyZHMgdHJhY2sgUkZDLiANCg0KW0NlZHJpYzNdDQpPaywgdGhlIGRhdGEgb3B0
aW9uIHNlZW1zIHNpbXBsZSBhbmQgZWZmaWNpZW50IGVub3VnaCBmb3IgdGhlIHVzZSBjYXNlIEkg
cG9pbnRlZCBvdXQuDQpMZXQncyBrZWVwIGl0IGFzIHRoZSBkZWZhdWx0IG9wdGlvbiB0byBkbyBz
aW1wbGUgUDJQIGRhdGEgZXhjaGFuZ2UuDQpJZiBtb3JlIHBlcmlvZGljIGFuZCByZWxpYWJsZSB0
cmFmZmljIGlzIG5lZWRlZCBiZXR3ZWVuIDIgbm9kZXMgaW4gYSBSUEwgbmV0d29yaywgdGhlbiBJ
IHRoaW5rIHdlIHNob3VsZCBpbmNsdWRlIGEgMiB3YXkgcGF0aCBlc3RhYmxpc2htZW50Lg0KIA0K
DQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KIFJlcG9ydGVyOiAganB2QOKApiAgICAgICAgICAgICAgICAgIHwgICAgICBPd25l
cjogIG11a3VsQOKApg0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICB8ICAgICBT
dGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICAgfCAgTWlsZXN0
b25lOg0KQ29tcG9uZW50OiAgcDJwLXJwbCAgICAgICAgICAgICAgICB8ICAgIFZlcnNpb246DQog
U2V2ZXJpdHk6ICBTdWJtaXR0ZWQgV0cgRG9jdW1lbnQgIHwgICBLZXl3b3JkczoNCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaWNr
ZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC90cmFjL3RpY2tldC85
Mz4NCnJvbGwgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9yb2xsLz4NCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpS
b2xsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwN
Cg0K


From c.chauvenet@watteco.com  Tue Apr 10 09:32:24 2012
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 8CA3C21F856F for ; Tue, 10 Apr 2012 09:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500,  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 1+qMON1O88k8 for ; Tue, 10 Apr 2012 09:32:23 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7F00C21F856A for ; Tue, 10 Apr 2012 09:32:14 -0700 (PDT)
Received: from mail130-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 16:32:13 +0000
Received: from mail130-va3 (localhost [127.0.0.1])	by mail130-va3-R.bigfish.com (Postfix) with ESMTP id 6A1D03C0522; Tue, 10 Apr 2012 16:32:13 +0000 (UTC)
X-SpamScore: -73
X-BigFish: VPS-73(z4b6Kzc89bh15caKJzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h93fhd25h)
X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT002.eurprd05.prod.outlook.com; RD:none; EFVD:NLI
Received: from mail130-va3 (localhost.localdomain [127.0.0.1]) by mail130-va3 (MessageSwitch) id 1334075530918515_8769; Tue, 10 Apr 2012 16:32:10 +0000 (UTC)
Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.254])	by mail130-va3.bigfish.com (Postfix) with ESMTP id D8BA3100095; Tue, 10 Apr 2012 16:32:10 +0000 (UTC)
Received: from AMXPRD0510HT002.eurprd05.prod.outlook.com (157.56.248.181) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 16:32:09 +0000
Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT002.eurprd05.prod.outlook.com ([10.255.57.37]) with mapi id 14.16.0143.004; Tue, 10 Apr 2012 16:32:07 +0000
From: C Chauvenet 
To: 'Mukul Goyal' 
Thread-Topic: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
Thread-Index: AQHNEx32hh4lWAafiEaDmA/VlsX0qpaMTC1wgAUtcwCAAs5AkA==
Date: Tue, 10 Apr 2012 16:32:07 +0000
Message-ID: <97B69B30E0EF244B940B65EA541E3F2D0221AE6D@AMXPRD0510MB390.eurprd05.prod.outlook.com>
References: <97B69B30E0EF244B940B65EA541E3F2D022166C5@AMXPRD0510MB390.eurprd05.prod.outlook.com> <1278156449.1852161.1333921106641.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <1278156449.1852161.1333921106641.JavaMail.root@mail17.pantherlink.uwm.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.4.8]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: "roll@ietf.org" 
Subject: Re: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
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, 10 Apr 2012 16:32:24 -0000

SW5saW5lLA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IE11a3VsIEdveWFs
IFttYWlsdG86bXVrdWxAdXdtLmVkdV0gDQpFbnZvecOpwqA6IGRpbWFuY2hlIDggYXZyaWwgMjAx
MiAyMzozOA0Kw4DCoDogQyBDaGF1dmVuZXQNCkNjwqA6IHJvbGxAaWV0Zi5vcmc7IGpwdkBjaXNj
by5jb20NCk9iamV0wqA6IFJlOiBbUm9sbF0gW3JvbGxdICM5NTogV2h5IG5lZWQgc3RvcCBmbGFn
PyBJcyB0aGUgcmVjZWlwdCBvZiBEUk8gbm90IHN1ZmZpY2llbnQgdG8gaW5kaWNhdGUgY29tcGxl
dGlvbiBvZiByb3V0ZSBkaXNjb3Zlcnk/DQoNCkhpIENlZHJpYw0KDQpQbGVhc2Ugc2VlIHRoZSBy
ZXNwb25zZSBpbmxpbmUuDQoNClRoYW5rcw0KTXVrdWwNCg0KDQojOTU6IFdoeSBuZWVkIHN0b3Ag
ZmxhZz8gSXMgdGhlIHJlY2VpcHQgb2YgRFJPIG5vdCBzdWZmaWNpZW50IHRvIGluZGljYXRlIGNv
bXBsZXRpb24gb2Ygcm91dGUgZGlzY292ZXJ5Pw0KDQogUmVzb2x1dGlvbjogTm8gYmVjYXVzZSBt
dWx0aXBsZSBEUk9zIHdvdWxkIGJlIGdlbmVyYXRlZCBpZiBtdWx0aXBsZSBzb3VyY2UgIHJvdXRl
cyBhcmUgYmVpbmcgZGlzY292ZXJlZC4NCg0KIERpc2N1c3Npb246DQoNCiBwMTUgOiAgU3RvcCAo
Uyk6IFRoaXMgZmxhZywgd2hlbiBzZXQgdG8gb25lIGJ5IGEgdGFyZ2V0LCBpbmRpY2F0ZXMgdGhh
dCAgdGhlIFAyUC1SUEwgcm91dGUgZGlzY292ZXJ5IGlzIG92ZXIuDQoNCiBbQ2VkcmljXQ0KIElz
IHRoaXMgYml0IHJlYWxseSB1c2VmdWxsID8gTXkgZ3Vlc3MgaXMgdGhhdCBpdCB3aWxsIGJlIGFs
d2F5cyBzZXQgdG8gMS4NCiBJZiB5b3UgaGVhciBhIERSTywgdGhpcyBpbmRlZWQgbWVhbnMgdGhh
dCB0aGUgUkRPIGhhcyByZWFjaGVkIHRoZSB0YXJnZXQsICBzbyB5b3UgY291bGQganVzdCBzdG9w
IHByb2Nlc3NpbmcgUkRPIHdoZW4geW91IGhlYXIgYSBEUk8uDQogRG8gd2UgcmVhbGx5IG5lZWQg
YSBmbGFnIHRvIHN0b3AgUkRPIHByb2Nlc3Npbmcgb3IgdGhlIGhlYXJpbmcgb2YgYSBEUk8gIHR5
cGUgbWVzc2FnZSBjb3VsZCBkbyB0aGUgam9iID8NCg0KIFtNdWt1bF0NCiBBIFAyUC1SUEwgaW52
b2NhdGlvbiBtaWdodCBpbnZvbHZlIGRpc2NvdmVyeSBvZiBtdWx0aXBsZSBzb3VyY2Ugcm91dGVz
LiBJbiAgdGhhdCBjYXNlLCByZWNlaXB0IG9mIGEgRFJPIGRvZXMgbm90IG1lYW4gcm91dGUgZGlz
Y292ZXJ5IGlzIG92ZXIuIE9ubHkgIHdoZW4gdGhlIHRhcmdldCBzZXRzIHRoZSBzdG9wIGZsYWcg
aW4gdGhlIERSTywgYSBub2RlIGNvdWxkIGJlIHN1cmUgdGhhdCAgdGhlIHJvdXRlIGRpc2NvdmVy
eSBpcyBvdmVyLg0KDQpbQ2VkcmljMl0NCk9LIGZvIG11bHRpcGxlIGRpc2NvdmVyeS4NCkJ1dCBp
ZiBJIHdhbnQgdG8gZGlzY292ZXIgYSByb3V0ZSB0byBhIG11bHRpY2FzdCBncm91cCBvZiB0YXJn
ZXQuIEkgc2V0IGEgbXVsdGljYXN0IGFkcmVzcyBpbiB0aGUgdGFyZ2V0IGZpZWxkIG9mIHRoZSBS
RE8uIFRoZW4sIGRvIEkgcmVjZWl2ZWQgYXMgbWFueSBEUk8gbWVzc2FnZSBhcyB0aGUgbnVtYmVy
IG9mIHRhcmdldCByZWFjaGVkID8gSW4gdGhhdCBjYXNlLCB3b3VsZCB0aGUgZmlyc3QgRFJPIHdp
dGggYSAiUyIgZmxhZyBzdG9wIHRoZSBSRE8gcHJvcGFnYXRpb24gdG8gcmVhY2ggYWxsIHRoZSB0
YXJnZXQgaW5jbHVkZWQgaW4gdGhlIG11bHRpY2FzdCBncm91cCA/DQoNCltNdWt1bDJdDQpBIHRh
cmdldCBjYW5ub3Qgc2V0IHRoZSBTIGZsYWcgdG8gb25lIGluIHRoZSBEUk8gaWYgdGhlIHRhcmdl
dCBhZGRyZXNzIGluIHRoZSBQMlAtUkRPIHNwZWNpZmllZCBhIG11bHRpY2FzdCBhZGRyZXNzLiBT
ZWUgdGhlIGZvbGxvd2luZyB0ZXh0IGF0IHRoZSBlbmQgb2YgcGFnZSAyMSBpbiBQMlAtUlBMLTk6
DQoNCiJUaGUgdGFyZ2V0IE1BWSBzZXQgdGhlIHN0b3AgZmxhZyBpbnNpZGUgdGhlIERSTyBtZXNz
YWdlIHRvIG9uZSBpZg0KDQoNCg0KR295YWwsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBTZXB0
ZW1iZXIgNywgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMjFdDQogDQpJbnRlcm5ldC1EcmFmdCAg
ICAgICAgIGRyYWZ0LWlldGYtcm9sbC1wMnAtcnBsLTA5ICAgICAgICAgICAgIE1hcmNoIDIwMTIN
Cg0KDQogICBvICB0aGlzIHJvdXRlciBpcyB0aGUgb25seSB0YXJnZXQgc3BlY2lmaWVkIGluIHRo
ZSBjb3JyZXNwb25kaW5nIERJTywNCiAgICAgIGkuZS4sIHRoZSBjb3JyZXNwb25kaW5nIERJTyBz
cGVjaWZpZWQgYSB1bmljYXN0IGFkZHJlc3Mgb2YgdGhlDQogICAgICByb3V0ZXIgYXMgdGhlIFRh
cmdldCBpbnNpZGUgdGhlIFAyUC1SRE8gd2l0aCBubyBhZGRpdGlvbmFsIHRhcmdldHMNCiAgICAg
IHNwZWNpZmllZCB2aWEgUlBMIFRhcmdldCBPcHRpb25zOyBhbmQNCg0KIiANCg0KW0NlZHJpYzNd
IA0KU28gaG93IGRvIHlvdSBzdG9wIHRoZSBSRE8gZmxvb2Rpbmcgd2hlbiB0aGUgdGFyZ2V0IGFk
cmVzcyBpcyBtdWxpY2FzdCA/IA0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAganB2QOKApiAgICAgICAg
ICAgICAgICAgIHwgICAgICBPd25lcjogIG11a3VsQOKApg0KICAgICBUeXBlOiAgZGVmZWN0ICAg
ICAgICAgICAgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1ham9yICAgICAg
ICAgICAgICAgICAgfCAgTWlsZXN0b25lOg0KQ29tcG9uZW50OiAgcDJwLXJwbCAgICAgICAgICAg
ICAgICB8ICAgIFZlcnNpb246DQogU2V2ZXJpdHk6ICBTdWJtaXR0ZWQgV0cgRG9jdW1lbnQgIHwg
ICBLZXl3b3JkczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcv
d2cvcm9sbC90cmFjL3RpY2tldC85NT4NCnJvbGwgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9y
b2xsLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
ClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3JvbGwNCg0K


From c.chauvenet@watteco.com  Tue Apr 10 09:35:04 2012
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 41C3C11E80BE for ; Tue, 10 Apr 2012 09:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.749
X-Spam-Level: 
X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 8dyeBUrqL1Gm for ; Tue, 10 Apr 2012 09:35:03 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9437C21F856A for ; Tue, 10 Apr 2012 09:35:02 -0700 (PDT)
Received: from mail20-am1-R.bigfish.com (10.3.201.241) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 16:35:01 +0000
Received: from mail20-am1 (localhost [127.0.0.1])	by mail20-am1-R.bigfish.com (Postfix) with ESMTP id 9973B4800F7; Tue, 10 Apr 2012 16:35:01 +0000 (UTC)
X-SpamScore: -75
X-BigFish: VPS-75(zzc89bh1418M15caKJzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h93fhd25h)
X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI
Received: from mail20-am1 (localhost.localdomain [127.0.0.1]) by mail20-am1 (MessageSwitch) id 1334075698995051_1321; Tue, 10 Apr 2012 16:34:58 +0000 (UTC)
Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.237])	by mail20-am1.bigfish.com (Postfix) with ESMTP id E5D4D3C0045; Tue, 10 Apr 2012 16:34:58 +0000 (UTC)
Received: from AMXPRD0510HT004.eurprd05.prod.outlook.com (157.56.248.181) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 16:34:58 +0000
Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT004.eurprd05.prod.outlook.com ([10.255.57.39]) with mapi id 14.16.0135.002; Tue, 10 Apr 2012 16:34:57 +0000
From: C Chauvenet 
To: 'Mukul Goyal' 
Thread-Topic: [Roll] [roll] #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs?
Thread-Index: AQHNEx3z89ZP4AFw/0ivhS+8MCKZOpaMSO8AgAU6WICAAsXSAA==
Date: Tue, 10 Apr 2012 16:34:57 +0000
Message-ID: <97B69B30E0EF244B940B65EA541E3F2D0221AE9F@AMXPRD0510MB390.eurprd05.prod.outlook.com>
References: <97B69B30E0EF244B940B65EA541E3F2D02216681@AMXPRD0510MB390.eurprd05.prod.outlook.com> <1226828832.1852306.1333923179020.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <1226828832.1852306.1333923179020.JavaMail.root@mail17.pantherlink.uwm.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.4.8]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: "roll@ietf.org" 
Subject: Re: [Roll] [roll] #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs?
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, 10 Apr 2012 16:35:04 -0000

aW5saW5lLA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IE11a3VsIEdveWFs
IFttYWlsdG86bXVrdWxAdXdtLmVkdV0gDQpFbnZvecOpwqA6IGx1bmRpIDkgYXZyaWwgMjAxMiAw
MDoxMw0Kw4DCoDogQyBDaGF1dmVuZXQNCkNjwqA6IHJvbGxAaWV0Zi5vcmc7IGpwdkBjaXNjby5j
b20NCk9iamV0wqA6IFJlOiBbUm9sbF0gW3JvbGxdICM5NjogQ2FuIHRoZSBkcmFmdCByZWNvbW1l
bmQgaG93IG11Y2ggdG8gd2FpdCBiZWZvcmUgYSB0YXJnZXQgc2VsZWN0cyByb3V0ZXMgdG8gYmUg
c2VudCBiYWNrIGluIERST3M/DQoNCkhpIENlZHJpYw0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0K
VGhhbmtzDQpNdWt1bA0KDQojOTY6IENhbiB0aGUgZHJhZnQgcmVjb21tZW5kIGhvdyBtdWNoIHRv
IHdhaXQgYmVmb3JlIGEgdGFyZ2V0IHNlbGVjdHMgcm91dGVzIHRvIGJlIHNlbnQgYmFjayBpbiBE
Uk9zPw0KDQogUmVzb2x1dGlvbjogVGhpcyBpcyBwdXJlbHkgYSBsb2NhbCBkZWNpc2lvbiBhdCB0
aGUgdGFyZ2V0LiBUaGUgZHJhZnQgIHNob3VsZCBub3QgbWFrZSBhbnkgcmVjb21tZW5kYXRpb24g
aW4gdGhpcyByZWdhcmQuDQoNCiBEaXNjdXNzaW9uOg0KDQogcDIxIDogIEV4YW1wbGUgbWV0aG9k
cyBpbmNsdWRlIHNlbGVjdGluZyBlYWNoIHJvdXRlIHRoYXQgbWVldHMgdGhlICBzcGVjaWZpZWQg
cm91dGluZyBjb25zdHJhaW50cw0KICAgdW50aWwgdGhlIGRlc2lyZWQgbnVtYmVyIGhhdmUgYmVl
biBzZWxlY3RlZCBvciBzZWxlY3RpbmcgdGhlIGJlc3QNCiAgIHJvdXRlcyBkaXNjb3ZlcmVkIG92
ZXIgYSBjZXJ0YWluIHRpbWUgcGVyaW9kLg0KDQogW0NlZHJpY10NCiBIb3cgY291bGQgd2Uga25v
dyB0aGUgdGltZSB0byB3YWl0IHVudGlsIHdlIGdldCBhbGwgdGhlIFJETyA/DQogSXMgdGhlcmUg
YSB3YXkgdG8gZXZhbHVhdGUgaXQgYWNjb3JkaW5nIHRvIHNvbWUgcGFyYW1ldGVycyByZWxhdGVk
IHRvIHRoZSAgbmV0d29yayAoZGlhbWV0ZXIgb2YgdGhlIG5ldHdvcmsgZm9yIGluc3RhbmNlKSA/
DQoNCiBbTXVrdWxdIFRoaXMgaGFzIHRvIGJlIGEgbG9jYWwgZGVjaXNpb24uIFBlcmhhcHMsIHRo
ZSB0YXJnZXQgY2FuIGxvb2sgYXQgIHRoZSBhZ2dyZWdhdGVkIHZhbHVlcyBvZiB0aGUgcm91dGlu
ZyBtZXRyaWNzIGZyb20gdGhlIG9yaWdpbiBhbmQgZGV0ZXJtaW5lICBpdHMgZGlzdGFuY2UgZnJv
bSB0aGUgb3JpZ2luLiBUaGlzIGRpc3RhbmNlIGVzdGltYXRlLCBhbG9uZyB3aXRoIHRyaWNrbGUg
IHBhcmFtZXRlcnMsIGNvdWxkIHBlcmhhcHMgZ2l2ZSBpdCBhIGJldHRlciBpZGVhIG9mIGhvdyBt
dWNoIHRvIHdhaXQuIEkgIGRvbnQgdGhpbmsgdGhhdCB0aGUgZHJhZnQgc2hvdWxkIHRhbGsgYWJv
dXQgdGhpcy4NCg0KW0NlZHJpYzJdDQpPSywgbGV0J3Mgc2F5IGl0IGlzIHVwIHRvIHRoZSBpbXBs
ZW1lbnRhdGlvbiBhbmQgc2hvdWxkIGJlIGRldGVyaW5pZWQgYWNjb3JkaW5nIHRvIHRoZSBzcGVj
aWZpYyBzZXQgb2YgbWV0cmljL2NvbnRyYWludHMgaW4gdXNlLg0KQSB0YXJnZXQgZnJvbSBhIERB
RyBiYXNlZCBvbiBhIGxhdGVuY3kgbWV0cmljIGNvdWxkIHdhaXQganVzdCBhIGZldyBtcyBhZnRl
ciByZWNlaXZpbmcgdGhlIGZpcnN0IFJETyAgYW5kIHNlbGVjdCB0aGUgYmVzdCBwYXRoIGFjY29y
ZGluZyB0byB0aGUgbGF0ZW5jeSBtZXRyaWMuDQpBIHRhcmdldCBmcm9tIGEgREFHIGJhc2VkIG9u
IGEgZW5lcmd5IG1ldHJpYyBjb3VsZCB3YWl0IG11Y2ggbW9yZSB0aW1lIGFmdGVyIHJlY2Vpdmlu
ZyB0aGUgZmlyc3QgUkRPIHRvIGJlIHN1cmUgdG8gdXNlIGFuIGVuZXJneSBlZmZpY2llbnQgcGF0
aCwgdGhhdCBjb3VsZCBiZSBkaXNjb3ZlcmVkIGFmdGVyIHNvbWUgdGltZSwgYmVjYXVzZSBvZiBk
dXR5IGN5Y2xpbmcgbm9kZXMgZm9yIGluc3RhbmNlLg0KDQpbTXVrdWwyXSBDaG9vc2luZyB0aGUg
d2FpdCB0aW1lIG9uIHRoZSBiYXNpcyBvZiBzcGVjaWZpYyBtZXRyaWNzIGJlaW5nIHVzZWQgaW4g
cm91dGUgZGlzY292ZXJ5IGNvdWxkIGJlIG9uZSBvcHRpb24uIEhvd2V2ZXIsIHdoZW4gYW4gb3Jp
Z2luIHdhbnRzIHRvIGRpc2NvdmVyIGxvdyBsYXRlbmN5IHJvdXRlcywgaXQgZG9lcyBub3QgbmVj
ZXNzYXJpbHkgbWVhbiB0aGF0IHRoZSBsYXRlbmN5IG9mIHRoZSByb3V0ZSBkaXNjb3ZlcnkgcHJv
Y2VzcyBoYXMgdG8gYmUgbG93IGFzIHdlbGwuIDopIFNvLCBpbiBnZW5lcmFsLCBJIHRoaW5rIHRo
YXQgdGhlIHRpbWUgYSB0YXJnZXQgd2FpdHMgYmVmb3JlIHNlbmRpbmcgRFJPcyAod2hpY2ggZGV0
ZXJtaW5lcyB0byBzb21lIGV4dGVudCB0aGUgbGF0ZW5jeSBvZiB0aGUgcm91dGUgZGlzY292ZXJ5
IHByb2Nlc3MpIGlzIGluZGVwZW5kZW50IG9mIHRoZSBzcGVjaWZpYyBtZXRyaWNzL2NvbnN0cmFp
bnRzIGJlaW5nIHVzZWQgaW4gcm91dGUgZGlzY292ZXJ5IHByb2Nlc3MuIEFzIEkgc2FpZCBiZWZv
cmUsIEkgdGhpbmsgdGhlIHRhcmdldCBzaG91bGQgZGVjaWRlIGZvciBpdHNlbGYgaG93IG11Y2gg
c2hvdWxkIGl0IHdhaXQgYmVmb3JlIHNlbmRpbmcgRFJPKHMpLiBJdCBtYXkgbm90IGJlIHdpc2Ug
dG8gbWFrZSBhbnkgc3VnZ2VzdGlvbnMgaW4gdGhpcyByZWdhcmQgaW4gdGhlIFAyUC1SUEwgc3Bl
Y3MgYmV5b25kIHdoYXQgdGhlIGRyYWZ0IGFscmVhZHkgc2F5cyAtIHRoZSBkcmFmdCBkb2VzIHN1
Z2dlc3QgdHdvIHNhbXBsZSBtZXRob2RzOiAxKSBzZWxlY3Qgcm91dGVzIG9uIEZDRlMgYmFzaXMg
MikgY2hvb3NlIHRoZSBiZXN0IHJvdXRlcyBkaXNjb3ZlcmVkIG92ZXIgYW4gaW50ZXJ2YWwuIA0K
DQpbQ2VkcmljM10NClllcyBnb29kIHBvaW50LiBTbyBJIHRoaW5rIHRoZSBkcmFmdCBpcyBnZW5l
cmljIGVub3VnaCByZWdhcmRpbmcgdGhpcyBwYXJhbWV0ZXIuICANCg0KLS0gDQotLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRl
cjogIGpwdkDigKYgICAgICAgICAgICAgICAgICB8ICAgICAgT3duZXI6ICBtdWt1bEDigKYNCiAg
ICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJp
b3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAgIHwgIE1pbGVzdG9uZToNCkNvbXBvbmVudDog
IGFwcGxpY2FiaWxpdHktYW1pICAgICAgfCAgICBWZXJzaW9uOg0KIFNldmVyaXR5OiAgU3VibWl0
dGVkIFdHIERvY3VtZW50ICB8ICAgS2V5d29yZHM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90
cmFjLnRvb2xzLmlldGYub3JnL3dnL3JvbGwvdHJhYy90aWNrZXQvOTY+DQpyb2xsIDxodHRwOi8v
dG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQoNCg==


From pal@cs.stanford.edu  Tue Apr 10 11:46:37 2012
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 CBCF711E812F for ; Tue, 10 Apr 2012 11:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.058
X-Spam-Level: 
X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=0.542,  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 EpYU+9l+dvEJ for ; Tue, 10 Apr 2012 11:46:37 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9899921F845C for ; Tue, 10 Apr 2012 11:46:36 -0700 (PDT)
Received: from dn5221c4.sunet ([10.33.5.132]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SHg5K-0000IV-So; Tue, 10 Apr 2012 11:46:34 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: 
Date: Tue, 10 Apr 2012 11:46:35 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9ED438F4-2555-4D00-971F-146002F01266@cs.stanford.edu>
References:  <3B42E04B-7DFB-4C42-83C5-4ED72B3AC8A6@cs.stanford.edu> 
To: Pascal Thubert (pthubert) 
X-Mailer: Apple Mail (2.1257)
X-Scan-Signature: b65b8f26ca423de213f14dca1c6ea011
Cc: roll@ietf.org
Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.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: Tue, 10 Apr 2012 18:46:38 -0000

On Apr 9, 2012, at 11:10 PM, Pascal Thubert (pthubert) wrote:

> Phil:
>=20
> It's not.=20
> If I switch a device with another from a different vendor I should
> expect the new device to interact properly with existing devices and I
> should expect globally a similar behavior in my network.=20
> That's what standards are for.

Disagree -- otherwise there is no room for improvement. What if all TCP =
implementations had globally a similar behavior to TCP pre-Van Jacobson? =
The purpose of a standard to specify the behavior that is necessary for =
correct interoperation, not complete and total behavior. This is =
ESPECIALLY true in a case where it's a new and growing area; it's a bit =
of hubris to assume you know and can specify exactly how everything =
should work.

Phil=

From prvs=440167eea=mukul@uwm.edu  Tue Apr 10 16:58:50 2012
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 821A011E811A for ; Tue, 10 Apr 2012 16:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.564
X-Spam-Level: 
X-Spam-Status: No, score=-5.564 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
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 ofUeDoJI573b for ; Tue, 10 Apr 2012 16:58:49 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 12DE611E810C for ; Tue, 10 Apr 2012 16:58:48 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApAGAOHIhE9/AAAB/2dsb2JhbABEhWaxZ4R/AQEFI1YMDxEEAQEDAg0WAwJICQgGExmHdQunQYoUiQmBL4lvhQiBGASIWo0SgRGPJYMFgTYBFg
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 3998F1FD0B8; Tue, 10 Apr 2012 18:58:48 -0500 (CDT)
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 1K28R35gYzbZ; Tue, 10 Apr 2012 18:58:47 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 83CE11FD0BE; Tue, 10 Apr 2012 18:58:47 -0500 (CDT)
Date: Tue, 10 Apr 2012 18:58:47 -0500 (CDT)
From: Mukul Goyal 
To: "Pascal Thubert (pthubert)" 
Message-ID: <994990080.1886442.1334102327422.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.91]
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] [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
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, 10 Apr 2012 23:58:50 -0000

Hi Pascal

>I do not wish to change the DAG lifetime.

>I'm pointing out that the conversation between the origin and target canno=
t work longer than the lifetime of the "hop-by-hop routing states" which it=
 depends on. So why not use that?

You mean state about the "temporary DAG" and not the hop-by-hop state for t=
he "discovered route"? They are two different things.

>I suggest that we converge the time duration specified in DODAG configurat=
ion option to mean the maximum duration of states in all nodes that need to=
 keep states, including origin and target, and in some case intermediate ro=
uters.

We are using the time duration in DODAG configuration option to specify the=
 lifetime of the "hop-by-hop state for the discovered route" (and not the l=
ifetime of the "temporary DAG"). A discovered HbH route may need to be main=
tained for a wide range of time durations. Hence, we would like to specify =
the lifetime of a discovered route using the rich semantics provided by the=
 time duration fields inside the DODAG configuration option. On the other h=
and, the lifetime of a temporary DAG does not need to vary a whole lot. So,=
 we provide 4 options for this lifetime (1, 4, 16 and 64 seconds) and speci=
fy this lifetime in a 2-bit field inside P2P-RDO.

Do you agree with how the two lifetimes (lifetime of DAG and lifetime of th=
e discovered route) are specified in P2P-RPL?

>IOW, if the HbH route is used, the lifetime in the config option is for al=
l states in all nodes on the path(s) including origins and target(s). If Hb=
H routing is not used, the lifetime in the config option is still valid for=
 the source and the origin. You may define a default value that suit classi=
cal P2P routes in the case where no config of any sort is provided.=20

You seem to want the config option to specify the lifetime of the temporary=
 DAG. This would be a wastage of rich semantic provided by those fields. If=
 you could agree to specifying the temporary DAG lifetime inside P2P-RDO (t=
he way P2P-RPL currently does), I see no problem whatsoever. All nodes (inc=
luding the origin and target) joining the temporary DAG maintain state for =
the temporary DAG (which is not same as the state for the discovered HbH ro=
ute) for the duration specified in P2P-RDO. We could further require that a=
ll DRO/DRO-ACK exchange MUST complete within the temporary DAG lifetime (sp=
ecified inside P2P-RDO). So, the temporary DAG's lifetime has to be chosen =
carefully. Having said that, I still prefer giving origin and target extra =
time (equal to one more lifetime) to complete DRO/DRO-ACK exchange.

Thanks
Mukul

>And yes, great point, you'd need to specify that the lifetime in the confi=
g option must be large enough to accommodate the retransmissions.

>Do we converge?

>Pascal


-----Original Message-----
From: Mukul Goyal [mailto:mukul@uwm.edu]=20
Sent: mardi 10 avril 2012 14:55
To: Pascal Thubert (pthubert)
Cc: jpv@cisco.com; roll
Subject: Re: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

OR the simpler option would be to require DRO/DRO-ACK exchange to complete =
within the DAG's life time? If we were to specify a new parameter for the t=
ime limit on DRO/DRO-ACK exchange, both target and origin would need to agr=
ee on the value of this parameter.

Mukul

----- Original Message -----
From: "Mukul Goyal" 
To: "Pascal Thubert (pthubert)" 
Cc: jpv@cisco.com, "roll" 
Sent: Tuesday, April 10, 2012 7:50:16 AM
Subject: Re: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Hi Pascal

Hopefully we are talking about the same thing.

>No, it's not closed. We are talking about a contract between lower layers =
in all nodes including the source and origin to maintain necessary resource=
s and all contracts must have a lifetime.

1. A node that joins a temporary P2P-RPL DAG maintains state for the DAG fo=
r the time duration specified as DAG life time.
2. A node that establishes hop-by-hop routing state for a route discovered =
using P2P-RPL maintains this state for the time duration specified in DODAG=
 configuration option.

Origin and target need to exchange DROs and DRO-ACKs. I could specify a new=
 configurable parameter to specify the time limit on this exchange. This pa=
rameter's value  has to be more than DAG life time. One option is to specif=
y it in terms of existing parameters: DAG life time + (MAX_DRO_RETRANSMISSI=
ONS + 1)*DRO_ACK_WAIT_TIME.

Thanks
Mukul
----- Original Message -----
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
Cc: jpv@cisco.com
Sent: Tuesday, April 10, 2012 4:45:46 AM
Subject: RE: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Hi Mukul,

No, it's not closed. We are talking about a contract between lower layers i=
n all nodes including the source and origin to maintain necessary resources=
 and all contracts must have a lifetime.
I do not mind you overload the RPL lifetime of the routing for the states a=
t origin and target and if you have a sentence that makes it clear then we'=
ll be in agreement.

Cheers,

Pascal


-----Original Message-----
From: Mukul Goyal [mailto:mukul@uwm.edu]=20
Sent: dimanche 8 avril 2012 17:52
To: Pascal Thubert (pthubert)
Cc: jpv@cisco.com
Subject: Re: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Pascal

Can we consider this issue closed? Please see my last response.

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" 
To: mukul@UWM.EDU, jpv@cisco.com
Cc: roll@ietf.org
Sent: Wednesday, April 4, 2012 8:06:30 AM
Subject: [roll] #85: which lifetime is for the end points (origin and targe=
t) vs. intermediate nodes.

#85: which lifetime is for the end points (origin and target) vs. intermedi=
ate nodes.

 Problem (currently open)
 ------------------------------
 P2P creates temporary states in the transient DAG and less-but-still  temp=
orary states in the endpoints. These are 2 different lifetimes. The  spec h=
as 2 lifetimes, one in the config option and one in the RDO. The  spec is n=
ot sufficiently clear about which is which. In can appear to be  conflictin=
g since the config option is supposed to apply to all routers  on the path.=
 On the side, and in order to allow the reuse of instance  ID, the origin m=
ust be sure that all states for a previous usage of the  same value are gon=
e. So we need a clear control / negotiation of the  lifetimes on the states=
 that come with an instanceID. Again this is not  clear enough in the spec.



 [Pascal2]
 2) Same question if you want to create states at the target to route  back=
. How long does the target need to maintain the route? Who controls  that, =
the origin or the target? I'd expect to find a suggested lifetime  in the R=
DO with a confirmation in the DRO to let the target amend it.

 [Mukul2]
 If the target wants DRO-ACK it needs to maintain state until DRO-ACK is  r=
eceived. Otherwise, the target needs to remember things until it is  done s=
ending all the DROs. I will add the text to this effect.

 [Pascal3]
 If you are setting up a short term conversation, how long exactly is  that=
 before the origin has to refresh the route? What controls clean up  in bot=
h sides? Usually you want a lifetime (see MIP6 for instance)

 [Mukul3]
 Is it that you are talking about the lifetime of the hop-by-hop routing  s=
tate? That is specified in the life time parameters in the DODAG  configura=
tion option. The draft says that on page 9 while describing how  the DODAG =
configuration option should be set inside a P2P mode DIO:

 "The Default Lifetime and Lifetime Unit parameters in DODAG
      Configuration option indicate the life time of the state the
      routers maintain for a hop-by-hop route established using P2P-RPL
      and may be set as desired.
 "

 [Pascal4] Maybe that's so but then you need to reword a little bit cause  =
you got me qiute confused. I've been talking of the lifetime of the  states=
 at origin and target for one conversation. Since they might be  having a t=
ransient conversation, and the origin might reuse the instance  ID soon, yo=
u need to give a limit in time to the states that you are  creating. Still =
that conversation is longer than the states in the  intermediate routers. S=
o you have 2 lifetimes and you have to be very  clear which is which. Perso=
nally, I'd have used the lifetime in the  configuration option for all the =
routers on the way and I'd have used  the new lifetime in the RDO as the co=
nversation lifetime in the end  points because:
 1)  that is the new concept.
 2) This would allow the target to confirm exactly how long it locks  resou=
rces,
 3) and this would be more compatible with the description of the config  o=
ption in RFC 6550.

 [Mukul4]
 There are two lifetimes:
 1) Lifetime of the temporary DAG: this is specified inside P2P-RDO
 2) Lifetime of the routing state for the hop-by-hop route established  usi=
ng P2P-RPL: this is specified inside the DODAG configuration option.
 All routers on the established route (including the origin) maintain  stat=
e for this route for this much time. This time could very well be  infinity=
.

 Now, lets talk about the "states at origin and target". The origin and  th=
e target maintain the state about the temporary DAG for the DAG's life  tim=
e. This is true for all the nodes that join this DAG. All such nodes  maint=
ain state about the temporary DAG until the DAG's life time is  over. It is=
 true that the target and the origin exchange DROs and  DRO-ACKs and this e=
xchange could conceivably go on even after the  temporary DAG's demise. How=
 long should the origin and target indulge in  this exchange (and hence rem=
ember the possibly dead DAG)? I think it is  purely their choice and the dr=
aft need not impose any artificial time  limit on this.

 Pascal

--=20
-----------------------------------+---------------------
 Reporter:  jpv@=E2=80=A6                  |      Owner:  mukul@=E2=80=A6
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: 
roll 


From prvs=441eb7f02=mukul@uwm.edu  Tue Apr 10 18:39:09 2012
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 2694E11E8143 for ; Tue, 10 Apr 2012 18:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.177
X-Spam-Level: 
X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=0.422,  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 el4jdBoDniT7 for ; Tue, 10 Apr 2012 18:39:08 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3125B11E811A for ; Tue, 10 Apr 2012 18:39:08 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAFXghE9/AAAB/2dsb2JhbABEhWa2ZgEBAQQBAQEgSwsMDxEEAQEDAg0WAwIpHwkIBhMZh3ULpzyKDokJgS+JZIUTgRgEiFqNEoERjyWDBYE2Fw
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id A8BB21FD0BC; Tue, 10 Apr 2012 20:39:06 -0500 (CDT)
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 WfcfGMXIt0bU; Tue, 10 Apr 2012 20:39:06 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 1D3A81FD0B8; Tue, 10 Apr 2012 20:39:06 -0500 (CDT)
Date: Tue, 10 Apr 2012 20:39:03 -0500 (CDT)
From: Mukul Goyal 
To: "Pascal Thubert (pthubert)" 
Message-ID: <1728662895.1887339.1334108343320.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.91]
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] #90: use of transient instance ID
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, 11 Apr 2012 01:39:09 -0000

Hi Pascal

>I meant a suggestion, not a capitalized word. I prefer the suggestion but =
I'm still OK with your proposal. If we get in agreement on the lifetime of =
the states (issue #85), then you can indicate that lifetime is one way to d=
etermine when all stale states can be considered gone.

Sounds good.

>Also, when there are no routing states in intermediate routers, an indicat=
ion from upper layers can be used in the end points to consider that all st=
ates for an instanceID are now cleaned up.

Not sure what you mean.=20

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" , roll@ietf.org
Sent: Tuesday, April 10, 2012 4:52:50 AM
Subject: RE: [Roll] [roll] #90: use of transient instance ID

Mukul:

I meant a suggestion, not a capitalized word. I prefer the suggestion but I=
'm still OK with your proposal. If we get in agreement on the lifetime of t=
he states (issue #85), then you can indicate that lifetime is one way to de=
termine when all stale states can be considered gone. Also, when there are =
no routing states in intermediate routers, an indication from upper layers =
can be used in the end points to consider that all states for an instanceID=
 are now cleaned up.

Cheers,

Pascal


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Muk=
ul Goyal
Sent: dimanche 8 avril 2012 18:09
To: roll@ietf.org
Subject: Re: [Roll] [roll] #90: use of transient instance ID

Hi Pascal

Re-read your proposed resolution text. I am not sure that the draft should =
suggest rotating the instance ids. My proposed resolution is to simply sugg=
est not using instance id that might be in use.

" [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD
 NOT) against reusing instance ids for which the stale state might exist  i=
n the nodes."

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" 
To: mukul@UWM.EDU, jpv@cisco.com
Cc: roll@ietf.org
Sent: Wednesday, April 4, 2012 8:11:44 AM
Subject: [roll] #90: use of transient instance ID

#90: use of transient instance ID

 Problem (resolution agreed upon)
 ------------------------------
 P2P creates temporary states in the transient DAG with a transient  instan=
ce ID. The protocol must ensure that if the instance ID is reused  then the=
 new operation it is not confused with states resulting from the  previous =
use of the same instance ID. Suggestion is to propose a  rotation.

 Discussion
 -------------

 [Pascal]
 "RPLInstanceID: RPLInstanceID MUST be a local value as described in  Secti=
on 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the same  RPLInstanc=
eID in two or more concurrent route discoveries."

 I'd suggest that you enforce a round robin or an opaque circulation so  th=
at the new instanceID is the least recently used one out of the 64  possibl=
e.

 [Mukul]
 I think we should leave it to the origin to decide which value it wants  t=
o use for RPLInstanceID. I know some implementations are planning to  use a=
 fixed RPLInstanceID value for all route discoveries.

 [Pascal2] Changing the instance ID will help debug the network and avoid  =
conflicts with stale states. What's really up to the device is the  initial=
 sequence. Leaving it up to the origin may help the origin defeat  some att=
acks to some degree. OTOH, after all the instances have been  played, LRU f=
orces to replay the same sequence again so the shield  drops. My preferred =
approach would be a SHOULD that would say that the  next instance ID SHOULD=
 NOT be one of the (16?) most recently used and  MUST NOT be one for which =
states might still exist in the network. IOW  either the states deletion wa=
s acknowledged, or all pending lifetimes  are exhausted.

 [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD
 NOT) against reusing instance ids for which the stale state might exist  i=
n the nodes. Using a "MUST NOT" may not be OK since a node may never be  10=
0% sure about non-existence of stale state with a particular instance  id (=
thus, all possible instance id values will become suspect and hence  unusab=
le after a while).

 [Pascal3] Agreed. Note that a circulation is a bonus to defeat replays.
 And now we're back to the issue above. How does the device know that  ther=
e is no state left? A lifetime definition would be very useful. That  lifet=
ime is different from the DAG's one in RDO. I think we have an open  issue =
here.

 [Mukul3] As I mentioned above, the life time parameters inside the DODAG  =
configuration option specify the life time of the hop-by-hop routing  state=
 for the routes discovered using P2P-RPL.

 [Pascal4] This boils down to the thread above. Only one issue really,  whi=
ch lifetime is which? So IMHO no need to log anything for this  thread.

 [Mukul4] OK.

 Pascal

--=20
-----------------------------------+---------------------
 Reporter:  jpv@=E2=80=A6                  |      Owner:  mukul@=E2=80=A6
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: 
roll 

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

From prvs=441eb7f02=mukul@uwm.edu  Tue Apr 10 19:51:31 2012
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 037E321F8692 for ; Tue, 10 Apr 2012 19:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.108
X-Spam-Level: 
X-Spam-Status: No, score=-5.108 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 FldjpWa3uQMN for ; Tue, 10 Apr 2012 19:51:29 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2951F21F8688 for ; Tue, 10 Apr 2012 19:51:27 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAHrwhE9/AAAB/2dsb2JhbABDhXO2byNPBzUCDRkCWQaIIatqihCBIYEviW+FCIEYBIhajRKQNoMFgTYBFg
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 623FE12E3BE; Tue, 10 Apr 2012 21:51:26 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu
Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpoN7sU3QAQK; Tue, 10 Apr 2012 21:51:25 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id D6B6812E3BD; Tue, 10 Apr 2012 21:51:25 -0500 (CDT)
Date: Tue, 10 Apr 2012 21:51:25 -0500 (CDT)
From: Mukul Goyal 
To: JP Vasseur 
Message-ID: <723690941.1887908.1334112685750.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <2058618921.1887387.1334108747023.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.91]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Cc: roll , Michael Richardson 
Subject: [Roll] Closure text for ticket #86
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, 11 Apr 2012 02:51:31 -0000

#86: G flag: do we need that text?

Problem
------------------------------
 Disagreement on the meaning of 'G' bit and imposed setting to 0;

Proposed resolution
---------------------------
Add the following text to the draft:

"The origin sets the G flag to indicate the relative importance of the route discovery it is initiating. The G flag is set to one if this particular route discovery is more important from application's perspective than some other route discovery. In other words, the origin sets the G flag to one if this particular route discovery helps meet the application defined goal \cite{rpl}. Thus, the G flag setting helps an intermediate router choose which route discoveries to participate in if it cannot participate in all route discoveries. An intermediate router SHOULD participate in route discoveries with G flag set to one (in preference to ones with G flag set to zero)."

Discussion:
-----------------

 [Pascal]
 " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in
 nature, is created solely for the purpose of P2P-RPL route discovery and
 MUST NOT be used for packet routing."

 On the contrary I'd set it to 1. The goal -being to reach the origin- is
 actually achieved by this DAG.

 [Mukul]
 Actually, the DAG is temporary in nature and vanishes after a short
 while. Even when it exists, it must/should not be used for routing
 packets back to the origin. So, I think the Grounded flag should be
 zero.

 [Pascal2] Please revisit RFC 6650 page 12.
 G means that a goal is achieved. So first you define the goal and then
 the bit becomes obvious. What's your goal?
 Can there be P2P DAGs that achieve the goal and others that make sense
 to build and yet do not achieve the goal?
 If you accept that your operation can actually depend on OF logic, then
 the setting of the goal influences that logic.
 By forcing a value to the goal in the PTP spec, we actually limit the
 applicability of the draft.
 Maybe you can define a default goal and a default setting. But do not
 MUST that it is set to 0...

 [Mukul2]
 When a node joins a temporary P2P DAG, it does not get any additional
 routing information. The DAG is going to disappear after some time,
 should not be used for routing while it exists and which nodes end up
 being on the discovered route is not known until the DRO message comes
 back. So, I think, by default, the G flag has to be zero. However, if
 the setting of G flag may affect how an intermediate node may calculate
 its rank (as per the OF being used), the origin should have the
 flexibility of setting the flag to 1. So, I could modify the text to say
 that "the origin sets the G flag based on its perception of how the
 flag's value would affect the rank calculation under the OF being used.
 By default, the G flag is set to zero given the temporary nature of the
 DAG being created."

 [Pascal3] Why do you feel the need to add anything above what RFC 6550
 says? I do not see any benefit or additional clarity from doing this.

 [Mukul3] RFC 6550 is actually kind of confusing in this regard. On page
 9, it says

 "A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data)."

 This seems to associate the goal with both OF and reachability to
 certain hosts. Later invocations of the term "goal" seem to refer just
 to the connectivity aspect, e.g., on page 18 RFC 6550 says

 "A grounded DODAG offers connectivity to hosts that are
   required for satisfying the application-defined goal."

 So, my understanding so far was that the "goal" defines connectivity to
 a certain hosts. The relation to objective function is not clear at all
 (if one restricts oneself to reading RFC 6550). The temporary DAGs
 created in P2P-RPL route discovery provide no connectivity whatsoever to
 the joining nodes. So, the only reason to set the G flag to 1 would be
 to allow correct use of an OF. So, I think P2P-RPL spec should use the
 text I offered above (and repeat below):

 "The origin sets the G flag based on its perception of whether joining
 how the flag's value would affect the rank calculation under the OF
 being used. By default, the G flag is set to zero given the temporary
 nature of the DAG being created."

 What do you think?

 [Pascal4] If you think this adds value, I will not oppose. Let's keep
 that as the proposed resolution

 [Mukul4] Sounds good.

Proposed resolution text:

"The origin sets the G flag based on its perception of whether joining
 how the flag's value would affect the rank calculation under the OF
 being used. By default, the G flag is set to zero given the temporary
 nature of the DAG being created."

[Richard5]
I disagree with the proposed resolution.  It adds needless confusion.
The G flag is 0 if and only if the DODAG is floating.
There is no point to allowing floating DODAGs with a P2P-RDO option.  I suggest that the G bit be set to 1 and that routers be explicitly prohibited from creating floating DODAGs with a P2P-RDO option.

[Mukul5]
>The G flag is 0 if and only if the DODAG is floating.

I think that the G flag is 1 if and only if the DODAG is grounded. The temporary DAGs used in P2P-RPL are not grounded, they are temporary. I think that all transient/temporary DAGs are floating by their very nature.

[Michael5]
> I think we need to determine what a grounded DODAG is.
> Does it mean that a node announcing such a thing is attached to the Internet? (In which case P2P usage should G=0)
> Or does it mean that a node is attached to the resource named in the DIO? (In which case origin P2P should G=1)
> 

[Phillip5]
The text in 6550 is pretty clear: 

   Goal: The Goal is an application-specific goal that is defined
         outside the scope of RPL.  Any node that roots a DODAG will
         need to know about this Goal to decide whether or not the Goal
         can be satisfied.  A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data).

   Grounded: A DODAG is grounded when the DODAG root can satisfy the
         Goal.

   Floating: A DODAG is floating if it is not grounded.  A floating
         DODAG is not expected to have the properties required to
         satisfy the goal.  It may, however, provide connectivity to
         other nodes within the DODAG.

The common case of the Goal is "has connectivity to the Internet" but that's not the only case. I think given the Goal for P2P traffic, I agree with Pascal and Richard that it should be 1.


[Pascal6]
Floating vs. Grounded depends on the goal of the DODAG. I asked you and will ask again what is your goal?
If the goal is to reach the root, then G is 1... If you want to signal something to the OF using the G bit, leave it  open.

[Mukul6]
>If the goal is to reach the root, then G is 1...

I have told you multiple times that joining a P2P-RPL DAG does not give any sort of connectivity to the node.

[Pascal7]
I think we disagree because of the definition of goal itself. The goal is an abstraction. Same goes for the term Objective in OF. RFC 6550 only gives examples of what G could be used for but that is not limiting. Certainly the abstraction may for instance mean that external nodes are reachable via the root. But it could be something else entirely. For instance it could designate a root that can aggregate data.

In practice, G is used to favor a root that reaches the goal vs. one that does not. But that's senseless for local instances that have by definition a single root.

So whatever you set it to does not make a difference for RFC 6550 operations. I figure it could be used for signaling a "transient goal" information to an OF that could use it for a purpose I can't fathom.

In any case, as I suggested earlier and as Richard also suggest now, G SHOULD probably be 1 by default but MAY be set otherwise.

[Mukul7]
Richard wants the flag to always be either 0 or 1. He prefers it to be always 1 but would settle for it being always zero.

I think this is not a critical point. I am OK with whatever resolution you and Richard arrive at. Kindly provide me the resolution text I should put in the draft.

[Pascal8]
I suggest a sentence that says that:

1) For a local instance there can be only one root and one DODAG. G bit cannot and is not used for DODAG selection within an instance. 
2) In a given deployment, a goal can be defined that some P2P DODAGs achieve and others do not. The roots that achieve that goal will set the G bit in their P2P DAGs.
3) the default goal is to create connectivity between origin and target. So by default G should be set to 1.
4) if an intermediate router does not have enough resources to participate to all DODAGs then it should favor DODAGs with the G bit on.

The exact wording is yours...

[Mukul8]
>1) For a local instance there can be only one root and one DODAG. G bit cannot and is not used for DODAG selection within an instance. 

The statement above seems to be at odds with following two statements

>2) In a given deployment, a goal can be defined that some P2P DODAGs achieve and others do not. The roots that achieve that goal will set the G bit in their P2P DAGs.
3) the default goal is to create connectivity between origin and target. So by default G should be set to 1.

As per statement 1, the G flag can never be 1 for P2P-RPL DAGs because they use local instance ids.
As per statement 2/3, the G flag could be 1 and is 1 by default.

I am OK with setting G flag to 1 always (as you, Richard and Phil seem to prefer) but I dont know how to reason this. Do we need to provide a reason at all?

[Pascal9]
Statement 1 does not say that at all. Can't fathom how you concluded that... Let me try to reword: There is only what DODAG for a given local instance so there cannot be a selection => G cannot be used for a selection that cannot happen.

>As per statement 2/3, the G flag could be 1 and is 1 by default.

Yes. I added an item to help the device prioritize when it is asker to participate to many DODAGs (for many P2P flows that it happens to be on the path of). In that case, and if the device cannot particpater to all the P2P DODAGs, then the G bit could be use to decide which are the most important. 

If you define a default goal that the DODAG fills, then you set G to one. For instance, G could mean 'important stuff' like swithing a light on. You'd set it for switching lights but not for reporting the hygrometry of your orchids, which anyway will be retried in a half hour. As a result, if the 2 DAG formations collide, the light on will have precedence...

[Mukul9]
How about the following text:

"The origin sets the G flag to indicate the relative importance of the route discovery it is initiating. The G flag is set to one if this particular route discovery is more important from application's perspective than some other route discovery. In other words, the origin sets the G flag to one if this particular route discovery helps meet the application defined goal \cite{rpl}. Thus, the G flag setting helps an intermediate router choose which route discoveries to participate in if it cannot participate in all route discoveries. An intermediate router SHOULD participate in route discoveries with G flag set to one (in preference to ones with G flag set to zero)."

[Pascal10]
As far as I'm concerned you've captured it and I'm happy with this text.


From pthubert@cisco.com  Tue Apr 10 23:15:44 2012
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 0105421F86A2 for ; Tue, 10 Apr 2012 23:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.027
X-Spam-Level: 
X-Spam-Status: No, score=-10.027 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AufVceLZCXng for ; Tue, 10 Apr 2012 23:15:43 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 85F4B21F86A6 for ; Tue, 10 Apr 2012 23:15:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=7800; q=dns/txt; s=iport; t=1334124942; x=1335334542; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=GeHn7u+jua4g4kzKD9uZ39wsxLUfsTZGIi5f5NsH9Yc=; b=lV2JPn+eNTVnH+prUWm5AIcPvmIl34MCYNREN3m7sj0UVn9ihEC5gv8c nhRoeslWDo5go0/Sbug+DCQD0pQ+AvPKm+FlZXcLrI8lyH2ZOi9RKRKAt iix3qxDAtoJiCpJlov2XbOF/3MU2lminryxNMelvRgWFWd9nCUN9JoqSA 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAD4hhU+Q/khL/2dsb2JhbABCDoVlsmB7gQeCCQEBAQQBAQEPARANBDoLDAQCAQgRBAEBAwIGBhcBAgICAQElHwkIAQEEEwgRCYdsC55gjRCLN4EviWWFEzVjBJZ9jTyBaYIwOYFSFw
X-IronPort-AV: E=Sophos;i="4.75,403,1330905600"; d="scan'208";a="134780265"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2012 06:15:41 +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 q3B6FfUF015757; Wed, 11 Apr 2012 06:15:41 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, 11 Apr 2012 08:15:41 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Wed, 11 Apr 2012 08:14:52 +0200
Message-ID: 
In-Reply-To: <1728662895.1887339.1334108343320.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] [roll] #90: use of transient instance ID
Thread-Index: Ac0Xg+ibrH9gg/KNRMOgN5BLi6jn7wAJcWbg
References:  <1728662895.1887339.1334108343320.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
X-OriginalArrivalTime: 11 Apr 2012 06:15:41.0359 (UTC) FILETIME=[8566ABF0:01CD17AA]
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #90: use of transient instance ID
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, 11 Apr 2012 06:15:44 -0000

SGVsbG8gTXVrdWw6DQoNCltQYXNjYWxdIEFsc28sIHdoZW4gdGhlcmUgYXJlIG5vIHJvdXRpbmcg
c3RhdGVzIGluIGludGVybWVkaWF0ZSByb3V0ZXJzLCBhbiBpbmRpY2F0aW9uIGZyb20gdXBwZXIg
bGF5ZXJzIGNhbiBiZSB1c2VkIGluIHRoZSBlbmQgcG9pbnRzIHRvIGNvbnNpZGVyIHRoYXQgYWxs
IHN0YXRlcyBmb3IgYW4gaW5zdGFuY2VJRCBhcmUgbm93IGNsZWFuZWQgdXAuDQoNCltNdWt1bF0g
Tm90IHN1cmUgd2hhdCB5b3UgbWVhbi4gDQoNCltQYXNjYWwyXSBMZXQgbWUgcmV3b3JkOiAgaWYg
SGJIIHJvdXRpbiBnaXMgbm90IHVzZWQsIHRoZSBvbmx5IHN0YXRlcyB3aXRoIGFueSBwZXJzaXN0
ZW5jZSBhcmUgb24gdGhlIG9yaWdpbiBhbmQgdGFyZ2V0KHMpLiBUaGUgdXBwZXIgbGF5ZXIgcHJv
dG9jb2wgKFVMUCkgaW4gb3JpZ2luIGFuZCB0YXJnZXQgbWF5IGtub3cgd2hlbiB0aGV5IGFyZSBk
b25lIHdpdGggdGhlaXIgbmVlZCBmb3IgdGhlIHJvdXRlcy4gSWYgdGhleSBhcmUgZG9uZSBiZWZv
cmUgKGNvbmZpZyBvcHRpb24pIGxpZmV0aW1lIGlzIHVwLCB0aGV5IGNhbiB0ZWFyIGRvd24gdGhl
IHN0YXRlcy4gVGhpcyByZXF1aXJlcyBhIG5ldyBjcm9zcyBsYXllciBpbnRlcmFjdGlvbiB0cmln
Z2VyZWQgYnkgVUxQLCBzaW1pbGFyIHRvIElQdjYgTkQgaW4gREVMQVkgc3RhdGUuDQoNCkNoZWVy
cywNCg0KUGFzY2FsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJQYXNj
YWwgVGh1YmVydCAocHRodWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPg0KVG86ICJNdWt1bCBH
b3lhbCIgPG11a3VsQHV3bS5lZHU+LCByb2xsQGlldGYub3JnDQpTZW50OiBUdWVzZGF5LCBBcHJp
bCAxMCwgMjAxMiA0OjUyOjUwIEFNDQpTdWJqZWN0OiBSRTogW1JvbGxdIFtyb2xsXSAjOTA6IHVz
ZSBvZiB0cmFuc2llbnQgaW5zdGFuY2UgSUQNCg0KTXVrdWw6DQoNCkkgbWVhbnQgYSBzdWdnZXN0
aW9uLCBub3QgYSBjYXBpdGFsaXplZCB3b3JkLiBJIHByZWZlciB0aGUgc3VnZ2VzdGlvbiBidXQg
SSdtIHN0aWxsIE9LIHdpdGggeW91ciBwcm9wb3NhbC4gSWYgd2UgZ2V0IGluIGFncmVlbWVudCBv
biB0aGUgbGlmZXRpbWUgb2YgdGhlIHN0YXRlcyAoaXNzdWUgIzg1KSwgdGhlbiB5b3UgY2FuIGlu
ZGljYXRlIHRoYXQgbGlmZXRpbWUgaXMgb25lIHdheSB0byBkZXRlcm1pbmUgd2hlbiBhbGwgc3Rh
bGUgc3RhdGVzIGNhbiBiZSBjb25zaWRlcmVkIGdvbmUuIEFsc28sIHdoZW4gdGhlcmUgYXJlIG5v
IHJvdXRpbmcgc3RhdGVzIGluIGludGVybWVkaWF0ZSByb3V0ZXJzLCBhbiBpbmRpY2F0aW9uIGZy
b20gdXBwZXIgbGF5ZXJzIGNhbiBiZSB1c2VkIGluIHRoZSBlbmQgcG9pbnRzIHRvIGNvbnNpZGVy
IHRoYXQgYWxsIHN0YXRlcyBmb3IgYW4gaW5zdGFuY2VJRCBhcmUgbm93IGNsZWFuZWQgdXAuDQoN
CkNoZWVycywNCg0KUGFzY2FsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIE11a3VsIEdveWFsDQpTZW50OiBkaW1hbmNoZSA4IGF2cmlsIDIwMTIgMTg6MDkN
ClRvOiByb2xsQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1JvbGxdIFtyb2xsXSAjOTA6IHVzZSBv
ZiB0cmFuc2llbnQgaW5zdGFuY2UgSUQNCg0KSGkgUGFzY2FsDQoNClJlLXJlYWQgeW91ciBwcm9w
b3NlZCByZXNvbHV0aW9uIHRleHQuIEkgYW0gbm90IHN1cmUgdGhhdCB0aGUgZHJhZnQgc2hvdWxk
IHN1Z2dlc3Qgcm90YXRpbmcgdGhlIGluc3RhbmNlIGlkcy4gTXkgcHJvcG9zZWQgcmVzb2x1dGlv
biBpcyB0byBzaW1wbHkgc3VnZ2VzdCBub3QgdXNpbmcgaW5zdGFuY2UgaWQgdGhhdCBtaWdodCBi
ZSBpbiB1c2UuDQoNCiIgW011a3VsMl0gTWFrZXMgc2Vuc2UuIEkgdGhpbmsgaXQgaXMgc3VmZmlj
aWVudCB0byBjYXV0aW9uICh3aXRoIGEgU0hPVUxEDQogTk9UKSBhZ2FpbnN0IHJldXNpbmcgaW5z
dGFuY2UgaWRzIGZvciB3aGljaCB0aGUgc3RhbGUgc3RhdGUgbWlnaHQgZXhpc3QgIGluIHRoZSBu
b2Rlcy4iDQoNClRoYW5rcw0KTXVrdWwNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0K
RnJvbTogInJvbGwgaXNzdWUgdHJhY2tlciIgPHRyYWMrcm9sbEB0cmFjLnRvb2xzLmlldGYub3Jn
Pg0KVG86IG11a3VsQFVXTS5FRFUsIGpwdkBjaXNjby5jb20NCkNjOiByb2xsQGlldGYub3JnDQpT
ZW50OiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTIgODoxMTo0NCBBTQ0KU3ViamVjdDogW3JvbGxd
ICM5MDogdXNlIG9mIHRyYW5zaWVudCBpbnN0YW5jZSBJRA0KDQojOTA6IHVzZSBvZiB0cmFuc2ll
bnQgaW5zdGFuY2UgSUQNCg0KIFByb2JsZW0gKHJlc29sdXRpb24gYWdyZWVkIHVwb24pDQogLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUDJQIGNyZWF0ZXMgdGVtcG9yYXJ5IHN0YXRl
cyBpbiB0aGUgdHJhbnNpZW50IERBRyB3aXRoIGEgdHJhbnNpZW50ICBpbnN0YW5jZSBJRC4gVGhl
IHByb3RvY29sIG11c3QgZW5zdXJlIHRoYXQgaWYgdGhlIGluc3RhbmNlIElEIGlzIHJldXNlZCAg
dGhlbiB0aGUgbmV3IG9wZXJhdGlvbiBpdCBpcyBub3QgY29uZnVzZWQgd2l0aCBzdGF0ZXMgcmVz
dWx0aW5nIGZyb20gdGhlICBwcmV2aW91cyB1c2Ugb2YgdGhlIHNhbWUgaW5zdGFuY2UgSUQuIFN1
Z2dlc3Rpb24gaXMgdG8gcHJvcG9zZSBhICByb3RhdGlvbi4NCg0KIERpc2N1c3Npb24NCiAtLS0t
LS0tLS0tLS0tDQoNCiBbUGFzY2FsXQ0KICJSUExJbnN0YW5jZUlEOiBSUExJbnN0YW5jZUlEIE1V
U1QgYmUgYSBsb2NhbCB2YWx1ZSBhcyBkZXNjcmliZWQgaW4gIFNlY3Rpb24gNS4xIG9mIFtJLUQu
aWV0Zi1yb2xsLXJwbF0uIFRoZSBvcmlnaW4gTVVTVCBOT1QgdXNlIHRoZSBzYW1lICBSUExJbnN0
YW5jZUlEIGluIHR3byBvciBtb3JlIGNvbmN1cnJlbnQgcm91dGUgZGlzY292ZXJpZXMuIg0KDQog
SSdkIHN1Z2dlc3QgdGhhdCB5b3UgZW5mb3JjZSBhIHJvdW5kIHJvYmluIG9yIGFuIG9wYXF1ZSBj
aXJjdWxhdGlvbiBzbyAgdGhhdCB0aGUgbmV3IGluc3RhbmNlSUQgaXMgdGhlIGxlYXN0IHJlY2Vu
dGx5IHVzZWQgb25lIG91dCBvZiB0aGUgNjQgIHBvc3NpYmxlLg0KDQogW011a3VsXQ0KIEkgdGhp
bmsgd2Ugc2hvdWxkIGxlYXZlIGl0IHRvIHRoZSBvcmlnaW4gdG8gZGVjaWRlIHdoaWNoIHZhbHVl
IGl0IHdhbnRzICB0byB1c2UgZm9yIFJQTEluc3RhbmNlSUQuIEkga25vdyBzb21lIGltcGxlbWVu
dGF0aW9ucyBhcmUgcGxhbm5pbmcgdG8gIHVzZSBhIGZpeGVkIFJQTEluc3RhbmNlSUQgdmFsdWUg
Zm9yIGFsbCByb3V0ZSBkaXNjb3Zlcmllcy4NCg0KIFtQYXNjYWwyXSBDaGFuZ2luZyB0aGUgaW5z
dGFuY2UgSUQgd2lsbCBoZWxwIGRlYnVnIHRoZSBuZXR3b3JrIGFuZCBhdm9pZCAgY29uZmxpY3Rz
IHdpdGggc3RhbGUgc3RhdGVzLiBXaGF0J3MgcmVhbGx5IHVwIHRvIHRoZSBkZXZpY2UgaXMgdGhl
ICBpbml0aWFsIHNlcXVlbmNlLiBMZWF2aW5nIGl0IHVwIHRvIHRoZSBvcmlnaW4gbWF5IGhlbHAg
dGhlIG9yaWdpbiBkZWZlYXQgIHNvbWUgYXR0YWNrcyB0byBzb21lIGRlZ3JlZS4gT1RPSCwgYWZ0
ZXIgYWxsIHRoZSBpbnN0YW5jZXMgaGF2ZSBiZWVuICBwbGF5ZWQsIExSVSBmb3JjZXMgdG8gcmVw
bGF5IHRoZSBzYW1lIHNlcXVlbmNlIGFnYWluIHNvIHRoZSBzaGllbGQgIGRyb3BzLiBNeSBwcmVm
ZXJyZWQgYXBwcm9hY2ggd291bGQgYmUgYSBTSE9VTEQgdGhhdCB3b3VsZCBzYXkgdGhhdCB0aGUg
IG5leHQgaW5zdGFuY2UgSUQgU0hPVUxEIE5PVCBiZSBvbmUgb2YgdGhlICgxNj8pIG1vc3QgcmVj
ZW50bHkgdXNlZCBhbmQgIE1VU1QgTk9UIGJlIG9uZSBmb3Igd2hpY2ggc3RhdGVzIG1pZ2h0IHN0
aWxsIGV4aXN0IGluIHRoZSBuZXR3b3JrLiBJT1cgIGVpdGhlciB0aGUgc3RhdGVzIGRlbGV0aW9u
IHdhcyBhY2tub3dsZWRnZWQsIG9yIGFsbCBwZW5kaW5nIGxpZmV0aW1lcyAgYXJlIGV4aGF1c3Rl
ZC4NCg0KIFtNdWt1bDJdIE1ha2VzIHNlbnNlLiBJIHRoaW5rIGl0IGlzIHN1ZmZpY2llbnQgdG8g
Y2F1dGlvbiAod2l0aCBhIFNIT1VMRA0KIE5PVCkgYWdhaW5zdCByZXVzaW5nIGluc3RhbmNlIGlk
cyBmb3Igd2hpY2ggdGhlIHN0YWxlIHN0YXRlIG1pZ2h0IGV4aXN0ICBpbiB0aGUgbm9kZXMuIFVz
aW5nIGEgIk1VU1QgTk9UIiBtYXkgbm90IGJlIE9LIHNpbmNlIGEgbm9kZSBtYXkgbmV2ZXIgYmUg
IDEwMCUgc3VyZSBhYm91dCBub24tZXhpc3RlbmNlIG9mIHN0YWxlIHN0YXRlIHdpdGggYSBwYXJ0
aWN1bGFyIGluc3RhbmNlICBpZCAodGh1cywgYWxsIHBvc3NpYmxlIGluc3RhbmNlIGlkIHZhbHVl
cyB3aWxsIGJlY29tZSBzdXNwZWN0IGFuZCBoZW5jZSAgdW51c2FibGUgYWZ0ZXIgYSB3aGlsZSku
DQoNCiBbUGFzY2FsM10gQWdyZWVkLiBOb3RlIHRoYXQgYSBjaXJjdWxhdGlvbiBpcyBhIGJvbnVz
IHRvIGRlZmVhdCByZXBsYXlzLg0KIEFuZCBub3cgd2UncmUgYmFjayB0byB0aGUgaXNzdWUgYWJv
dmUuIEhvdyBkb2VzIHRoZSBkZXZpY2Uga25vdyB0aGF0ICB0aGVyZSBpcyBubyBzdGF0ZSBsZWZ0
PyBBIGxpZmV0aW1lIGRlZmluaXRpb24gd291bGQgYmUgdmVyeSB1c2VmdWwuIFRoYXQgIGxpZmV0
aW1lIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBEQUcncyBvbmUgaW4gUkRPLiBJIHRoaW5rIHdlIGhh
dmUgYW4gb3BlbiAgaXNzdWUgaGVyZS4NCg0KIFtNdWt1bDNdIEFzIEkgbWVudGlvbmVkIGFib3Zl
LCB0aGUgbGlmZSB0aW1lIHBhcmFtZXRlcnMgaW5zaWRlIHRoZSBET0RBRyAgY29uZmlndXJhdGlv
biBvcHRpb24gc3BlY2lmeSB0aGUgbGlmZSB0aW1lIG9mIHRoZSBob3AtYnktaG9wIHJvdXRpbmcg
IHN0YXRlIGZvciB0aGUgcm91dGVzIGRpc2NvdmVyZWQgdXNpbmcgUDJQLVJQTC4NCg0KIFtQYXNj
YWw0XSBUaGlzIGJvaWxzIGRvd24gdG8gdGhlIHRocmVhZCBhYm92ZS4gT25seSBvbmUgaXNzdWUg
cmVhbGx5LCAgd2hpY2ggbGlmZXRpbWUgaXMgd2hpY2g/IFNvIElNSE8gbm8gbmVlZCB0byBsb2cg
YW55dGhpbmcgZm9yIHRoaXMgIHRocmVhZC4NCg0KIFtNdWt1bDRdIE9LLg0KDQogUGFzY2FsDQoN
Ci0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQogUmVwb3J0ZXI6ICBqcHZA4oCmICAgICAgICAgICAgICAgICAgfCAgICAgIE93bmVy
OiAgbXVrdWxA4oCmDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgIHwgICAgIFN0
YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICB8ICBNaWxlc3Rv
bmU6DQpDb21wb25lbnQ6ICBwMnAtcnBsICAgICAgICAgICAgICAgIHwgICAgVmVyc2lvbjoNCiBT
ZXZlcml0eTogIFN1Ym1pdHRlZCBXRyBEb2N1bWVudCAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tl
dCBVUkw6IDxodHRwczovL3N2bi50b29scy5pZXRmLm9yZy93Zy9yb2xsL3RyYWMvdGlja2V0Lzkw
Pg0Kcm9sbCA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3JvbGwvPg0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJv
bGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K

From pthubert@cisco.com  Tue Apr 10 23:23:40 2012
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 CB5DC21F86DB for ; Tue, 10 Apr 2012 23:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.437
X-Spam-Level: 
X-Spam-Status: No, score=-9.437 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24]
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 y8JYsyGzmbPR for ; Tue, 10 Apr 2012 23:23:39 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E48FC21F86D3 for ; Tue, 10 Apr 2012 23:23:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=15396; q=dns/txt; s=iport; t=1334125419; x=1335335019; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=t50f6FVOTZpXMxZpfOB0sk4eVU5l0G2ikyh+2/oF7pA=; b=Spcy+kQfoj6l4+t0huWm/53s7tf94+/9D5bL4UapdFFHIyJUnBAG13ln Afi941MdUb4ZBFZQ88PP+ym0XOy+oNsXmDIov73s7uXV5cQ9bcRDdeqaA noH9PZoHhQyxIS9cXnQOHJfWeS7qHpPEpO8A6mGKozvqHzZwVjl/8OsH3 M=;
X-IronPort-AV: E=Sophos;i="4.75,403,1330905600"; d="scan'208";a="134780689"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2012 06:23:35 +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 q3B6NZ6M016957; Wed, 11 Apr 2012 06:23:35 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, 11 Apr 2012 08:23:35 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Wed, 11 Apr 2012 08:22:52 +0200
Message-ID: 
In-Reply-To: <994990080.1886442.1334102327422.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
Thread-Index: Ac0XdeCZNPSIBFb9Qz6agwH2ZqWubQANLTTQ
References:  <994990080.1886442.1334102327422.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
X-OriginalArrivalTime: 11 Apr 2012 06:23:35.0541 (UTC) FILETIME=[A0091A50:01CD17AB]
Cc: roll 
Subject: Re: [Roll] [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
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, 11 Apr 2012 06:23:40 -0000

TXVrdWw6DQoNCldlIGhhdmUgYSBkaXNjb25uZWN0IGJlY2F1c2UgeW91IGluc2lzdCBpbiB0aGlu
a2luZyB0aGF0IEkgcmVmZXIgdG8gdGhlIGxpZmV0aW1lIG9mIHRoZSB0ZW1wb3JhcnkgREFHIGFz
IGluZGljYXRlZCBpbiB0aGUgUkRPLg0KQnV0IG5vLiBJIHJld29yZGVkIHR3aWNlIGFuZCB1c2Vk
IHZlcnkgc3BlY2lmaWMgd29yZHMgdGhpcyBsYXN0IHRpbWUuIA0KUGxlYXNlIHJlbW92ZSB0aGUg
dGVtcCBEYWcgZnJvbSB0aGUgZGlzY3Vzc2lvbiBhbmQgcmVhZCBhZ2FpbiBpbiB0aGUgbGlnaHQg
dGhhdCBJJ20gcmVhbGx5IHRhbGtpbmcgYWJvdXQgdGhlIHN0YXRlcyBIYkggcm91dGluZyBzdGF0
ZXMgYXMgSSB2ZXJ5IHNwZWNpZmljYWxseSBpbmRpY2F0ZS4NCklmIHRoYXQgZG9lcyBub3Qgd29y
ayB0aGVuIHdlJ2xsIG5lZWQgYSBwaG9uZSBjYWxsIHRvIHJlc3luYy4NCg0KQ2hlZXJzLA0KDQpQ
YXNjYWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTXVrdWwgR295YWwg
W21haWx0bzptdWt1bEB1d20uZWR1XSANClNlbnQ6IG1lcmNyZWRpIDExIGF2cmlsIDIwMTIgMDE6
NTkNClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpDYzoganB2QGNpc2NvLmNvbTsgcm9s
bA0KU3ViamVjdDogUmU6IFtyb2xsXSAjODU6IHdoaWNoIGxpZmV0aW1lIGlzIGZvciB0aGUgZW5k
IHBvaW50cyAob3JpZ2luIGFuZCB0YXJnZXQpIHZzLiBpbnRlcm1lZGlhdGUgbm9kZXMuDQoNCkhp
IFBhc2NhbA0KDQo+SSBkbyBub3Qgd2lzaCB0byBjaGFuZ2UgdGhlIERBRyBsaWZldGltZS4NCg0K
PkknbSBwb2ludGluZyBvdXQgdGhhdCB0aGUgY29udmVyc2F0aW9uIGJldHdlZW4gdGhlIG9yaWdp
biBhbmQgdGFyZ2V0IGNhbm5vdCB3b3JrIGxvbmdlciB0aGFuIHRoZSBsaWZldGltZSBvZiB0aGUg
ImhvcC1ieS1ob3Agcm91dGluZyBzdGF0ZXMiIHdoaWNoIGl0IGRlcGVuZHMgb24uIFNvIHdoeSBu
b3QgdXNlIHRoYXQ/DQoNCllvdSBtZWFuIHN0YXRlIGFib3V0IHRoZSAidGVtcG9yYXJ5IERBRyIg
YW5kIG5vdCB0aGUgaG9wLWJ5LWhvcCBzdGF0ZSBmb3IgdGhlICJkaXNjb3ZlcmVkIHJvdXRlIj8g
VGhleSBhcmUgdHdvIGRpZmZlcmVudCB0aGluZ3MuDQoNCj5JIHN1Z2dlc3QgdGhhdCB3ZSBjb252
ZXJnZSB0aGUgdGltZSBkdXJhdGlvbiBzcGVjaWZpZWQgaW4gRE9EQUcgY29uZmlndXJhdGlvbiBv
cHRpb24gdG8gbWVhbiB0aGUgbWF4aW11bSBkdXJhdGlvbiBvZiBzdGF0ZXMgaW4gYWxsIG5vZGVz
IHRoYXQgbmVlZCB0byBrZWVwIHN0YXRlcywgaW5jbHVkaW5nIG9yaWdpbiBhbmQgdGFyZ2V0LCBh
bmQgaW4gc29tZSBjYXNlIGludGVybWVkaWF0ZSByb3V0ZXJzLg0KDQpXZSBhcmUgdXNpbmcgdGhl
IHRpbWUgZHVyYXRpb24gaW4gRE9EQUcgY29uZmlndXJhdGlvbiBvcHRpb24gdG8gc3BlY2lmeSB0
aGUgbGlmZXRpbWUgb2YgdGhlICJob3AtYnktaG9wIHN0YXRlIGZvciB0aGUgZGlzY292ZXJlZCBy
b3V0ZSIgKGFuZCBub3QgdGhlIGxpZmV0aW1lIG9mIHRoZSAidGVtcG9yYXJ5IERBRyIpLiBBIGRp
c2NvdmVyZWQgSGJIIHJvdXRlIG1heSBuZWVkIHRvIGJlIG1haW50YWluZWQgZm9yIGEgd2lkZSBy
YW5nZSBvZiB0aW1lIGR1cmF0aW9ucy4gSGVuY2UsIHdlIHdvdWxkIGxpa2UgdG8gc3BlY2lmeSB0
aGUgbGlmZXRpbWUgb2YgYSBkaXNjb3ZlcmVkIHJvdXRlIHVzaW5nIHRoZSByaWNoIHNlbWFudGlj
cyBwcm92aWRlZCBieSB0aGUgdGltZSBkdXJhdGlvbiBmaWVsZHMgaW5zaWRlIHRoZSBET0RBRyBj
b25maWd1cmF0aW9uIG9wdGlvbi4gT24gdGhlIG90aGVyIGhhbmQsIHRoZSBsaWZldGltZSBvZiBh
IHRlbXBvcmFyeSBEQUcgZG9lcyBub3QgbmVlZCB0byB2YXJ5IGEgd2hvbGUgbG90LiBTbywgd2Ug
cHJvdmlkZSA0IG9wdGlvbnMgZm9yIHRoaXMgbGlmZXRpbWUgKDEsIDQsIDE2IGFuZCA2NCBzZWNv
bmRzKSBhbmQgc3BlY2lmeSB0aGlzIGxpZmV0aW1lIGluIGEgMi1iaXQgZmllbGQgaW5zaWRlIFAy
UC1SRE8uDQoNCkRvIHlvdSBhZ3JlZSB3aXRoIGhvdyB0aGUgdHdvIGxpZmV0aW1lcyAobGlmZXRp
bWUgb2YgREFHIGFuZCBsaWZldGltZSBvZiB0aGUgZGlzY292ZXJlZCByb3V0ZSkgYXJlIHNwZWNp
ZmllZCBpbiBQMlAtUlBMPw0KDQo+SU9XLCBpZiB0aGUgSGJIIHJvdXRlIGlzIHVzZWQsIHRoZSBs
aWZldGltZSBpbiB0aGUgY29uZmlnIG9wdGlvbiBpcyBmb3IgYWxsIHN0YXRlcyBpbiBhbGwgbm9k
ZXMgb24gdGhlIHBhdGgocykgaW5jbHVkaW5nIG9yaWdpbnMgYW5kIHRhcmdldChzKS4gSWYgSGJI
IHJvdXRpbmcgaXMgbm90IHVzZWQsIHRoZSBsaWZldGltZSBpbiB0aGUgY29uZmlnIG9wdGlvbiBp
cyBzdGlsbCB2YWxpZCBmb3IgdGhlIHNvdXJjZSBhbmQgdGhlIG9yaWdpbi4gWW91IG1heSBkZWZp
bmUgYSBkZWZhdWx0IHZhbHVlIHRoYXQgc3VpdCBjbGFzc2ljYWwgUDJQIHJvdXRlcyBpbiB0aGUg
Y2FzZSB3aGVyZSBubyBjb25maWcgb2YgYW55IHNvcnQgaXMgcHJvdmlkZWQuIA0KDQpZb3Ugc2Vl
bSB0byB3YW50IHRoZSBjb25maWcgb3B0aW9uIHRvIHNwZWNpZnkgdGhlIGxpZmV0aW1lIG9mIHRo
ZSB0ZW1wb3JhcnkgREFHLiBUaGlzIHdvdWxkIGJlIGEgd2FzdGFnZSBvZiByaWNoIHNlbWFudGlj
IHByb3ZpZGVkIGJ5IHRob3NlIGZpZWxkcy4gSWYgeW91IGNvdWxkIGFncmVlIHRvIHNwZWNpZnlp
bmcgdGhlIHRlbXBvcmFyeSBEQUcgbGlmZXRpbWUgaW5zaWRlIFAyUC1SRE8gKHRoZSB3YXkgUDJQ
LVJQTCBjdXJyZW50bHkgZG9lcyksIEkgc2VlIG5vIHByb2JsZW0gd2hhdHNvZXZlci4gQWxsIG5v
ZGVzIChpbmNsdWRpbmcgdGhlIG9yaWdpbiBhbmQgdGFyZ2V0KSBqb2luaW5nIHRoZSB0ZW1wb3Jh
cnkgREFHIG1haW50YWluIHN0YXRlIGZvciB0aGUgdGVtcG9yYXJ5IERBRyAod2hpY2ggaXMgbm90
IHNhbWUgYXMgdGhlIHN0YXRlIGZvciB0aGUgZGlzY292ZXJlZCBIYkggcm91dGUpIGZvciB0aGUg
ZHVyYXRpb24gc3BlY2lmaWVkIGluIFAyUC1SRE8uIFdlIGNvdWxkIGZ1cnRoZXIgcmVxdWlyZSB0
aGF0IGFsbCBEUk8vRFJPLUFDSyBleGNoYW5nZSBNVVNUIGNvbXBsZXRlIHdpdGhpbiB0aGUgdGVt
cG9yYXJ5IERBRyBsaWZldGltZSAoc3BlY2lmaWVkIGluc2lkZSBQMlAtUkRPKS4gU28sIHRoZSB0
ZW1wb3JhcnkgREFHJ3MgbGlmZXRpbWUgaGFzIHRvIGJlIGNob3NlbiBjYXJlZnVsbHkuIEhhdmlu
ZyBzYWlkIHRoYXQsIEkgc3RpbGwgcHJlZmVyIGdpdmluZyBvcmlnaW4gYW5kIHRhcmdldCBleHRy
YSB0aW1lIChlcXVhbCB0byBvbmUgbW9yZSBsaWZldGltZSkgdG8gY29tcGxldGUgRFJPL0RSTy1B
Q0sgZXhjaGFuZ2UuDQoNClRoYW5rcw0KTXVrdWwNCg0KPkFuZCB5ZXMsIGdyZWF0IHBvaW50LCB5
b3UnZCBuZWVkIHRvIHNwZWNpZnkgdGhhdCB0aGUgbGlmZXRpbWUgaW4gdGhlIGNvbmZpZyBvcHRp
b24gbXVzdCBiZSBsYXJnZSBlbm91Z2ggdG8gYWNjb21tb2RhdGUgdGhlIHJldHJhbnNtaXNzaW9u
cy4NCg0KPkRvIHdlIGNvbnZlcmdlPw0KDQo+UGFzY2FsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCkZyb206IE11a3VsIEdveWFsIFttYWlsdG86bXVrdWxAdXdtLmVkdV0gDQpTZW50
OiBtYXJkaSAxMCBhdnJpbCAyMDEyIDE0OjU1DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0
KQ0KQ2M6IGpwdkBjaXNjby5jb207IHJvbGwNClN1YmplY3Q6IFJlOiBbcm9sbF0gIzg1OiB3aGlj
aCBsaWZldGltZSBpcyBmb3IgdGhlIGVuZCBwb2ludHMgKG9yaWdpbiBhbmQgdGFyZ2V0KSB2cy4g
aW50ZXJtZWRpYXRlIG5vZGVzLg0KDQpPUiB0aGUgc2ltcGxlciBvcHRpb24gd291bGQgYmUgdG8g
cmVxdWlyZSBEUk8vRFJPLUFDSyBleGNoYW5nZSB0byBjb21wbGV0ZSB3aXRoaW4gdGhlIERBRydz
IGxpZmUgdGltZT8gSWYgd2Ugd2VyZSB0byBzcGVjaWZ5IGEgbmV3IHBhcmFtZXRlciBmb3IgdGhl
IHRpbWUgbGltaXQgb24gRFJPL0RSTy1BQ0sgZXhjaGFuZ2UsIGJvdGggdGFyZ2V0IGFuZCBvcmln
aW4gd291bGQgbmVlZCB0byBhZ3JlZSBvbiB0aGUgdmFsdWUgb2YgdGhpcyBwYXJhbWV0ZXIuDQoN
Ck11a3VsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJNdWt1bCBHb3lh
bCIgPG11a3VsQHV3bS5lZHU+DQpUbzogIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1
YmVydEBjaXNjby5jb20+DQpDYzoganB2QGNpc2NvLmNvbSwgInJvbGwiIDxyb2xsQGlldGYub3Jn
Pg0KU2VudDogVHVlc2RheSwgQXByaWwgMTAsIDIwMTIgNzo1MDoxNiBBTQ0KU3ViamVjdDogUmU6
IFtyb2xsXSAjODU6IHdoaWNoIGxpZmV0aW1lIGlzIGZvciB0aGUgZW5kIHBvaW50cyAob3JpZ2lu
IGFuZCB0YXJnZXQpIHZzLiBpbnRlcm1lZGlhdGUgbm9kZXMuDQoNCkhpIFBhc2NhbA0KDQpIb3Bl
ZnVsbHkgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUgdGhpbmcuDQoNCj5ObywgaXQncyBu
b3QgY2xvc2VkLiBXZSBhcmUgdGFsa2luZyBhYm91dCBhIGNvbnRyYWN0IGJldHdlZW4gbG93ZXIg
bGF5ZXJzIGluIGFsbCBub2RlcyBpbmNsdWRpbmcgdGhlIHNvdXJjZSBhbmQgb3JpZ2luIHRvIG1h
aW50YWluIG5lY2Vzc2FyeSByZXNvdXJjZXMgYW5kIGFsbCBjb250cmFjdHMgbXVzdCBoYXZlIGEg
bGlmZXRpbWUuDQoNCjEuIEEgbm9kZSB0aGF0IGpvaW5zIGEgdGVtcG9yYXJ5IFAyUC1SUEwgREFH
IG1haW50YWlucyBzdGF0ZSBmb3IgdGhlIERBRyBmb3IgdGhlIHRpbWUgZHVyYXRpb24gc3BlY2lm
aWVkIGFzIERBRyBsaWZlIHRpbWUuDQoyLiBBIG5vZGUgdGhhdCBlc3RhYmxpc2hlcyBob3AtYnkt
aG9wIHJvdXRpbmcgc3RhdGUgZm9yIGEgcm91dGUgZGlzY292ZXJlZCB1c2luZyBQMlAtUlBMIG1h
aW50YWlucyB0aGlzIHN0YXRlIGZvciB0aGUgdGltZSBkdXJhdGlvbiBzcGVjaWZpZWQgaW4gRE9E
QUcgY29uZmlndXJhdGlvbiBvcHRpb24uDQoNCk9yaWdpbiBhbmQgdGFyZ2V0IG5lZWQgdG8gZXhj
aGFuZ2UgRFJPcyBhbmQgRFJPLUFDS3MuIEkgY291bGQgc3BlY2lmeSBhIG5ldyBjb25maWd1cmFi
bGUgcGFyYW1ldGVyIHRvIHNwZWNpZnkgdGhlIHRpbWUgbGltaXQgb24gdGhpcyBleGNoYW5nZS4g
VGhpcyBwYXJhbWV0ZXIncyB2YWx1ZSAgaGFzIHRvIGJlIG1vcmUgdGhhbiBEQUcgbGlmZSB0aW1l
LiBPbmUgb3B0aW9uIGlzIHRvIHNwZWNpZnkgaXQgaW4gdGVybXMgb2YgZXhpc3RpbmcgcGFyYW1l
dGVyczogREFHIGxpZmUgdGltZSArIChNQVhfRFJPX1JFVFJBTlNNSVNTSU9OUyArIDEpKkRST19B
Q0tfV0FJVF9USU1FLg0KDQpUaGFua3MNCk11a3VsDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t
LS0tDQpGcm9tOiAiUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0aHViZXJ0QGNpc2NvLmNv
bT4NClRvOiAiTXVrdWwgR295YWwiIDxtdWt1bEB1d20uZWR1Pg0KQ2M6IGpwdkBjaXNjby5jb20N
ClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDEwLCAyMDEyIDQ6NDU6NDYgQU0NClN1YmplY3Q6IFJFOiBb
cm9sbF0gIzg1OiB3aGljaCBsaWZldGltZSBpcyBmb3IgdGhlIGVuZCBwb2ludHMgKG9yaWdpbiBh
bmQgdGFyZ2V0KSB2cy4gaW50ZXJtZWRpYXRlIG5vZGVzLg0KDQpIaSBNdWt1bCwNCg0KTm8sIGl0
J3Mgbm90IGNsb3NlZC4gV2UgYXJlIHRhbGtpbmcgYWJvdXQgYSBjb250cmFjdCBiZXR3ZWVuIGxv
d2VyIGxheWVycyBpbiBhbGwgbm9kZXMgaW5jbHVkaW5nIHRoZSBzb3VyY2UgYW5kIG9yaWdpbiB0
byBtYWludGFpbiBuZWNlc3NhcnkgcmVzb3VyY2VzIGFuZCBhbGwgY29udHJhY3RzIG11c3QgaGF2
ZSBhIGxpZmV0aW1lLg0KSSBkbyBub3QgbWluZCB5b3Ugb3ZlcmxvYWQgdGhlIFJQTCBsaWZldGlt
ZSBvZiB0aGUgcm91dGluZyBmb3IgdGhlIHN0YXRlcyBhdCBvcmlnaW4gYW5kIHRhcmdldCBhbmQg
aWYgeW91IGhhdmUgYSBzZW50ZW5jZSB0aGF0IG1ha2VzIGl0IGNsZWFyIHRoZW4gd2UnbGwgYmUg
aW4gYWdyZWVtZW50Lg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQpGcm9tOiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3VsQHV3bS5lZHVdIA0KU2Vu
dDogZGltYW5jaGUgOCBhdnJpbCAyMDEyIDE3OjUyDQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHVi
ZXJ0KQ0KQ2M6IGpwdkBjaXNjby5jb20NClN1YmplY3Q6IFJlOiBbcm9sbF0gIzg1OiB3aGljaCBs
aWZldGltZSBpcyBmb3IgdGhlIGVuZCBwb2ludHMgKG9yaWdpbiBhbmQgdGFyZ2V0KSB2cy4gaW50
ZXJtZWRpYXRlIG5vZGVzLg0KDQpQYXNjYWwNCg0KQ2FuIHdlIGNvbnNpZGVyIHRoaXMgaXNzdWUg
Y2xvc2VkPyBQbGVhc2Ugc2VlIG15IGxhc3QgcmVzcG9uc2UuDQoNClRoYW5rcw0KTXVrdWwNCg0K
LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogInJvbGwgaXNzdWUgdHJhY2tlciIg
PHRyYWMrcm9sbEB0cmFjLnRvb2xzLmlldGYub3JnPg0KVG86IG11a3VsQFVXTS5FRFUsIGpwdkBj
aXNjby5jb20NCkNjOiByb2xsQGlldGYub3JnDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDQsIDIw
MTIgODowNjozMCBBTQ0KU3ViamVjdDogW3JvbGxdICM4NTogd2hpY2ggbGlmZXRpbWUgaXMgZm9y
IHRoZSBlbmQgcG9pbnRzIChvcmlnaW4gYW5kIHRhcmdldCkgdnMuIGludGVybWVkaWF0ZSBub2Rl
cy4NCg0KIzg1OiB3aGljaCBsaWZldGltZSBpcyBmb3IgdGhlIGVuZCBwb2ludHMgKG9yaWdpbiBh
bmQgdGFyZ2V0KSB2cy4gaW50ZXJtZWRpYXRlIG5vZGVzLg0KDQogUHJvYmxlbSAoY3VycmVudGx5
IG9wZW4pDQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUDJQIGNyZWF0ZXMgdGVt
cG9yYXJ5IHN0YXRlcyBpbiB0aGUgdHJhbnNpZW50IERBRyBhbmQgbGVzcy1idXQtc3RpbGwgIHRl
bXBvcmFyeSBzdGF0ZXMgaW4gdGhlIGVuZHBvaW50cy4gVGhlc2UgYXJlIDIgZGlmZmVyZW50IGxp
ZmV0aW1lcy4gVGhlICBzcGVjIGhhcyAyIGxpZmV0aW1lcywgb25lIGluIHRoZSBjb25maWcgb3B0
aW9uIGFuZCBvbmUgaW4gdGhlIFJETy4gVGhlICBzcGVjIGlzIG5vdCBzdWZmaWNpZW50bHkgY2xl
YXIgYWJvdXQgd2hpY2ggaXMgd2hpY2guIEluIGNhbiBhcHBlYXIgdG8gYmUgIGNvbmZsaWN0aW5n
IHNpbmNlIHRoZSBjb25maWcgb3B0aW9uIGlzIHN1cHBvc2VkIHRvIGFwcGx5IHRvIGFsbCByb3V0
ZXJzICBvbiB0aGUgcGF0aC4gT24gdGhlIHNpZGUsIGFuZCBpbiBvcmRlciB0byBhbGxvdyB0aGUg
cmV1c2Ugb2YgaW5zdGFuY2UgIElELCB0aGUgb3JpZ2luIG11c3QgYmUgc3VyZSB0aGF0IGFsbCBz
dGF0ZXMgZm9yIGEgcHJldmlvdXMgdXNhZ2Ugb2YgdGhlICBzYW1lIHZhbHVlIGFyZSBnb25lLiBT
byB3ZSBuZWVkIGEgY2xlYXIgY29udHJvbCAvIG5lZ290aWF0aW9uIG9mIHRoZSAgbGlmZXRpbWVz
IG9uIHRoZSBzdGF0ZXMgdGhhdCBjb21lIHdpdGggYW4gaW5zdGFuY2VJRC4gQWdhaW4gdGhpcyBp
cyBub3QgIGNsZWFyIGVub3VnaCBpbiB0aGUgc3BlYy4NCg0KDQoNCiBbUGFzY2FsMl0NCiAyKSBT
YW1lIHF1ZXN0aW9uIGlmIHlvdSB3YW50IHRvIGNyZWF0ZSBzdGF0ZXMgYXQgdGhlIHRhcmdldCB0
byByb3V0ZSAgYmFjay4gSG93IGxvbmcgZG9lcyB0aGUgdGFyZ2V0IG5lZWQgdG8gbWFpbnRhaW4g
dGhlIHJvdXRlPyBXaG8gY29udHJvbHMgIHRoYXQsIHRoZSBvcmlnaW4gb3IgdGhlIHRhcmdldD8g
SSdkIGV4cGVjdCB0byBmaW5kIGEgc3VnZ2VzdGVkIGxpZmV0aW1lICBpbiB0aGUgUkRPIHdpdGgg
YSBjb25maXJtYXRpb24gaW4gdGhlIERSTyB0byBsZXQgdGhlIHRhcmdldCBhbWVuZCBpdC4NCg0K
IFtNdWt1bDJdDQogSWYgdGhlIHRhcmdldCB3YW50cyBEUk8tQUNLIGl0IG5lZWRzIHRvIG1haW50
YWluIHN0YXRlIHVudGlsIERSTy1BQ0sgaXMgIHJlY2VpdmVkLiBPdGhlcndpc2UsIHRoZSB0YXJn
ZXQgbmVlZHMgdG8gcmVtZW1iZXIgdGhpbmdzIHVudGlsIGl0IGlzICBkb25lIHNlbmRpbmcgYWxs
IHRoZSBEUk9zLiBJIHdpbGwgYWRkIHRoZSB0ZXh0IHRvIHRoaXMgZWZmZWN0Lg0KDQogW1Bhc2Nh
bDNdDQogSWYgeW91IGFyZSBzZXR0aW5nIHVwIGEgc2hvcnQgdGVybSBjb252ZXJzYXRpb24sIGhv
dyBsb25nIGV4YWN0bHkgaXMgIHRoYXQgYmVmb3JlIHRoZSBvcmlnaW4gaGFzIHRvIHJlZnJlc2gg
dGhlIHJvdXRlPyBXaGF0IGNvbnRyb2xzIGNsZWFuIHVwICBpbiBib3RoIHNpZGVzPyBVc3VhbGx5
IHlvdSB3YW50IGEgbGlmZXRpbWUgKHNlZSBNSVA2IGZvciBpbnN0YW5jZSkNCg0KIFtNdWt1bDNd
DQogSXMgaXQgdGhhdCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGxpZmV0aW1lIG9mIHRoZSBo
b3AtYnktaG9wIHJvdXRpbmcgIHN0YXRlPyBUaGF0IGlzIHNwZWNpZmllZCBpbiB0aGUgbGlmZSB0
aW1lIHBhcmFtZXRlcnMgaW4gdGhlIERPREFHICBjb25maWd1cmF0aW9uIG9wdGlvbi4gVGhlIGRy
YWZ0IHNheXMgdGhhdCBvbiBwYWdlIDkgd2hpbGUgZGVzY3JpYmluZyBob3cgIHRoZSBET0RBRyBj
b25maWd1cmF0aW9uIG9wdGlvbiBzaG91bGQgYmUgc2V0IGluc2lkZSBhIFAyUCBtb2RlIERJTzoN
Cg0KICJUaGUgRGVmYXVsdCBMaWZldGltZSBhbmQgTGlmZXRpbWUgVW5pdCBwYXJhbWV0ZXJzIGlu
IERPREFHDQogICAgICBDb25maWd1cmF0aW9uIG9wdGlvbiBpbmRpY2F0ZSB0aGUgbGlmZSB0aW1l
IG9mIHRoZSBzdGF0ZSB0aGUNCiAgICAgIHJvdXRlcnMgbWFpbnRhaW4gZm9yIGEgaG9wLWJ5LWhv
cCByb3V0ZSBlc3RhYmxpc2hlZCB1c2luZyBQMlAtUlBMDQogICAgICBhbmQgbWF5IGJlIHNldCBh
cyBkZXNpcmVkLg0KICINCg0KIFtQYXNjYWw0XSBNYXliZSB0aGF0J3Mgc28gYnV0IHRoZW4geW91
IG5lZWQgdG8gcmV3b3JkIGEgbGl0dGxlIGJpdCBjYXVzZSAgeW91IGdvdCBtZSBxaXV0ZSBjb25m
dXNlZC4gSSd2ZSBiZWVuIHRhbGtpbmcgb2YgdGhlIGxpZmV0aW1lIG9mIHRoZSAgc3RhdGVzIGF0
IG9yaWdpbiBhbmQgdGFyZ2V0IGZvciBvbmUgY29udmVyc2F0aW9uLiBTaW5jZSB0aGV5IG1pZ2h0
IGJlICBoYXZpbmcgYSB0cmFuc2llbnQgY29udmVyc2F0aW9uLCBhbmQgdGhlIG9yaWdpbiBtaWdo
dCByZXVzZSB0aGUgaW5zdGFuY2UgIElEIHNvb24sIHlvdSBuZWVkIHRvIGdpdmUgYSBsaW1pdCBp
biB0aW1lIHRvIHRoZSBzdGF0ZXMgdGhhdCB5b3UgYXJlICBjcmVhdGluZy4gU3RpbGwgdGhhdCBj
b252ZXJzYXRpb24gaXMgbG9uZ2VyIHRoYW4gdGhlIHN0YXRlcyBpbiB0aGUgIGludGVybWVkaWF0
ZSByb3V0ZXJzLiBTbyB5b3UgaGF2ZSAyIGxpZmV0aW1lcyBhbmQgeW91IGhhdmUgdG8gYmUgdmVy
eSAgY2xlYXIgd2hpY2ggaXMgd2hpY2guIFBlcnNvbmFsbHksIEknZCBoYXZlIHVzZWQgdGhlIGxp
ZmV0aW1lIGluIHRoZSAgY29uZmlndXJhdGlvbiBvcHRpb24gZm9yIGFsbCB0aGUgcm91dGVycyBv
biB0aGUgd2F5IGFuZCBJJ2QgaGF2ZSB1c2VkICB0aGUgbmV3IGxpZmV0aW1lIGluIHRoZSBSRE8g
YXMgdGhlIGNvbnZlcnNhdGlvbiBsaWZldGltZSBpbiB0aGUgZW5kICBwb2ludHMgYmVjYXVzZToN
CiAxKSAgdGhhdCBpcyB0aGUgbmV3IGNvbmNlcHQuDQogMikgVGhpcyB3b3VsZCBhbGxvdyB0aGUg
dGFyZ2V0IHRvIGNvbmZpcm0gZXhhY3RseSBob3cgbG9uZyBpdCBsb2NrcyAgcmVzb3VyY2VzLA0K
IDMpIGFuZCB0aGlzIHdvdWxkIGJlIG1vcmUgY29tcGF0aWJsZSB3aXRoIHRoZSBkZXNjcmlwdGlv
biBvZiB0aGUgY29uZmlnICBvcHRpb24gaW4gUkZDIDY1NTAuDQoNCiBbTXVrdWw0XQ0KIFRoZXJl
IGFyZSB0d28gbGlmZXRpbWVzOg0KIDEpIExpZmV0aW1lIG9mIHRoZSB0ZW1wb3JhcnkgREFHOiB0
aGlzIGlzIHNwZWNpZmllZCBpbnNpZGUgUDJQLVJETw0KIDIpIExpZmV0aW1lIG9mIHRoZSByb3V0
aW5nIHN0YXRlIGZvciB0aGUgaG9wLWJ5LWhvcCByb3V0ZSBlc3RhYmxpc2hlZCAgdXNpbmcgUDJQ
LVJQTDogdGhpcyBpcyBzcGVjaWZpZWQgaW5zaWRlIHRoZSBET0RBRyBjb25maWd1cmF0aW9uIG9w
dGlvbi4NCiBBbGwgcm91dGVycyBvbiB0aGUgZXN0YWJsaXNoZWQgcm91dGUgKGluY2x1ZGluZyB0
aGUgb3JpZ2luKSBtYWludGFpbiAgc3RhdGUgZm9yIHRoaXMgcm91dGUgZm9yIHRoaXMgbXVjaCB0
aW1lLiBUaGlzIHRpbWUgY291bGQgdmVyeSB3ZWxsIGJlICBpbmZpbml0eS4NCg0KIE5vdywgbGV0
cyB0YWxrIGFib3V0IHRoZSAic3RhdGVzIGF0IG9yaWdpbiBhbmQgdGFyZ2V0Ii4gVGhlIG9yaWdp
biBhbmQgIHRoZSB0YXJnZXQgbWFpbnRhaW4gdGhlIHN0YXRlIGFib3V0IHRoZSB0ZW1wb3Jhcnkg
REFHIGZvciB0aGUgREFHJ3MgbGlmZSAgdGltZS4gVGhpcyBpcyB0cnVlIGZvciBhbGwgdGhlIG5v
ZGVzIHRoYXQgam9pbiB0aGlzIERBRy4gQWxsIHN1Y2ggbm9kZXMgIG1haW50YWluIHN0YXRlIGFi
b3V0IHRoZSB0ZW1wb3JhcnkgREFHIHVudGlsIHRoZSBEQUcncyBsaWZlIHRpbWUgaXMgIG92ZXIu
IEl0IGlzIHRydWUgdGhhdCB0aGUgdGFyZ2V0IGFuZCB0aGUgb3JpZ2luIGV4Y2hhbmdlIERST3Mg
YW5kICBEUk8tQUNLcyBhbmQgdGhpcyBleGNoYW5nZSBjb3VsZCBjb25jZWl2YWJseSBnbyBvbiBl
dmVuIGFmdGVyIHRoZSAgdGVtcG9yYXJ5IERBRydzIGRlbWlzZS4gSG93IGxvbmcgc2hvdWxkIHRo
ZSBvcmlnaW4gYW5kIHRhcmdldCBpbmR1bGdlIGluICB0aGlzIGV4Y2hhbmdlIChhbmQgaGVuY2Ug
cmVtZW1iZXIgdGhlIHBvc3NpYmx5IGRlYWQgREFHKT8gSSB0aGluayBpdCBpcyAgcHVyZWx5IHRo
ZWlyIGNob2ljZSBhbmQgdGhlIGRyYWZ0IG5lZWQgbm90IGltcG9zZSBhbnkgYXJ0aWZpY2lhbCB0
aW1lICBsaW1pdCBvbiB0aGlzLg0KDQogUGFzY2FsDQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICBqcHZA
4oCmICAgICAgICAgICAgICAgICAgfCAgICAgIE93bmVyOiAgbXVrdWxA4oCmDQogICAgIFR5cGU6
ICBkZWZlY3QgICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAg
bWFqb3IgICAgICAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBwMnAtcnBs
ICAgICAgICAgICAgICAgIHwgICAgVmVyc2lvbjoNCiBTZXZlcml0eTogIFN1Ym1pdHRlZCBXRyBE
b2N1bWVudCAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29s
cy5pZXRmLm9yZy93Zy9yb2xsL3RyYWMvdGlja2V0Lzg1Pg0Kcm9sbCA8aHR0cDovL3Rvb2xzLmll
dGYub3JnL3dnL3JvbGwvPg0KDQo=

From prvs=441eb7f02=mukul@uwm.edu  Wed Apr 11 03:07:40 2012
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 F04B521F8647 for ; Wed, 11 Apr 2012 03:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.17
X-Spam-Level: 
X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.429,  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 RN+8FdGRaIg1 for ; Wed, 11 Apr 2012 03:07:39 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2F51E21F85BD for ; Wed, 11 Apr 2012 03:07:37 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAPBWhU9/AAAB/2dsb2JhbABFhWa2cAEBAQQBAQEgSwsMDxEEAQEDAg0WAwIpHwkIBhMZh3ULp06KFokJgS+JZYUTgRgEiFqNEoERjyWDBYE2Fw
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 56BDFE6A8D; Wed, 11 Apr 2012 05:07:36 -0500 (CDT)
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 YzrFQO8yyogo; Wed, 11 Apr 2012 05:07:35 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id D2767E6A72; Wed, 11 Apr 2012 05:07:35 -0500 (CDT)
Date: Wed, 11 Apr 2012 05:07:35 -0500 (CDT)
From: Mukul Goyal 
To: "Pascal Thubert (pthubert)" 
Message-ID: <692352940.1889031.1334138855749.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.91]
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] #90: use of transient instance ID
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, 11 Apr 2012 10:07:40 -0000

Hi Pascal

Please see inline.

Thanks
Mukul

[Pascal] Also, when there are no routing states in intermediate routers, an=
 indication from upper layers can be used in the end points to consider tha=
t all states for an instanceID are now cleaned up.

[Mukul] Not sure what you mean.=20

[Pascal2] Let me reword:  if HbH routin gis not used, the only states with =
any persistence are on the origin and target(s). The upper layer protocol (=
ULP) in origin and target may know when they are done with their need for t=
he routes. If they are done before (config option) lifetime is up, they can=
 tear down the states. This requires a new cross layer interaction triggere=
d by ULP, similar to IPv6 ND in DELAY state.

[Mukul2]
You think P2P-RPL needs to define this cross-layer interaction? This is sim=
ply the upper layer telling the network layer to chuck a source route. Isn'=
t it? The upper/lower layers dont even need to remember that this route was=
 discovered using P2P-RPL. Also, the origin (or the target) can use a sourc=
e route as long as it wants. Why should the lifetime in config option dicta=
te how long this route can be used?

----- Original Message -----
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" , roll@ietf.org
Sent: Tuesday, April 10, 2012 4:52:50 AM
Subject: RE: [Roll] [roll] #90: use of transient instance ID

Mukul:

I meant a suggestion, not a capitalized word. I prefer the suggestion but I=
'm still OK with your proposal. If we get in agreement on the lifetime of t=
he states (issue #85), then you can indicate that lifetime is one way to de=
termine when all stale states can be considered gone. Also, when there are =
no routing states in intermediate routers, an indication from upper layers =
can be used in the end points to consider that all states for an instanceID=
 are now cleaned up.

Cheers,

Pascal


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Muk=
ul Goyal
Sent: dimanche 8 avril 2012 18:09
To: roll@ietf.org
Subject: Re: [Roll] [roll] #90: use of transient instance ID

Hi Pascal

Re-read your proposed resolution text. I am not sure that the draft should =
suggest rotating the instance ids. My proposed resolution is to simply sugg=
est not using instance id that might be in use.

" [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD
 NOT) against reusing instance ids for which the stale state might exist  i=
n the nodes."

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" 
To: mukul@UWM.EDU, jpv@cisco.com
Cc: roll@ietf.org
Sent: Wednesday, April 4, 2012 8:11:44 AM
Subject: [roll] #90: use of transient instance ID

#90: use of transient instance ID

 Problem (resolution agreed upon)
 ------------------------------
 P2P creates temporary states in the transient DAG with a transient  instan=
ce ID. The protocol must ensure that if the instance ID is reused  then the=
 new operation it is not confused with states resulting from the  previous =
use of the same instance ID. Suggestion is to propose a  rotation.

 Discussion
 -------------

 [Pascal]
 "RPLInstanceID: RPLInstanceID MUST be a local value as described in  Secti=
on 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the same  RPLInstanc=
eID in two or more concurrent route discoveries."

 I'd suggest that you enforce a round robin or an opaque circulation so  th=
at the new instanceID is the least recently used one out of the 64  possibl=
e.

 [Mukul]
 I think we should leave it to the origin to decide which value it wants  t=
o use for RPLInstanceID. I know some implementations are planning to  use a=
 fixed RPLInstanceID value for all route discoveries.

 [Pascal2] Changing the instance ID will help debug the network and avoid  =
conflicts with stale states. What's really up to the device is the  initial=
 sequence. Leaving it up to the origin may help the origin defeat  some att=
acks to some degree. OTOH, after all the instances have been  played, LRU f=
orces to replay the same sequence again so the shield  drops. My preferred =
approach would be a SHOULD that would say that the  next instance ID SHOULD=
 NOT be one of the (16?) most recently used and  MUST NOT be one for which =
states might still exist in the network. IOW  either the states deletion wa=
s acknowledged, or all pending lifetimes  are exhausted.

 [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD
 NOT) against reusing instance ids for which the stale state might exist  i=
n the nodes. Using a "MUST NOT" may not be OK since a node may never be  10=
0% sure about non-existence of stale state with a particular instance  id (=
thus, all possible instance id values will become suspect and hence  unusab=
le after a while).

 [Pascal3] Agreed. Note that a circulation is a bonus to defeat replays.
 And now we're back to the issue above. How does the device know that  ther=
e is no state left? A lifetime definition would be very useful. That  lifet=
ime is different from the DAG's one in RDO. I think we have an open  issue =
here.

 [Mukul3] As I mentioned above, the life time parameters inside the DODAG  =
configuration option specify the life time of the hop-by-hop routing  state=
 for the routes discovered using P2P-RPL.

 [Pascal4] This boils down to the thread above. Only one issue really,  whi=
ch lifetime is which? So IMHO no need to log anything for this  thread.

 [Mukul4] OK.

 Pascal

--=20
-----------------------------------+---------------------
 Reporter:  jpv@=E2=80=A6                  |      Owner:  mukul@=E2=80=A6
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: 
roll 

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

From prvs=441eb7f02=mukul@uwm.edu  Wed Apr 11 03:23:48 2012
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 6C30611E8086 for ; Wed, 11 Apr 2012 03:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.183
X-Spam-Level: 
X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.416,  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 lJjIl8y6oTq4 for ; Wed, 11 Apr 2012 03:23:47 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA2211E8089 for ; Wed, 11 Apr 2012 03:23:47 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0EAHBbhU9/AAAB/2dsb2JhbABFhWa2cgUBAQEgSwsbGgINEgcCKTAGE4gOC6dMihWJCYEvjniBGASIWo0SgRGPJYMF
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id C99BC1FD0BC; Wed, 11 Apr 2012 05:23:46 -0500 (CDT)
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 Y62cAzV3VUa5; Wed, 11 Apr 2012 05:23:46 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6F9561FD0B8; Wed, 11 Apr 2012 05:23:46 -0500 (CDT)
Date: Wed, 11 Apr 2012 05:23:46 -0500 (CDT)
From: Mukul Goyal 
To: C Chauvenet 
Message-ID: <1717308358.1889035.1334139826359.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D0221AE6D@AMXPRD0510MB390.eurprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [129.89.7.91]
X-Mailer: Zimbra 6.0.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] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
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, 11 Apr 2012 10:23:48 -0000

Please see inline

Thanks
Mukul

#95: Why need stop flag? Is the receipt of DRO not sufficient to indicate c=
ompletion of route discovery?

 Resolution: No because multiple DROs would be generated if multiple source=
  routes are being discovered.

 Discussion:

 p15 :  Stop (S): This flag, when set to one by a target, indicates that  t=
he P2P-RPL route discovery is over.

 [Cedric]
 Is this bit really usefull ? My guess is that it will be always set to 1.
 If you hear a DRO, this indeed means that the RDO has reached the target, =
 so you could just stop processing RDO when you hear a DRO.
 Do we really need a flag to stop RDO processing or the hearing of a DRO  t=
ype message could do the job ?

 [Mukul]
 A P2P-RPL invocation might involve discovery of multiple source routes. In=
  that case, receipt of a DRO does not mean route discovery is over. Only  =
when the target sets the stop flag in the DRO, a node could be sure that  t=
he route discovery is over.

[Cedric2]
OK fo multiple discovery.
But if I want to discover a route to a multicast group of target. I set a m=
ulticast adress in the target field of the RDO. Then, do I received as many=
 DRO message as the number of target reached ? In that case, would the firs=
t DRO with a "S" flag stop the RDO propagation to reach all the target incl=
uded in the multicast group ?

[Mukul2]
A target cannot set the S flag to one in the DRO if the target address in t=
he P2P-RDO specified a multicast address. See the following text at the end=
 of page 21 in P2P-RPL-9:

"The target MAY set the stop flag inside the DRO message to one if



Goyal, et al.           Expires September 7, 2012              [Page 21]
=20
Internet-Draft         draft-ietf-roll-p2p-rpl-09             March 2012


   o  this router is the only target specified in the corresponding DIO,
      i.e., the corresponding DIO specified a unicast address of the
      router as the Target inside the P2P-RDO with no additional targets
      specified via RPL Target Options; and

"=20

[Cedric3]=20
So how do you stop the RDO flooding when the target adress is mulicast ?=20

[Mukul3]

Stop flag cannot be used when the target address is multicast or when multi=
ple unicast targets are there. The DIO generation will stop when the DAG di=
es. In the meanwhile, trickle algorithm would hopefully avoid unnecessary m=
essage generation. Note that the draft recommends a very small value for th=
e redundancy constant.

--=20
-----------------------------------+---------------------
 Reporter:  jpv@=E2=80=A6                  |      Owner:  mukul@=E2=80=A6
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: 
roll 

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


From richard.kelsey@ember.com  Wed Apr 11 04:33:07 2012
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 79ED421F85AA for ; Wed, 11 Apr 2012 04:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.516
X-Spam-Level: 
X-Spam-Status: No, score=-5.516 tagged_above=-999 required=5 tests=[AWL=1.083,  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 4k-O5vNACmYO for ; Wed, 11 Apr 2012 04:33:05 -0700 (PDT)
Received: from p01c12o149.mxlogic.net (p01c12o149.mxlogic.net [208.65.145.72]) by ietfa.amsl.com (Postfix) with ESMTP id AABF421F85A7 for ; Wed, 11 Apr 2012 04:33:00 -0700 (PDT)
Received: from unknown [216.236.254.3] (EHLO p01c12o149.mxlogic.net) by p01c12o149.mxlogic.net(mxl_mta-6.13.0-3) with ESMTP id ceb658f4.64ee8940.32286.00-508.54894.p01c12o149.mxlogic.net (envelope-from );  Wed, 11 Apr 2012 05:33:00 -0600 (MDT)
X-MXL-Hash: 4f856bec002a1ff3-efaf7b641801572a3ca2df7cfe54040df708aea6
Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c12o149.mxlogic.net(mxl_mta-6.13.0-3) over TLS secured channel with ESMTP id beb658f4.0.32276.00-364.54874.p01c12o149.mxlogic.net (envelope-from );  Wed, 11 Apr 2012 05:33:00 -0600 (MDT)
X-MXL-Hash: 4f856bec1f994553-061c07622378d5bbc4391f12f4fa38a66ce24126
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.355.2; Wed, 11 Apr 2012 07:34:45 -0400
Date: Wed, 11 Apr 2012 07:31:42 -0400
Message-ID: <87lim28py9.fsf@kelsey-ws.hq.ember.com>
To: Mukul Goyal 
In-Reply-To: <723690941.1887908.1334112685750.JavaMail.root@mail17.pantherlink.uwm.edu> (message from Mukul Goyal on Tue, 10 Apr 2012 21:51:25 -0500)
From: Richard Kelsey 
X-Auto-Response-Suppress: DR, OOF, AutoReply
References: <723690941.1887908.1334112685750.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=Sk5VZAiC-DMA:10 a=saA6nF2ZJa]
X-AnalysisOut: [AA:10 a=BLceEmwcHowA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=i3]
X-AnalysisOut: [Xo98xXh8o0aazUTSkA:9 a=6tWRrwPX1JYPD2Z_DssA:7]
Cc: roll@ietf.org, mcr@sandelman.ca
Subject: Re: [Roll] Closure text for ticket #86
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, 11 Apr 2012 11:33:07 -0000

> Date: Tue, 10 Apr 2012 21:51:25 -0500
> From: Mukul Goyal 
>
> #86: G flag: do we need that text?
> 
> Problem
> ------------------------------
>  Disagreement on the meaning of 'G' bit and imposed setting to 0;
> 
> Proposed resolution
> ---------------------------
> Add the following text to the draft:
> 
> "The origin sets the G flag to indicate the relative importance of the
> route discovery it is initiating. The G flag is set to one if this
> particular route discovery is more important from application's
> perspective than some other route discovery. In other words, the
> origin sets the G flag to one if this particular route discovery helps
> meet the application defined goal \cite{rpl}. Thus, the G flag setting
> helps an intermediate router choose which route discoveries to
> participate in if it cannot participate in all route discoveries. An
> intermediate router SHOULD participate in route discoveries with G
> flag set to one (in preference to ones with G flag set to zero)."

If you want to repurpose the G flag in this way you need to be
clear that the usage in RFC 6550 no longer applies.  I think that
the best way to do this would be to say that clause 3 of 8.2.2.2
does not apply to P2P DAGs:

  8.2.2.2. DODAG Roots

   ...
   3.  A node whose DODAG parent set is empty MAY become the DODAG root
       of a floating DODAG.  ...

Not having floating DODAGs would mean that the original use of
the G flag is no longer necessary.

                                -Richard Kelsey

From c.chauvenet@watteco.com  Wed Apr 11 05:02:26 2012
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 DE43421F84B4 for ; Wed, 11 Apr 2012 05:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.735
X-Spam-Level: 
X-Spam-Status: No, score=-3.735 tagged_above=-999 required=5 tests=[AWL=-0.136, 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 5R5HoQ04F+F5 for ; Wed, 11 Apr 2012 05:02:26 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3EC21F84B6 for ; Wed, 11 Apr 2012 05:02:25 -0700 (PDT)
Received: from mail6-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 11 Apr 2012 12:02:25 +0000
Received: from mail6-va3 (localhost [127.0.0.1])	by mail6-va3-R.bigfish.com (Postfix) with ESMTP id 7A02724040B; Wed, 11 Apr 2012 12:02:25 +0000 (UTC)
X-SpamScore: -33
X-BigFish: VPS-33(z4b6Kzc89bh1dbaL1432Nzz1202hzz1033IL8275dhz2dh2a8h668h839h946hd25h)
X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI
Received: from mail6-va3 (localhost.localdomain [127.0.0.1]) by mail6-va3 (MessageSwitch) id 1334145742858239_1486; Wed, 11 Apr 2012 12:02:22 +0000 (UTC)
Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.235])	by mail6-va3.bigfish.com (Postfix) with ESMTP id CBB3F2004E; Wed, 11 Apr 2012 12:02:22 +0000 (UTC)
Received: from AMXPRD0510HT004.eurprd05.prod.outlook.com (157.56.248.181) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 11 Apr 2012 12:02:21 +0000
Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT004.eurprd05.prod.outlook.com ([10.255.57.39]) with mapi id 14.16.0143.004; Wed, 11 Apr 2012 12:02:18 +0000
From: C Chauvenet 
To: Mukul Goyal 
Thread-Topic: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
Thread-Index: AQHNEx32hh4lWAafiEaDmA/VlsX0qpaMTC1wgAUtcwCAAs5AkIABLD4AgAAbh4A=
Date: Wed, 11 Apr 2012 12:02:17 +0000
Message-ID: 
References: <1717308358.1889035.1334139826359.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <1717308358.1889035.1334139826359.JavaMail.root@mail17.pantherlink.uwm.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.4.8]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: "" 
Subject: Re: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
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, 11 Apr 2012 12:02:27 -0000

inline,

Le 11 avr. 2012 =E0 12:23, Mukul Goyal a =E9crit :

> Please see inline
>=20
> Thanks
> Mukul
>=20
> #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate=
 completion of route discovery?
>=20
> Resolution: No because multiple DROs would be generated if multiple sourc=
e  routes are being discovered.
>=20
> Discussion:
>=20
> p15 :  Stop (S): This flag, when set to one by a target, indicates that  =
the P2P-RPL route discovery is over.
>=20
> [Cedric]
> Is this bit really usefull ? My guess is that it will be always set to 1.
> If you hear a DRO, this indeed means that the RDO has reached the target,=
  so you could just stop processing RDO when you hear a DRO.
> Do we really need a flag to stop RDO processing or the hearing of a DRO  =
type message could do the job ?
>=20
> [Mukul]
> A P2P-RPL invocation might involve discovery of multiple source routes. I=
n  that case, receipt of a DRO does not mean route discovery is over. Only =
 when the target sets the stop flag in the DRO, a node could be sure that  =
the route discovery is over.
>=20
> [Cedric2]
> OK fo multiple discovery.
> But if I want to discover a route to a multicast group of target. I set a=
 multicast adress in the target field of the RDO. Then, do I received as ma=
ny DRO message as the number of target reached ? In that case, would the fi=
rst DRO with a "S" flag stop the RDO propagation to reach all the target in=
cluded in the multicast group ?
>=20
> [Mukul2]
> A target cannot set the S flag to one in the DRO if the target address in=
 the P2P-RDO specified a multicast address. See the following text at the e=
nd of page 21 in P2P-RPL-9:
>=20
> "The target MAY set the stop flag inside the DRO message to one if
>=20
>=20
>=20
> Goyal, et al.           Expires September 7, 2012              [Page 21]
>=20
> Internet-Draft         draft-ietf-roll-p2p-rpl-09             March 2012
>=20
>=20
>   o  this router is the only target specified in the corresponding DIO,
>      i.e., the corresponding DIO specified a unicast address of the
>      router as the Target inside the P2P-RDO with no additional targets
>      specified via RPL Target Options; and
>=20
> "=20
>=20
> [Cedric3]=20
> So how do you stop the RDO flooding when the target adress is mulicast ?=
=20
>=20
> [Mukul3]
>=20
> Stop flag cannot be used when the target address is multicast or when mul=
tiple unicast targets are there. The DIO generation will stop when the DAG =
dies. In the meanwhile, trickle algorithm would hopefully avoid unnecessary=
 message generation. Note that the draft recommends a very small value for =
the redundancy constant.

[Cedric4]
So in this case, the RDO (I guess this is what you mean when you mentioned =
"DIO" in you previous message) generation to discover the route is never en=
ding until the temporary DAG dies ?
I guess the RDO flooding would stop according to the MaxRank/NH field  of t=
he P2P-RDO message.
But if this field is set to 0 (meaning infinity according to section 7.1), =
we should find a mechanism to stop the discovery mechanism.
What do you think ?


>=20
> --=20
> -----------------------------------+---------------------
> Reporter:  jpv@=85                  |      Owner:  mukul@=85
>     Type:  defect                 |     Status:  new
> Priority:  major                  |  Milestone:
> Component:  p2p-rpl                |    Version:
> Severity:  Submitted WG Document  |   Keywords:
> -----------------------------------+---------------------
>=20
> Ticket URL: 
> roll 
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>=20
>=20



From prvs=441eb7f02=mukul@uwm.edu  Wed Apr 11 05:24:00 2012
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 8792921F84A6 for ; Wed, 11 Apr 2012 05:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.196
X-Spam-Level: 
X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.403,  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 FwRHeCsBR3Yd for ; Wed, 11 Apr 2012 05:23:59 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1A621F858A for ; Wed, 11 Apr 2012 05:23:58 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAIR2hU9/AAAB/2dsb2JhbABFhWa2fyNWGxoCDRIHAlkGLId1p3GKEokJgS+JdgGFCIEYBIhajRKQNoMFgTYBFg
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 492F11FD0C8; Wed, 11 Apr 2012 07:23:58 -0500 (CDT)
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 Zo-84PMwMk6L; Wed, 11 Apr 2012 07:23:58 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 09D111FD0BE; Wed, 11 Apr 2012 07:23:58 -0500 (CDT)
Date: Wed, 11 Apr 2012 07:23:57 -0500 (CDT)
From: Mukul Goyal 
To: C Chauvenet 
Message-ID: <2031218940.1889327.1334147037927.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.91]
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] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
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, 11 Apr 2012 12:24:00 -0000

Please see inline.

Thanks
Mukul

> #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
> 
> Resolution: No because multiple DROs would be generated if multiple source  routes are being discovered.
> 
> Discussion:
> 
> p15 :  Stop (S): This flag, when set to one by a target, indicates that  the P2P-RPL route discovery is over.
> 
> [Cedric]
> Is this bit really usefull ? My guess is that it will be always set to 1.
> If you hear a DRO, this indeed means that the RDO has reached the target,  so you could just stop processing RDO when you hear a DRO.
> Do we really need a flag to stop RDO processing or the hearing of a DRO  type message could do the job ?
> 
> [Mukul]
> A P2P-RPL invocation might involve discovery of multiple source routes. In  that case, receipt of a DRO does not mean route discovery is over. Only  when the target sets the stop flag in the DRO, a node could be sure that  the route discovery is over.
> 
> [Cedric2]
> OK fo multiple discovery.
> But if I want to discover a route to a multicast group of target. I set a multicast adress in the target field of the RDO. Then, do I received as many DRO message as the number of target reached ? In that case, would the first DRO with a "S" flag stop the RDO propagation to reach all the target included in the multicast group ?
> 
> [Mukul2]
> A target cannot set the S flag to one in the DRO if the target address in the P2P-RDO specified a multicast address. See the following text at the end of page 21 in P2P-RPL-9:
> 
> "The target MAY set the stop flag inside the DRO message to one if
> 
> 
> 
> Goyal, et al.           Expires September 7, 2012              [Page 21]
> 
> Internet-Draft         draft-ietf-roll-p2p-rpl-09             March 2012
> 
> 
>   o  this router is the only target specified in the corresponding DIO,
>      i.e., the corresponding DIO specified a unicast address of the
>      router as the Target inside the P2P-RDO with no additional targets
>      specified via RPL Target Options; and
> 
> " 
> 
> [Cedric3] 
> So how do you stop the RDO flooding when the target adress is mulicast ? 
> 
> [Mukul3]
> 
> Stop flag cannot be used when the target address is multicast or when multiple unicast targets are there. The DIO generation will stop when the DAG dies. In the meanwhile, trickle algorithm would hopefully avoid unnecessary message generation. Note that the draft recommends a very small value for the redundancy constant.

[Cedric4]
So in this case, the RDO (I guess this is what you mean when you mentioned "DIO" in you previous message) generation to discover the route is never ending until the temporary DAG dies ?

[Mukul4] Never ending wont be the correct description. The temporary DAG lasts for a few seconds only. Plus, the trickle algorithm would prevent the generation of many DIOs.

[Cedric4]
I guess the RDO flooding would stop according to the MaxRank/NH field  of the P2P-RDO message.

[Mukul4]
Yes, it would. MaxRank and other routing constraints would always limit the scope of route discovery. Note that there are two separate things:
1) scope of discovery: how far the discovery message (P2P-RDO inside the DIO) travels. This is controlled by the routing constraints and the maxRank field inside the P2P-RDO.
2) How many discovery messages are generated by the nodes that join the DAG: this is controlled by trickle timer and ultimately by the DAG life time. The stop flag in the DRO is an optimization that allows DIO generation to stop in the nodes that can hear the stop flag.

[Cedric4]
But if this field is set to 0 (meaning infinity according to section 7.1), we should find a mechanism to stop the discovery mechanism.
What do you think ?

[Mukul4]
To tell the truth, MaxRank is basically a way to avoid putting a metric container in the DIO (when a limit on rank is the only constraint you want to specify). The scope of discovery is limited by both MaxRank as well as the routing constraints in the metric container. 



From prvs=441eb7f02=mukul@uwm.edu  Wed Apr 11 05:35:56 2012
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 8C41C21F8686 for ; Wed, 11 Apr 2012 05:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.207
X-Spam-Level: 
X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.392,  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 q+1cCPccmsTg for ; Wed, 11 Apr 2012 05:35:55 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7910D21F8658 for ; Wed, 11 Apr 2012 05:35:55 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEALZ5hU9/AAAB/2dsb2JhbABChXO2fyNRBRsaAg0ZAlkGiCGsFYoUgSGBL45/gRgEiFqNEpA2gwWBNhc
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id EB9FB1FD0B8; Wed, 11 Apr 2012 07:35:54 -0500 (CDT)
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 uaLV+jxPkHrK; Wed, 11 Apr 2012 07:35:54 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 9FE471FD0B7; Wed, 11 Apr 2012 07:35:54 -0500 (CDT)
Date: Wed, 11 Apr 2012 07:35:54 -0500 (CDT)
From: Mukul Goyal 
To: C Chauvenet 
Message-ID: <1421177451.1889423.1334147754525.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D0221AE47@AMXPRD0510MB390.eurprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.91]
X-Mailer: Zimbra 6.0.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] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4?
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, 11 Apr 2012 12:35:56 -0000

Inline.



#93: Whether P2P-RPL should support establishment of a backward hop-by-hop route?

 Resolution: Open

 Discussion:

 p12 :  This specification does not allow for the establishment of hop-by-  hop routes in the backward direction.

 [Cedric]
 Why ? This would enable to establish 2 routes within a single route  request.
 Furthermore, you stipulates in the draft that links have to be  bidirectional to propagates RDO, in order to be able to send back the DRO.
 So if I understand it correctly you ensure that you have a reliable path  in both ways. Why using it in a single way only ?

 [Mukul]
 Suppose a DRO establishing a forward hop-by-hop route fails to make it to  the origin. In this case, all we have is some nodes storing the hop-by-hop  state for a broken route but that route is never used since the origin  never gets the DRO. On the other hand, if the DRO establishing a backward  hop-by-hop route fails to make it to the origin, we have a broken route  that the target is likely to use (to reach the origin). So, if we want  P2P-RPL to establish a backward hop-by-hop route, the target MUST ask for  a DRO-ACK from the origin (to make sure that the DRO does reach the origin  and hence the backward route is not broken). This can be done if you think  it will be useful. We did not include this in P2P-RPL because we did not  have a usecase for backward hop-by-hop routes and we wanted to avoid the  additional complexity.

 This is how we can implement this functionality: we will let the target  decide whether it wants the DRO to establish a backward hop-by-hop route.
 In that case:
 1) the target will set a new flag, the B flag (B for backward hop-by-hop  route), inside the DRO to let intermediate routers know that backward  route state needs to be established as well;
 2) the target will set the A flag to require a DRO-ACK from the origin;
 3) the target will specify (inside a new field in the DRO), an  RPLInstanceID under which the hop-by-hop state for the backward route will  be stored. Note that the RPLInstanceID of the forward route (selected by  the origin) may not be OK for use in backward route (because the target  may have already used this RPLInstanceID for another hop-by-hop route,  using different routing-metrics/constraints/OF, to the origin).
 When the intermediate routers receive this DRO, they will store the hop-  by-hop state for the backward route. This hop-by-hop state will consist
 of:
 1) Target address (taken from P2P-RDO inside the DRO).
 2) RPLInstanceID specified by the target
 3) The destination, i.e., the origin address (same as DODAGID inside the  DRO).

 Do you want this functionality?

[Cedric2] 
The group has to discuss and decide wether it is usefull or not. I personnaly think that RPL-P2P draft may be used for binding devices, so it could be valuable to create a 2 way path between the origin and the target. So I would vote in favor of such a mechanism. 
Though, I don't think we should create a new DAG (i.e. select a new RPLInstanceID) for the backward route. What I would like is just the ability for 2 devices to exchange packet in both ways using the same temporary DAG created by RPL-P2P. Let me explain the use case with an example : For instance, if you have nodes deployed in a building or a city, and you want to configure some of them. An operator could go in the area where devices to be programmed are installed (or in the neighborhood at least) with a "configurator node", and need to established a P2P route between this configurator node and the node(s) to be configurated. They create a temporary DAG (possibly through several hops) and exchange configuration frames. Because such messages are  critically important, you often need application layer acknowledgments, so a backward route is needed.
Is the actual specification compliant with such a use case without modification ? (using piggybacked DATA inside RDO and DRO messages) ? Or do wee need an additional mechanism such as the one you described ?

[Mukul2]
The target can always use the route inside a received P2P-RDO to source-route a message (e.g. an application level ack) back to the origin. Also, as you noticed, the target can place one or more data options inside the DRO to send an application level message back to the origin. So, the use case you have mentioned (which is, by the way, a common use case in commercial building environment) is supported by current P2P-RPL specification. In my view, no additional mechanism is required if the intent is to just support the usecase you described. Infact, we could not come up with a usecase where backward hop-by-hop routes are absolutely must. So, we decided to keep the specs simple by not allowing establishment of such routes. Also, currently we are shooting for an experimental RFC. If, at a later stage, we realize that backward hop-by-hop routes are necessary, we could support them in standards track RFC. 

[Cedric3]
Ok, the data option seems simple and efficient enough for the use case I pointed out.
Let's keep it as the default option to do simple P2P data exchange.
 
[Mukul3]
Whether the target uses data option in the DRO or a regular data packet (source routed using the discovered route) to reach the origin is target's prerogative. P2P-RPL spec has to be silent in this matter. 

[Cedric3]
If more periodic and reliable traffic is needed between 2 nodes in a RPL network, then I think we should include a 2 way path establishment.

[Mukul3]
So you want backward hop-by-hop route? Target using the discovered route as a source route won't be sufficient?

From c.chauvenet@watteco.com  Wed Apr 11 05:45:07 2012
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 3940021F8592 for ; Wed, 11 Apr 2012 05:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.724
X-Spam-Level: 
X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 Qi2n2+GbHXIG for ; Wed, 11 Apr 2012 05:45:05 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5D721F858A for ; Wed, 11 Apr 2012 05:45:04 -0700 (PDT)
Received: from mail72-am1-R.bigfish.com (10.3.201.232) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 11 Apr 2012 12:45:03 +0000
Received: from mail72-am1 (localhost [127.0.0.1])	by mail72-am1-R.bigfish.com (Postfix) with ESMTP id 79F44A02ED; Wed, 11 Apr 2012 12:45:03 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzc89bh1432N1453Mzz1202hzzz2dh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI
Received: from mail72-am1 (localhost.localdomain [127.0.0.1]) by mail72-am1 (MessageSwitch) id 1334148300298999_29038; Wed, 11 Apr 2012 12:45:00 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.229])	by mail72-am1.bigfish.com (Postfix) with ESMTP id 4100E40058; Wed, 11 Apr 2012 12:45:00 +0000 (UTC)
Received: from AMXPRD0510HT004.eurprd05.prod.outlook.com (157.56.248.181) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 11 Apr 2012 12:44:54 +0000
Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT004.eurprd05.prod.outlook.com ([10.255.57.39]) with mapi id 14.16.0143.004; Wed, 11 Apr 2012 12:44:27 +0000
From: C Chauvenet 
To: Mukul Goyal 
Thread-Topic: [Roll] [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4?
Thread-Index: AQHNExt2WB0Ei/9t6USXDGCl+MKLpJaMPEqwgAUul4CAAtuWQIABUpcAgAACYYA=
Date: Wed, 11 Apr 2012 12:44:27 +0000
Message-ID: <7D81DED5-2C87-4A57-88C5-F71F681D3D7B@watteco.com>
References: <1421177451.1889423.1334147754525.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <1421177451.1889423.1334147754525.JavaMail.root@mail17.pantherlink.uwm.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.4.7]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <15AD28B3E99DB34089499DF04C61A0D5@eurprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: "" 
Subject: Re: [Roll] [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4?
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, 11 Apr 2012 12:45:07 -0000

inline,

Le 11 avr. 2012 =E0 14:35, Mukul Goyal a =E9crit :

> Inline.
>=20
>=20
>=20
> #93: Whether P2P-RPL should support establishment of a backward hop-by-ho=
p route?
>=20
> Resolution: Open
>=20
> Discussion:
>=20
> p12 :  This specification does not allow for the establishment of hop-by-=
  hop routes in the backward direction.
>=20
> [Cedric]
> Why ? This would enable to establish 2 routes within a single route  requ=
est.
> Furthermore, you stipulates in the draft that links have to be  bidirecti=
onal to propagates RDO, in order to be able to send back the DRO.
> So if I understand it correctly you ensure that you have a reliable path =
 in both ways. Why using it in a single way only ?
>=20
> [Mukul]
> Suppose a DRO establishing a forward hop-by-hop route fails to make it to=
  the origin. In this case, all we have is some nodes storing the hop-by-ho=
p  state for a broken route but that route is never used since the origin  =
never gets the DRO. On the other hand, if the DRO establishing a backward  =
hop-by-hop route fails to make it to the origin, we have a broken route  th=
at the target is likely to use (to reach the origin). So, if we want  P2P-R=
PL to establish a backward hop-by-hop route, the target MUST ask for  a DRO=
-ACK from the origin (to make sure that the DRO does reach the origin  and =
hence the backward route is not broken). This can be done if you think  it =
will be useful. We did not include this in P2P-RPL because we did not  have=
 a usecase for backward hop-by-hop routes and we wanted to avoid the  addit=
ional complexity.
>=20
> This is how we can implement this functionality: we will let the target  =
decide whether it wants the DRO to establish a backward hop-by-hop route.
> In that case:
> 1) the target will set a new flag, the B flag (B for backward hop-by-hop =
 route), inside the DRO to let intermediate routers know that backward  rou=
te state needs to be established as well;
> 2) the target will set the A flag to require a DRO-ACK from the origin;
> 3) the target will specify (inside a new field in the DRO), an  RPLInstan=
ceID under which the hop-by-hop state for the backward route will  be store=
d. Note that the RPLInstanceID of the forward route (selected by  the origi=
n) may not be OK for use in backward route (because the target  may have al=
ready used this RPLInstanceID for another hop-by-hop route,  using differen=
t routing-metrics/constraints/OF, to the origin).
> When the intermediate routers receive this DRO, they will store the hop- =
 by-hop state for the backward route. This hop-by-hop state will consist
> of:
> 1) Target address (taken from P2P-RDO inside the DRO).
> 2) RPLInstanceID specified by the target
> 3) The destination, i.e., the origin address (same as DODAGID inside the =
 DRO).
>=20
> Do you want this functionality?
>=20
> [Cedric2]=20
> The group has to discuss and decide wether it is usefull or not. I person=
naly think that RPL-P2P draft may be used for binding devices, so it could =
be valuable to create a 2 way path between the origin and the target. So I =
would vote in favor of such a mechanism.=20
> Though, I don't think we should create a new DAG (i.e. select a new RPLIn=
stanceID) for the backward route. What I would like is just the ability for=
 2 devices to exchange packet in both ways using the same temporary DAG cre=
ated by RPL-P2P. Let me explain the use case with an example : For instance=
, if you have nodes deployed in a building or a city, and you want to confi=
gure some of them. An operator could go in the area where devices to be pro=
grammed are installed (or in the neighborhood at least) with a "configurato=
r node", and need to established a P2P route between this configurator node=
 and the node(s) to be configurated. They create a temporary DAG (possibly =
through several hops) and exchange configuration frames. Because such messa=
ges are  critically important, you often need application layer acknowledgm=
ents, so a backward route is needed.
> Is the actual specification compliant with such a use case without modifi=
cation ? (using piggybacked DATA inside RDO and DRO messages) ? Or do wee n=
eed an additional mechanism such as the one you described ?
>=20
> [Mukul2]
> The target can always use the route inside a received P2P-RDO to source-r=
oute a message (e.g. an application level ack) back to the origin. Also, as=
 you noticed, the target can place one or more data options inside the DRO =
to send an application level message back to the origin. So, the use case y=
ou have mentioned (which is, by the way, a common use case in commercial bu=
ilding environment) is supported by current P2P-RPL specification. In my vi=
ew, no additional mechanism is required if the intent is to just support th=
e usecase you described. Infact, we could not come up with a usecase where =
backward hop-by-hop routes are absolutely must. So, we decided to keep the =
specs simple by not allowing establishment of such routes. Also, currently =
we are shooting for an experimental RFC. If, at a later stage, we realize t=
hat backward hop-by-hop routes are necessary, we could support them in stan=
dards track RFC.=20
>=20
> [Cedric3]
> Ok, the data option seems simple and efficient enough for the use case I =
pointed out.
> Let's keep it as the default option to do simple P2P data exchange.
>=20
> [Mukul3]
> Whether the target uses data option in the DRO or a regular data packet (=
source routed using the discovered route) to reach the origin is target's p=
rerogative. P2P-RPL spec has to be silent in this matter.=20
>=20
> [Cedric3]
> If more periodic and reliable traffic is needed between 2 nodes in a RPL =
network, then I think we should include a 2 way path establishment.
>=20
> [Mukul3]
> So you want backward hop-by-hop route? Target using the discovered route =
as a source route won't be sufficient?

[Cedric4]
Let me reword it : I'm OK to close this ticket as it is an experimental int=
ended status.
Using the discovered route as a source route is sufficient, and the picky b=
acked data option is OK with what I had in mind.
If this draft wants to step up to a standard track, then it could be valuab=
le to discuss the backward hop by hop route establishment.

>=20



From prvs=441eb7f02=mukul@uwm.edu  Wed Apr 11 05:53:21 2012
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 E5B8621F86DE for ; Wed, 11 Apr 2012 05:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.219
X-Spam-Level: 
X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.380,  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 jGULORUw6S6f for ; Wed, 11 Apr 2012 05:53:21 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id CDC3921F8692 for ; Wed, 11 Apr 2012 05:53:20 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEALx9hU9/AAAB/2dsb2JhbABFhWa2fyNRBTUCDRkCWQaIIagKihOJCYEvjn+BGASIWo0SkDaDBYE2Fw
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 51C3AE6A8D; Wed, 11 Apr 2012 07:53:20 -0500 (CDT)
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 pRtVElWsXqHX; Wed, 11 Apr 2012 07:53:20 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 019CCE6A72; Wed, 11 Apr 2012 07:53:20 -0500 (CDT)
Date: Wed, 11 Apr 2012 07:53:19 -0500 (CDT)
From: Mukul Goyal 
To: C Chauvenet 
Message-ID: <191646880.1889576.1334148799902.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <7D81DED5-2C87-4A57-88C5-F71F681D3D7B@watteco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.91]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Cc: roll 
Subject: [Roll] Closure text for ticket #93
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, 11 Apr 2012 12:53:22 -0000

#93: Whether P2P-RPL should support establishment of a backward hop-by-hop route?
 
Resolution:
---------------

No need to do so in current spec as it has experimental intended status.
Using the discovered route as a source route or the piggybacked data option is sufficient for now.
If this draft wants to step up to a standard track, then it could be valuable to discuss the backward hop by hop route establishment.

Discussion:
-----------------

p12 :  This specification does not allow for the establishment of hop-by-  hop routes in the backward direction.
 
[Cedric]
Why ? This would enable to establish 2 routes within a single route  request.
Furthermore, you stipulates in the draft that links have to be  bidirectional to propagates RDO, in order to be able to send back the DRO.
So if I understand it correctly you ensure that you have a reliable path  in both ways. Why using it in a single way only ?
 
[Mukul]
Suppose a DRO establishing a forward hop-by-hop route fails to make it to  the origin. In this case, all we have is some nodes storing the hop-by-hop  state for a broken route but that route is never used since the origin  never gets the DRO. On the other hand, if the DRO establishing a backward  hop-by-hop route fails to make it to the origin, we have a broken route  that the target is likely to use (to reach the origin). So, if we want  P2P-RPL to establish a backward hop-by-hop route, the target MUST ask for  a DRO-ACK from the origin (to make sure that the DRO does reach the origin  and hence the backward route is not broken). This can be done if you think  it will be useful. We did not include this in P2P-RPL because we did not  have a usecase for backward hop-by-hop routes and we wanted to avoid the  additional complexity.
 
This is how we can implement this functionality: we will let the target  decide whether it wants the DRO to establish a backward hop-by-hop route.
In that case:
1) the target will set a new flag, the B flag (B for backward hop-by-hop  route), inside the DRO to let intermediate routers know that backward  route state needs to be established as well;
2) the target will set the A flag to require a DRO-ACK from the origin;
3) the target will specify (inside a new field in the DRO), an  RPLInstanceID under which the hop-by-hop state for the backward route will  be stored. Note that the RPLInstanceID of the forward route (selected by  the origin) may not be OK for use in backward route (because the target  may have already used this RPLInstanceID for another hop-by-hop route,  using different routing-metrics/constraints/OF, to the origin).
When the intermediate routers receive this DRO, they will store the hop-  by-hop state for the backward route. This hop-by-hop state will consist of:
1) Target address (taken from P2P-RDO inside the DRO).
2) RPLInstanceID specified by the target
3) The destination, i.e., the origin address (same as DODAGID inside the  DRO).
 
Do you want this functionality?
 
[Cedric2] 
The group has to discuss and decide wether it is usefull or not. I personnaly think that RPL-P2P draft may be used for binding devices, so it could be valuable to create a 2 way path between the origin and the target. So I would vote in favor of such a mechanism. 

Though, I don't think we should create a new DAG (i.e. select a new RPLInstanceID) for the backward route. What I would like is just the ability for 2 devices to exchange packet in both ways using the same temporary DAG created by RPL-P2P. Let me explain the use case with an example : For instance, if you have nodes deployed in a building or a city, and you want to configure some of them. An operator could go in the area where devices to be programmed are installed (or in the neighborhood at least) with a "configurator node", and need to established a P2P route between this configurator node and the node(s) to be configurated. They create a temporary DAG (possibly through several hops) and exchange configuration frames. Because such messages are  critically important, you often need application layer acknowledgments, so a backward route is needed.

Is the actual specification compliant with such a use case without modification ? (using piggybacked DATA inside RDO and DRO messages) ? Or do wee need an additional mechanism such as the one you described ?
 
[Mukul2]
The target can always use the route inside a received P2P-RDO to source-route a message (e.g. an application level ack) back to the origin. Also, as you noticed, the target can place one or more data options inside the DRO to send an application level message back to the origin. So, the use case you have mentioned (which is, by the way, a common use case in commercial building environment) is supported by current P2P-RPL specification. In my view, no additional mechanism is required if the intent is to just support the usecase you described. Infact, we could not come up with a usecase where backward hop-by-hop routes are absolutely must. So, we decided to keep the specs simple by not allowing establishment of such routes. Also, currently we are shooting for an experimental RFC. If, at a later stage, we realize that backward hop-by-hop routes are necessary, we could support them in standards track RFC. 
 
[Cedric3]
Ok, the data option seems simple and efficient enough for the use case I pointed out.
Let's keep it as the default option to do simple P2P data exchange.
 
[Mukul3]
Whether the target uses data option in the DRO or a regular data packet (source routed using the discovered route) to reach the origin is target's prerogative. P2P-RPL spec has to be silent in this matter. 
 
[Cedric3]
If more periodic and reliable traffic is needed between 2 nodes in a RPL network, then I think we should include a 2 way path establishment.
 
[Mukul3]
So you want backward hop-by-hop route? Target using the discovered route as a source route won't be sufficient?

[Cedric4]
Let me reword it : I'm OK to close this ticket as it is an experimental intended status.
Using the discovered route as a source route is sufficient, and the picky backed data option is OK with what I had in mind.
If this draft wants to step up to a standard track, then it could be valuable to discuss the backward hop by hop route establishment.




From c.chauvenet@watteco.com  Wed Apr 11 07:05:42 2012
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 11F0B11E80B0 for ; Wed, 11 Apr 2012 07:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.714
X-Spam-Level: 
X-Spam-Status: No, score=-3.714 tagged_above=-999 required=5 tests=[AWL=-0.115, 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 d91+30SMBTjR for ; Wed, 11 Apr 2012 07:05:41 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0F311E8074 for ; Wed, 11 Apr 2012 07:05:40 -0700 (PDT)
Received: from mail106-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Wed, 11 Apr 2012 14:05:39 +0000
Received: from mail106-va3 (localhost [127.0.0.1])	by mail106-va3-R.bigfish.com (Postfix) with ESMTP id CA75B12007C; Wed, 11 Apr 2012 14:05:39 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(z4b6Kzc89bh1dbaL1432Nzz1202hzzz2dh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI
Received: from mail106-va3 (localhost.localdomain [127.0.0.1]) by mail106-va3 (MessageSwitch) id 1334153137221188_29233; Wed, 11 Apr 2012 14:05:37 +0000 (UTC)
Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.251])	by mail106-va3.bigfish.com (Postfix) with ESMTP id 20E892A0069; Wed, 11 Apr 2012 14:05:37 +0000 (UTC)
Received: from AMXPRD0510HT004.eurprd05.prod.outlook.com (157.56.248.181) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 11 Apr 2012 14:05:35 +0000
Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT004.eurprd05.prod.outlook.com ([10.255.57.39]) with mapi id 14.16.0143.004; Wed, 11 Apr 2012 14:04:54 +0000
From: C Chauvenet 
To: Mukul Goyal 
Thread-Topic: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
Thread-Index: AQHNEx32hh4lWAafiEaDmA/VlsX0qpaMTC1wgAUtcwCAAs5AkIABLD4AgAAbh4CAAAYNgIAAHDMA
Date: Wed, 11 Apr 2012 14:04:53 +0000
Message-ID: <042A14A9-10A8-42BF-8F07-489E981F7D98@watteco.com>
References: <2031218940.1889327.1334147037927.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <2031218940.1889327.1334147037927.JavaMail.root@mail17.pantherlink.uwm.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.4.8]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7967CA024BDAA4469B97FF14DF34B5E3@eurprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: roll 
Subject: Re: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
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, 11 Apr 2012 14:05:42 -0000

Hi,=20

See inline,=20

Le 11 avr. 2012 =E0 14:23, Mukul Goyal a =E9crit :

> Please see inline.
>=20
> Thanks
> Mukul
>=20
>> #95: Why need stop flag? Is the receipt of DRO not sufficient to indicat=
e completion of route discovery?
>>=20
>> Resolution: No because multiple DROs would be generated if multiple sour=
ce  routes are being discovered.
>>=20
>> Discussion:
>>=20
>> p15 :  Stop (S): This flag, when set to one by a target, indicates that =
 the P2P-RPL route discovery is over.
>>=20
>> [Cedric]
>> Is this bit really usefull ? My guess is that it will be always set to 1=
.
>> If you hear a DRO, this indeed means that the RDO has reached the target=
,  so you could just stop processing RDO when you hear a DRO.
>> Do we really need a flag to stop RDO processing or the hearing of a DRO =
 type message could do the job ?
>>=20
>> [Mukul]
>> A P2P-RPL invocation might involve discovery of multiple source routes. =
In  that case, receipt of a DRO does not mean route discovery is over. Only=
  when the target sets the stop flag in the DRO, a node could be sure that =
 the route discovery is over.
>>=20
>> [Cedric2]
>> OK fo multiple discovery.
>> But if I want to discover a route to a multicast group of target. I set =
a multicast adress in the target field of the RDO. Then, do I received as m=
any DRO message as the number of target reached ? In that case, would the f=
irst DRO with a "S" flag stop the RDO propagation to reach all the target i=
ncluded in the multicast group ?
>>=20
>> [Mukul2]
>> A target cannot set the S flag to one in the DRO if the target address i=
n the P2P-RDO specified a multicast address. See the following text at the =
end of page 21 in P2P-RPL-9:
>>=20
>> "The target MAY set the stop flag inside the DRO message to one if
>>=20
>>=20
>>=20
>> Goyal, et al.           Expires September 7, 2012              [Page 21]
>>=20
>> Internet-Draft         draft-ietf-roll-p2p-rpl-09             March 2012
>>=20
>>=20
>>  o  this router is the only target specified in the corresponding DIO,
>>     i.e., the corresponding DIO specified a unicast address of the
>>     router as the Target inside the P2P-RDO with no additional targets
>>     specified via RPL Target Options; and
>>=20
>> "=20
>>=20
>> [Cedric3]=20
>> So how do you stop the RDO flooding when the target adress is mulicast ?=
=20
>>=20
>> [Mukul3]
>>=20
>> Stop flag cannot be used when the target address is multicast or when mu=
ltiple unicast targets are there. The DIO generation will stop when the DAG=
 dies. In the meanwhile, trickle algorithm would hopefully avoid unnecessar=
y message generation. Note that the draft recommends a very small value for=
 the redundancy constant.
>=20
> [Cedric4]
> So in this case, the RDO (I guess this is what you mean when you mentione=
d "DIO" in you previous message) generation to discover the route is never =
ending until the temporary DAG dies ?
>=20
> [Mukul4] Never ending wont be the correct description. The temporary DAG =
lasts for a few seconds only. Plus, the trickle algorithm would prevent the=
 generation of many DIOs.
>=20
> [Cedric4]
> I guess the RDO flooding would stop according to the MaxRank/NH field  of=
 the P2P-RDO message.
>=20
> [Mukul4]
> Yes, it would. MaxRank and other routing constraints would always limit t=
he scope of route discovery. Note that there are two separate things:
> 1) scope of discovery: how far the discovery message (P2P-RDO inside the =
DIO) travels. This is controlled by the routing constraints and the maxRank=
 field inside the P2P-RDO.
> 2) How many discovery messages are generated by the nodes that join the D=
AG: this is controlled by trickle timer and ultimately by the DAG life time=
. The stop flag in the DRO is an optimization that allows DIO generation to=
 stop in the nodes that can hear the stop flag.

[Cedric5]
Actually, the problem for stopping the discovery process without the "S" fl=
ag is also present with unicast addresses, because not all nodes will hear =
the DRO (Only the nodes in the neighborhood of DRO forwarders).
So we ended with some nodes forming and maintaining a temporary DAG even is=
 they are not included in the discovered path, until the temporary DAG dies=
.
As you mentioned, the maxRank field, routing constraints, and trickle or DA=
G lifetime limit this overhead.
The section 9.2 of this draft give useful guidelines for trickle operation =
using the P2P RPL mechanism, and limit the flooding of RDO messages.
The only improvement we could add is to avoid the maintenance of some part =
of the temporary DAG that don't hear the DRO with the S flag.
This nodes will still send out some DIO when the trickle timer fires. Thoug=
h, thank's to the trickle's operation described in section 9.2, they won't =
be propagated.
One possibility could be to state that : "if a DRO has not been heard withi=
n a certain period of time, then their node is not considered as a part of =
the discovered path and should leave the temporary DAG".
This "certain period of time" could be determined according to the network =
topology, the application, or the network diameter for instance and let to =
the implementation.
I see a benefit in the case of a discovery process to a unicast target in a=
 very large and sparse network. Here, a lot of nodes will maintain unnecess=
ary states if they are not part of the discovered path.
With the current spec, they will send periodic and unnessecary DIO. The han=
dling of a "DRO timeout reception" could save packets, thus battery, bandwi=
dth etc...=20

>=20
> [Cedric4]
> But if this field is set to 0 (meaning infinity according to section 7.1)=
, we should find a mechanism to stop the discovery mechanism.
> What do you think ?
>=20
> [Mukul4]
> To tell the truth, MaxRank is basically a way to avoid putting a metric c=
ontainer in the DIO (when a limit on rank is the only constraint you want t=
o specify). The scope of discovery is limited by both MaxRank as well as th=
e routing constraints in the metric container.=20
>=20
>=20
>=20



From trac+roll@trac.tools.ietf.org  Wed Apr 11 07:16:11 2012
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 4BC3E21F8584 for ; Wed, 11 Apr 2012 07:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.475
X-Spam-Level: 
X-Spam-Status: No, score=-101.475 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 S6Exx2AMzwjt for ; Wed, 11 Apr 2012 07:16:10 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD0A21F8582 for ; Wed, 11 Apr 2012 07:16:09 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SHyL4-0001TP-Nj; Wed, 11 Apr 2012 10:16:03 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Wed, 11 Apr 2012 14:16:01 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/86#comment:2
Message-ID: <070.9560a9d9aa6ca2442092da51eb376ae2@trac.tools.ietf.org>
References: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 86
In-Reply-To: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #86: G flag: do we need that text?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2012 14:16:11 -0000

#86: G flag: do we need that text?

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 #86: G flag: do we need that text?

 Problem
 ------------------------------
 Disagreement on the meaning of 'G' bit and imposed setting to 0;

 Proposed resolution
 ---------------------------
 Add the following text to the draft:

 "The origin sets the G flag to indicate the relative importance of the
 route discovery it is initiating. The G flag is set to one if this
 particular route discovery is more important from application's
 perspective than some other route discovery. In other words, the origin
 sets the G flag to one if this particular route discovery helps meet the
 application defined goal \cite{rpl}. Thus, the G flag setting helps an
 intermediate router choose which route discoveries to participate in if it
 cannot participate in all route discoveries. An intermediate router SHOULD
 participate in route discoveries with G flag set to one (in preference to
 ones with G flag set to zero)."

 Discussion:
 -----------------

 [Pascal]
 " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in
 nature, is created solely for the purpose of P2P-RPL route discovery and
 MUST NOT be used for packet routing."

 On the contrary I'd set it to 1. The goal -being to reach the origin- is
 actually achieved by this DAG.

 [Mukul]
 Actually, the DAG is temporary in nature and vanishes after a short
 while. Even when it exists, it must/should not be used for routing
 packets back to the origin. So, I think the Grounded flag should be
 zero.

 [Pascal2] Please revisit RFC 6650 page 12.
 G means that a goal is achieved. So first you define the goal and then
 the bit becomes obvious. What's your goal?
 Can there be P2P DAGs that achieve the goal and others that make sense
 to build and yet do not achieve the goal?
 If you accept that your operation can actually depend on OF logic, then
 the setting of the goal influences that logic.
 By forcing a value to the goal in the PTP spec, we actually limit the
 applicability of the draft.
 Maybe you can define a default goal and a default setting. But do not
 MUST that it is set to 0...

 [Mukul2]
 When a node joins a temporary P2P DAG, it does not get any additional
 routing information. The DAG is going to disappear after some time,
 should not be used for routing while it exists and which nodes end up
 being on the discovered route is not known until the DRO message comes
 back. So, I think, by default, the G flag has to be zero. However, if
 the setting of G flag may affect how an intermediate node may calculate
 its rank (as per the OF being used), the origin should have the
 flexibility of setting the flag to 1. So, I could modify the text to say
 that "the origin sets the G flag based on its perception of how the
 flag's value would affect the rank calculation under the OF being used.
 By default, the G flag is set to zero given the temporary nature of the
 DAG being created."

 [Pascal3] Why do you feel the need to add anything above what RFC 6550
 says? I do not see any benefit or additional clarity from doing this.

 [Mukul3] RFC 6550 is actually kind of confusing in this regard. On page
 9, it says

 "A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data)."

 This seems to associate the goal with both OF and reachability to
 certain hosts. Later invocations of the term "goal" seem to refer just
 to the connectivity aspect, e.g., on page 18 RFC 6550 says

 "A grounded DODAG offers connectivity to hosts that are
   required for satisfying the application-defined goal."

 So, my understanding so far was that the "goal" defines connectivity to
 a certain hosts. The relation to objective function is not clear at all
 (if one restricts oneself to reading RFC 6550). The temporary DAGs
 created in P2P-RPL route discovery provide no connectivity whatsoever to
 the joining nodes. So, the only reason to set the G flag to 1 would be
 to allow correct use of an OF. So, I think P2P-RPL spec should use the
 text I offered above (and repeat below):

 "The origin sets the G flag based on its perception of whether joining
 how the flag's value would affect the rank calculation under the OF
 being used. By default, the G flag is set to zero given the temporary
 nature of the DAG being created."

 What do you think?

 [Pascal4] If you think this adds value, I will not oppose. Let's keep
 that as the proposed resolution

 [Mukul4] Sounds good.

 Proposed resolution text:

 "The origin sets the G flag based on its perception of whether joining
 how the flag's value would affect the rank calculation under the OF
 being used. By default, the G flag is set to zero given the temporary
 nature of the DAG being created."

 [Richard5]
 I disagree with the proposed resolution.  It adds needless confusion.
 The G flag is 0 if and only if the DODAG is floating.
 There is no point to allowing floating DODAGs with a P2P-RDO option.  I
 suggest that the G bit be set to 1 and that routers be explicitly
 prohibited from creating floating DODAGs with a P2P-RDO option.

 [Mukul5]
 The G flag is 0 if and only if the DODAG is floating.

 I think that the G flag is 1 if and only if the DODAG is grounded. The
 temporary DAGs used in P2P-RPL are not grounded, they are temporary. I
 think that all transient/temporary DAGs are floating by their very nature.

 [Michael5]
 I think we need to determine what a grounded DODAG is.
 Does it mean that a node announcing such a thing is attached to the
 Internet? (In which case P2P usage should G=0)
 Or does it mean that a node is attached to the resource named in the DIO?
 (In which case origin P2P should G=1)


 [Phillip5]
 The text in 6550 is pretty clear:

   Goal: The Goal is an application-specific goal that is defined
         outside the scope of RPL.  Any node that roots a DODAG will
         need to know about this Goal to decide whether or not the Goal
         can be satisfied.  A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data).

   Grounded: A DODAG is grounded when the DODAG root can satisfy the
         Goal.

   Floating: A DODAG is floating if it is not grounded.  A floating
         DODAG is not expected to have the properties required to
         satisfy the goal.  It may, however, provide connectivity to
         other nodes within the DODAG.

 The common case of the Goal is "has connectivity to the Internet" but
 that's not the only case. I think given the Goal for P2P traffic, I agree
 with Pascal and Richard that it should be 1.


 [Pascal6]
 Floating vs. Grounded depends on the goal of the DODAG. I asked you and
 will ask again what is your goal?
 If the goal is to reach the root, then G is 1... If you want to signal
 something to the OF using the G bit, leave it  open.

 [Mukul6]
 If the goal is to reach the root, then G is 1...

 I have told you multiple times that joining a P2P-RPL DAG does not give
 any sort of connectivity to the node.

 [Pascal7]
 I think we disagree because of the definition of goal itself. The goal is
 an abstraction. Same goes for the term Objective in OF. RFC 6550 only
 gives examples of what G could be used for but that is not limiting.
 Certainly the abstraction may for instance mean that external nodes are
 reachable via the root. But it could be something else entirely. For
 instance it could designate a root that can aggregate data.

 In practice, G is used to favor a root that reaches the goal vs. one that
 does not. But that's senseless for local instances that have by definition
 a single root.

 So whatever you set it to does not make a difference for RFC 6550
 operations. I figure it could be used for signaling a "transient goal"
 information to an OF that could use it for a purpose I can't fathom.

 In any case, as I suggested earlier and as Richard also suggest now, G
 SHOULD probably be 1 by default but MAY be set otherwise.

 [Mukul7]
 Richard wants the flag to always be either 0 or 1. He prefers it to be
 always 1 but would settle for it being always zero.

 I think this is not a critical point. I am OK with whatever resolution you
 and Richard arrive at. Kindly provide me the resolution text I should put
 in the draft.

 [Pascal8]
 I suggest a sentence that says that:

 1) For a local instance there can be only one root and one DODAG. G bit
 cannot and is not used for DODAG selection within an instance.
 2) In a given deployment, a goal can be defined that some P2P DODAGs
 achieve and others do not. The roots that achieve that goal will set the G
 bit in their P2P DAGs.
 3) the default goal is to create connectivity between origin and target.
 So by default G should be set to 1.
 4) if an intermediate router does not have enough resources to participate
 to all DODAGs then it should favor DODAGs with the G bit on.

 The exact wording is yours...

 [Mukul8]
 1) For a local instance there can be only one root and one DODAG. G bit
 cannot and is not used for DODAG selection within an instance.

 The statement above seems to be at odds with following two statements

 2) In a given deployment, a goal can be defined that some P2P DODAGs
 achieve and others do not. The roots that achieve that goal will set the G
 bit in their P2P DAGs.
 3) the default goal is to create connectivity between origin and target.
 So by default G should be set to 1.

 As per statement 1, the G flag can never be 1 for P2P-RPL DAGs because
 they use local instance ids.
 As per statement 2/3, the G flag could be 1 and is 1 by default.

 I am OK with setting G flag to 1 always (as you, Richard and Phil seem to
 prefer) but I dont know how to reason this. Do we need to provide a reason
 at all?

 [Pascal9]
 Statement 1 does not say that at all. Can't fathom how you concluded
 that... Let me try to reword: There is only what DODAG for a given local
 instance so there cannot be a selection => G cannot be used for a
 selection that cannot happen.

 As per statement 2/3, the G flag could be 1 and is 1 by default.

 Yes. I added an item to help the device prioritize when it is asker to
 participate to many DODAGs (for many P2P flows that it happens to be on
 the path of). In that case, and if the device cannot particpater to all
 the P2P DODAGs, then the G bit could be use to decide which are the most
 important.

 If you define a default goal that the DODAG fills, then you set G to one.
 For instance, G could mean 'important stuff' like swithing a light on.
 You'd set it for switching lights but not for reporting the hygrometry of
 your orchids, which anyway will be retried in a half hour. As a result, if
 the 2 DAG formations collide, the light on will have precedence...

 [Mukul9]
 How about the following text:

 "The origin sets the G flag to indicate the relative importance of the
 route discovery it is initiating. The G flag is set to one if this
 particular route discovery is more important from application's
 perspective than some other route discovery. In other words, the origin
 sets the G flag to one if this particular route discovery helps meet the
 application defined goal \cite{rpl}. Thus, the G flag setting helps an
 intermediate router choose which route discoveries to participate in if it
 cannot participate in all route discoveries. An intermediate router SHOULD
 participate in route discoveries with G flag set to one (in preference to
 ones with G flag set to zero)."

 [Pascal10]
 As far as I'm concerned you've captured it and I'm happy with this text.

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From jpv@cisco.com  Wed Apr 11 07:17:53 2012
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 D712511E8085 for ; Wed, 11 Apr 2012 07:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.433
X-Spam-Level: 
X-Spam-Status: No, score=-108.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_HI=-8, 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 ZawK3h+ynzJk for ; Wed, 11 Apr 2012 07:17:52 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B7E8811E8088 for ; Wed, 11 Apr 2012 07:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=12752; q=dns/txt; s=iport; t=1334153871; x=1335363471; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=GpYJ7DNmUk+7a5BabR8QMuJJZmngep18SIw3zfEb1E0=; b=XzsJSmKum3uKPyNJedhPyykMtyXU2i2em/RECSLBj6e3iRp+NaCSQce+ w7uN4B+bIK4wepzR2AW69fiAuKWZg1ZdPsfmwa0aj1OGkAiTn4X4njiax /D6AaqxwL4aBIzi6ypBylTZRzlNuCrC3SDhaRrokQ/BHSgThoAJLpG7BY g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIGACqShU+Q/khL/2dsb2JhbABFDoMOtjKBB4IKAQEEEgEnOAcQC0ZXBjWHbJp8oCyLJoU9YwSVbIVyiFuBaYIwOYFSARY
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="134842239"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2012 14:17:49 +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 q3BEHnVF029847; Wed, 11 Apr 2012 14:17:49 GMT
Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 11 Apr 2012 16:17:37 +0200
Received: from [10.60.114.227] ([10.60.114.227]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 16:17:36 +0200
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: JP Vasseur 
In-Reply-To: <723690941.1887908.1334112685750.JavaMail.root@mail17.pantherlink.uwm.edu>
Date: Wed, 11 Apr 2012 16:17:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <723690941.1887908.1334112685750.JavaMail.root@mail17.pantherlink.uwm.edu>
To: Mukul Goyal 
X-Mailer: Apple Mail (2.1257)
X-OriginalArrivalTime: 11 Apr 2012 14:17:36.0873 (UTC) FILETIME=[D863F590:01CD17ED]
Cc: roll , Michael Richardson 
Subject: Re: [Roll] Closure text for ticket #86
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, 11 Apr 2012 14:17:54 -0000

Thanks Mukul and the WG - Ticket closed.

JP.

On Apr 11, 2012, at 4:51 AM, Mukul Goyal wrote:

> #86: G flag: do we need that text?
>=20
> Problem
> ------------------------------
> Disagreement on the meaning of 'G' bit and imposed setting to 0;
>=20
> Proposed resolution
> ---------------------------
> Add the following text to the draft:
>=20
> "The origin sets the G flag to indicate the relative importance of the =
route discovery it is initiating. The G flag is set to one if this =
particular route discovery is more important from application's =
perspective than some other route discovery. In other words, the origin =
sets the G flag to one if this particular route discovery helps meet the =
application defined goal \cite{rpl}. Thus, the G flag setting helps an =
intermediate router choose which route discoveries to participate in if =
it cannot participate in all route discoveries. An intermediate router =
SHOULD participate in route discoveries with G flag set to one (in =
preference to ones with G flag set to zero)."
>=20
> Discussion:
> -----------------
>=20
> [Pascal]
> " Grounded (G) Flag: MUST be set to zero since this DAG is temporary =
in
> nature, is created solely for the purpose of P2P-RPL route discovery =
and
> MUST NOT be used for packet routing."
>=20
> On the contrary I'd set it to 1. The goal -being to reach the origin- =
is
> actually achieved by this DAG.
>=20
> [Mukul]
> Actually, the DAG is temporary in nature and vanishes after a short
> while. Even when it exists, it must/should not be used for routing
> packets back to the origin. So, I think the Grounded flag should be
> zero.
>=20
> [Pascal2] Please revisit RFC 6650 page 12.
> G means that a goal is achieved. So first you define the goal and then
> the bit becomes obvious. What's your goal?
> Can there be P2P DAGs that achieve the goal and others that make sense
> to build and yet do not achieve the goal?
> If you accept that your operation can actually depend on OF logic, =
then
> the setting of the goal influences that logic.
> By forcing a value to the goal in the PTP spec, we actually limit the
> applicability of the draft.
> Maybe you can define a default goal and a default setting. But do not
> MUST that it is set to 0...
>=20
> [Mukul2]
> When a node joins a temporary P2P DAG, it does not get any additional
> routing information. The DAG is going to disappear after some time,
> should not be used for routing while it exists and which nodes end up
> being on the discovered route is not known until the DRO message comes
> back. So, I think, by default, the G flag has to be zero. However, if
> the setting of G flag may affect how an intermediate node may =
calculate
> its rank (as per the OF being used), the origin should have the
> flexibility of setting the flag to 1. So, I could modify the text to =
say
> that "the origin sets the G flag based on its perception of how the
> flag's value would affect the rank calculation under the OF being =
used.
> By default, the G flag is set to zero given the temporary nature of =
the
> DAG being created."
>=20
> [Pascal3] Why do you feel the need to add anything above what RFC 6550
> says? I do not see any benefit or additional clarity from doing this.
>=20
> [Mukul3] RFC 6550 is actually kind of confusing in this regard. On =
page
> 9, it says
>=20
> "A typical Goal is to construct the DODAG
>         according to a specific Objective Function and to keep
>         connectivity to a set of hosts (e.g., to use an Objective
>         Function that minimizes a metric and is connected to a =
specific
>         database host to store the collected data)."
>=20
> This seems to associate the goal with both OF and reachability to
> certain hosts. Later invocations of the term "goal" seem to refer just
> to the connectivity aspect, e.g., on page 18 RFC 6550 says
>=20
> "A grounded DODAG offers connectivity to hosts that are
>   required for satisfying the application-defined goal."
>=20
> So, my understanding so far was that the "goal" defines connectivity =
to
> a certain hosts. The relation to objective function is not clear at =
all
> (if one restricts oneself to reading RFC 6550). The temporary DAGs
> created in P2P-RPL route discovery provide no connectivity whatsoever =
to
> the joining nodes. So, the only reason to set the G flag to 1 would be
> to allow correct use of an OF. So, I think P2P-RPL spec should use the
> text I offered above (and repeat below):
>=20
> "The origin sets the G flag based on its perception of whether joining
> how the flag's value would affect the rank calculation under the OF
> being used. By default, the G flag is set to zero given the temporary
> nature of the DAG being created."
>=20
> What do you think?
>=20
> [Pascal4] If you think this adds value, I will not oppose. Let's keep
> that as the proposed resolution
>=20
> [Mukul4] Sounds good.
>=20
> Proposed resolution text:
>=20
> "The origin sets the G flag based on its perception of whether joining
> how the flag's value would affect the rank calculation under the OF
> being used. By default, the G flag is set to zero given the temporary
> nature of the DAG being created."
>=20
> [Richard5]
> I disagree with the proposed resolution.  It adds needless confusion.
> The G flag is 0 if and only if the DODAG is floating.
> There is no point to allowing floating DODAGs with a P2P-RDO option.  =
I suggest that the G bit be set to 1 and that routers be explicitly =
prohibited from creating floating DODAGs with a P2P-RDO option.
>=20
> [Mukul5]
>> The G flag is 0 if and only if the DODAG is floating.
>=20
> I think that the G flag is 1 if and only if the DODAG is grounded. The =
temporary DAGs used in P2P-RPL are not grounded, they are temporary. I =
think that all transient/temporary DAGs are floating by their very =
nature.
>=20
> [Michael5]
>> I think we need to determine what a grounded DODAG is.
>> Does it mean that a node announcing such a thing is attached to the =
Internet? (In which case P2P usage should G=3D0)
>> Or does it mean that a node is attached to the resource named in the =
DIO? (In which case origin P2P should G=3D1)
>>=20
>=20
> [Phillip5]
> The text in 6550 is pretty clear:=20
>=20
>   Goal: The Goal is an application-specific goal that is defined
>         outside the scope of RPL.  Any node that roots a DODAG will
>         need to know about this Goal to decide whether or not the Goal
>         can be satisfied.  A typical Goal is to construct the DODAG
>         according to a specific Objective Function and to keep
>         connectivity to a set of hosts (e.g., to use an Objective
>         Function that minimizes a metric and is connected to a =
specific
>         database host to store the collected data).
>=20
>   Grounded: A DODAG is grounded when the DODAG root can satisfy the
>         Goal.
>=20
>   Floating: A DODAG is floating if it is not grounded.  A floating
>         DODAG is not expected to have the properties required to
>         satisfy the goal.  It may, however, provide connectivity to
>         other nodes within the DODAG.
>=20
> The common case of the Goal is "has connectivity to the Internet" but =
that's not the only case. I think given the Goal for P2P traffic, I =
agree with Pascal and Richard that it should be 1.
>=20
>=20
> [Pascal6]
> Floating vs. Grounded depends on the goal of the DODAG. I asked you =
and will ask again what is your goal?
> If the goal is to reach the root, then G is 1... If you want to signal =
something to the OF using the G bit, leave it  open.
>=20
> [Mukul6]
>> If the goal is to reach the root, then G is 1...
>=20
> I have told you multiple times that joining a P2P-RPL DAG does not =
give any sort of connectivity to the node.
>=20
> [Pascal7]
> I think we disagree because of the definition of goal itself. The goal =
is an abstraction. Same goes for the term Objective in OF. RFC 6550 only =
gives examples of what G could be used for but that is not limiting. =
Certainly the abstraction may for instance mean that external nodes are =
reachable via the root. But it could be something else entirely. For =
instance it could designate a root that can aggregate data.
>=20
> In practice, G is used to favor a root that reaches the goal vs. one =
that does not. But that's senseless for local instances that have by =
definition a single root.
>=20
> So whatever you set it to does not make a difference for RFC 6550 =
operations. I figure it could be used for signaling a "transient goal" =
information to an OF that could use it for a purpose I can't fathom.
>=20
> In any case, as I suggested earlier and as Richard also suggest now, G =
SHOULD probably be 1 by default but MAY be set otherwise.
>=20
> [Mukul7]
> Richard wants the flag to always be either 0 or 1. He prefers it to be =
always 1 but would settle for it being always zero.
>=20
> I think this is not a critical point. I am OK with whatever resolution =
you and Richard arrive at. Kindly provide me the resolution text I =
should put in the draft.
>=20
> [Pascal8]
> I suggest a sentence that says that:
>=20
> 1) For a local instance there can be only one root and one DODAG. G =
bit cannot and is not used for DODAG selection within an instance.=20
> 2) In a given deployment, a goal can be defined that some P2P DODAGs =
achieve and others do not. The roots that achieve that goal will set the =
G bit in their P2P DAGs.
> 3) the default goal is to create connectivity between origin and =
target. So by default G should be set to 1.
> 4) if an intermediate router does not have enough resources to =
participate to all DODAGs then it should favor DODAGs with the G bit on.
>=20
> The exact wording is yours...
>=20
> [Mukul8]
>> 1) For a local instance there can be only one root and one DODAG. G =
bit cannot and is not used for DODAG selection within an instance.=20
>=20
> The statement above seems to be at odds with following two statements
>=20
>> 2) In a given deployment, a goal can be defined that some P2P DODAGs =
achieve and others do not. The roots that achieve that goal will set the =
G bit in their P2P DAGs.
> 3) the default goal is to create connectivity between origin and =
target. So by default G should be set to 1.
>=20
> As per statement 1, the G flag can never be 1 for P2P-RPL DAGs because =
they use local instance ids.
> As per statement 2/3, the G flag could be 1 and is 1 by default.
>=20
> I am OK with setting G flag to 1 always (as you, Richard and Phil seem =
to prefer) but I dont know how to reason this. Do we need to provide a =
reason at all?
>=20
> [Pascal9]
> Statement 1 does not say that at all. Can't fathom how you concluded =
that... Let me try to reword: There is only what DODAG for a given local =
instance so there cannot be a selection =3D> G cannot be used for a =
selection that cannot happen.
>=20
>> As per statement 2/3, the G flag could be 1 and is 1 by default.
>=20
> Yes. I added an item to help the device prioritize when it is asker to =
participate to many DODAGs (for many P2P flows that it happens to be on =
the path of). In that case, and if the device cannot particpater to all =
the P2P DODAGs, then the G bit could be use to decide which are the most =
important.=20
>=20
> If you define a default goal that the DODAG fills, then you set G to =
one. For instance, G could mean 'important stuff' like swithing a light =
on. You'd set it for switching lights but not for reporting the =
hygrometry of your orchids, which anyway will be retried in a half hour. =
As a result, if the 2 DAG formations collide, the light on will have =
precedence...
>=20
> [Mukul9]
> How about the following text:
>=20
> "The origin sets the G flag to indicate the relative importance of the =
route discovery it is initiating. The G flag is set to one if this =
particular route discovery is more important from application's =
perspective than some other route discovery. In other words, the origin =
sets the G flag to one if this particular route discovery helps meet the =
application defined goal \cite{rpl}. Thus, the G flag setting helps an =
intermediate router choose which route discoveries to participate in if =
it cannot participate in all route discoveries. An intermediate router =
SHOULD participate in route discoveries with G flag set to one (in =
preference to ones with G flag set to zero)."
>=20
> [Pascal10]
> As far as I'm concerned you've captured it and I'm happy with this =
text.
>=20


From trac+roll@trac.tools.ietf.org  Wed Apr 11 07:20:35 2012
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 908EB11E808C for ; Wed, 11 Apr 2012 07:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.493
X-Spam-Level: 
X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 Zv1-O5O6ZtVK for ; Wed, 11 Apr 2012 07:20:34 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7496C11E8088 for ; Wed, 11 Apr 2012 07:20:34 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SHyPR-0001Hv-EV; Wed, 11 Apr 2012 10:20:33 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Wed, 11 Apr 2012 14:20:33 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/93#comment:1
Message-ID: <070.4d1aea1790327f84e7ff686ae95a4f85@trac.tools.ietf.org>
References: <055.ed950f694b72a8ba34415940cc53be68@trac.tools.ietf.org>
X-Trac-Ticket-ID: 93
In-Reply-To: <055.ed950f694b72a8ba34415940cc53be68@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2012 14:20:35 -0000

#93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4?

Changes (by jpv@…):

 * cc: roll@… (added)
 * status:  new => closed
 * resolution:   => fixed


Old description:

> Resolution: Open
>
> Discussion:
>
> p12 :  This specification does not allow for the establishment of hop-by-
> hop routes in the backward direction.
>
> [Cedric]
> Why ? This would enable to establish 2 routes within a single route
> request.
> Furthermore, you stipulates in the draft that links have to be
> bidirectional to propagates RDO, in order to be able to send back the
> DRO.
> So if I understand it correctly you ensure that you have a reliable path
> in both ways. Why using it in a single way only ?
>
> [Mukul]
> Suppose a DRO establishing a forward hop-by-hop route fails to make it to
> the origin. In this case, all we have is some nodes storing the hop-by-
> hop state for a broken route but that route is never used since the
> origin never gets the DRO. On the other hand, if the DRO establishing a
> backward hop-by-hop route fails to make it to the origin, we have a
> broken route that the target is likely to use (to reach the origin). So,
> if we want P2P-RPL to establish a backward hop-by-hop route, the target
> MUST ask for a DRO-ACK from the origin (to make sure that the DRO does
> reach the origin and hence the backward route is not broken). This can be
> done if you think it will be useful. We did not include this in P2P-RPL
> because we did not have a usecase for backward hop-by-hop routes and we
> wanted to avoid the additional complexity.
>
> This is how we can implement this functionality: we will let the target
> decide whether it wants the DRO to establish a backward hop-by-hop route.
> In that case:
> 1) the target will set a new flag, the B flag (B for backward hop-by-hop
> route), inside the DRO to let intermediate routers know that backward
> route state needs to be established as well;
> 2) the target will set the A flag to require a DRO-ACK from the origin;
> 3) the target will specify (inside a new field in the DRO), an
> RPLInstanceID under which the hop-by-hop state for the backward route
> will be stored. Note that the RPLInstanceID of the forward route
> (selected by the origin) may not be OK for use in backward route (because
> the target may have already used this RPLInstanceID for another hop-by-
> hop route, using different routing-metrics/constraints/OF, to the
> origin).
> When the intermediate routers receive this DRO, they will store the hop-
> by-hop state for the backward route. This hop-by-hop state will consist
> of:
> 1) Target address (taken from P2P-RDO inside the DRO).
> 2) RPLInstanceID specified by the target
> 3) The destination, i.e., the origin address (same as DODAGID inside the
> DRO).
>
> Do you want this functionality?

New description:

 #93: Whether P2P-RPL should support establishment of a backward hop-by-hop
 route?

 Resolution:
 ---------------

 No need to do so in current spec as it has experimental intended status.
 Using the discovered route as a source route or the piggybacked data
 option is sufficient for now.
 If this draft wants to step up to a standard track, then it could be
 valuable to discuss the backward hop by hop route establishment.

 Discussion:
 -----------------

 p12 :  This specification does not allow for the establishment of hop-by-
 hop routes in the backward direction.

 [Cedric]
 Why ? This would enable to establish 2 routes within a single route
 request.
 Furthermore, you stipulates in the draft that links have to be
 bidirectional to propagates RDO, in order to be able to send back the DRO.
 So if I understand it correctly you ensure that you have a reliable path
 in both ways. Why using it in a single way only ?

 [Mukul]
 Suppose a DRO establishing a forward hop-by-hop route fails to make it to
 the origin. In this case, all we have is some nodes storing the hop-by-hop
 state for a broken route but that route is never used since the origin
 never gets the DRO. On the other hand, if the DRO establishing a backward
 hop-by-hop route fails to make it to the origin, we have a broken route
 that the target is likely to use (to reach the origin). So, if we want
 P2P-RPL to establish a backward hop-by-hop route, the target MUST ask for
 a DRO-ACK from the origin (to make sure that the DRO does reach the origin
 and hence the backward route is not broken). This can be done if you think
 it will be useful. We did not include this in P2P-RPL because we did not
 have a usecase for backward hop-by-hop routes and we wanted to avoid the
 additional complexity.

 This is how we can implement this functionality: we will let the target
 decide whether it wants the DRO to establish a backward hop-by-hop route.
 In that case:
 1) the target will set a new flag, the B flag (B for backward hop-by-hop
 route), inside the DRO to let intermediate routers know that backward
 route state needs to be established as well;
 2) the target will set the A flag to require a DRO-ACK from the origin;
 3) the target will specify (inside a new field in the DRO), an
 RPLInstanceID under which the hop-by-hop state for the backward route will
 be stored. Note that the RPLInstanceID of the forward route (selected by
 the origin) may not be OK for use in backward route (because the target
 may have already used this RPLInstanceID for another hop-by-hop route,
 using different routing-metrics/constraints/OF, to the origin).
 When the intermediate routers receive this DRO, they will store the hop-
 by-hop state for the backward route. This hop-by-hop state will consist
 of:
 1) Target address (taken from P2P-RDO inside the DRO).
 2) RPLInstanceID specified by the target
 3) The destination, i.e., the origin address (same as DODAGID inside the
 DRO).

 Do you want this functionality?

 [Cedric2]
 The group has to discuss and decide wether it is usefull or not. I
 personnaly think that RPL-P2P draft may be used for binding devices, so it
 could be valuable to create a 2 way path between the origin and the
 target. So I would vote in favor of such a mechanism.

 Though, I don't think we should create a new DAG (i.e. select a new
 RPLInstanceID) for the backward route. What I would like is just the
 ability for 2 devices to exchange packet in both ways using the same
 temporary DAG created by RPL-P2P. Let me explain the use case with an
 example : For instance, if you have nodes deployed in a building or a
 city, and you want to configure some of them. An operator could go in the
 area where devices to be programmed are installed (or in the neighborhood
 at least) with a "configurator node", and need to established a P2P route
 between this configurator node and the node(s) to be configurated. They
 create a temporary DAG (possibly through several hops) and exchange
 configuration frames. Because such messages are  critically important, you
 often need application layer acknowledgments, so a backward route is
 needed.

 Is the actual specification compliant with such a use case without
 modification ? (using piggybacked DATA inside RDO and DRO messages) ? Or
 do wee need an additional mechanism such as the one you described ?

 [Mukul2]
 The target can always use the route inside a received P2P-RDO to source-
 route a message (e.g. an application level ack) back to the origin. Also,
 as you noticed, the target can place one or more data options inside the
 DRO to send an application level message back to the origin. So, the use
 case you have mentioned (which is, by the way, a common use case in
 commercial building environment) is supported by current P2P-RPL
 specification. In my view, no additional mechanism is required if the
 intent is to just support the usecase you described. Infact, we could not
 come up with a usecase where backward hop-by-hop routes are absolutely
 must. So, we decided to keep the specs simple by not allowing
 establishment of such routes. Also, currently we are shooting for an
 experimental RFC. If, at a later stage, we realize that backward hop-by-
 hop routes are necessary, we could support them in standards track RFC.

 [Cedric3]
 Ok, the data option seems simple and efficient enough for the use case I
 pointed out.
 Let's keep it as the default option to do simple P2P data exchange.

 [Mukul3]
 Whether the target uses data option in the DRO or a regular data packet
 (source routed using the discovered route) to reach the origin is target's
 prerogative. P2P-RPL spec has to be silent in this matter.

 [Cedric3]
 If more periodic and reliable traffic is needed between 2 nodes in a RPL
 network, then I think we should include a 2 way path establishment.

 [Mukul3]
 So you want backward hop-by-hop route? Target using the discovered route
 as a source route won't be sufficient?

 [Cedric4]
 Let me reword it : I'm OK to close this ticket as it is an experimental
 intended status.
 Using the discovered route as a source route is sufficient, and the picky
 backed data option is OK with what I had in mind.
 If this draft wants to step up to a standard track, then it could be
 valuable to discuss the backward hop by hop route establishment.

--

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From jpv@cisco.com  Wed Apr 11 07:21:31 2012
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 5F89911E8085 for ; Wed, 11 Apr 2012 07:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.516
X-Spam-Level: 
X-Spam-Status: No, score=-109.516 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 51ZRrgl2K7LR for ; Wed, 11 Apr 2012 07:21:30 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0F11211E8072 for ; Wed, 11 Apr 2012 07:21:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=6923; q=dns/txt; s=iport; t=1334154089; x=1335363689; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CCtyCoMa8aghWnACWHb7SAXbq8NoFKQigZYGNCseOf0=; b=QBYdFshIXnYPU6Z9nzYt2AIJLI69smItpX8u1iUFBPbrZLvFpBCtgU4S jLHhGXld3xHojAnC+q6mxBoiVpPgQJ058v6XKOoOzwaKA39SAi5wr12B7 f7ccV3SIBw74ok6NwEGlGugKfO+1z6uWo3bPBgHUjeP/Ev/leDnnZXgvS I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIGACqShU+Q/khM/2dsb2JhbABFDoMOtjKBB4IKAQEEAQEBDwEnNAYFEAtGJzAGEyKHbAuacaAoBJBjYwSVbIVyiFuBaYIwOYFSFw
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="134842684"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2012 14:21:16 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3BEL9il028181; Wed, 11 Apr 2012 14:21:09 GMT
Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 11 Apr 2012 16:21:09 +0200
Received: from [10.60.114.227] ([10.60.114.227]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 16:21:08 +0200
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: JP Vasseur 
In-Reply-To: <191646880.1889576.1334148799902.JavaMail.root@mail17.pantherlink.uwm.edu>
Date: Wed, 11 Apr 2012 16:21:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <191646880.1889576.1334148799902.JavaMail.root@mail17.pantherlink.uwm.edu>
To: Mukul Goyal 
X-Mailer: Apple Mail (2.1257)
X-OriginalArrivalTime: 11 Apr 2012 14:21:08.0505 (UTC) FILETIME=[56887090:01CD17EE]
Cc: roll 
Subject: Re: [Roll] Closure text for ticket #93
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, 11 Apr 2012 14:21:31 -0000

Ticket closed.

On Apr 11, 2012, at 2:53 PM, Mukul Goyal wrote:

> #93: Whether P2P-RPL should support establishment of a backward =
hop-by-hop route?
>=20
> Resolution:
> ---------------
>=20
> No need to do so in current spec as it has experimental intended =
status.
> Using the discovered route as a source route or the piggybacked data =
option is sufficient for now.
> If this draft wants to step up to a standard track, then it could be =
valuable to discuss the backward hop by hop route establishment.
>=20
> Discussion:
> -----------------
>=20
> p12 :  This specification does not allow for the establishment of =
hop-by-  hop routes in the backward direction.
>=20
> [Cedric]
> Why ? This would enable to establish 2 routes within a single route  =
request.
> Furthermore, you stipulates in the draft that links have to be  =
bidirectional to propagates RDO, in order to be able to send back the =
DRO.
> So if I understand it correctly you ensure that you have a reliable =
path  in both ways. Why using it in a single way only ?
>=20
> [Mukul]
> Suppose a DRO establishing a forward hop-by-hop route fails to make it =
to  the origin. In this case, all we have is some nodes storing the =
hop-by-hop  state for a broken route but that route is never used since =
the origin  never gets the DRO. On the other hand, if the DRO =
establishing a backward  hop-by-hop route fails to make it to the =
origin, we have a broken route  that the target is likely to use (to =
reach the origin). So, if we want  P2P-RPL to establish a backward =
hop-by-hop route, the target MUST ask for  a DRO-ACK from the origin (to =
make sure that the DRO does reach the origin  and hence the backward =
route is not broken). This can be done if you think  it will be useful. =
We did not include this in P2P-RPL because we did not  have a usecase =
for backward hop-by-hop routes and we wanted to avoid the  additional =
complexity.
>=20
> This is how we can implement this functionality: we will let the =
target  decide whether it wants the DRO to establish a backward =
hop-by-hop route.
> In that case:
> 1) the target will set a new flag, the B flag (B for backward =
hop-by-hop  route), inside the DRO to let intermediate routers know that =
backward  route state needs to be established as well;
> 2) the target will set the A flag to require a DRO-ACK from the =
origin;
> 3) the target will specify (inside a new field in the DRO), an  =
RPLInstanceID under which the hop-by-hop state for the backward route =
will  be stored. Note that the RPLInstanceID of the forward route =
(selected by  the origin) may not be OK for use in backward route =
(because the target  may have already used this RPLInstanceID for =
another hop-by-hop route,  using different =
routing-metrics/constraints/OF, to the origin).
> When the intermediate routers receive this DRO, they will store the =
hop-  by-hop state for the backward route. This hop-by-hop state will =
consist of:
> 1) Target address (taken from P2P-RDO inside the DRO).
> 2) RPLInstanceID specified by the target
> 3) The destination, i.e., the origin address (same as DODAGID inside =
the  DRO).
>=20
> Do you want this functionality?
>=20
> [Cedric2]=20
> The group has to discuss and decide wether it is usefull or not. I =
personnaly think that RPL-P2P draft may be used for binding devices, so =
it could be valuable to create a 2 way path between the origin and the =
target. So I would vote in favor of such a mechanism.=20
>=20
> Though, I don't think we should create a new DAG (i.e. select a new =
RPLInstanceID) for the backward route. What I would like is just the =
ability for 2 devices to exchange packet in both ways using the same =
temporary DAG created by RPL-P2P. Let me explain the use case with an =
example : For instance, if you have nodes deployed in a building or a =
city, and you want to configure some of them. An operator could go in =
the area where devices to be programmed are installed (or in the =
neighborhood at least) with a "configurator node", and need to =
established a P2P route between this configurator node and the node(s) =
to be configurated. They create a temporary DAG (possibly through =
several hops) and exchange configuration frames. Because such messages =
are  critically important, you often need application layer =
acknowledgments, so a backward route is needed.
>=20
> Is the actual specification compliant with such a use case without =
modification ? (using piggybacked DATA inside RDO and DRO messages) ? Or =
do wee need an additional mechanism such as the one you described ?
>=20
> [Mukul2]
> The target can always use the route inside a received P2P-RDO to =
source-route a message (e.g. an application level ack) back to the =
origin. Also, as you noticed, the target can place one or more data =
options inside the DRO to send an application level message back to the =
origin. So, the use case you have mentioned (which is, by the way, a =
common use case in commercial building environment) is supported by =
current P2P-RPL specification. In my view, no additional mechanism is =
required if the intent is to just support the usecase you described. =
Infact, we could not come up with a usecase where backward hop-by-hop =
routes are absolutely must. So, we decided to keep the specs simple by =
not allowing establishment of such routes. Also, currently we are =
shooting for an experimental RFC. If, at a later stage, we realize that =
backward hop-by-hop routes are necessary, we could support them in =
standards track RFC.=20
>=20
> [Cedric3]
> Ok, the data option seems simple and efficient enough for the use case =
I pointed out.
> Let's keep it as the default option to do simple P2P data exchange.
>=20
> [Mukul3]
> Whether the target uses data option in the DRO or a regular data =
packet (source routed using the discovered route) to reach the origin is =
target's prerogative. P2P-RPL spec has to be silent in this matter.=20
>=20
> [Cedric3]
> If more periodic and reliable traffic is needed between 2 nodes in a =
RPL network, then I think we should include a 2 way path establishment.
>=20
> [Mukul3]
> So you want backward hop-by-hop route? Target using the discovered =
route as a source route won't be sufficient?
>=20
> [Cedric4]
> Let me reword it : I'm OK to close this ticket as it is an =
experimental intended status.
> Using the discovered route as a source route is sufficient, and the =
picky backed data option is OK with what I had in mind.
> If this draft wants to step up to a standard track, then it could be =
valuable to discuss the backward hop by hop route establishment.
>=20
>=20
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From trac+roll@trac.tools.ietf.org  Wed Apr 11 10:10:29 2012
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 8691221F84D0 for ; Wed, 11 Apr 2012 10:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level: 
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 v9CoIIu2S5P7 for ; Wed, 11 Apr 2012 10:10:29 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DE9B121F84C8 for ; Wed, 11 Apr 2012 10:10:28 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SI13l-000773-MM; Wed, 11 Apr 2012 13:10:22 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Wed, 11 Apr 2012 17:10:20 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/86#comment:3
Message-ID: <070.9c8bc623eee8027740d27f94026e7d42@trac.tools.ietf.org>
References: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 86
In-Reply-To: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #86: G flag: do we need that text?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2012 17:10:29 -0000

#86: G flag: do we need that text?

Changes (by jpv@…):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 RE-OPENING Ticket - Comments from Richard Kelsey

-- 
-----------------------------------+-----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  reopened
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:
 Keywords:                         |
-----------------------------------+-----------------------

Ticket URL: 
roll 


From prvs=441eb7f02=mukul@uwm.edu  Wed Apr 11 10:44:53 2012
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 084E621F8557 for ; Wed, 11 Apr 2012 10:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.229
X-Spam-Level: 
X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370,  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 QRApU79w+7Gd for ; Wed, 11 Apr 2012 10:44:51 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id A244021F8554 for ; Wed, 11 Apr 2012 10:44:51 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEANrChU9/AAAB/2dsb2JhbABEhWa2fyNWGxoCDRIHAlkGLId1qBqKEokJgS+JdgGFCIEYBIhajRKQNoMFgTYBFg
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 23E461FD0C7; Wed, 11 Apr 2012 12:32:08 -0500 (CDT)
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 vCgPo3zdzHQO; Wed, 11 Apr 2012 12:32:07 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id C6BA51FD0B7; Wed, 11 Apr 2012 12:32:07 -0500 (CDT)
Date: Wed, 11 Apr 2012 12:32:07 -0500 (CDT)
From: Mukul Goyal 
To: C Chauvenet 
Message-ID: <1480539095.1895120.1334165527537.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <042A14A9-10A8-42BF-8F07-489E981F7D98@watteco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.91]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Cc: roll 
Subject: Re: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
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, 11 Apr 2012 17:44:53 -0000

Please see inline.

Thanks
Mukul

>> #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
>> 
>> Resolution: No because multiple DROs would be generated if multiple source  routes are being discovered.
>> 
>> Discussion:
>> 
>> p15 :  Stop (S): This flag, when set to one by a target, indicates that  the P2P-RPL route discovery is over.
>> 
>> [Cedric]
>> Is this bit really usefull ? My guess is that it will be always set to 1.
>> If you hear a DRO, this indeed means that the RDO has reached the target,  so you could just stop processing RDO when you hear a DRO.
>> Do we really need a flag to stop RDO processing or the hearing of a DRO  type message could do the job ?
>> 
>> [Mukul]
>> A P2P-RPL invocation might involve discovery of multiple source routes. In  that case, receipt of a DRO does not mean route discovery is over. Only  when the target sets the stop flag in the DRO, a node could be sure that  the route discovery is over.
>> 
>> [Cedric2]
>> OK fo multiple discovery.
>> But if I want to discover a route to a multicast group of target. I set a multicast adress in the target field of the RDO. Then, do I received as many DRO message as the number of target reached ? In that case, would the first DRO with a "S" flag stop the RDO propagation to reach all the target included in the multicast group ?
>> 
>> [Mukul2]
>> A target cannot set the S flag to one in the DRO if the target address in the P2P-RDO specified a multicast address. See the following text at the end of page 21 in P2P-RPL-9:
>> 
>> "The target MAY set the stop flag inside the DRO message to one if
>> 
>> 
>> 
>> Goyal, et al.           Expires September 7, 2012              [Page 21]
>> 
>> Internet-Draft         draft-ietf-roll-p2p-rpl-09             March 2012
>> 
>> 
>>  o  this router is the only target specified in the corresponding DIO,
>>     i.e., the corresponding DIO specified a unicast address of the
>>     router as the Target inside the P2P-RDO with no additional targets
>>     specified via RPL Target Options; and
>> 
>> " 
>> 
>> [Cedric3] 
>> So how do you stop the RDO flooding when the target adress is mulicast ? 
>> 
>> [Mukul3]
>> 
>> Stop flag cannot be used when the target address is multicast or when multiple unicast targets are there. The DIO generation will stop when the DAG dies. In the meanwhile, trickle algorithm would hopefully avoid unnecessary message generation. Note that the draft recommends a very small value for the redundancy constant.
> 
> [Cedric4]
> So in this case, the RDO (I guess this is what you mean when you mentioned "DIO" in you previous message) generation to discover the route is never ending until the temporary DAG dies ?
> 
> [Mukul4] Never ending wont be the correct description. The temporary DAG lasts for a few seconds only. Plus, the trickle algorithm would prevent the generation of many DIOs.
> 
> [Cedric4]
> I guess the RDO flooding would stop according to the MaxRank/NH field  of the P2P-RDO message.
> 
> [Mukul4]
> Yes, it would. MaxRank and other routing constraints would always limit the scope of route discovery. Note that there are two separate things:
> 1) scope of discovery: how far the discovery message (P2P-RDO inside the DIO) travels. This is controlled by the routing constraints and the maxRank field inside the P2P-RDO.
> 2) How many discovery messages are generated by the nodes that join the DAG: this is controlled by trickle timer and ultimately by the DAG life time. The stop flag in the DRO is an optimization that allows DIO generation to stop in the nodes that can hear the stop flag.

> 
> [Cedric4]
> But if this field is set to 0 (meaning infinity according to section 7.1), we should find a mechanism to stop the discovery mechanism.
> What do you think ?
> 
> [Mukul4]
> To tell the truth, MaxRank is basically a way to avoid putting a metric container in the DIO (when a limit on rank is the only constraint you want to specify). The scope of discovery is limited by both MaxRank as well as the routing constraints in the metric container. 

[Cedric5]
Actually, the problem for stopping the discovery process without the "S" flag is also present with unicast addresses, because not all nodes will hear the DRO (Only the nodes in the neighborhood of DRO forwarders).
So we ended with some nodes forming and maintaining a temporary DAG even is they are not included in the discovered path, until the temporary DAG dies.
As you mentioned, the maxRank field, routing constraints, and trickle or DAG lifetime limit this overhead.
The section 9.2 of this draft give useful guidelines for trickle operation using the P2P RPL mechanism, and limit the flooding of RDO messages.
The only improvement we could add is to avoid the maintenance of some part of the temporary DAG that don't hear the DRO with the S flag.
This nodes will still send out some DIO when the trickle timer fires. Though, thank's to the trickle's operation described in section 9.2, they won't be propagated.
One possibility could be to state that : "if a DRO has not been heard within a certain period of time, then their node is not considered as a part of the discovered path and should leave the temporary DAG".

[Mukul5]
Two problems:
1) An intermediate router has no idea how long the target wants to wait before generating DRO.
2) If an intermediate router leaves the DAG early (ie before the DAG's lifetime is over), it might end up rejoining the DAG when it hears the DAG's DIO again.

[Cedric5] 
This "certain period of time" could be determined according to the network topology, the application, or the network diameter for instance and let to the implementation.

[Mukul5]
It would be much easier if the origin could choose a small (yet reasonable) lifetime for the DAG.

[Cedric5]
I see a benefit in the case of a discovery process to a unicast target in a very large and sparse network. Here, a lot of nodes will maintain unnecessary states if they are not part of the discovered path.
With the current spec, they will send periodic and unnessecary DIO. The handling of a "DRO timeout reception" could save packets, thus battery, bandwidth etc... 

[Mukul5]
I am not sure this will work as I explained above.
> 
> 
> 



From prvs=441eb7f02=mukul@uwm.edu  Wed Apr 11 16:14:51 2012
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 015E911E8102 for ; Wed, 11 Apr 2012 16:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.239
X-Spam-Level: 
X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.360,  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 txR3llyZfSGo for ; Wed, 11 Apr 2012 16:14:50 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7F26C11E80D9 for ; Wed, 11 Apr 2012 16:14:47 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAJoPhk9/AAAB/2dsb2JhbABDhXK3DSNWNQINGQJZBoghrBGJfYEhgS+PLoEYBIhajRKQNoMF
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 098301FD0B8; Wed, 11 Apr 2012 18:14:42 -0500 (CDT)
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 ShvQGOXsT2F2; Wed, 11 Apr 2012 18:14:41 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D72951FD0B7; Wed, 11 Apr 2012 18:14:41 -0500 (CDT)
Date: Wed, 11 Apr 2012 18:14:41 -0500 (CDT)
From: Mukul Goyal 
To: C Chauvenet 
Message-ID: <2058754072.1901974.1334186081750.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <820013775.1852322.1333923401124.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.91]
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] closure text for ticket #97
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, 11 Apr 2012 23:14:51 -0000

#97: A fixed value for DRO_ACK_WAIT_TIME not OK for all P2P-RPL deployments.

Resolution:
------------------------
 Make DRO_ACK_WAIT_TIME as well as MAX_DRO_RETRANSMISSIONS  configurable parameters.

Discussion:
-------------------------
 p25 :  o DRO_ACK_WAIT_TIME: The time duration a target waits for the DRO-  ACK before retransmitting a DRO message. DRO_ACK_WAIT_TIME has a
      value of 1 second.

 [Cedric]
 I'm not sure it is compliant with all RPL deployments.
 Could we adapt it to the characteristics of the network used ?

 [Mukul]
 I am OK with making DRO_ACK_WAIT_TIME as well as MAX_DRO_RETRANSMISSIONS  configurable parameters.

[Cedric2]
Safe enough.


From prvs=441eb7f02=mukul@uwm.edu  Wed Apr 11 16:21:25 2012
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 3590311E8109 for ; Wed, 11 Apr 2012 16:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.350,  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 fQJBjWVu68dE for ; Wed, 11 Apr 2012 16:21:20 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 711E211E8102 for ; Wed, 11 Apr 2012 16:21:19 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAAYRhk9/AAAB/2dsb2JhbABEhWa3DSNWNQINGQJZBoghp3uJe4kJgS+PLoEYBIhajRKQNoMF
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id B51C5E6A8D; Wed, 11 Apr 2012 18:18:55 -0500 (CDT)
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 0-y0nSbdvCYq; Wed, 11 Apr 2012 18:18:55 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 80904E6A72; Wed, 11 Apr 2012 18:18:55 -0500 (CDT)
Date: Wed, 11 Apr 2012 18:18:55 -0500 (CDT)
From: Mukul Goyal 
To: C Chauvenet 
Message-ID: <1197036182.1902018.1334186335455.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D0221AE9F@AMXPRD0510MB390.eurprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.91]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Cc: roll@ietf.org
Subject: [Roll] Closure text for ticket #96
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, 11 Apr 2012 23:21:25 -0000

#96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs?

Resolution:
-----------------
 This is purely a local decision at the target. The draft  should not make any recommendation in this regard.

Discussion:
-----------------
 p21 :  Example methods include selecting each route that meets the  specified routing constraints
   until the desired number have been selected or selecting the best
   routes discovered over a certain time period.

 [Cedric]
 How could we know the time to wait until we get all the RDO ?
 Is there a way to evaluate it according to some parameters related to the  network (diameter of the network for instance) ?

 [Mukul] This has to be a local decision. Perhaps, the target can look at  the aggregated values of the routing metrics from the origin and determine  its distance from the origin. This distance estimate, along with trickle  parameters, could perhaps give it a better idea of how much to wait. I  dont think that the draft should talk about this.

[Cedric2]
OK, let's say it is up to the implementation and should be deterinied according to the specific set of metric/contraints in use.
A target from a DAG based on a latency metric could wait just a few ms after receiving the first RDO  and select the best path according to the latency metric.
A target from a DAG based on a energy metric could wait much more time after receiving the first RDO to be sure to use an energy efficient path, that could be discovered after some time, because of duty cycling nodes for instance.

[Mukul2] Choosing the wait time on the basis of specific metrics being used in route discovery could be one option. However, when an origin wants to discover low latency routes, it does not necessarily mean that the latency of the route discovery process has to be low as well. :) So, in general, I think that the time a target waits before sending DROs (which determines to some extent the latency of the route discovery process) is independent of the specific metrics/constraints being used in route discovery process. As I said before, I think the target should decide for itself how much should it wait before sending DRO(s). It may not be wise to make any suggestions in this regard in the P2P-RPL specs beyond what the draft already says - the draft does suggest two sample methods: 1) select routes on FCFS basis 2) choose the best routes discovered over an interval. 

[Cedric3]
Yes good point. So I think the draft is generic enough regarding this parameter.  


From prvs=441eb7f02=mukul@uwm.edu  Wed Apr 11 16:24:17 2012
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 0685C11E8102 for ; Wed, 11 Apr 2012 16:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.258
X-Spam-Level: 
X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=0.341,  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 Je8TKAGhppQL for ; Wed, 11 Apr 2012 16:24:16 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4A211E809D for ; Wed, 11 Apr 2012 16:24:16 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAAYRhk9/AAAB/2dsb2JhbABEhWa3DSNWNQINGQJZBoghp3uJe4kJgS+PLoEYBIhajRKQNoMFgTYX
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 5534DE6A90; Wed, 11 Apr 2012 18:23:59 -0500 (CDT)
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 lkJuI9NcTqRZ; Wed, 11 Apr 2012 18:23:59 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 2C35CE6A72; Wed, 11 Apr 2012 18:23:59 -0500 (CDT)
Date: Wed, 11 Apr 2012 18:23:59 -0500 (CDT)
From: Mukul Goyal 
To: C Chauvenet 
Message-ID: <902775528.1902060.1334186639127.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D022165B2@AMXPRD0510MB390.eurprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.91]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Cc: roll@ietf.org
Subject: [Roll] Closure text for ticket #94
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, 11 Apr 2012 23:24:17 -0000

#94: Why does DRO travel by multicast.

Resolution:
--------------
 Because we want the stop flag in DRO to reach as many nodes as  possible.

Discussion:
---------------

 p14 :  A DRO message travels from the target to the origin via link-local  multicast along the
   route specified inside the Address vector in the P2P-RDO.

 [Cedric]
 Why using multicast if you know every destinators ?
 Could we unicast packets to each destinators in the address vector ?

 [Mukul]
 DRO travels by link local multicast so that the nodes, that are on the  temporary DAG but not necessarily on a discovered route, may know that the  route discovery is over (via the stop flag) and there is no need to  generate any more DIOs. This may lead to a significant reduction in the
 (unnecessary) DIOs generated. Only the routers on the discovered route do  the multicast-based forwarding though.

[Cedric2]
Makes sense, thank's for clarification.
This ticket can be closed.

From prvs=441eb7f02=mukul@uwm.edu  Wed Apr 11 16:29:31 2012
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 86A0811E8109 for ; Wed, 11 Apr 2012 16:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.266
X-Spam-Level: 
X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.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 z74ST4oJvLiW for ; Wed, 11 Apr 2012 16:29:31 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id F149A11E809D for ; Wed, 11 Apr 2012 16:29:30 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAIEShk9/AAAB/2dsb2JhbABEhWa3ECNWNQINGQJZBoghqAWJeIkJgS+PLoEYBIhajRKQNoMFgTYX
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 8BF632B3F0A; Wed, 11 Apr 2012 18:29:30 -0500 (CDT)
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 cH2QE3Y-69PC; Wed, 11 Apr 2012 18:29:30 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 630802B3EF6; Wed, 11 Apr 2012 18:29:30 -0500 (CDT)
Date: Wed, 11 Apr 2012 18:29:30 -0500 (CDT)
From: Mukul Goyal 
To: C Chauvenet 
Message-ID: <264116309.1902104.1334186970290.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <287665186.1851186.1333901473996.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.91]
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] Closure text for ticket #92
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, 11 Apr 2012 23:29:31 -0000

#92: Is it possible to make P2P-RPL independent of trickle algorithm

Resolution:
----------------
No. P2P-RPL depends on DAG creation for route discovery which inturn inherently depends on trickle algorithm.

Discussion:
-----------------

 [Cedric]
 Another point that has been discussed today during the ROLL meeting, is  that some people may find other mechanisms than trickle more efficient to  flood the RDO.
 Could we let the door opened to other flooding optimization mechanism, or  explicitly say that the trickle mechanism MUST be used ?

 [Mukul]
 I think inherent dependence on the trickle mechanism is apparent because  of the fact that the route discovery takes place by forming a temporary  DAG. DAG creation (or DIO generation) depends on trickle algorithm. So,  P2P-RPL also depends on trickle algorithm. P2P-RPL being an extension of  core RPL, I dont think there is a way to separate P2P-RPL from trickle  algorithm.

[Cedric2]
Fine. If this is needed for RPL compliancy, then I agree.


From prvs=4421d3a9b=mukul@uwm.edu  Wed Apr 11 17:03:47 2012
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 1152D11E80B8 for ; Wed, 11 Apr 2012 17:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.274
X-Spam-Level: 
X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325,  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 b40CCPVMKLjo for ; Wed, 11 Apr 2012 17:03:46 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB9511E809D for ; Wed, 11 Apr 2012 17:03:46 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEANsahk9/AAAB/2dsb2JhbABEhWa3EiNWNQINGQJZBiyHdagBiXyJCYEvjy6BGASIWo0SkDaDBYE2Fw
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E1BA91FD0B8; Wed, 11 Apr 2012 19:03:45 -0500 (CDT)
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 AwmwmNAVbBAr; Wed, 11 Apr 2012 19:03:45 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id AEB931FD0B7; Wed, 11 Apr 2012 19:03:45 -0500 (CDT)
Date: Wed, 11 Apr 2012 19:03:45 -0500 (CDT)
From: Mukul Goyal 
To: C Chauvenet 
Message-ID: <117902819.1902407.1334189025553.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <1729392135.1851179.1333901413319.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.91]
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] Closure text for ticket #91
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, 12 Apr 2012 00:03:47 -0000

#91: Is it possible for an origin to get an error message in case the P2P-RPL route discovery fails.

Resolution:
-------------
No. Because no intermediate router knows whether a DIO reached the target or not.


 Discussion:
--------------
 [Cedric]
 On big question that rise my mind is, what happened if the route discovery  fail ?
 Some protocols sends out an error message when the route discovery fails  or get stuck.
 Do authors think that it could be relevant to add a "discovery-error"
 message as defined in other route discovery protocols ?

 [Mukul]
 I dont think it is possible to detect the failure of a P2P-RPL route  discovery. No node knows if a P2P-RPL route discovery has failed.

 P2P-RPL forms a temporary DAG and the route discovery (well, at least the  first half) succeeds when a target joins the DAG. Only the target knows  whether it joined the DAG or not. So, no node knows if the (first half of
 the) route discovery failed.

 Second half involves the target sending DRO to the origin. If the DRO does  not reach the origin, (the second half of) the route discovery fails. The  target can ensure (or at least increase the probability of) success by  asking for DRO-ACK and retransmitting the DRO if the DRO-ACK is not  received within certain time duration. DRO message travels by multicast,  so an intermediate router, that forwards a DRO further, has no idea  whether the next hop on the route received the DRO or not. Again, no node  knows if the (second half of the) there is no one to generate the  discovery-error message.

 I think an origin might infer the route discovery to have failed, if the  DAG's life time has expired but no DRO is received. But I am not sure we  should mandate this to be the way failure is inferred. We have just 4  values for the DAG life time. So, I think we should leave it to origin how  much to wait for a DRO before admitting failure.

[Cedric2]

I was thinking about an error message if the delivery of a message fails when using a route established by the P2P-RPL mechanism.
When a node included in the discovered route cannot be reached, then an error message could initiate a new route discovery using the P2P-RPL mechanism.

[Mukul2]
P2P-RPL routes are used in exactly the same manner as core RPL routes, that is you use an RPL Source Routing Header (RFC6554) or an RPL Option (RFC6553) to send a packet to its destination. These RFCs specify what ICMP error messages could be generated if the route is broken.

[Cedric3]
Ok.
If the route error detection is alredy handled, I think an additional error message is not necessary.


From prvs=4421d3a9b=mukul@uwm.edu  Wed Apr 11 19:39:51 2012
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 7E3DE11E80E6 for ; Wed, 11 Apr 2012 19:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.282
X-Spam-Level: 
X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=0.317,  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 qvwtSjIFP3t6 for ; Wed, 11 Apr 2012 19:39:50 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id A756C11E80BF for ; Wed, 11 Apr 2012 19:39:50 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAF8/hk9/AAAB/2dsb2JhbABEhWa3FiNWNQINGQJZiCeneYl5iQmBL40mggyBGASIWo0SkDaDBQ
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id EEA721FD0B8; Wed, 11 Apr 2012 21:39:49 -0500 (CDT)
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 WcVbDVl-uhTN; Wed, 11 Apr 2012 21:39:49 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id BD3291FD0B7; Wed, 11 Apr 2012 21:39:49 -0500 (CDT)
Date: Wed, 11 Apr 2012 21:39:49 -0500 (CDT)
From: Mukul Goyal 
To: roll@ietf.org
Message-ID: <131236703.1903578.1334198389674.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <984808904.1851138.1333900679203.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.91]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Subject: [Roll] Closure text for ticket #88
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, 12 Apr 2012 02:39:51 -0000

#88: Data option and ULP

 Problem 
 ------------------------------
 An option exists for carrying payload. The use of the option (tunnel,
 transport?) is not described properly.

 Resolution
 ------------------------
 Add a next header and a sequence to the data option so upper layers can
 be determined.

 Discussion
 -------------

 [Pascal]
 Can the data option be different from one DIO to the next?

 [Mukul]
 The contents of the data option are specified by the origin (for the
 DIO) or the target (for the DRO). In theory, an origin can send
 different data options in different DIOs it generates for a particular
 route discovery (assuming that it does generate multiple DIOs; it is
 very much possible that the origin generates just one DIO and then sits
 silent). But, then the origin is taking the risk that some of the data
 options would never each the target(s). I guess the origin might do this
 if the data sent earlier is now stale and the origin would like the
 target(s) to receive newer data.


 [Pascal2] This should be discussed in the draft. You need to set the
 expectation for the upper layer(s). Is there a way to differentiate
 different data sets? Eg instance or sequence nb?
 My suggestion so far is that the data should have 3 bits of next header
 and 5 bits of sequence.

 [Mukul2] This sounds good to me. I will incorporate this in the draft
 unless I hear a better proposal.

 [Pascal3] Cool. Please make that another LC issue and the proposed
 resolution, see if there is anyone adding anything to it.

 [Mukul3] Actually, I would like the next header to be 4 bits and the
 sequence number to be 4 bits. 4-bit sequence number will still allow up
 to 16 different messages to be sent during a P2P-RPL discovery. 4 bit
 next header will allow 16 different possibilities. We can have so many
 different ways to compress UDP/TCP headers. I think 3 bit next header
 may not be sufficient.

 [Pascal4] Cool. Let's use that as the proposed resolution


From prvs=4421d3a9b=mukul@uwm.edu  Wed Apr 11 19:44:13 2012
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 2598511E80E6 for ; Wed, 11 Apr 2012 19:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.289
X-Spam-Level: 
X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310,  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 u2qxbxQAquKm for ; Wed, 11 Apr 2012 19:44:12 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9178A11E80BF for ; Wed, 11 Apr 2012 19:44:12 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAHFAhk9/AAAB/2dsb2JhbABEhWa3FiNWNQINGQJZBoghp3uJeYkJgS+PMoEYBIhajRKQNoMF
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 2450F2B3F0A; Wed, 11 Apr 2012 21:44:12 -0500 (CDT)
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 pcWFTHIc6FcA; Wed, 11 Apr 2012 21:44:11 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id E69C62B3EF6; Wed, 11 Apr 2012 21:44:11 -0500 (CDT)
Date: Wed, 11 Apr 2012 21:44:11 -0500 (CDT)
From: Mukul Goyal 
To: "Pascal Thubert (pthubert)" 
Message-ID: <1034499059.1903619.1334198651843.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.91]
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] Closure text for ticket #87
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, 12 Apr 2012 02:44:13 -0000

#87: Can't we split the target from the RDO ?

 Problem 
 ------------------------------
 The RDO is a garbage option will all sorts of data in it. The advocated  reason for that is conciseness since separate options mean overhead.
 OTOH, it makes more sense to have all the targets expresses as target  options as opposed to having one target in the DRO and then all other  targets listed after. Having the target separate would allow for a DIO  with no RDO but only a target, which would be useful to poll a device on  an existing DAG. Currently the draft MUST a RDO and MAY and target  option. The suggestion is to allow for a target in DIO without a RDO.

 Proposed resolution
 -------------------------
 Keep it at that since 1) there are implementations and 2) it's  experimental . This resolution implies that the issue will be reopened  should the work go for standard track

 Discussion
 -------------

 [Pascal]" MAY carry one or more RPL Target Options to specify additional  unicast/multicast addresses for the target."
 Now here I would have a MUST carry at least one target. That is indeed  what makes is a lookup DIO...

 [Mukul]
 As I stated in the previous message, we need to include the target in  the P2P-RDO to save bytes for the common case (discover route to one  unicast/multicast target). So, we cannot make using the target option a  MUST.

 [Pascal2] Certainly. I prefer the split, in which case the MUST IMHO  goes to the target as opposed to the RDO. In a case where the RDO is not  needed, the target only message is actually shorter...

 [Mukul2] As I said before, I think a P2P mode DIO always needs to have  one P2P-RDO. I guess, in this case, we agree to disagree!

 [Pascal3] Certainly. And there's nothing blocking with that  disagreement, mostly if the draft targets experimental.
 I think it's OK to keep your response as the proposed resolution for  the issue. Still I'd like advice from others so exposing the issue as LC  will help. Let's see on which side the coin falls.

 [Mukul3] OK. I will be happy to hear additional opinions.

 [Pascal4] Fine, let's keep that as the proposed resolution


From pthubert@cisco.com  Wed Apr 11 23:14:12 2012
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 6B9F321F85B5 for ; Wed, 11 Apr 2012 23:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.053
X-Spam-Level: 
X-Spam-Status: No, score=-10.053 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB-1lXtU06kQ for ; Wed, 11 Apr 2012 23:14:11 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id EF9CA21F85A5 for ; Wed, 11 Apr 2012 23:14:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=12826; q=dns/txt; s=iport; t=1334211248; x=1335420848; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BE5+9CFFuUsDBd0fc9uwk2oE11iBZFuYgrN8PYI3hS8=; b=G6Lvj8xSKeT2PPa2zeUn5ESExfhrv5iPlWWOJoRKPeUp/p9mEkLyDZga lMc3O5ZLD2TvNtzN81Z271BYLI7fcXm5su4yw7tAZdqx8X18RI3qReZX+ ZZZ6WtS5jgHAW+R5XjcDj0xvuHjunSUMgM8uO03IKIUu+dYItMVELZ8Bl 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAJBxhk+Q/khM/2dsb2JhbABCDoVkswV7gQeCCQEBAQQBAQEPARANBDoLDAQCAQgRBAEBAwIGBhcBAgICAQElHwkIAQEEEwgRCYdsC55vjRCLE4EviXAKhTg1YwSWfY08gWmCMDmBUgISAwI
X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="134900703"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2012 06:14:06 +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 q3C6E6kd024829; Thu, 12 Apr 2012 06:14:06 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);  Thu, 12 Apr 2012 08:14:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Thu, 12 Apr 2012 08:13:14 +0200
Message-ID: 
In-Reply-To: <692352940.1889031.1334138855749.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] [roll] #90: use of transient instance ID
Thread-Index: Ac0XyvRrSP113alQSOaq04aT5M3YWgAo7CdA
References:  <692352940.1889031.1334138855749.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
X-OriginalArrivalTime: 12 Apr 2012 06:14:06.0468 (UTC) FILETIME=[77413440:01CD1873]
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #90: use of transient instance ID
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, 12 Apr 2012 06:14:12 -0000

SGkgTXVrdWwNCg0KRG9uJ3Qgd29ycnkhIEZvciB0aGUgdXBwZXIgbGF5ZXJzIGludGVyYWN0aW9u
IEknbSBvbmx5IGFza2luZyBmb3Igb25lIHNlbnRlbmNlLCBub3QgYW4gQVBJIHNwZWMuLi4gTGlr
ZToNCiANCiJUaGUgcmVxdWlyZWQgbGlmZXRpbWUgZm9yIHRoZSByb3V0aW5nIHN0YXRlcyBtYXkg
YmUgcHJvdmlkZWQgYnkgdGhlIGFwcGxpY2F0aW9uIHZpYSBhIGhpbnQgZnJvbSB1cHBlci1sYXll
ciBwcm90b2NvbHMuIEFkZGl0aW9uYWwgaGludHMgZnJvbSB1cHBlci1sYXllciBwcm90b2NvbHMg
Y2FuIGJlIHVzZWQgdG8gdGVhciBkb3duIHRoZSByZW1haW5pbmcgc3RhdGVzIGF0IHRoZSBvcmln
aW4gYW5kL29yIGF0IHRoZSB0YXJnZXQgYXMgc29vbiB0aGUgYXBwbGljYXRpb24gbmVlZCBvZiB0
aG9zZSBzdGF0ZXMgaXMgdGVybWluYXRlZCBvciB0aGUgYXBwbGljYXRpb24gZGV0ZWN0cyB0aGF0
IHRoZSBzdGF0ZXMgYXJlIG5vdCBmdW5jdGlvbmFsIGFueW1vcmUuIEluIGEgc2FtZSBmYXNoaW9u
LCBhbiBpbnRlcmFjdGlvbiB3aXRoIHVwcGVyIGxheWVycyBjYW4gYmUgdXNlZCB0byBkZXRlcm1p
bmUgdGhhdCB0aGUgcm91dGluZyBzdGF0ZXMgYXJlIHN0aWxsIHZhbGlkIGFuZCBjYW4gYmUgcHJv
bG9uZ2VkIGZvciBhbiBhZGRpdGlvbmFsIGxpZmV0aW1lIg0KDQpUaGF0J3MgYWxsIQ0KDQpGb3Ig
eW91ciBxdWVzdGlvbnMgcGxlYXNlIHNlZSBpbmxpbmUuIEFsc28sIGFzIGFuIGV4YW1wbGUgb2Yg
ZXhpc3RpbmcgYXJ0LCBSRkMgNDg2MSBzdGF5cyBhcyBhYnN0cmFjdCBhcyBJIGRvIGFib3ZlIHdp
dGggdGV4dCBsaWtlOg0KDQogICAgICBERUxBWSAgICAgICBUaGUgbmVpZ2hib3IgaXMgbm8gbG9u
Z2VyIGtub3duIHRvIGJlIHJlYWNoYWJsZSwgYW5kDQogICAgICAgICAgICAgICAgICB0cmFmZmlj
IGhhcyByZWNlbnRseSBiZWVuIHNlbnQgdG8gdGhlIG5laWdoYm9yLg0KICAgICAgICAgICAgICAg
ICAgUmF0aGVyIHRoYW4gcHJvYmUgdGhlIG5laWdoYm9yIGltbWVkaWF0ZWx5LCBob3dldmVyLA0K
ICAgICAgICAgICAgICAgICAgZGVsYXkgc2VuZGluZyBwcm9iZXMgZm9yIGEgc2hvcnQgd2hpbGUg
aW4gb3JkZXIgdG8NCiAgICAgICAgICAgICAgICAgIGdpdmUgdXBwZXItbGF5ZXIgcHJvdG9jb2xz
IGEgY2hhbmNlIHRvIHByb3ZpZGUNCiAgICAgICAgICAgICAgICAgIHJlYWNoYWJpbGl0eSBjb25m
aXJtYXRpb24uDQoNCi4uLg0KDQo3LjMuMS4gUmVhY2hhYmlsaXR5IENvbmZpcm1hdGlvbg0KDQoN
CiAgIEEgbmVpZ2hib3IgaXMgY29uc2lkZXJlZCByZWFjaGFibGUgaWYgdGhlIG5vZGUgaGFzIHJl
Y2VudGx5IHJlY2VpdmVkDQogICBhIGNvbmZpcm1hdGlvbiB0aGF0IHBhY2tldHMgc2VudCByZWNl
bnRseSB0byB0aGUgbmVpZ2hib3Igd2VyZQ0KICAgcmVjZWl2ZWQgYnkgaXRzIElQIGxheWVyLiAg
UG9zaXRpdmUgY29uZmlybWF0aW9uIGNhbiBiZSBnYXRoZXJlZCBpbg0KICAgdHdvIHdheXM6IGhp
bnRzIGZyb20gdXBwZXItbGF5ZXIgcHJvdG9jb2xzIHRoYXQgaW5kaWNhdGUgYSBjb25uZWN0aW9u
DQogICBpcyBtYWtpbmcgImZvcndhcmQgcHJvZ3Jlc3MiLCBvciByZWNlaXB0IG9mIGEgTmVpZ2hi
b3IgQWR2ZXJ0aXNlbWVudA0KICAgbWVzc2FnZSB0aGF0IGlzIGEgcmVzcG9uc2UgdG8gYSBOZWln
aGJvciBTb2xpY2l0YXRpb24gbWVzc2FnZS4NCg0KDQpQYXNjYWwNCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCg0KW1Bhc2NhbF0gQWxzbywgd2hlbiB0aGVyZSBhcmUgbm8gcm91dGluZyBz
dGF0ZXMgaW4gaW50ZXJtZWRpYXRlIHJvdXRlcnMsIGFuIGluZGljYXRpb24gZnJvbSB1cHBlciBs
YXllcnMgY2FuIGJlIHVzZWQgaW4gdGhlIGVuZCBwb2ludHMgdG8gY29uc2lkZXIgdGhhdCBhbGwg
c3RhdGVzIGZvciBhbiBpbnN0YW5jZUlEIGFyZSBub3cgY2xlYW5lZCB1cC4NCg0KW011a3VsXSBO
b3Qgc3VyZSB3aGF0IHlvdSBtZWFuLiANCg0KW1Bhc2NhbDJdIExldCBtZSByZXdvcmQ6ICBpZiBI
Ykggcm91dGluIGdpcyBub3QgdXNlZCwgdGhlIG9ubHkgc3RhdGVzIHdpdGggYW55IHBlcnNpc3Rl
bmNlIGFyZSBvbiB0aGUgb3JpZ2luIGFuZCB0YXJnZXQocykuIFRoZSB1cHBlciBsYXllciBwcm90
b2NvbCAoVUxQKSBpbiBvcmlnaW4gYW5kIHRhcmdldCBtYXkga25vdyB3aGVuIHRoZXkgYXJlIGRv
bmUgd2l0aCB0aGVpciBuZWVkIGZvciB0aGUgcm91dGVzLiBJZiB0aGV5IGFyZSBkb25lIGJlZm9y
ZSAoY29uZmlnIG9wdGlvbikgbGlmZXRpbWUgaXMgdXAsIHRoZXkgY2FuIHRlYXIgZG93biB0aGUg
c3RhdGVzLiBUaGlzIHJlcXVpcmVzIGEgbmV3IGNyb3NzIGxheWVyIGludGVyYWN0aW9uIHRyaWdn
ZXJlZCBieSBVTFAsIHNpbWlsYXIgdG8gSVB2NiBORCBpbiBERUxBWSBzdGF0ZS4NCg0KW011a3Vs
Ml0NCllvdSB0aGluayBQMlAtUlBMIG5lZWRzIHRvIGRlZmluZSB0aGlzIGNyb3NzLWxheWVyIGlu
dGVyYWN0aW9uPyBUaGlzIGlzIHNpbXBseSB0aGUgdXBwZXIgbGF5ZXIgdGVsbGluZyB0aGUgbmV0
d29yayBsYXllciB0byBjaHVjayBhIHNvdXJjZSByb3V0ZS4gSXNuJ3QgaXQ/IFRoZSB1cHBlci9s
b3dlciBsYXllcnMgZG9udCBldmVuIG5lZWQgdG8gcmVtZW1iZXIgdGhhdCB0aGlzIHJvdXRlIHdh
cyBkaXNjb3ZlcmVkIHVzaW5nIFAyUC1SUEwuIEFsc28sIHRoZSBvcmlnaW4gKG9yIHRoZSB0YXJn
ZXQpIGNhbiB1c2UgYSBzb3VyY2Ugcm91dGUgYXMgbG9uZyBhcyBpdCB3YW50cy4gV2h5IHNob3Vs
ZCB0aGUgbGlmZXRpbWUgaW4gY29uZmlnIG9wdGlvbiBkaWN0YXRlIGhvdyBsb25nIHRoaXMgcm91
dGUgY2FuIGJlIHVzZWQ/DQoNCltQYXNjYWwzXSBJbiBJUHY2LCBieSBkZXNpZ24sIGV2ZXJ5dGhp
bmcgaGFzIGEgbGlmZXRpbWUuIEJldHRlciBmaXggdGhpcyBub3cgdGhhbiBkdXJpbmcgSUVTRyBy
ZXZpZXcuIEluIHRoZSBjYXNlIG9mIHRoaXMgZHJhZnQsIG5vZGVzIGNvbW1pdCByZXNvdXJjZXMg
d2hpY2ggYXJlIGJ5IGRlZmluaXRpb24gbGltaXRlZC4gVGh1cyBpbiB0aGUgZ2VuZXJhbCBjYXNl
IHRoYXQgdGhlIGRyYWZ0IGFkZHJlc3NlcyB0aGV5IGNhbid0IGNvbW1pdCB0aG9zZSByZXNvdXJj
ZXMgZm9yZXZlci4gT25lIGVuZCBwb2ludCBtaWdodCBkaWUsIHNheSBvdXQgb2YgYmF0dGVyeS4g
VGhlcmUgbXVzdCBiZSBzb21ldGhpbmcgdGhhdCBpbiBhbnkgY2FzZSB3aWxsIGVuc3VyZSB0aGF0
IGFsbCBwYXJ0aWVzLCBlbmQgcG9pbnRzIGFuZCBpbnRlcm1lZGlhdGUgcm91dGVycyBpbiBIYkgg
ZW5kIHVwIGNsZWFuIGV2ZW4gaWYgdGhlcmUgaXMgbm8gKHJzdCkgc2lnbmFsaW5nIHRvIGFjaGll
dmUgc28uIA0KDQpZb3UgY2FuIHBpY2sgYSBsYXJnZSBsaWZldGltZSBpZiB5b3UgbGlrZSBmb3Ig
dGhlIGxpZ2h0IHN3aXRjaCB5b3UgaGF2ZSBpbiBtaW5kOyBidXQgdGhlcmUgbmVlZHMgdG8gYmUg
YSBsaWZldGltZSwgYWZ0ZXIgd2hpY2ggc3RhdGVzIG11c3QgYmUgcmV2YWxpZGF0ZWQuIFRoYXQg
Y2FuIGJlIHJlYnVpbGRpbmcgdGhlIERBRywgdGhpcyBjYW4gYmUgdW5pY2FzdCBsaWtlIGEgcGlu
ZywgYW5kIHRoaXMgY2FuIGJ5IHBpZ2d5IGJhY2tlZCB3aXRoIHRyYWZmaWMuIE5EIGZvciBpbnN0
YW5jZSB1c2VzIHVwcGVyIGxheWVyIGhpbnRzIHRvIHZhbGlkYXRlIHRoYXQgdGhlIHJlYWNoYWJp
bGl0eSB3aXRob3V0IG5lY2Vzc2FyaWx5IHNpZ25hbGluZyBldmVyeXRoaW5nLiBTaW5jZSB5b3Ug
YXJlIGdvaW5nIGZvciBleHBlcmltZW50YWwsIEknbSBhc2tpbmcgZm9yIHRoZSBiYXJlIG1pbmlt
dW0sIGEgc2ltcGxlIGxpZmV0aW1lIHVzaW5nIGV4aXN0aW5nIG1lYW5zICh0aGUgY29uZmlnIG9w
dGlvbikuIA0KDQogSWYgYW4gYXBwbGljYXRpb24gaXMgcmVzcG9uc2libGUgZm9yIHNldHRpbmcg
dXAgcm91dGluZyBzdGF0ZXMsIHRoaXMgYXBwbGljYXRpb24gbWF5IGFsc28gYmUgY2xldmVyIGVu
b3VnaCB0byBwcm92aWRlIGEgaGludCBvbiB0aGUgbGlmZXRpbWUsIGFuZCB0byB0ZWFyIGRvd24g
dGhlIHN0YXRlcyB0aGF0IGl0IGNhdXNlZCB3aGVuIGl0IGRvZXMgbm90IG5lZWQgdGhlbSBhbnlt
b3JlLiBJZiB0aGUgYXBwbGljYXRpb24gZG9lcyBub3QgcHJvdmlkZSBhbnkgaGludCB3aGF0c29l
dmVyLCB0aGUgaW1wbGVtZW50YXRpb24gYXQgdGhlIG9yaWdpbiB3aWxsIHNlbGVjdCBhIHJlYXNv
bmFibGUgbGlmZXRpbWUgdGhhdCB3aWxsIGRlcGVuZCBvbiB0aGUgZnVuY3Rpb24gb2YgdGhlIG9i
amVjdC4gSSdtIGNlcnRhaW5seSBub3QgYXNraW5nIHRvIGRlZmluZSB0aGUgaW50ZXJhY3Rpb24g
YmV0d2VlbiB1cHBlciBsYXllciBhbmQgTDMsIHRoaXMgaXMgaW50ZXJuYWwgYW5kIHRodXMgaW1w
bGVtZW50YXRpb24uDQoNCiBDaGVlcnMsDQoNClBhc2NhbA0KDQotLS0tLSBPcmlnaW5hbCBNZXNz
YWdlIC0tLS0tDQpGcm9tOiAiUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0aHViZXJ0QGNp
c2NvLmNvbT4NClRvOiAiTXVrdWwgR295YWwiIDxtdWt1bEB1d20uZWR1Piwgcm9sbEBpZXRmLm9y
Zw0KU2VudDogVHVlc2RheSwgQXByaWwgMTAsIDIwMTIgNDo1Mjo1MCBBTQ0KU3ViamVjdDogUkU6
IFtSb2xsXSBbcm9sbF0gIzkwOiB1c2Ugb2YgdHJhbnNpZW50IGluc3RhbmNlIElEDQoNCk11a3Vs
Og0KDQpJIG1lYW50IGEgc3VnZ2VzdGlvbiwgbm90IGEgY2FwaXRhbGl6ZWQgd29yZC4gSSBwcmVm
ZXIgdGhlIHN1Z2dlc3Rpb24gYnV0IEknbSBzdGlsbCBPSyB3aXRoIHlvdXIgcHJvcG9zYWwuIElm
IHdlIGdldCBpbiBhZ3JlZW1lbnQgb24gdGhlIGxpZmV0aW1lIG9mIHRoZSBzdGF0ZXMgKGlzc3Vl
ICM4NSksIHRoZW4geW91IGNhbiBpbmRpY2F0ZSB0aGF0IGxpZmV0aW1lIGlzIG9uZSB3YXkgdG8g
ZGV0ZXJtaW5lIHdoZW4gYWxsIHN0YWxlIHN0YXRlcyBjYW4gYmUgY29uc2lkZXJlZCBnb25lLiBB
bHNvLCB3aGVuIHRoZXJlIGFyZSBubyByb3V0aW5nIHN0YXRlcyBpbiBpbnRlcm1lZGlhdGUgcm91
dGVycywgYW4gaW5kaWNhdGlvbiBmcm9tIHVwcGVyIGxheWVycyBjYW4gYmUgdXNlZCBpbiB0aGUg
ZW5kIHBvaW50cyB0byBjb25zaWRlciB0aGF0IGFsbCBzdGF0ZXMgZm9yIGFuIGluc3RhbmNlSUQg
YXJlIG5vdyBjbGVhbmVkIHVwLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiByb2xsLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyb2xs
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNdWt1bCBHb3lhbA0KU2VudDogZGltYW5j
aGUgOCBhdnJpbCAyMDEyIDE4OjA5DQpUbzogcm9sbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtS
b2xsXSBbcm9sbF0gIzkwOiB1c2Ugb2YgdHJhbnNpZW50IGluc3RhbmNlIElEDQoNCkhpIFBhc2Nh
bA0KDQpSZS1yZWFkIHlvdXIgcHJvcG9zZWQgcmVzb2x1dGlvbiB0ZXh0LiBJIGFtIG5vdCBzdXJl
IHRoYXQgdGhlIGRyYWZ0IHNob3VsZCBzdWdnZXN0IHJvdGF0aW5nIHRoZSBpbnN0YW5jZSBpZHMu
IE15IHByb3Bvc2VkIHJlc29sdXRpb24gaXMgdG8gc2ltcGx5IHN1Z2dlc3Qgbm90IHVzaW5nIGlu
c3RhbmNlIGlkIHRoYXQgbWlnaHQgYmUgaW4gdXNlLg0KDQoiIFtNdWt1bDJdIE1ha2VzIHNlbnNl
LiBJIHRoaW5rIGl0IGlzIHN1ZmZpY2llbnQgdG8gY2F1dGlvbiAod2l0aCBhIFNIT1VMRA0KIE5P
VCkgYWdhaW5zdCByZXVzaW5nIGluc3RhbmNlIGlkcyBmb3Igd2hpY2ggdGhlIHN0YWxlIHN0YXRl
IG1pZ2h0IGV4aXN0ICBpbiB0aGUgbm9kZXMuIg0KDQpUaGFua3MNCk11a3VsDQoNCi0tLS0tIE9y
aWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJyb2xsIGlzc3VlIHRyYWNrZXIiIDx0cmFjK3Jv
bGxAdHJhYy50b29scy5pZXRmLm9yZz4NClRvOiBtdWt1bEBVV00uRURVLCBqcHZAY2lzY28uY29t
DQpDYzogcm9sbEBpZXRmLm9yZw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDEyIDg6MTE6
NDQgQU0NClN1YmplY3Q6IFtyb2xsXSAjOTA6IHVzZSBvZiB0cmFuc2llbnQgaW5zdGFuY2UgSUQN
Cg0KIzkwOiB1c2Ugb2YgdHJhbnNpZW50IGluc3RhbmNlIElEDQoNCiBQcm9ibGVtIChyZXNvbHV0
aW9uIGFncmVlZCB1cG9uKQ0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFAyUCBj
cmVhdGVzIHRlbXBvcmFyeSBzdGF0ZXMgaW4gdGhlIHRyYW5zaWVudCBEQUcgd2l0aCBhIHRyYW5z
aWVudCAgaW5zdGFuY2UgSUQuIFRoZSBwcm90b2NvbCBtdXN0IGVuc3VyZSB0aGF0IGlmIHRoZSBp
bnN0YW5jZSBJRCBpcyByZXVzZWQgIHRoZW4gdGhlIG5ldyBvcGVyYXRpb24gaXQgaXMgbm90IGNv
bmZ1c2VkIHdpdGggc3RhdGVzIHJlc3VsdGluZyBmcm9tIHRoZSAgcHJldmlvdXMgdXNlIG9mIHRo
ZSBzYW1lIGluc3RhbmNlIElELiBTdWdnZXN0aW9uIGlzIHRvIHByb3Bvc2UgYSAgcm90YXRpb24u
DQoNCiBEaXNjdXNzaW9uDQogLS0tLS0tLS0tLS0tLQ0KDQogW1Bhc2NhbF0NCiAiUlBMSW5zdGFu
Y2VJRDogUlBMSW5zdGFuY2VJRCBNVVNUIGJlIGEgbG9jYWwgdmFsdWUgYXMgZGVzY3JpYmVkIGlu
ICBTZWN0aW9uIDUuMSBvZiBbSS1ELmlldGYtcm9sbC1ycGxdLiBUaGUgb3JpZ2luIE1VU1QgTk9U
IHVzZSB0aGUgc2FtZSAgUlBMSW5zdGFuY2VJRCBpbiB0d28gb3IgbW9yZSBjb25jdXJyZW50IHJv
dXRlIGRpc2NvdmVyaWVzLiINCg0KIEknZCBzdWdnZXN0IHRoYXQgeW91IGVuZm9yY2UgYSByb3Vu
ZCByb2JpbiBvciBhbiBvcGFxdWUgY2lyY3VsYXRpb24gc28gIHRoYXQgdGhlIG5ldyBpbnN0YW5j
ZUlEIGlzIHRoZSBsZWFzdCByZWNlbnRseSB1c2VkIG9uZSBvdXQgb2YgdGhlIDY0ICBwb3NzaWJs
ZS4NCg0KIFtNdWt1bF0NCiBJIHRoaW5rIHdlIHNob3VsZCBsZWF2ZSBpdCB0byB0aGUgb3JpZ2lu
IHRvIGRlY2lkZSB3aGljaCB2YWx1ZSBpdCB3YW50cyAgdG8gdXNlIGZvciBSUExJbnN0YW5jZUlE
LiBJIGtub3cgc29tZSBpbXBsZW1lbnRhdGlvbnMgYXJlIHBsYW5uaW5nIHRvICB1c2UgYSBmaXhl
ZCBSUExJbnN0YW5jZUlEIHZhbHVlIGZvciBhbGwgcm91dGUgZGlzY292ZXJpZXMuDQoNCiBbUGFz
Y2FsMl0gQ2hhbmdpbmcgdGhlIGluc3RhbmNlIElEIHdpbGwgaGVscCBkZWJ1ZyB0aGUgbmV0d29y
ayBhbmQgYXZvaWQgIGNvbmZsaWN0cyB3aXRoIHN0YWxlIHN0YXRlcy4gV2hhdCdzIHJlYWxseSB1
cCB0byB0aGUgZGV2aWNlIGlzIHRoZSAgaW5pdGlhbCBzZXF1ZW5jZS4gTGVhdmluZyBpdCB1cCB0
byB0aGUgb3JpZ2luIG1heSBoZWxwIHRoZSBvcmlnaW4gZGVmZWF0ICBzb21lIGF0dGFja3MgdG8g
c29tZSBkZWdyZWUuIE9UT0gsIGFmdGVyIGFsbCB0aGUgaW5zdGFuY2VzIGhhdmUgYmVlbiAgcGxh
eWVkLCBMUlUgZm9yY2VzIHRvIHJlcGxheSB0aGUgc2FtZSBzZXF1ZW5jZSBhZ2FpbiBzbyB0aGUg
c2hpZWxkICBkcm9wcy4gTXkgcHJlZmVycmVkIGFwcHJvYWNoIHdvdWxkIGJlIGEgU0hPVUxEIHRo
YXQgd291bGQgc2F5IHRoYXQgdGhlICBuZXh0IGluc3RhbmNlIElEIFNIT1VMRCBOT1QgYmUgb25l
IG9mIHRoZSAoMTY/KSBtb3N0IHJlY2VudGx5IHVzZWQgYW5kICBNVVNUIE5PVCBiZSBvbmUgZm9y
IHdoaWNoIHN0YXRlcyBtaWdodCBzdGlsbCBleGlzdCBpbiB0aGUgbmV0d29yay4gSU9XICBlaXRo
ZXIgdGhlIHN0YXRlcyBkZWxldGlvbiB3YXMgYWNrbm93bGVkZ2VkLCBvciBhbGwgcGVuZGluZyBs
aWZldGltZXMgIGFyZSBleGhhdXN0ZWQuDQoNCiBbTXVrdWwyXSBNYWtlcyBzZW5zZS4gSSB0aGlu
ayBpdCBpcyBzdWZmaWNpZW50IHRvIGNhdXRpb24gKHdpdGggYSBTSE9VTEQNCiBOT1QpIGFnYWlu
c3QgcmV1c2luZyBpbnN0YW5jZSBpZHMgZm9yIHdoaWNoIHRoZSBzdGFsZSBzdGF0ZSBtaWdodCBl
eGlzdCAgaW4gdGhlIG5vZGVzLiBVc2luZyBhICJNVVNUIE5PVCIgbWF5IG5vdCBiZSBPSyBzaW5j
ZSBhIG5vZGUgbWF5IG5ldmVyIGJlICAxMDAlIHN1cmUgYWJvdXQgbm9uLWV4aXN0ZW5jZSBvZiBz
dGFsZSBzdGF0ZSB3aXRoIGEgcGFydGljdWxhciBpbnN0YW5jZSAgaWQgKHRodXMsIGFsbCBwb3Nz
aWJsZSBpbnN0YW5jZSBpZCB2YWx1ZXMgd2lsbCBiZWNvbWUgc3VzcGVjdCBhbmQgaGVuY2UgIHVu
dXNhYmxlIGFmdGVyIGEgd2hpbGUpLg0KDQogW1Bhc2NhbDNdIEFncmVlZC4gTm90ZSB0aGF0IGEg
Y2lyY3VsYXRpb24gaXMgYSBib251cyB0byBkZWZlYXQgcmVwbGF5cy4NCiBBbmQgbm93IHdlJ3Jl
IGJhY2sgdG8gdGhlIGlzc3VlIGFib3ZlLiBIb3cgZG9lcyB0aGUgZGV2aWNlIGtub3cgdGhhdCAg
dGhlcmUgaXMgbm8gc3RhdGUgbGVmdD8gQSBsaWZldGltZSBkZWZpbml0aW9uIHdvdWxkIGJlIHZl
cnkgdXNlZnVsLiBUaGF0ICBsaWZldGltZSBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgREFHJ3Mgb25l
IGluIFJETy4gSSB0aGluayB3ZSBoYXZlIGFuIG9wZW4gIGlzc3VlIGhlcmUuDQoNCiBbTXVrdWwz
XSBBcyBJIG1lbnRpb25lZCBhYm92ZSwgdGhlIGxpZmUgdGltZSBwYXJhbWV0ZXJzIGluc2lkZSB0
aGUgRE9EQUcgIGNvbmZpZ3VyYXRpb24gb3B0aW9uIHNwZWNpZnkgdGhlIGxpZmUgdGltZSBvZiB0
aGUgaG9wLWJ5LWhvcCByb3V0aW5nICBzdGF0ZSBmb3IgdGhlIHJvdXRlcyBkaXNjb3ZlcmVkIHVz
aW5nIFAyUC1SUEwuDQoNCiBbUGFzY2FsNF0gVGhpcyBib2lscyBkb3duIHRvIHRoZSB0aHJlYWQg
YWJvdmUuIE9ubHkgb25lIGlzc3VlIHJlYWxseSwgIHdoaWNoIGxpZmV0aW1lIGlzIHdoaWNoPyBT
byBJTUhPIG5vIG5lZWQgdG8gbG9nIGFueXRoaW5nIGZvciB0aGlzICB0aHJlYWQuDQoNCiBbTXVr
dWw0XSBPSy4NCg0KIFBhc2NhbA0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAganB2QOKApiAgICAgICAg
ICAgICAgICAgIHwgICAgICBPd25lcjogIG11a3VsQOKApg0KICAgICBUeXBlOiAgZGVmZWN0ICAg
ICAgICAgICAgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1ham9yICAgICAg
ICAgICAgICAgICAgfCAgTWlsZXN0b25lOg0KQ29tcG9uZW50OiAgcDJwLXJwbCAgICAgICAgICAg
ICAgICB8ICAgIFZlcnNpb246DQogU2V2ZXJpdHk6ICBTdWJtaXR0ZWQgV0cgRG9jdW1lbnQgIHwg
ICBLZXl3b3JkczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cHM6Ly9zdm4udG9vbHMuaWV0Zi5vcmcv
d2cvcm9sbC90cmFjL3RpY2tldC85MD4NCnJvbGwgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9y
b2xsLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
ClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3JvbGwNCg==

From trac+roll@trac.tools.ietf.org  Thu Apr 12 00:52:51 2012
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 2235021F859A for ; Thu, 12 Apr 2012 00:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.504
X-Spam-Level: 
X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 XUKZI8+Asr6d for ; Thu, 12 Apr 2012 00:52:47 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 77F2B21F8599 for ; Thu, 12 Apr 2012 00:52:45 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIEpc-0004JB-2o; Thu, 12 Apr 2012 03:52:40 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Thu, 12 Apr 2012 07:52:40 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/91#comment:1
Message-ID: <070.69271f424556ec822b0501319e162ced@trac.tools.ietf.org>
References: <055.920233a6500cd12143f61f93f9b312dd@trac.tools.ietf.org>
X-Trac-Ticket-ID: 91
In-Reply-To: <055.920233a6500cd12143f61f93f9b312dd@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #91: Is it possible for an origin to get an error message in case the P2P-RPL route discovery fails.
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Apr 2012 07:52:51 -0000

#91: Is it possible for an origin to get an error message in case the P2P-RPL
route discovery fails.

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Resolution:
 -------------
 No. Because no intermediate router knows whether a DIO reached the target
 or not.


 Discussion:
 --------------
 [Cedric]
 On big question that rise my mind is, what happened if the route discovery
 fail ?
 Some protocols sends out an error message when the route discovery fails
 or get stuck.
 Do authors think that it could be relevant to add a "discovery-error"
 message as defined in other route discovery protocols ?

 [Mukul]
 I dont think it is possible to detect the failure of a P2P-RPL route
 discovery. No node knows if a P2P-RPL route discovery has failed.

 P2P-RPL forms a temporary DAG and the route discovery (well, at least the
 first half) succeeds when a target joins the DAG. Only the target knows
 whether it joined the DAG or not. So, no node knows if the (first half of
 the) route discovery failed.

 Second half involves the target sending DRO to the origin. If the DRO does
 not reach the origin, (the second half of) the route discovery fails. The
 target can ensure (or at least increase the probability of) success by
 asking for DRO-ACK and retransmitting the DRO if the DRO-ACK is not
 received within certain time duration. DRO message travels by multicast,
 so an intermediate router, that forwards a DRO further, has no idea
 whether the next hop on the route received the DRO or not. Again, no node
 knows if the (second half of the) there is no one to generate the
 discovery-error message.

 I think an origin might infer the route discovery to have failed, if the
 DAG's life time has expired but no DRO is received. But I am not sure we
 should mandate this to be the way failure is inferred. We have just 4
 values for the DAG life time. So, I think we should leave it to origin how
 much to wait for a DRO before admitting failure.

 [Cedric2]

 I was thinking about an error message if the delivery of a message fails
 when using a route established by the P2P-RPL mechanism.
 When a node included in the discovered route cannot be reached, then an
 error message could initiate a new route discovery using the P2P-RPL
 mechanism.

 [Mukul2]
 P2P-RPL routes are used in exactly the same manner as core RPL routes,
 that is you use an RPL Source Routing Header (RFC6554) or an RPL Option
 (RFC6553) to send a packet to its destination. These RFCs specify what
 ICMP error messages could be generated if the route is broken.

 [Cedric3]
 Ok.
 If the route error detection is alredy handled, I think an additional
 error message is not necessary.

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From c.chauvenet@watteco.com  Thu Apr 12 05:18:23 2012
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 74F7D21F8604 for ; Thu, 12 Apr 2012 05:18:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.206
X-Spam-Level: 
X-Spam-Status: No, score=-5.206 tagged_above=-999 required=5 tests=[AWL=1.393,  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 a8DYjo213LNL for ; Thu, 12 Apr 2012 05:18:22 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5174E21F85FF for ; Thu, 12 Apr 2012 05:18:22 -0700 (PDT)
Received: from mail77-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 12:18:21 +0000
Received: from mail77-tx2 (localhost [127.0.0.1])	by mail77-tx2-R.bigfish.com (Postfix) with ESMTP id 8707E440369; Thu, 12 Apr 2012 12:18:21 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(z4b6Kzc89bh1dbaL1432Nzz1202hzzz2dh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT003.eurprd05.prod.outlook.com; RD:none; EFVD:NLI
Received: from mail77-tx2 (localhost.localdomain [127.0.0.1]) by mail77-tx2 (MessageSwitch) id 1334233097942613_19977; Thu, 12 Apr 2012 12:18:17 +0000 (UTC)
Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.249])	by mail77-tx2.bigfish.com (Postfix) with ESMTP id E045C480095; Thu, 12 Apr 2012 12:18:17 +0000 (UTC)
Received: from AMXPRD0510HT003.eurprd05.prod.outlook.com (157.56.248.181) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 12:18:17 +0000
Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT003.eurprd05.prod.outlook.com ([10.255.57.38]) with mapi id 14.16.0143.004; Thu, 12 Apr 2012 12:18:16 +0000
From: C Chauvenet 
To: Mukul Goyal 
Thread-Topic: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
Thread-Index: AQHNEx32hh4lWAafiEaDmA/VlsX0qpaMTC1wgAUtcwCAAs5AkIABLD4AgAAbh4CAAAYNgIAAHDMAgAA554CAATqiAA==
Date: Thu, 12 Apr 2012 12:18:15 +0000
Message-ID: 
References: <1480539095.1895120.1334165527537.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <1480539095.1895120.1334165527537.JavaMail.root@mail17.pantherlink.uwm.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.4.9]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2760CC4FA277234A84583EC321AFF8FA@eurprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: roll 
Subject: Re: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
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, 12 Apr 2012 12:18:23 -0000

inline,

Le 11 avr. 2012 =E0 19:32, Mukul Goyal a =E9crit :

> Please see inline.
>=20
> Thanks
> Mukul
>=20
>>> #95: Why need stop flag? Is the receipt of DRO not sufficient to indica=
te completion of route discovery?
>>>=20
>>> Resolution: No because multiple DROs would be generated if multiple sou=
rce  routes are being discovered.
>>>=20
>>> Discussion:
>>>=20
>>> p15 :  Stop (S): This flag, when set to one by a target, indicates that=
  the P2P-RPL route discovery is over.
>>>=20
>>> [Cedric]
>>> Is this bit really usefull ? My guess is that it will be always set to =
1.
>>> If you hear a DRO, this indeed means that the RDO has reached the targe=
t,  so you could just stop processing RDO when you hear a DRO.
>>> Do we really need a flag to stop RDO processing or the hearing of a DRO=
  type message could do the job ?
>>>=20
>>> [Mukul]
>>> A P2P-RPL invocation might involve discovery of multiple source routes.=
 In  that case, receipt of a DRO does not mean route discovery is over. Onl=
y  when the target sets the stop flag in the DRO, a node could be sure that=
  the route discovery is over.
>>>=20
>>> [Cedric2]
>>> OK fo multiple discovery.
>>> But if I want to discover a route to a multicast group of target. I set=
 a multicast adress in the target field of the RDO. Then, do I received as =
many DRO message as the number of target reached ? In that case, would the =
first DRO with a "S" flag stop the RDO propagation to reach all the target =
included in the multicast group ?
>>>=20
>>> [Mukul2]
>>> A target cannot set the S flag to one in the DRO if the target address =
in the P2P-RDO specified a multicast address. See the following text at the=
 end of page 21 in P2P-RPL-9:
>>>=20
>>> "The target MAY set the stop flag inside the DRO message to one if
>>>=20
>>>=20
>>>=20
>>> Goyal, et al.           Expires September 7, 2012              [Page 21=
]
>>>=20
>>> Internet-Draft         draft-ietf-roll-p2p-rpl-09             March 201=
2
>>>=20
>>>=20
>>> o  this router is the only target specified in the corresponding DIO,
>>>    i.e., the corresponding DIO specified a unicast address of the
>>>    router as the Target inside the P2P-RDO with no additional targets
>>>    specified via RPL Target Options; and
>>>=20
>>> "=20
>>>=20
>>> [Cedric3]=20
>>> So how do you stop the RDO flooding when the target adress is mulicast =
?=20
>>>=20
>>> [Mukul3]
>>>=20
>>> Stop flag cannot be used when the target address is multicast or when m=
ultiple unicast targets are there. The DIO generation will stop when the DA=
G dies. In the meanwhile, trickle algorithm would hopefully avoid unnecessa=
ry message generation. Note that the draft recommends a very small value fo=
r the redundancy constant.
>>=20
>> [Cedric4]
>> So in this case, the RDO (I guess this is what you mean when you mention=
ed "DIO" in you previous message) generation to discover the route is never=
 ending until the temporary DAG dies ?
>>=20
>> [Mukul4] Never ending wont be the correct description. The temporary DAG=
 lasts for a few seconds only. Plus, the trickle algorithm would prevent th=
e generation of many DIOs.
>>=20
>> [Cedric4]
>> I guess the RDO flooding would stop according to the MaxRank/NH field  o=
f the P2P-RDO message.
>>=20
>> [Mukul4]
>> Yes, it would. MaxRank and other routing constraints would always limit =
the scope of route discovery. Note that there are two separate things:
>> 1) scope of discovery: how far the discovery message (P2P-RDO inside the=
 DIO) travels. This is controlled by the routing constraints and the maxRan=
k field inside the P2P-RDO.
>> 2) How many discovery messages are generated by the nodes that join the =
DAG: this is controlled by trickle timer and ultimately by the DAG life tim=
e. The stop flag in the DRO is an optimization that allows DIO generation t=
o stop in the nodes that can hear the stop flag.
>=20
>>=20
>> [Cedric4]
>> But if this field is set to 0 (meaning infinity according to section 7.1=
), we should find a mechanism to stop the discovery mechanism.
>> What do you think ?
>>=20
>> [Mukul4]
>> To tell the truth, MaxRank is basically a way to avoid putting a metric =
container in the DIO (when a limit on rank is the only constraint you want =
to specify). The scope of discovery is limited by both MaxRank as well as t=
he routing constraints in the metric container.=20
>=20
> [Cedric5]
> Actually, the problem for stopping the discovery process without the "S" =
flag is also present with unicast addresses, because not all nodes will hea=
r the DRO (Only the nodes in the neighborhood of DRO forwarders).
> So we ended with some nodes forming and maintaining a temporary DAG even =
is they are not included in the discovered path, until the temporary DAG di=
es.
> As you mentioned, the maxRank field, routing constraints, and trickle or =
DAG lifetime limit this overhead.
> The section 9.2 of this draft give useful guidelines for trickle operatio=
n using the P2P RPL mechanism, and limit the flooding of RDO messages.
> The only improvement we could add is to avoid the maintenance of some par=
t of the temporary DAG that don't hear the DRO with the S flag.
> This nodes will still send out some DIO when the trickle timer fires. Tho=
ugh, thank's to the trickle's operation described in section 9.2, they won'=
t be propagated.
> One possibility could be to state that : "if a DRO has not been heard wit=
hin a certain period of time, then their node is not considered as a part o=
f the discovered path and should leave the temporary DAG".
>=20
> [Mukul5]
> Two problems:
> 1) An intermediate router has no idea how long the target wants to wait b=
efore generating DRO.

[Cedric6]
Correct.

> 2) If an intermediate router leaves the DAG early (ie before the DAG's li=
fetime is over), it might end up rejoining the DAG when it hears the DAG's =
DIO again.

[Cedric6]
Yes. So if I understand correctly, even if a mechanism enable nodes that ar=
e not along the discovered path to leave the temporary DAG, they will join =
it at some point due to the temporary DAG maintenance messages (DIOs).
So in the end, the benefit I saw (Saving power, packets, state maintenance)=
, is not there.
Then if there is no benefit, there is no reason to change the spec.
So if what I wrote above is correct, I'm OK to close the ticket and don't c=
hange anything about the "S" flag behavior.

>=20
> [Cedric5]=20
> This "certain period of time" could be determined according to the networ=
k topology, the application, or the network diameter for instance and let t=
o the implementation.
>=20
> [Mukul5]
> It would be much easier if the origin could choose a small (yet reasonabl=
e) lifetime for the DAG.

[Cedric6]
I agree that this parameters will greatly impact on the RPL P2P cost.

>=20
> [Cedric5]
> I see a benefit in the case of a discovery process to a unicast target in=
 a very large and sparse network. Here, a lot of nodes will maintain unnece=
ssary states if they are not part of the discovered path.
> With the current spec, they will send periodic and unnessecary DIO. The h=
andling of a "DRO timeout reception" could save packets, thus battery, band=
width etc...=20
>=20
> [Mukul5]
> I am not sure this will work as I explained above.
>>=20
>>=20
>>=20
>=20
>=20
>=20



From prvs=4421d3a9b=mukul@uwm.edu  Thu Apr 12 06:00:00 2012
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 9E5AA21F8608 for ; Thu, 12 Apr 2012 06:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.296
X-Spam-Level: 
X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.303,  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 f03lvCnugvvS for ; Thu, 12 Apr 2012 05:59:59 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 659A821F85F4 for ; Thu, 12 Apr 2012 05:59:59 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAALRhk9/AAAB/2dsb2JhbABDhXK3FyNWNQINGQJZBiyHdat+iXmBIYEviX8BhTeBGASIWo0SkDaDBYE2ARY
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4E9D91FD0C9; Thu, 12 Apr 2012 07:59:58 -0500 (CDT)
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 vJS7jC3BY5WF; Thu, 12 Apr 2012 07:59:57 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id EA2E61FD0C8; Thu, 12 Apr 2012 07:59:57 -0500 (CDT)
Date: Thu, 12 Apr 2012 07:59:57 -0500 (CDT)
From: Mukul Goyal 
To: C Chauvenet 
Message-ID: <1657890566.1196.1334235597878.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.91]
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] Closure text for Ticket #95
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, 12 Apr 2012 13:00:00 -0000

#95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
 
Resolution:
------------

 No because multiple DROs would be generated if multiple source  routes are being discovered.

Discussion:
--------------

p15 :  Stop (S): This flag, when set to one by a target, indicates that  the P2P-RPL route discovery is over.

[Cedric]
Is this bit really usefull ? My guess is that it will be always set to 1.
If you hear a DRO, this indeed means that the RDO has reached the target,  so you could just stop processing RDO when you hear a DRO.
Do we really need a flag to stop RDO processing or the hearing of a DRO  type message could do the job ?

[Mukul]
A P2P-RPL invocation might involve discovery of multiple source routes. In  that case, receipt of a DRO does not mean route discovery is over. Only  when the target sets the stop flag in the DRO, a node could be sure that  the route discovery is over.

[Cedric2]
OK fo multiple discovery.
But if I want to discover a route to a multicast group of target. I set a multicast adress in the target field of the RDO. Then, do I received as many DRO message as the number of target reached ? In that case, would the first DRO with a "S" flag stop the RDO propagation to reach all the target included in the multicast group ?
 
[Mukul2]
A target cannot set the S flag to one in the DRO if the target address in the P2P-RDO specified a multicast address. See the following text at the end of page 21 in P2P-RPL-9:
 
"The target MAY set the stop flag inside the DRO message to one if

Goyal, et al.           Expires September 7, 2012              [Page 21]
 
 Internet-Draft         draft-ietf-roll-p2p-rpl-09             March 2012 

 o  this router is the only target specified in the corresponding DIO,
    i.e., the corresponding DIO specified a unicast address of the
    router as the Target inside the P2P-RDO with no additional targets
    specified via RPL Target Options; and
 
 " 
 
[Cedric3] 
 So how do you stop the RDO flooding when the target adress is mulicast ? 
 
[Mukul3]
 
 Stop flag cannot be used when the target address is multicast or when multiple unicast targets are there. The DIO generation will stop when the DAG dies. In the meanwhile, trickle algorithm would hopefully avoid unnecessary message generation. Note that the draft recommends a very small value for the redundancy constant.
 
[Cedric4]
 So in this case, the RDO (I guess this is what you mean when you mentioned "DIO" in you previous message) generation to discover the route is never ending until the temporary DAG dies ?
 
[Mukul4] Never ending wont be the correct description. The temporary DAG lasts for a few seconds only. Plus, the trickle algorithm would prevent the generation of many DIOs.
 
[Cedric4]
I guess the RDO flooding would stop according to the MaxRank/NH field  of the P2P-RDO message.
 
[Mukul4]
Yes, it would. MaxRank and other routing constraints would always limit the scope of route discovery. Note that there are two separate things:
 1) scope of discovery: how far the discovery message (P2P-RDO inside the DIO) travels. This is controlled by the routing constraints and the maxRank field inside the P2P-RDO.
 2) How many discovery messages are generated by the nodes that join the DAG: this is controlled by trickle timer and ultimately by the DAG life time. The stop flag in the DRO is an optimization that allows DIO generation to stop in the nodes that can hear the stop flag.
 
[Cedric4]
But if this field is set to 0 (meaning infinity according to section 7.1), we should find a mechanism to stop the discovery mechanism.
What do you think ?
 
[Mukul4]
To tell the truth, MaxRank is basically a way to avoid putting a metric container in the DIO (when a limit on rank is the only constraint you want to specify). The scope of discovery is limited by both MaxRank as well as the routing constraints in the metric container. 
 
[Cedric5]
Actually, the problem for stopping the discovery process without the "S" flag is also present with unicast addresses, because not all nodes will hear the DRO (Only the nodes in the neighborhood of DRO forwarders).
So we ended with some nodes forming and maintaining a temporary DAG even is they are not included in the discovered path, until the temporary DAG dies.
As you mentioned, the maxRank field, routing constraints, and trickle or DAG lifetime limit this overhead.
The section 9.2 of this draft give useful guidelines for trickle operation using the P2P RPL mechanism, and limit the flooding of RDO messages.
The only improvement we could add is to avoid the maintenance of some part of the temporary DAG that don't hear the DRO with the S flag.
This nodes will still send out some DIO when the trickle timer fires. Though, thank's to the trickle's operation described in section 9.2, they won't be propagated.
One possibility could be to state that : "if a DRO has not been heard within a certain period of time, then their node is not considered as a part of the discovered path and should leave the temporary DAG".
 
[Mukul5]
Two problems:
 1) An intermediate router has no idea how long the target wants to wait before generating DRO.

[Cedric6]
Correct.

[Mukul5]
2) If an intermediate router leaves the DAG early (ie before the DAG's lifetime is over), it might end up rejoining the DAG when it hears the DAG's DIO again.

[Cedric6]
Yes. So if I understand correctly, even if a mechanism enable nodes that are not along the discovered path to leave the temporary DAG, they will join it at some point due to the temporary DAG maintenance messages (DIOs).
So in the end, the benefit I saw (Saving power, packets, state maintenance), is not there.
Then if there is no benefit, there is no reason to change the spec.
So if what I wrote above is correct, I'm OK to close the ticket and don't change anything about the "S" flag behavior.


[Cedric5] 
This "certain period of time" could be determined according to the network topology, the application, or the network diameter for instance and let to the implementation.
 
[Mukul5]
It would be much easier if the origin could choose a small (yet reasonable) lifetime for the DAG.

[Cedric6]
I agree that this parameters will greatly impact on the RPL P2P cost.

 
[Cedric5]
I see a benefit in the case of a discovery process to a unicast target in a very large and sparse network. Here, a lot of nodes will maintain unnecessary states if they are not part of the discovered path.
With the current spec, they will send periodic and unnessecary DIO. The handling of a "DRO timeout reception" could save packets, thus battery, bandwidth etc... 
 
[Mukul5]
I am not sure this will work as I explained above.

From trac+roll@trac.tools.ietf.org  Thu Apr 12 07:27:30 2012
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 0B77621F853C for ; Thu, 12 Apr 2012 07:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.509
X-Spam-Level: 
X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 nIw+x5lpPun0 for ; Thu, 12 Apr 2012 07:27:29 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 46D9721F852E for ; Thu, 12 Apr 2012 07:27:28 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIKzZ-00053v-CM; Thu, 12 Apr 2012 10:27:22 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Thu, 12 Apr 2012 14:27:21 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/87#comment:1
Message-ID: <070.5061628a409140c45d644c5e77e4c442@trac.tools.ietf.org>
References: <055.f551806bbfcbaa57b44d89571c962af8@trac.tools.ietf.org>
X-Trac-Ticket-ID: 87
In-Reply-To: <055.f551806bbfcbaa57b44d89571c962af8@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #87: Can't we split the target from the RDO ?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Apr 2012 14:27:30 -0000

#87: Can't we split the target from the RDO ?

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 JP

 I Agree to close for an experimental and I suggest we revisit should the
 work go standard track.

 Cheers
 Pascal


 -----Original Message-----
 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
 Mukul Goyal
 Sent: dimanche 8 avril 2012 17:56
 To: roll@ietf.org
 Subject: Re: [Roll] [roll] #87: Can't we split the target from the RDO ?

 Hi JP

 Please mark this ticket as closed.

 Thanks
 Mukul

 ----- Original Message -----
 From: "roll issue tracker" 
 To: mukul@UWM.EDU, jpv@cisco.com
 Cc: roll@ietf.org
 Sent: Wednesday, April 4, 2012 8:09:56 AM
 Subject: [roll] #87: Can't we split the target from the RDO ?

 #87: Can't we split the target from the RDO ?

 Problem (proposed resolution)
 ------------------------------
 The RDO is a garbage option will all sorts of data in it. The advocated
 reason for that is conciseness since separate options mean overhead.
 OTOH, it makes more sense to have all the targets expresses as target
 options as opposed to having one target in the DRO and then all other
 targets listed after. Having the target separate would allow for a DIO
 with no RDO but only a target, which would be useful to poll a device on
 an existing DAG. Currently the draft MUST a RDO and MAY and target
 option. The suggestion is to allow for a target in DIO without a RDO.

 Proposed resolution
 -------------------------
 Keep it at that since 1) there are implementations and 2) it's
 experimental . This resolution implies that the issue will be reopened
 should the work go for standard track

 Discussion
 -------------

 [Pascal]" MAY carry one or more RPL Target Options to specify additional
 unicast/multicast addresses for the target."
 Now here I would have a MUST carry at least one target. That is indeed
 what makes is a lookup DIO...

 [Mukul]
 As I stated in the previous message, we need to include the target in  the
 P2P-RDO to save bytes for the common case (discover route to one
 unicast/multicast target). So, we cannot make using the target option a
 MUST.

 [Pascal2] Certainly. I prefer the split, in which case the MUST IMHO  goes
 to the target as opposed to the RDO. In a case where the RDO is not
 needed, the target only message is actually shorter...

 [Mukul2] As I said before, I think a P2P mode DIO always needs to have
 one P2P-RDO. I guess, in this case, we agree to disagree!

 [Pascal3] Certainly. And there's nothing blocking with that  disagreement,
 mostly if the draft targets experimental.
 I think it's OK to keep your response as the proposed resolution for  the
 issue. Still I'd like advice from others so exposing the issue as LC  will
 help. Let's see on which side the coin falls.

 [Mukul3] OK. I will be happy to hear additional opinions.

 [Pascal4] Fine, let's keep that as the proposed resolution

 [Mukul4] OK.
 Pascal

 --
 -----------------------------------+---------------------
 Reporter:  jpv@…                  |      Owner:  mukul@…
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
 Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
 -----------------------------------+---------------------

 Ticket URL: 
 roll 

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

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From mcr@sandelman.ca  Thu Apr 12 07:45:49 2012
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 1258021F867F for ; Thu, 12 Apr 2012 07:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.954
X-Spam-Level: 
X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 I7cj-10UclbP for ; Thu, 12 Apr 2012 07:45:48 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 154D021F8674 for ; Thu, 12 Apr 2012 07:45:47 -0700 (PDT)
Received: from sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 91D8A3450E; Thu, 12 Apr 2012 10:42:52 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id E65C798AAF; Thu, 12 Apr 2012 10:45:43 -0400 (EDT)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E081398AA9; Thu, 12 Apr 2012 10:45:43 -0400 (EDT)
From: Michael Richardson 
To: Mukul Goyal 
In-Reply-To: <723690941.1887908.1334112685750.JavaMail.root@mail17.pantherlink.uwm.edu>
References: <723690941.1887908.1334112685750.JavaMail.root@mail17.pantherlink.uwm.edu>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 12 Apr 2012 10:45:43 -0400
Message-ID: <18955.1334241943@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll 
Subject: Re: [Roll] Closure text for ticket #86
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, 12 Apr 2012 14:45:49 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Mukul" =3D=3D Mukul Goyal  writes:
    Mukul> #86: G flag: do we need that text?

    Mukul> Problem ------------------------------ Disagreement on the
    Mukul> meaning of 'G' bit and imposed setting to 0;

    Mukul> Proposed resolution --------------------------- Add the
    Mukul> following text to the draft:

    Mukul> "The origin sets the G flag to indicate the relative
    Mukul> importance of the route discovery it is initiating. The G
    Mukul> flag is set to one if this particular route discovery is more
    Mukul> important from application's perspective than some other
    Mukul> route discovery. In other words, the origin sets the G flag
    Mukul> to one if this particular route discovery helps meet the
    Mukul> application defined goal \cite{rpl}. Thus, the G flag setting
    Mukul> helps an intermediate router choose which route discoveries
    Mukul> to participate in if it cannot participate in all route
    Mukul> discoveries. An intermediate router SHOULD participate in
    Mukul> route discoveries with G flag set to one (in preference to
    Mukul> ones with G flag set to zero)."

I concur.

{I can conceive of a situation where the target node creates a DODAG
with G=3D0, seeking the originating end, but this is outside of the scope of
what P2P describes.}

=2D-=20
]       He who is tired of Weird Al is tired of life!           |  firewall=
s  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net archit=
ect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri=
ver[
   Kyoto Plus: watch the video 
	               then sign the petition.=20

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQCVAwUAT4bql4qHRg3pndX9AQLh1AQAwV+4xuk0nTmP33Rexyah6InpPHiIaHfc
GsXjZJ0RS8qiQCBPxvrayhtcjrfI16S/Do7HImJUiHuFo51vxCJUN5VGgoV4enuX
EFUvEAzQFzmKPdC74lvzMGmV9oxwOqd+riQJsCOIQBcQTwC+gKEBFVmWdAwQCuPG
JOwqfK/evt4=
=Ni3M
-----END PGP SIGNATURE-----
--=-=-=--

From mcr@sandelman.ca  Thu Apr 12 10:40:05 2012
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 8DF7121F8535 for ; Thu, 12 Apr 2012 10:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.871
X-Spam-Level: 
X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 RO5EFRKhX0ur for ; Thu, 12 Apr 2012 10:40:04 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id D5AB821F8532 for ; Thu, 12 Apr 2012 10:40:04 -0700 (PDT)
Received: from sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 190FD344E2 for ; Thu, 12 Apr 2012 13:37:11 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id BA96698AAF; Thu, 12 Apr 2012 13:40:02 -0400 (EDT)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8694298AA9 for ; Thu, 12 Apr 2012 13:40:02 -0400 (EDT)
From: Michael Richardson 
To: roll@ietf.org
In-Reply-To: <87lim28py9.fsf@kelsey-ws.hq.ember.com>
References: <723690941.1887908.1334112685750.JavaMail.root@mail17.pantherlink.uwm.edu> <87lim28py9.fsf@kelsey-ws.hq.ember.com>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 12 Apr 2012 13:40:02 -0400
Message-ID: <17970.1334252402@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] Closure text for ticket #86
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, 12 Apr 2012 17:40:05 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Richard" =3D=3D Richard Kelsey  writes:
    >> "The origin sets the G flag to indicate the relative importance
    >> of the route discovery it is initiating. The G flag is set to one
    >> if this particular route discovery is more important from
    >> application's perspective than some other route discovery. In
    >> other words, the origin sets the G flag to one if this particular
    >> route discovery helps meet the application defined goal
    >> \cite{rpl}. Thus, the G flag setting helps an intermediate router
    >> choose which route discoveries to participate in if it cannot
    >> participate in all route discoveries. An intermediate router
    >> SHOULD participate in route discoveries with G flag set to one
    >> (in preference to ones with G flag set to zero)."

    Richard> If you want to repurpose the G flag in this way you need to
    Richard> be clear that the usage in RFC 6550 no longer applies.  I
    Richard> think that the best way to do this would be to say that
    Richard> clause 3 of 8.2.2.2 does not apply to P2P DAGs:

I would like to understand why you feel that in the P2P case, setting
G=3D1 is somehow repurposing the G flag.

    Richard> Not having floating DODAGs would mean that the original use
    Richard> of the G flag is no longer necessary.

There is no use in floating DODAGs... *for the P2P case*.
I think that floating DODAGs have many uses in the P2MP case, during
DODAG construction and repair.

=2D-=20
]       He who is tired of Weird Al is tired of life!           |  firewall=
s  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net archit=
ect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri=
ver[
   Kyoto Plus: watch the video 
	               then sign the petition.=20



--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQCVAwUAT4cTcoqHRg3pndX9AQKUqAQApfQULOMVVAnpFVLLosWSSLZS9azt0wnS
gMeMApF0NYoP+VunsSuUIiSWTDG9i6i20j+SiWTcn+Sfq+zILQWDfcdfk/CsNTCp
6O0HbzsuNamB9UoMCvRvISMxtcvSGBUjWP0VFaDLuA5RCVG44cF10I3UM9u6CIE/
ckNiN1uD0w4=
=Y5+1
-----END PGP SIGNATURE-----
--=-=-=--

From prvs=44399eb11=mukul@uwm.edu  Fri Apr 13 00:02:59 2012
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 BCEED21F8669 for ; Fri, 13 Apr 2012 00:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.683
X-Spam-Level: 
X-Spam-Status: No, score=-5.683 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
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 ezIM6xs7H9rK for ; Fri, 13 Apr 2012 00:02:58 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5E33B21F8668 for ; Fri, 13 Apr 2012 00:02:58 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisGAI/Oh09/AAAB/2dsb2JhbABDhXKyKIUAAQEFI1YMDxEEAQEDAg0WAwJICQgGExmHdQurXYlmgSGBL4oEhQyBGASIWo0SgRGPJYMFgTYBFg
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 43BA3E6A8D; Fri, 13 Apr 2012 02:02:57 -0500 (CDT)
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 PD6rGhtkx+Nw; Fri, 13 Apr 2012 02:02:56 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id AB0C4E6A72; Fri, 13 Apr 2012 02:02:56 -0500 (CDT)
Date: Fri, 13 Apr 2012 02:02:56 -0500 (CDT)
From: Mukul Goyal 
To: "Pascal Thubert (pthubert)" 
Message-ID: <251473365.14968.1334300576562.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.91]
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] [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
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, 13 Apr 2012 07:02:59 -0000

Hi Pascal

Now we are on the same page. I propose that the following text in section 6=
.1 of P2P-RPL spec:

"The Default Lifetime and Lifetime Unit parameters in DODAG
      Configuration option indicate the life time of the state the
      routers maintain for a hop-by-hop route established using P2P-RPL
      and may be set as desired.

"

be replaced by the following text:

"The origin sets the Default Lifetime and Lifetime Unit parameters in DODAG=
 Configuration option to indicate the life time of the state the routers, i=
ncluding the origin and the target(s), maintain for a hop-by-hop or a sourc=
e route discovered using P2P-RPL.
"

Thanks
Mukul


----- Original Message -----
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
Cc: jpv@cisco.com, "roll" 
Sent: Wednesday, April 11, 2012 1:22:52 AM
Subject: RE: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Mukul:

We have a disconnect because you insist in thinking that I refer to the lif=
etime of the temporary DAG as indicated in the RDO.
But no. I reworded twice and used very specific words this last time.=20
Please remove the temp Dag from the discussion and read again in the light =
that I'm really talking about the states HbH routing states as I very speci=
fically indicate.
If that does not work then we'll need a phone call to resync.

Cheers,

Pascal


-----Original Message-----
From: Mukul Goyal [mailto:mukul@uwm.edu]=20
Sent: mercredi 11 avril 2012 01:59
To: Pascal Thubert (pthubert)
Cc: jpv@cisco.com; roll
Subject: Re: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Hi Pascal

>I do not wish to change the DAG lifetime.

>I'm pointing out that the conversation between the origin and target canno=
t work longer than the lifetime of the "hop-by-hop routing states" which it=
 depends on. So why not use that?

You mean state about the "temporary DAG" and not the hop-by-hop state for t=
he "discovered route"? They are two different things.

>I suggest that we converge the time duration specified in DODAG configurat=
ion option to mean the maximum duration of states in all nodes that need to=
 keep states, including origin and target, and in some case intermediate ro=
uters.

We are using the time duration in DODAG configuration option to specify the=
 lifetime of the "hop-by-hop state for the discovered route" (and not the l=
ifetime of the "temporary DAG"). A discovered HbH route may need to be main=
tained for a wide range of time durations. Hence, we would like to specify =
the lifetime of a discovered route using the rich semantics provided by the=
 time duration fields inside the DODAG configuration option. On the other h=
and, the lifetime of a temporary DAG does not need to vary a whole lot. So,=
 we provide 4 options for this lifetime (1, 4, 16 and 64 seconds) and speci=
fy this lifetime in a 2-bit field inside P2P-RDO.

Do you agree with how the two lifetimes (lifetime of DAG and lifetime of th=
e discovered route) are specified in P2P-RPL?

>IOW, if the HbH route is used, the lifetime in the config option is for al=
l states in all nodes on the path(s) including origins and target(s). If Hb=
H routing is not used, the lifetime in the config option is still valid for=
 the source and the origin. You may define a default value that suit classi=
cal P2P routes in the case where no config of any sort is provided.=20

You seem to want the config option to specify the lifetime of the temporary=
 DAG. This would be a wastage of rich semantic provided by those fields. If=
 you could agree to specifying the temporary DAG lifetime inside P2P-RDO (t=
he way P2P-RPL currently does), I see no problem whatsoever. All nodes (inc=
luding the origin and target) joining the temporary DAG maintain state for =
the temporary DAG (which is not same as the state for the discovered HbH ro=
ute) for the duration specified in P2P-RDO. We could further require that a=
ll DRO/DRO-ACK exchange MUST complete within the temporary DAG lifetime (sp=
ecified inside P2P-RDO). So, the temporary DAG's lifetime has to be chosen =
carefully. Having said that, I still prefer giving origin and target extra =
time (equal to one more lifetime) to complete DRO/DRO-ACK exchange.

Thanks
Mukul

>And yes, great point, you'd need to specify that the lifetime in the confi=
g option must be large enough to accommodate the retransmissions.

>Do we converge?

>Pascal


-----Original Message-----
From: Mukul Goyal [mailto:mukul@uwm.edu]=20
Sent: mardi 10 avril 2012 14:55
To: Pascal Thubert (pthubert)
Cc: jpv@cisco.com; roll
Subject: Re: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

OR the simpler option would be to require DRO/DRO-ACK exchange to complete =
within the DAG's life time? If we were to specify a new parameter for the t=
ime limit on DRO/DRO-ACK exchange, both target and origin would need to agr=
ee on the value of this parameter.

Mukul

----- Original Message -----
From: "Mukul Goyal" 
To: "Pascal Thubert (pthubert)" 
Cc: jpv@cisco.com, "roll" 
Sent: Tuesday, April 10, 2012 7:50:16 AM
Subject: Re: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Hi Pascal

Hopefully we are talking about the same thing.

>No, it's not closed. We are talking about a contract between lower layers =
in all nodes including the source and origin to maintain necessary resource=
s and all contracts must have a lifetime.

1. A node that joins a temporary P2P-RPL DAG maintains state for the DAG fo=
r the time duration specified as DAG life time.
2. A node that establishes hop-by-hop routing state for a route discovered =
using P2P-RPL maintains this state for the time duration specified in DODAG=
 configuration option.

Origin and target need to exchange DROs and DRO-ACKs. I could specify a new=
 configurable parameter to specify the time limit on this exchange. This pa=
rameter's value  has to be more than DAG life time. One option is to specif=
y it in terms of existing parameters: DAG life time + (MAX_DRO_RETRANSMISSI=
ONS + 1)*DRO_ACK_WAIT_TIME.

Thanks
Mukul
----- Original Message -----
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
Cc: jpv@cisco.com
Sent: Tuesday, April 10, 2012 4:45:46 AM
Subject: RE: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Hi Mukul,

No, it's not closed. We are talking about a contract between lower layers i=
n all nodes including the source and origin to maintain necessary resources=
 and all contracts must have a lifetime.
I do not mind you overload the RPL lifetime of the routing for the states a=
t origin and target and if you have a sentence that makes it clear then we'=
ll be in agreement.

Cheers,

Pascal


-----Original Message-----
From: Mukul Goyal [mailto:mukul@uwm.edu]=20
Sent: dimanche 8 avril 2012 17:52
To: Pascal Thubert (pthubert)
Cc: jpv@cisco.com
Subject: Re: [roll] #85: which lifetime is for the end points (origin and t=
arget) vs. intermediate nodes.

Pascal

Can we consider this issue closed? Please see my last response.

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" 
To: mukul@UWM.EDU, jpv@cisco.com
Cc: roll@ietf.org
Sent: Wednesday, April 4, 2012 8:06:30 AM
Subject: [roll] #85: which lifetime is for the end points (origin and targe=
t) vs. intermediate nodes.

#85: which lifetime is for the end points (origin and target) vs. intermedi=
ate nodes.

 Problem (currently open)
 ------------------------------
 P2P creates temporary states in the transient DAG and less-but-still  temp=
orary states in the endpoints. These are 2 different lifetimes. The  spec h=
as 2 lifetimes, one in the config option and one in the RDO. The  spec is n=
ot sufficiently clear about which is which. In can appear to be  conflictin=
g since the config option is supposed to apply to all routers  on the path.=
 On the side, and in order to allow the reuse of instance  ID, the origin m=
ust be sure that all states for a previous usage of the  same value are gon=
e. So we need a clear control / negotiation of the  lifetimes on the states=
 that come with an instanceID. Again this is not  clear enough in the spec.



 [Pascal2]
 2) Same question if you want to create states at the target to route  back=
. How long does the target need to maintain the route? Who controls  that, =
the origin or the target? I'd expect to find a suggested lifetime  in the R=
DO with a confirmation in the DRO to let the target amend it.

 [Mukul2]
 If the target wants DRO-ACK it needs to maintain state until DRO-ACK is  r=
eceived. Otherwise, the target needs to remember things until it is  done s=
ending all the DROs. I will add the text to this effect.

 [Pascal3]
 If you are setting up a short term conversation, how long exactly is  that=
 before the origin has to refresh the route? What controls clean up  in bot=
h sides? Usually you want a lifetime (see MIP6 for instance)

 [Mukul3]
 Is it that you are talking about the lifetime of the hop-by-hop routing  s=
tate? That is specified in the life time parameters in the DODAG  configura=
tion option. The draft says that on page 9 while describing how  the DODAG =
configuration option should be set inside a P2P mode DIO:

 "The Default Lifetime and Lifetime Unit parameters in DODAG
      Configuration option indicate the life time of the state the
      routers maintain for a hop-by-hop route established using P2P-RPL
      and may be set as desired.
 "

 [Pascal4] Maybe that's so but then you need to reword a little bit cause  =
you got me qiute confused. I've been talking of the lifetime of the  states=
 at origin and target for one conversation. Since they might be  having a t=
ransient conversation, and the origin might reuse the instance  ID soon, yo=
u need to give a limit in time to the states that you are  creating. Still =
that conversation is longer than the states in the  intermediate routers. S=
o you have 2 lifetimes and you have to be very  clear which is which. Perso=
nally, I'd have used the lifetime in the  configuration option for all the =
routers on the way and I'd have used  the new lifetime in the RDO as the co=
nversation lifetime in the end  points because:
 1)  that is the new concept.
 2) This would allow the target to confirm exactly how long it locks  resou=
rces,
 3) and this would be more compatible with the description of the config  o=
ption in RFC 6550.

 [Mukul4]
 There are two lifetimes:
 1) Lifetime of the temporary DAG: this is specified inside P2P-RDO
 2) Lifetime of the routing state for the hop-by-hop route established  usi=
ng P2P-RPL: this is specified inside the DODAG configuration option.
 All routers on the established route (including the origin) maintain  stat=
e for this route for this much time. This time could very well be  infinity=
.

 Now, lets talk about the "states at origin and target". The origin and  th=
e target maintain the state about the temporary DAG for the DAG's life  tim=
e. This is true for all the nodes that join this DAG. All such nodes  maint=
ain state about the temporary DAG until the DAG's life time is  over. It is=
 true that the target and the origin exchange DROs and  DRO-ACKs and this e=
xchange could conceivably go on even after the  temporary DAG's demise. How=
 long should the origin and target indulge in  this exchange (and hence rem=
ember the possibly dead DAG)? I think it is  purely their choice and the dr=
aft need not impose any artificial time  limit on this.

 Pascal

--=20
-----------------------------------+---------------------
 Reporter:  jpv@=E2=80=A6                  |      Owner:  mukul@=E2=80=A6
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: 
roll 


From pthubert@cisco.com  Fri Apr 13 01:12:09 2012
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 DFB9C21F8669 for ; Fri, 13 Apr 2012 01:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.041
X-Spam-Level: 
X-Spam-Status: No, score=-9.041 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 OTi8DLYpQbKh for ; Fri, 13 Apr 2012 01:12:09 -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 B9BF721F864B for ; Fri, 13 Apr 2012 01:12:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3628; q=dns/txt; s=iport; t=1334304728; x=1335514328; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=bvf32ueJOuBK4uu0ZKo+W04R6wwdn4NmmXifp+qRdZA=; b=WAa/03ugth/dAnesye1sJSokkCuoAx9bo2ndGGSVjNhp8cpknj480HOu Uqnj39dSPL3yk0b/Q4SyftO+drEvTnvQinJ+v1xIq/lS8OSOkeAm4M9cW OSitgonSoLkokfF58rPYJ/hdyjlJIzKQLA31vdyGPt2RW8cn0cdqCvCSG 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAL3eh0+Q/khM/2dsb2JhbABFuXGBB4IJAQEBBBIBHQpLBAIBCBEEAQELBhcBBgEbKgkIAQEEARIIEQmHbAuZeZFSjiqQdGMEhwqbA4IsgWmCaQ
X-IronPort-AV: E=Sophos;i="4.75,415,1330905600"; d="scan'208";a="70749501"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2012 08:12:07 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3D8C7CD025707; Fri, 13 Apr 2012 08:12:07 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);  Fri, 13 Apr 2012 10:12:07 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Apr 2012 10:11:35 +0200
Message-ID: 
In-Reply-To: <17970.1334252402@marajade.sandelman.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Closure text for ticket #86
Thread-Index: Ac0Y01KgLnWRpK6kRey70E+kWEOgAAAd6yvA
References: <723690941.1887908.1334112685750.JavaMail.root@mail17.pantherlink.uwm.edu><87lim28py9.fsf@kelsey-ws.hq.ember.com> <17970.1334252402@marajade.sandelman.ca>
From: "Pascal Thubert (pthubert)" 
To: "Michael Richardson" , 
X-OriginalArrivalTime: 13 Apr 2012 08:12:07.0789 (UTC) FILETIME=[1E76C9D0:01CD194D]
Subject: Re: [Roll] Closure text for ticket #86
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, 13 Apr 2012 08:12:10 -0000

Hi Michael:

I tend to agree that we are somewhat repurposing G... or extending it if
that's a better word.
The clear part of G's meaning is related to floating DAGs which is a
concept that comes with global instances.
Local instances were defined and reserved in RFC 6550 for use in P2P.
RFC 6550 did not push as far as locking meaning for the G bit.
It actually makes sense that the draft that really defines a use of
local instances also defines what G does in that world.
And here we thought is that instead of comparing DODAGs within a DAG
associated to a global instance, G would now be used to compare DODAGs
that are each a DAG associated to a local instance.
The semantic shift is that now, G eventually compares the applicative
value of different apps for a user as opposed to the routing value of
various DODAGs for an application. We went up a level.
That's actually not a bad idea since P2P is getting us deeper in the
world of autonomic networks and thus into higher level abstractions.
I do not see that there is any opposition in doing it. The wish here is
that the text must indicate more clearly that we are doing this shift.
I think that Mukul will provide the additional informative sentence that
we'd like to see.=20
In any case, I see no point in keeping that ticket open. Too much ML
bandwidth was used on that discussion. Unless Richard speaks up again
which I doubt, I think we really want the ticket and discussion closed.
=20
Cheers,

Pascal


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Michael Richardson
Sent: jeudi 12 avril 2012 19:40
To: roll@ietf.org
Subject: Re: [Roll] Closure text for ticket #86


>>>>> "Richard" =3D=3D Richard Kelsey  writes:
    >> "The origin sets the G flag to indicate the relative importance
    >> of the route discovery it is initiating. The G flag is set to one
    >> if this particular route discovery is more important from
    >> application's perspective than some other route discovery. In
    >> other words, the origin sets the G flag to one if this particular
    >> route discovery helps meet the application defined goal
    >> \cite{rpl}. Thus, the G flag setting helps an intermediate router
    >> choose which route discoveries to participate in if it cannot
    >> participate in all route discoveries. An intermediate router
    >> SHOULD participate in route discoveries with G flag set to one
    >> (in preference to ones with G flag set to zero)."

    Richard> If you want to repurpose the G flag in this way you need to
    Richard> be clear that the usage in RFC 6550 no longer applies.  I
    Richard> think that the best way to do this would be to say that
    Richard> clause 3 of 8.2.2.2 does not apply to P2P DAGs:

I would like to understand why you feel that in the P2P case, setting
G=3D1 is somehow repurposing the G flag.

    Richard> Not having floating DODAGs would mean that the original use
    Richard> of the G flag is no longer necessary.

There is no use in floating DODAGs... *for the P2P case*.
I think that floating DODAGs have many uses in the P2MP case, during
DODAG construction and repair.

--=20
]       He who is tired of Weird Al is tired of life!           |
firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
driver[
   Kyoto Plus: watch the video

	               then sign the petition.=20



From prvs=44399eb11=mukul@uwm.edu  Fri Apr 13 01:20:04 2012
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 7835D21F847D for ; Fri, 13 Apr 2012 01:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.296
X-Spam-Level: 
X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.303,  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 SIHxj4xe6vFw for ; Fri, 13 Apr 2012 01:20:02 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0000521F8476 for ; Fri, 13 Apr 2012 01:20:01 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAKrgh09/AAAB/2dsb2JhbABFhWa2ewEBAQQBAQEgSwsMDxEEAQEDAg0WAwIpHwkIBhMZh3ULpweJZIkJgS+JeQqFDYEYBIhajRKBEY8lgwWBNgISAwI
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id D59D6E6A8E; Fri, 13 Apr 2012 03:19:58 -0500 (CDT)
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 VpNakTkCqNea; Fri, 13 Apr 2012 03:19:58 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 2CA5AE6A8D; Fri, 13 Apr 2012 03:19:58 -0500 (CDT)
Date: Fri, 13 Apr 2012 03:19:58 -0500 (CDT)
From: Mukul Goyal 
To: "Pascal Thubert (pthubert)" 
Message-ID: <676835701.15044.1334305198002.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.91]
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] #90: use of transient instance ID
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, 13 Apr 2012 08:20:04 -0000

Hi Pascal

1.) I propose adding the following text at the end of Section 9.6 (Processi=
ng a DRO at an Intermediate Router) in P2P-RPL spec:

"The hop-by-hop routing state established on receiving a DRO MUST expire at=
 the end of the lifetime specified by the Default Lifetime and Lifetime Uni=
t parameters inside the DODAG Configuration Option used in P2P mode DIOs fo=
r this route discovery.
A future version of this document may consider specifying a signalling mech=
anism that will allow the origin to extend (or shorten)
the lifetime of a P2P-RPL hop-by-hop route following a suitable hint from a=
n upper-layer protocol."

2.) I propose replacing the following text in Section 9.5 (Additional Proce=
ssing of a P2P mode DIO at the Target):

"The target MAY store the route contained in the P2P-RDO in the received DI=
O for use as a source route to reach the origin."

with the following text:

"The target MAY store the route contained in the P2P-RDO in the received DI=
O for use as a source route to reach the origin. The lifetime of this sourc=
e route is specified by the Default Lifetime and Lifetime Unit parameters i=
nside the DODAG Configuration Option in the received DIO. This lifetime can=
 be extended (or shortened) appropriately following a suitable hint from an=
 upper-layer protocol."

3.) I propose replacing the following text in Section 9.7 (Processing a DRO=
 at the Origin):

"If the P2P-RDO inside the DRO identifies the discovered route as a source =
route (H=3D0), the origin MUST store in its memory the
   discovered route contained in the Address vector."

with the following text:

"If the P2P-RDO inside the DRO identifies the discovered route as a source =
route (H=3D0), the origin MUST store in its memory the
   discovered route contained in the Address vector. The lifetime of this s=
ource route is specified by the Default Lifetime and Lifetime Unit paramete=
rs inside the DODAG Configuration Option used in P2P mode DIOs for this rou=
te discovery. This lifetime can be extended (or shortened) appropriately fo=
llowing a suitable hint from an upper-layer protocol."

4.) One consequence of these changes is that the intermediate router or the=
 origin MUST still belong to the temporary DAG in order to process a receiv=
ed DRO. This is because the intermediate router (or the origin) needs to kn=
ow the lifetime (contained in the config option) to be associated with the =
HbH/source routing state it would establish on processing the DRO.

Can we now consider the issue closed?

Thanks
Mukul


----- Original Message -----
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
Cc: roll@ietf.org
Sent: Thursday, April 12, 2012 1:13:14 AM
Subject: RE: [Roll] [roll] #90: use of transient instance ID

Hi Mukul

Don't worry! For the upper layers interaction I'm only asking for one sente=
nce, not an API spec... Like:
=20
"The required lifetime for the routing states may be provided by the applic=
ation via a hint from upper-layer protocols. Additional hints from upper-la=
yer protocols can be used to tear down the remaining states at the origin a=
nd/or at the target as soon the application need of those states is termina=
ted or the application detects that the states are not functional anymore. =
In a same fashion, an interaction with upper layers can be used to determin=
e that the routing states are still valid and can be prolonged for an addit=
ional lifetime"

That's all!

For your questions please see inline. Also, as an example of existing art, =
RFC 4861 stays as abstract as I do above with text like:

      DELAY       The neighbor is no longer known to be reachable, and
                  traffic has recently been sent to the neighbor.
                  Rather than probe the neighbor immediately, however,
                  delay sending probes for a short while in order to
                  give upper-layer protocols a chance to provide
                  reachability confirmation.

...

7.3.1. Reachability Confirmation


   A neighbor is considered reachable if the node has recently received
   a confirmation that packets sent recently to the neighbor were
   received by its IP layer.  Positive confirmation can be gathered in
   two ways: hints from upper-layer protocols that indicate a connection
   is making "forward progress", or receipt of a Neighbor Advertisement
   message that is a response to a Neighbor Solicitation message.


Pascal

-----Original Message-----

[Pascal] Also, when there are no routing states in intermediate routers, an=
 indication from upper layers can be used in the end points to consider tha=
t all states for an instanceID are now cleaned up.

[Mukul] Not sure what you mean.=20

[Pascal2] Let me reword:  if HbH routin gis not used, the only states with =
any persistence are on the origin and target(s). The upper layer protocol (=
ULP) in origin and target may know when they are done with their need for t=
he routes. If they are done before (config option) lifetime is up, they can=
 tear down the states. This requires a new cross layer interaction triggere=
d by ULP, similar to IPv6 ND in DELAY state.

[Mukul2]
You think P2P-RPL needs to define this cross-layer interaction? This is sim=
ply the upper layer telling the network layer to chuck a source route. Isn'=
t it? The upper/lower layers dont even need to remember that this route was=
 discovered using P2P-RPL. Also, the origin (or the target) can use a sourc=
e route as long as it wants. Why should the lifetime in config option dicta=
te how long this route can be used?

[Pascal3] In IPv6, by design, everything has a lifetime. Better fix this no=
w than during IESG review. In the case of this draft, nodes commit resource=
s which are by definition limited. Thus in the general case that the draft =
addresses they can't commit those resources forever. One end point might di=
e, say out of battery. There must be something that in any case will ensure=
 that all parties, end points and intermediate routers in HbH end up clean =
even if there is no (rst) signaling to achieve so.=20

You can pick a large lifetime if you like for the light switch you have in =
mind; but there needs to be a lifetime, after which states must be revalida=
ted. That can be rebuilding the DAG, this can be unicast like a ping, and t=
his can by piggy backed with traffic. ND for instance uses upper layer hint=
s to validate that the reachability without necessarily signaling everythin=
g. Since you are going for experimental, I'm asking for the bare minimum, a=
 simple lifetime using existing means (the config option).=20

 If an application is responsible for setting up routing states, this appli=
cation may also be clever enough to provide a hint on the lifetime, and to =
tear down the states that it caused when it does not need them anymore. If =
the application does not provide any hint whatsoever, the implementation at=
 the origin will select a reasonable lifetime that will depend on the funct=
ion of the object. I'm certainly not asking to define the interaction betwe=
en upper layer and L3, this is internal and thus implementation.

 Cheers,

Pascal

----- Original Message -----
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" , roll@ietf.org
Sent: Tuesday, April 10, 2012 4:52:50 AM
Subject: RE: [Roll] [roll] #90: use of transient instance ID

Mukul:

I meant a suggestion, not a capitalized word. I prefer the suggestion but I=
'm still OK with your proposal. If we get in agreement on the lifetime of t=
he states (issue #85), then you can indicate that lifetime is one way to de=
termine when all stale states can be considered gone. Also, when there are =
no routing states in intermediate routers, an indication from upper layers =
can be used in the end points to consider that all states for an instanceID=
 are now cleaned up.

Cheers,

Pascal


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Muk=
ul Goyal
Sent: dimanche 8 avril 2012 18:09
To: roll@ietf.org
Subject: Re: [Roll] [roll] #90: use of transient instance ID

Hi Pascal

Re-read your proposed resolution text. I am not sure that the draft should =
suggest rotating the instance ids. My proposed resolution is to simply sugg=
est not using instance id that might be in use.

" [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD
 NOT) against reusing instance ids for which the stale state might exist  i=
n the nodes."

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" 
To: mukul@UWM.EDU, jpv@cisco.com
Cc: roll@ietf.org
Sent: Wednesday, April 4, 2012 8:11:44 AM
Subject: [roll] #90: use of transient instance ID

#90: use of transient instance ID

 Problem (resolution agreed upon)
 ------------------------------
 P2P creates temporary states in the transient DAG with a transient  instan=
ce ID. The protocol must ensure that if the instance ID is reused  then the=
 new operation it is not confused with states resulting from the  previous =
use of the same instance ID. Suggestion is to propose a  rotation.

 Discussion
 -------------

 [Pascal]
 "RPLInstanceID: RPLInstanceID MUST be a local value as described in  Secti=
on 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the same  RPLInstanc=
eID in two or more concurrent route discoveries."

 I'd suggest that you enforce a round robin or an opaque circulation so  th=
at the new instanceID is the least recently used one out of the 64  possibl=
e.

 [Mukul]
 I think we should leave it to the origin to decide which value it wants  t=
o use for RPLInstanceID. I know some implementations are planning to  use a=
 fixed RPLInstanceID value for all route discoveries.

 [Pascal2] Changing the instance ID will help debug the network and avoid  =
conflicts with stale states. What's really up to the device is the  initial=
 sequence. Leaving it up to the origin may help the origin defeat  some att=
acks to some degree. OTOH, after all the instances have been  played, LRU f=
orces to replay the same sequence again so the shield  drops. My preferred =
approach would be a SHOULD that would say that the  next instance ID SHOULD=
 NOT be one of the (16?) most recently used and  MUST NOT be one for which =
states might still exist in the network. IOW  either the states deletion wa=
s acknowledged, or all pending lifetimes  are exhausted.

 [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD
 NOT) against reusing instance ids for which the stale state might exist  i=
n the nodes. Using a "MUST NOT" may not be OK since a node may never be  10=
0% sure about non-existence of stale state with a particular instance  id (=
thus, all possible instance id values will become suspect and hence  unusab=
le after a while).

 [Pascal3] Agreed. Note that a circulation is a bonus to defeat replays.
 And now we're back to the issue above. How does the device know that  ther=
e is no state left? A lifetime definition would be very useful. That  lifet=
ime is different from the DAG's one in RDO. I think we have an open  issue =
here.

 [Mukul3] As I mentioned above, the life time parameters inside the DODAG  =
configuration option specify the life time of the hop-by-hop routing  state=
 for the routes discovered using P2P-RPL.

 [Pascal4] This boils down to the thread above. Only one issue really,  whi=
ch lifetime is which? So IMHO no need to log anything for this  thread.

 [Mukul4] OK.

 Pascal

--=20
-----------------------------------+---------------------
 Reporter:  jpv@=E2=80=A6                  |      Owner:  mukul@=E2=80=A6
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: 
roll 

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

From pthubert@cisco.com  Fri Apr 13 01:39:15 2012
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 B28E721F8786 for ; Fri, 13 Apr 2012 01:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.099
X-Spam-Level: 
X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw117SIxWSTO for ; Fri, 13 Apr 2012 01:39:14 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4024D21F877D for ; Fri, 13 Apr 2012 01:39:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=17394; q=dns/txt; s=iport; t=1334306353; x=1335515953; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=EaHd6dI38alCrxbeMV/FZi+ScR0eAbBlPV4+HVtcK/U=; b=EPxJ1juAerxz045x/ZHRKSQ0G+PvraZljDz3RniBn7GYwrLMUiOaJa1E qCnBEjIJb0jip3EMOi632b4OqTuVjXf4fGlN2pQnF6ZmclrpYjCGzs78j jfzWzYNHkMEZZxjROr7Z3HrYGnncXaJdy52buQKT94IaQHqenvbKN3vI7 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAOjlh0+Q/khR/2dsb2JhbABFDoVYsWF4gQeCCQEBAQQBAQEPARANBDoLDAQCAQgRBAEBAwIGBhcBAgICAQElHwkIAQEEEwgRCYdsC5l5jRCSb4EviXkKhQ01YwSWfY08gWmCMDmBUgISAwI
X-IronPort-AV: E=Sophos;i="4.75,415,1330905600"; d="scan'208";a="135039230"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2012 08:39:12 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3D8dCQk022819; Fri, 13 Apr 2012 08:39:12 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);  Fri, 13 Apr 2012 10:39:12 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 13 Apr 2012 10:37:38 +0200
Message-ID: 
In-Reply-To: <676835701.15044.1334305198002.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] [roll] #90: use of transient instance ID
Thread-Index: Ac0ZTjpVsc9vTz+OTwqA2ndt1zVIEwAAOzgw
References:  <676835701.15044.1334305198002.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
X-OriginalArrivalTime: 13 Apr 2012 08:39:12.0083 (UTC) FILETIME=[E69E6230:01CD1950]
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #90: use of transient instance ID
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, 13 Apr 2012 08:39:15 -0000

SGVsbG8gTXVrdWwNCg0KMS4pIEkgcHJvcG9zZSBhZGRpbmcgdGhlIGZvbGxvd2luZyB0ZXh0IGF0
IHRoZSBlbmQgb2YgU2VjdGlvbiA5LjYgKFByb2Nlc3NpbmcgYSBEUk8gYXQgYW4gSW50ZXJtZWRp
YXRlIFJvdXRlcikgaW4gUDJQLVJQTCBzcGVjOg0KDQoiVGhlIGhvcC1ieS1ob3Agcm91dGluZyBz
dGF0ZSBlc3RhYmxpc2hlZCBvbiByZWNlaXZpbmcgYSBEUk8gTVVTVCBleHBpcmUgYXQgdGhlIGVu
ZCBvZiB0aGUgbGlmZXRpbWUgc3BlY2lmaWVkIGJ5IHRoZSBEZWZhdWx0IExpZmV0aW1lIGFuZCBM
aWZldGltZSBVbml0IHBhcmFtZXRlcnMgaW5zaWRlIHRoZSBET0RBRyBDb25maWd1cmF0aW9uIE9w
dGlvbiB1c2VkIGluIFAyUCBtb2RlIERJT3MgZm9yIHRoaXMgcm91dGUgZGlzY292ZXJ5Lg0KQSBm
dXR1cmUgdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50IG1heSBjb25zaWRlciBzcGVjaWZ5aW5nIGEg
c2lnbmFsbGluZyBtZWNoYW5pc20gdGhhdCB3aWxsIGFsbG93IHRoZSBvcmlnaW4gdG8gZXh0ZW5k
IChvciBzaG9ydGVuKSB0aGUgbGlmZXRpbWUgb2YgYSBQMlAtUlBMIGhvcC1ieS1ob3Agcm91dGUg
Zm9sbG93aW5nIGEgc3VpdGFibGUgaGludCBmcm9tIGFuIHVwcGVyLWxheWVyIHByb3RvY29sLiIN
Cg0KW1Bhc2NhbF0gU2luY2Ugd2UncmUgc2hvb3RpbmcgZm9yIGV4cGVyaW1lbnRhbCBJJ20gZmlu
ZSB3aXRoIHRoaXMuIFdlJ2xsIGhhdmUgdG8gZWZmZWN0aXZlbHkgY29uc2lkZXIgdGhlIG1lbnRp
b25lZCBhZGRpdGlvbiB3aGVuIGdvaW5nIHN0YW5kYXJkIHRyYWNrLg0KDQoyLikgSSBwcm9wb3Nl
IHJlcGxhY2luZyB0aGUgZm9sbG93aW5nIHRleHQgaW4gU2VjdGlvbiA5LjUgKEFkZGl0aW9uYWwg
UHJvY2Vzc2luZyBvZiBhIFAyUCBtb2RlIERJTyBhdCB0aGUgVGFyZ2V0KToNCg0KIlRoZSB0YXJn
ZXQgTUFZIHN0b3JlIHRoZSByb3V0ZSBjb250YWluZWQgaW4gdGhlIFAyUC1SRE8gaW4gdGhlIHJl
Y2VpdmVkIERJTyBmb3IgdXNlIGFzIGEgc291cmNlIHJvdXRlIHRvIHJlYWNoIHRoZSBvcmlnaW4u
Ig0KDQp3aXRoIHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KIlRoZSB0YXJnZXQgTUFZIHN0b3JlIHRo
ZSByb3V0ZSBjb250YWluZWQgaW4gdGhlIFAyUC1SRE8gaW4gdGhlIHJlY2VpdmVkIERJTyBmb3Ig
dXNlIGFzIGEgc291cmNlIHJvdXRlIHRvIHJlYWNoIHRoZSBvcmlnaW4uIFRoZSBsaWZldGltZSBv
ZiB0aGlzIHNvdXJjZSByb3V0ZSBpcyBzcGVjaWZpZWQgYnkgdGhlIERlZmF1bHQgTGlmZXRpbWUg
YW5kIExpZmV0aW1lIFVuaXQgcGFyYW1ldGVycyBpbnNpZGUgdGhlIERPREFHIENvbmZpZ3VyYXRp
b24gT3B0aW9uIGluIHRoZSByZWNlaXZlZCBESU8uIFRoaXMgbGlmZXRpbWUgY2FuIGJlIGV4dGVu
ZGVkIChvciBzaG9ydGVuZWQpIGFwcHJvcHJpYXRlbHkgZm9sbG93aW5nIGEgc3VpdGFibGUgaGlu
dCBmcm9tIGFuIHVwcGVyLWxheWVyIHByb3RvY29sLiINCg0KW1Bhc2NhbF0gV29ya3MgZm9yIG1l
DQoNCg0KMy4pIEkgcHJvcG9zZSByZXBsYWNpbmcgdGhlIGZvbGxvd2luZyB0ZXh0IGluIFNlY3Rp
b24gOS43IChQcm9jZXNzaW5nIGEgRFJPIGF0IHRoZSBPcmlnaW4pOg0KDQoiSWYgdGhlIFAyUC1S
RE8gaW5zaWRlIHRoZSBEUk8gaWRlbnRpZmllcyB0aGUgZGlzY292ZXJlZCByb3V0ZSBhcyBhIHNv
dXJjZSByb3V0ZSAoSD0wKSwgdGhlIG9yaWdpbiBNVVNUIHN0b3JlIGluIGl0cyBtZW1vcnkgdGhl
DQogICBkaXNjb3ZlcmVkIHJvdXRlIGNvbnRhaW5lZCBpbiB0aGUgQWRkcmVzcyB2ZWN0b3IuIg0K
DQp3aXRoIHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KIklmIHRoZSBQMlAtUkRPIGluc2lkZSB0aGUg
RFJPIGlkZW50aWZpZXMgdGhlIGRpc2NvdmVyZWQgcm91dGUgYXMgYSBzb3VyY2Ugcm91dGUgKEg9
MCksIHRoZSBvcmlnaW4gTVVTVCBzdG9yZSBpbiBpdHMgbWVtb3J5IHRoZQ0KICAgZGlzY292ZXJl
ZCByb3V0ZSBjb250YWluZWQgaW4gdGhlIEFkZHJlc3MgdmVjdG9yLiBUaGUgbGlmZXRpbWUgb2Yg
dGhpcyBzb3VyY2Ugcm91dGUgaXMgc3BlY2lmaWVkIGJ5IHRoZSBEZWZhdWx0IExpZmV0aW1lIGFu
ZCBMaWZldGltZSBVbml0IHBhcmFtZXRlcnMgaW5zaWRlIHRoZSBET0RBRyBDb25maWd1cmF0aW9u
IE9wdGlvbiB1c2VkIGluIFAyUCBtb2RlIERJT3MgZm9yIHRoaXMgcm91dGUgZGlzY292ZXJ5LiBU
aGlzIGxpZmV0aW1lIGNhbiBiZSBleHRlbmRlZCAob3Igc2hvcnRlbmVkKSBhcHByb3ByaWF0ZWx5
IGZvbGxvd2luZyBhIHN1aXRhYmxlIGhpbnQgZnJvbSBhbiB1cHBlci1sYXllciBwcm90b2NvbC4i
DQoNCltQYXNjYWxdIFdvcmtzIGZvciBtZQ0KDQo0LikgT25lIGNvbnNlcXVlbmNlIG9mIHRoZXNl
IGNoYW5nZXMgaXMgdGhhdCB0aGUgaW50ZXJtZWRpYXRlIHJvdXRlciBvciB0aGUgb3JpZ2luIE1V
U1Qgc3RpbGwgYmVsb25nIHRvIHRoZSB0ZW1wb3JhcnkgREFHIGluIG9yZGVyIHRvIHByb2Nlc3Mg
YSByZWNlaXZlZCBEUk8uIFRoaXMgaXMgYmVjYXVzZSB0aGUgaW50ZXJtZWRpYXRlIHJvdXRlciAo
b3IgdGhlIG9yaWdpbikgbmVlZHMgdG8ga25vdyB0aGUgbGlmZXRpbWUgKGNvbnRhaW5lZCBpbiB0
aGUgY29uZmlnIG9wdGlvbikgdG8gYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBIYkgvc291cmNlIHJv
dXRpbmcgc3RhdGUgaXQgd291bGQgZXN0YWJsaXNoIG9uIHByb2Nlc3NpbmcgdGhlIERSTy4NCg0K
DQpbUGFzY2FsXSBXaGljaCBpcyBhIGNvbnN0cmFpbnQgdGhhdCB5b3UgcGxhY2Ugb24gdGhlIGFk
bWluIHRoYXQgY2hvb3NlcyB0aGUgdGVtcG9yYXJ5IERBRyBsaWZldGltZS4gIEFuZCB0aGVyZSds
bCBwcm9iYWJseSBiZSBhIHdlbGwta25vd24gZGVmYXVsdCBzbyB0aGF0IHRoZSBjb25maWcgb3B0
aW9uIGlzIG5vdCByZXF1aXJlZCBpbiB3aGljaCBjYXNlIHN0b3JpbmcgdGhhdCBzdGF0ZSBpcyBu
b3QgcmVxdWlyZWQgZWl0aGVyLiBZb3UgbWF5IHdhbnQgYSBzZW50ZW5jZSB0byBzYXkgdGhhdC4u
Lg0KDQpDYW4gd2Ugbm93IGNvbnNpZGVyIHRoZSBpc3N1ZSBjbG9zZWQ/DQoNCltQYXNjYWxdIHll
cywgd2UgY2FuLiAoSSBhbHdheXMgZHJlYW1lZCBvZiBzYXlpbmcgdGhpcy4uLikNCiANClRoYW5r
cw0KTXVrdWwNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiUGFzY2Fs
IFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0aHViZXJ0QGNpc2NvLmNvbT4NClRvOiAiTXVrdWwgR295
YWwiIDxtdWt1bEB1d20uZWR1Pg0KQ2M6IHJvbGxAaWV0Zi5vcmcNClNlbnQ6IFRodXJzZGF5LCBB
cHJpbCAxMiwgMjAxMiAxOjEzOjE0IEFNDQpTdWJqZWN0OiBSRTogW1JvbGxdIFtyb2xsXSAjOTA6
IHVzZSBvZiB0cmFuc2llbnQgaW5zdGFuY2UgSUQNCg0KSGkgTXVrdWwNCg0KRG9uJ3Qgd29ycnkh
IEZvciB0aGUgdXBwZXIgbGF5ZXJzIGludGVyYWN0aW9uIEknbSBvbmx5IGFza2luZyBmb3Igb25l
IHNlbnRlbmNlLCBub3QgYW4gQVBJIHNwZWMuLi4gTGlrZToNCiANCiJUaGUgcmVxdWlyZWQgbGlm
ZXRpbWUgZm9yIHRoZSByb3V0aW5nIHN0YXRlcyBtYXkgYmUgcHJvdmlkZWQgYnkgdGhlIGFwcGxp
Y2F0aW9uIHZpYSBhIGhpbnQgZnJvbSB1cHBlci1sYXllciBwcm90b2NvbHMuIEFkZGl0aW9uYWwg
aGludHMgZnJvbSB1cHBlci1sYXllciBwcm90b2NvbHMgY2FuIGJlIHVzZWQgdG8gdGVhciBkb3du
IHRoZSByZW1haW5pbmcgc3RhdGVzIGF0IHRoZSBvcmlnaW4gYW5kL29yIGF0IHRoZSB0YXJnZXQg
YXMgc29vbiB0aGUgYXBwbGljYXRpb24gbmVlZCBvZiB0aG9zZSBzdGF0ZXMgaXMgdGVybWluYXRl
ZCBvciB0aGUgYXBwbGljYXRpb24gZGV0ZWN0cyB0aGF0IHRoZSBzdGF0ZXMgYXJlIG5vdCBmdW5j
dGlvbmFsIGFueW1vcmUuIEluIGEgc2FtZSBmYXNoaW9uLCBhbiBpbnRlcmFjdGlvbiB3aXRoIHVw
cGVyIGxheWVycyBjYW4gYmUgdXNlZCB0byBkZXRlcm1pbmUgdGhhdCB0aGUgcm91dGluZyBzdGF0
ZXMgYXJlIHN0aWxsIHZhbGlkIGFuZCBjYW4gYmUgcHJvbG9uZ2VkIGZvciBhbiBhZGRpdGlvbmFs
IGxpZmV0aW1lIg0KDQpUaGF0J3MgYWxsIQ0KDQpGb3IgeW91ciBxdWVzdGlvbnMgcGxlYXNlIHNl
ZSBpbmxpbmUuIEFsc28sIGFzIGFuIGV4YW1wbGUgb2YgZXhpc3RpbmcgYXJ0LCBSRkMgNDg2MSBz
dGF5cyBhcyBhYnN0cmFjdCBhcyBJIGRvIGFib3ZlIHdpdGggdGV4dCBsaWtlOg0KDQogICAgICBE
RUxBWSAgICAgICBUaGUgbmVpZ2hib3IgaXMgbm8gbG9uZ2VyIGtub3duIHRvIGJlIHJlYWNoYWJs
ZSwgYW5kDQogICAgICAgICAgICAgICAgICB0cmFmZmljIGhhcyByZWNlbnRseSBiZWVuIHNlbnQg
dG8gdGhlIG5laWdoYm9yLg0KICAgICAgICAgICAgICAgICAgUmF0aGVyIHRoYW4gcHJvYmUgdGhl
IG5laWdoYm9yIGltbWVkaWF0ZWx5LCBob3dldmVyLA0KICAgICAgICAgICAgICAgICAgZGVsYXkg
c2VuZGluZyBwcm9iZXMgZm9yIGEgc2hvcnQgd2hpbGUgaW4gb3JkZXIgdG8NCiAgICAgICAgICAg
ICAgICAgIGdpdmUgdXBwZXItbGF5ZXIgcHJvdG9jb2xzIGEgY2hhbmNlIHRvIHByb3ZpZGUNCiAg
ICAgICAgICAgICAgICAgIHJlYWNoYWJpbGl0eSBjb25maXJtYXRpb24uDQoNCi4uLg0KDQo3LjMu
MS4gUmVhY2hhYmlsaXR5IENvbmZpcm1hdGlvbg0KDQoNCiAgIEEgbmVpZ2hib3IgaXMgY29uc2lk
ZXJlZCByZWFjaGFibGUgaWYgdGhlIG5vZGUgaGFzIHJlY2VudGx5IHJlY2VpdmVkDQogICBhIGNv
bmZpcm1hdGlvbiB0aGF0IHBhY2tldHMgc2VudCByZWNlbnRseSB0byB0aGUgbmVpZ2hib3Igd2Vy
ZQ0KICAgcmVjZWl2ZWQgYnkgaXRzIElQIGxheWVyLiAgUG9zaXRpdmUgY29uZmlybWF0aW9uIGNh
biBiZSBnYXRoZXJlZCBpbg0KICAgdHdvIHdheXM6IGhpbnRzIGZyb20gdXBwZXItbGF5ZXIgcHJv
dG9jb2xzIHRoYXQgaW5kaWNhdGUgYSBjb25uZWN0aW9uDQogICBpcyBtYWtpbmcgImZvcndhcmQg
cHJvZ3Jlc3MiLCBvciByZWNlaXB0IG9mIGEgTmVpZ2hib3IgQWR2ZXJ0aXNlbWVudA0KICAgbWVz
c2FnZSB0aGF0IGlzIGEgcmVzcG9uc2UgdG8gYSBOZWlnaGJvciBTb2xpY2l0YXRpb24gbWVzc2Fn
ZS4NCg0KDQpQYXNjYWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KW1Bhc2NhbF0g
QWxzbywgd2hlbiB0aGVyZSBhcmUgbm8gcm91dGluZyBzdGF0ZXMgaW4gaW50ZXJtZWRpYXRlIHJv
dXRlcnMsIGFuIGluZGljYXRpb24gZnJvbSB1cHBlciBsYXllcnMgY2FuIGJlIHVzZWQgaW4gdGhl
IGVuZCBwb2ludHMgdG8gY29uc2lkZXIgdGhhdCBhbGwgc3RhdGVzIGZvciBhbiBpbnN0YW5jZUlE
IGFyZSBub3cgY2xlYW5lZCB1cC4NCg0KW011a3VsXSBOb3Qgc3VyZSB3aGF0IHlvdSBtZWFuLiAN
Cg0KW1Bhc2NhbDJdIExldCBtZSByZXdvcmQ6ICBpZiBIYkggcm91dGluIGdpcyBub3QgdXNlZCwg
dGhlIG9ubHkgc3RhdGVzIHdpdGggYW55IHBlcnNpc3RlbmNlIGFyZSBvbiB0aGUgb3JpZ2luIGFu
ZCB0YXJnZXQocykuIFRoZSB1cHBlciBsYXllciBwcm90b2NvbCAoVUxQKSBpbiBvcmlnaW4gYW5k
IHRhcmdldCBtYXkga25vdyB3aGVuIHRoZXkgYXJlIGRvbmUgd2l0aCB0aGVpciBuZWVkIGZvciB0
aGUgcm91dGVzLiBJZiB0aGV5IGFyZSBkb25lIGJlZm9yZSAoY29uZmlnIG9wdGlvbikgbGlmZXRp
bWUgaXMgdXAsIHRoZXkgY2FuIHRlYXIgZG93biB0aGUgc3RhdGVzLiBUaGlzIHJlcXVpcmVzIGEg
bmV3IGNyb3NzIGxheWVyIGludGVyYWN0aW9uIHRyaWdnZXJlZCBieSBVTFAsIHNpbWlsYXIgdG8g
SVB2NiBORCBpbiBERUxBWSBzdGF0ZS4NCg0KW011a3VsMl0NCllvdSB0aGluayBQMlAtUlBMIG5l
ZWRzIHRvIGRlZmluZSB0aGlzIGNyb3NzLWxheWVyIGludGVyYWN0aW9uPyBUaGlzIGlzIHNpbXBs
eSB0aGUgdXBwZXIgbGF5ZXIgdGVsbGluZyB0aGUgbmV0d29yayBsYXllciB0byBjaHVjayBhIHNv
dXJjZSByb3V0ZS4gSXNuJ3QgaXQ/IFRoZSB1cHBlci9sb3dlciBsYXllcnMgZG9udCBldmVuIG5l
ZWQgdG8gcmVtZW1iZXIgdGhhdCB0aGlzIHJvdXRlIHdhcyBkaXNjb3ZlcmVkIHVzaW5nIFAyUC1S
UEwuIEFsc28sIHRoZSBvcmlnaW4gKG9yIHRoZSB0YXJnZXQpIGNhbiB1c2UgYSBzb3VyY2Ugcm91
dGUgYXMgbG9uZyBhcyBpdCB3YW50cy4gV2h5IHNob3VsZCB0aGUgbGlmZXRpbWUgaW4gY29uZmln
IG9wdGlvbiBkaWN0YXRlIGhvdyBsb25nIHRoaXMgcm91dGUgY2FuIGJlIHVzZWQ/DQoNCltQYXNj
YWwzXSBJbiBJUHY2LCBieSBkZXNpZ24sIGV2ZXJ5dGhpbmcgaGFzIGEgbGlmZXRpbWUuIEJldHRl
ciBmaXggdGhpcyBub3cgdGhhbiBkdXJpbmcgSUVTRyByZXZpZXcuIEluIHRoZSBjYXNlIG9mIHRo
aXMgZHJhZnQsIG5vZGVzIGNvbW1pdCByZXNvdXJjZXMgd2hpY2ggYXJlIGJ5IGRlZmluaXRpb24g
bGltaXRlZC4gVGh1cyBpbiB0aGUgZ2VuZXJhbCBjYXNlIHRoYXQgdGhlIGRyYWZ0IGFkZHJlc3Nl
cyB0aGV5IGNhbid0IGNvbW1pdCB0aG9zZSByZXNvdXJjZXMgZm9yZXZlci4gT25lIGVuZCBwb2lu
dCBtaWdodCBkaWUsIHNheSBvdXQgb2YgYmF0dGVyeS4gVGhlcmUgbXVzdCBiZSBzb21ldGhpbmcg
dGhhdCBpbiBhbnkgY2FzZSB3aWxsIGVuc3VyZSB0aGF0IGFsbCBwYXJ0aWVzLCBlbmQgcG9pbnRz
IGFuZCBpbnRlcm1lZGlhdGUgcm91dGVycyBpbiBIYkggZW5kIHVwIGNsZWFuIGV2ZW4gaWYgdGhl
cmUgaXMgbm8gKHJzdCkgc2lnbmFsaW5nIHRvIGFjaGlldmUgc28uIA0KDQpZb3UgY2FuIHBpY2sg
YSBsYXJnZSBsaWZldGltZSBpZiB5b3UgbGlrZSBmb3IgdGhlIGxpZ2h0IHN3aXRjaCB5b3UgaGF2
ZSBpbiBtaW5kOyBidXQgdGhlcmUgbmVlZHMgdG8gYmUgYSBsaWZldGltZSwgYWZ0ZXIgd2hpY2gg
c3RhdGVzIG11c3QgYmUgcmV2YWxpZGF0ZWQuIFRoYXQgY2FuIGJlIHJlYnVpbGRpbmcgdGhlIERB
RywgdGhpcyBjYW4gYmUgdW5pY2FzdCBsaWtlIGEgcGluZywgYW5kIHRoaXMgY2FuIGJ5IHBpZ2d5
IGJhY2tlZCB3aXRoIHRyYWZmaWMuIE5EIGZvciBpbnN0YW5jZSB1c2VzIHVwcGVyIGxheWVyIGhp
bnRzIHRvIHZhbGlkYXRlIHRoYXQgdGhlIHJlYWNoYWJpbGl0eSB3aXRob3V0IG5lY2Vzc2FyaWx5
IHNpZ25hbGluZyBldmVyeXRoaW5nLiBTaW5jZSB5b3UgYXJlIGdvaW5nIGZvciBleHBlcmltZW50
YWwsIEknbSBhc2tpbmcgZm9yIHRoZSBiYXJlIG1pbmltdW0sIGEgc2ltcGxlIGxpZmV0aW1lIHVz
aW5nIGV4aXN0aW5nIG1lYW5zICh0aGUgY29uZmlnIG9wdGlvbikuIA0KDQogSWYgYW4gYXBwbGlj
YXRpb24gaXMgcmVzcG9uc2libGUgZm9yIHNldHRpbmcgdXAgcm91dGluZyBzdGF0ZXMsIHRoaXMg
YXBwbGljYXRpb24gbWF5IGFsc28gYmUgY2xldmVyIGVub3VnaCB0byBwcm92aWRlIGEgaGludCBv
biB0aGUgbGlmZXRpbWUsIGFuZCB0byB0ZWFyIGRvd24gdGhlIHN0YXRlcyB0aGF0IGl0IGNhdXNl
ZCB3aGVuIGl0IGRvZXMgbm90IG5lZWQgdGhlbSBhbnltb3JlLiBJZiB0aGUgYXBwbGljYXRpb24g
ZG9lcyBub3QgcHJvdmlkZSBhbnkgaGludCB3aGF0c29ldmVyLCB0aGUgaW1wbGVtZW50YXRpb24g
YXQgdGhlIG9yaWdpbiB3aWxsIHNlbGVjdCBhIHJlYXNvbmFibGUgbGlmZXRpbWUgdGhhdCB3aWxs
IGRlcGVuZCBvbiB0aGUgZnVuY3Rpb24gb2YgdGhlIG9iamVjdC4gSSdtIGNlcnRhaW5seSBub3Qg
YXNraW5nIHRvIGRlZmluZSB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiB1cHBlciBsYXllciBhbmQg
TDMsIHRoaXMgaXMgaW50ZXJuYWwgYW5kIHRodXMgaW1wbGVtZW50YXRpb24uDQoNCiBDaGVlcnMs
DQoNClBhc2NhbA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiUGFzY2Fs
IFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0aHViZXJ0QGNpc2NvLmNvbT4NClRvOiAiTXVrdWwgR295
YWwiIDxtdWt1bEB1d20uZWR1Piwgcm9sbEBpZXRmLm9yZw0KU2VudDogVHVlc2RheSwgQXByaWwg
MTAsIDIwMTIgNDo1Mjo1MCBBTQ0KU3ViamVjdDogUkU6IFtSb2xsXSBbcm9sbF0gIzkwOiB1c2Ug
b2YgdHJhbnNpZW50IGluc3RhbmNlIElEDQoNCk11a3VsOg0KDQpJIG1lYW50IGEgc3VnZ2VzdGlv
biwgbm90IGEgY2FwaXRhbGl6ZWQgd29yZC4gSSBwcmVmZXIgdGhlIHN1Z2dlc3Rpb24gYnV0IEkn
bSBzdGlsbCBPSyB3aXRoIHlvdXIgcHJvcG9zYWwuIElmIHdlIGdldCBpbiBhZ3JlZW1lbnQgb24g
dGhlIGxpZmV0aW1lIG9mIHRoZSBzdGF0ZXMgKGlzc3VlICM4NSksIHRoZW4geW91IGNhbiBpbmRp
Y2F0ZSB0aGF0IGxpZmV0aW1lIGlzIG9uZSB3YXkgdG8gZGV0ZXJtaW5lIHdoZW4gYWxsIHN0YWxl
IHN0YXRlcyBjYW4gYmUgY29uc2lkZXJlZCBnb25lLiBBbHNvLCB3aGVuIHRoZXJlIGFyZSBubyBy
b3V0aW5nIHN0YXRlcyBpbiBpbnRlcm1lZGlhdGUgcm91dGVycywgYW4gaW5kaWNhdGlvbiBmcm9t
IHVwcGVyIGxheWVycyBjYW4gYmUgdXNlZCBpbiB0aGUgZW5kIHBvaW50cyB0byBjb25zaWRlciB0
aGF0IGFsbCBzdGF0ZXMgZm9yIGFuIGluc3RhbmNlSUQgYXJlIG5vdyBjbGVhbmVkIHVwLg0KDQpD
aGVlcnMsDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBy
b2xsLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBNdWt1bCBHb3lhbA0KU2VudDogZGltYW5jaGUgOCBhdnJpbCAyMDEyIDE4OjA5DQpU
bzogcm9sbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtSb2xsXSBbcm9sbF0gIzkwOiB1c2Ugb2Yg
dHJhbnNpZW50IGluc3RhbmNlIElEDQoNCkhpIFBhc2NhbA0KDQpSZS1yZWFkIHlvdXIgcHJvcG9z
ZWQgcmVzb2x1dGlvbiB0ZXh0LiBJIGFtIG5vdCBzdXJlIHRoYXQgdGhlIGRyYWZ0IHNob3VsZCBz
dWdnZXN0IHJvdGF0aW5nIHRoZSBpbnN0YW5jZSBpZHMuIE15IHByb3Bvc2VkIHJlc29sdXRpb24g
aXMgdG8gc2ltcGx5IHN1Z2dlc3Qgbm90IHVzaW5nIGluc3RhbmNlIGlkIHRoYXQgbWlnaHQgYmUg
aW4gdXNlLg0KDQoiIFtNdWt1bDJdIE1ha2VzIHNlbnNlLiBJIHRoaW5rIGl0IGlzIHN1ZmZpY2ll
bnQgdG8gY2F1dGlvbiAod2l0aCBhIFNIT1VMRA0KIE5PVCkgYWdhaW5zdCByZXVzaW5nIGluc3Rh
bmNlIGlkcyBmb3Igd2hpY2ggdGhlIHN0YWxlIHN0YXRlIG1pZ2h0IGV4aXN0ICBpbiB0aGUgbm9k
ZXMuIg0KDQpUaGFua3MNCk11a3VsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZy
b206ICJyb2xsIGlzc3VlIHRyYWNrZXIiIDx0cmFjK3JvbGxAdHJhYy50b29scy5pZXRmLm9yZz4N
ClRvOiBtdWt1bEBVV00uRURVLCBqcHZAY2lzY28uY29tDQpDYzogcm9sbEBpZXRmLm9yZw0KU2Vu
dDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDEyIDg6MTE6NDQgQU0NClN1YmplY3Q6IFtyb2xsXSAj
OTA6IHVzZSBvZiB0cmFuc2llbnQgaW5zdGFuY2UgSUQNCg0KIzkwOiB1c2Ugb2YgdHJhbnNpZW50
IGluc3RhbmNlIElEDQoNCiBQcm9ibGVtIChyZXNvbHV0aW9uIGFncmVlZCB1cG9uKQ0KIC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFAyUCBjcmVhdGVzIHRlbXBvcmFyeSBzdGF0ZXMg
aW4gdGhlIHRyYW5zaWVudCBEQUcgd2l0aCBhIHRyYW5zaWVudCAgaW5zdGFuY2UgSUQuIFRoZSBw
cm90b2NvbCBtdXN0IGVuc3VyZSB0aGF0IGlmIHRoZSBpbnN0YW5jZSBJRCBpcyByZXVzZWQgIHRo
ZW4gdGhlIG5ldyBvcGVyYXRpb24gaXQgaXMgbm90IGNvbmZ1c2VkIHdpdGggc3RhdGVzIHJlc3Vs
dGluZyBmcm9tIHRoZSAgcHJldmlvdXMgdXNlIG9mIHRoZSBzYW1lIGluc3RhbmNlIElELiBTdWdn
ZXN0aW9uIGlzIHRvIHByb3Bvc2UgYSAgcm90YXRpb24uDQoNCiBEaXNjdXNzaW9uDQogLS0tLS0t
LS0tLS0tLQ0KDQogW1Bhc2NhbF0NCiAiUlBMSW5zdGFuY2VJRDogUlBMSW5zdGFuY2VJRCBNVVNU
IGJlIGEgbG9jYWwgdmFsdWUgYXMgZGVzY3JpYmVkIGluICBTZWN0aW9uIDUuMSBvZiBbSS1ELmll
dGYtcm9sbC1ycGxdLiBUaGUgb3JpZ2luIE1VU1QgTk9UIHVzZSB0aGUgc2FtZSAgUlBMSW5zdGFu
Y2VJRCBpbiB0d28gb3IgbW9yZSBjb25jdXJyZW50IHJvdXRlIGRpc2NvdmVyaWVzLiINCg0KIEkn
ZCBzdWdnZXN0IHRoYXQgeW91IGVuZm9yY2UgYSByb3VuZCByb2JpbiBvciBhbiBvcGFxdWUgY2ly
Y3VsYXRpb24gc28gIHRoYXQgdGhlIG5ldyBpbnN0YW5jZUlEIGlzIHRoZSBsZWFzdCByZWNlbnRs
eSB1c2VkIG9uZSBvdXQgb2YgdGhlIDY0ICBwb3NzaWJsZS4NCg0KIFtNdWt1bF0NCiBJIHRoaW5r
IHdlIHNob3VsZCBsZWF2ZSBpdCB0byB0aGUgb3JpZ2luIHRvIGRlY2lkZSB3aGljaCB2YWx1ZSBp
dCB3YW50cyAgdG8gdXNlIGZvciBSUExJbnN0YW5jZUlELiBJIGtub3cgc29tZSBpbXBsZW1lbnRh
dGlvbnMgYXJlIHBsYW5uaW5nIHRvICB1c2UgYSBmaXhlZCBSUExJbnN0YW5jZUlEIHZhbHVlIGZv
ciBhbGwgcm91dGUgZGlzY292ZXJpZXMuDQoNCiBbUGFzY2FsMl0gQ2hhbmdpbmcgdGhlIGluc3Rh
bmNlIElEIHdpbGwgaGVscCBkZWJ1ZyB0aGUgbmV0d29yayBhbmQgYXZvaWQgIGNvbmZsaWN0cyB3
aXRoIHN0YWxlIHN0YXRlcy4gV2hhdCdzIHJlYWxseSB1cCB0byB0aGUgZGV2aWNlIGlzIHRoZSAg
aW5pdGlhbCBzZXF1ZW5jZS4gTGVhdmluZyBpdCB1cCB0byB0aGUgb3JpZ2luIG1heSBoZWxwIHRo
ZSBvcmlnaW4gZGVmZWF0ICBzb21lIGF0dGFja3MgdG8gc29tZSBkZWdyZWUuIE9UT0gsIGFmdGVy
IGFsbCB0aGUgaW5zdGFuY2VzIGhhdmUgYmVlbiAgcGxheWVkLCBMUlUgZm9yY2VzIHRvIHJlcGxh
eSB0aGUgc2FtZSBzZXF1ZW5jZSBhZ2FpbiBzbyB0aGUgc2hpZWxkICBkcm9wcy4gTXkgcHJlZmVy
cmVkIGFwcHJvYWNoIHdvdWxkIGJlIGEgU0hPVUxEIHRoYXQgd291bGQgc2F5IHRoYXQgdGhlICBu
ZXh0IGluc3RhbmNlIElEIFNIT1VMRCBOT1QgYmUgb25lIG9mIHRoZSAoMTY/KSBtb3N0IHJlY2Vu
dGx5IHVzZWQgYW5kICBNVVNUIE5PVCBiZSBvbmUgZm9yIHdoaWNoIHN0YXRlcyBtaWdodCBzdGls
bCBleGlzdCBpbiB0aGUgbmV0d29yay4gSU9XICBlaXRoZXIgdGhlIHN0YXRlcyBkZWxldGlvbiB3
YXMgYWNrbm93bGVkZ2VkLCBvciBhbGwgcGVuZGluZyBsaWZldGltZXMgIGFyZSBleGhhdXN0ZWQu
DQoNCiBbTXVrdWwyXSBNYWtlcyBzZW5zZS4gSSB0aGluayBpdCBpcyBzdWZmaWNpZW50IHRvIGNh
dXRpb24gKHdpdGggYSBTSE9VTEQNCiBOT1QpIGFnYWluc3QgcmV1c2luZyBpbnN0YW5jZSBpZHMg
Zm9yIHdoaWNoIHRoZSBzdGFsZSBzdGF0ZSBtaWdodCBleGlzdCAgaW4gdGhlIG5vZGVzLiBVc2lu
ZyBhICJNVVNUIE5PVCIgbWF5IG5vdCBiZSBPSyBzaW5jZSBhIG5vZGUgbWF5IG5ldmVyIGJlICAx
MDAlIHN1cmUgYWJvdXQgbm9uLWV4aXN0ZW5jZSBvZiBzdGFsZSBzdGF0ZSB3aXRoIGEgcGFydGlj
dWxhciBpbnN0YW5jZSAgaWQgKHRodXMsIGFsbCBwb3NzaWJsZSBpbnN0YW5jZSBpZCB2YWx1ZXMg
d2lsbCBiZWNvbWUgc3VzcGVjdCBhbmQgaGVuY2UgIHVudXNhYmxlIGFmdGVyIGEgd2hpbGUpLg0K
DQogW1Bhc2NhbDNdIEFncmVlZC4gTm90ZSB0aGF0IGEgY2lyY3VsYXRpb24gaXMgYSBib251cyB0
byBkZWZlYXQgcmVwbGF5cy4NCiBBbmQgbm93IHdlJ3JlIGJhY2sgdG8gdGhlIGlzc3VlIGFib3Zl
LiBIb3cgZG9lcyB0aGUgZGV2aWNlIGtub3cgdGhhdCAgdGhlcmUgaXMgbm8gc3RhdGUgbGVmdD8g
QSBsaWZldGltZSBkZWZpbml0aW9uIHdvdWxkIGJlIHZlcnkgdXNlZnVsLiBUaGF0ICBsaWZldGlt
ZSBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgREFHJ3Mgb25lIGluIFJETy4gSSB0aGluayB3ZSBoYXZl
IGFuIG9wZW4gIGlzc3VlIGhlcmUuDQoNCiBbTXVrdWwzXSBBcyBJIG1lbnRpb25lZCBhYm92ZSwg
dGhlIGxpZmUgdGltZSBwYXJhbWV0ZXJzIGluc2lkZSB0aGUgRE9EQUcgIGNvbmZpZ3VyYXRpb24g
b3B0aW9uIHNwZWNpZnkgdGhlIGxpZmUgdGltZSBvZiB0aGUgaG9wLWJ5LWhvcCByb3V0aW5nICBz
dGF0ZSBmb3IgdGhlIHJvdXRlcyBkaXNjb3ZlcmVkIHVzaW5nIFAyUC1SUEwuDQoNCiBbUGFzY2Fs
NF0gVGhpcyBib2lscyBkb3duIHRvIHRoZSB0aHJlYWQgYWJvdmUuIE9ubHkgb25lIGlzc3VlIHJl
YWxseSwgIHdoaWNoIGxpZmV0aW1lIGlzIHdoaWNoPyBTbyBJTUhPIG5vIG5lZWQgdG8gbG9nIGFu
eXRoaW5nIGZvciB0aGlzICB0aHJlYWQuDQoNCiBbTXVrdWw0XSBPSy4NCg0KIFBhc2NhbA0KDQot
LSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t
LS0tLQ0KIFJlcG9ydGVyOiAganB2QOKApiAgICAgICAgICAgICAgICAgIHwgICAgICBPd25lcjog
IG11a3VsQOKApg0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICB8ICAgICBTdGF0
dXM6ICBuZXcNCiBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICAgfCAgTWlsZXN0b25l
Og0KQ29tcG9uZW50OiAgcDJwLXJwbCAgICAgICAgICAgICAgICB8ICAgIFZlcnNpb246DQogU2V2
ZXJpdHk6ICBTdWJtaXR0ZWQgV0cgRG9jdW1lbnQgIHwgICBLZXl3b3JkczoNCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaWNrZXQg
VVJMOiA8aHR0cHM6Ly9zdm4udG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC90cmFjL3RpY2tldC85MD4N
CnJvbGwgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9yb2xsLz4NCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xs
QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg==

From pthubert@cisco.com  Fri Apr 13 01:44:59 2012
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 54F4B21F87A9 for ; Fri, 13 Apr 2012 01:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.499
X-Spam-Level: 
X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24]
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 obid3yiapM0d for ; Fri, 13 Apr 2012 01:44:58 -0700 (PDT)
Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 329B821F879F for ; Fri, 13 Apr 2012 01:44:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=17576; q=dns/txt; s=iport; t=1334306696; x=1335516296; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=WjsR/oqohc4DuuajFeFmL9aNf9jx1iqxiy5B2m3sqmE=; b=KgwGD3cnsBvg0chPbax/3DqXIn2iB1HwDnxXd3t2FX/gva74y5gsLtJs OdN1rn2cVUfn+gMpMnlSsF1JvpptZpf4qFnF/LGPPeceNrCiQF+o38rOw FVEyxWLjouhv3Y03dBoQZwHR7kyB97kzoSfz7rwydUE0EqQ5MZGnzF/Uj 4=;
X-IronPort-AV: E=Sophos;i="4.75,415,1330905600";  d="scan'208";a="9976980"
Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 13 Apr 2012 08:16:27 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3D8GCnm015686; Fri, 13 Apr 2012 08:16:27 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);  Fri, 13 Apr 2012 10:16:22 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 13 Apr 2012 10:15:15 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
Thread-Index: Ac0ZTYwvpyi1PZq6TWOd2LsQP6RDpg==
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
X-OriginalArrivalTime: 13 Apr 2012 08:16:22.0401 (UTC) FILETIME=[B6397F10:01CD194D]
Cc: roll 
Subject: Re: [Roll] [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
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, 13 Apr 2012 08:44:59 -0000

SGkgTXVrdWwNCg0KUGVyZmVjdC4gQXMgZmFyIGFzIEknbSBjb25jZXJuZWQgd2UgY2FuIGNsb3Nl
IHRoaXMgb25lLi4uDQoNCjx0byB0aGUgTUw+IE11a3VsIGFuZCBJIGhhZCBhIGNhbGwgd2hlcmUg
d2UgZml4ZWQgb3VyIGRpc2Nvbm5lY3QuIA0KTXVrdWwncyBwcm9wb3NhbCBiZWxvdyBhZGRyZXNz
ZXMgdGhlIGlzc3VlIHRoYXQgSSBoYWQgaW4gbWluZCAtIGFzIG9wcG9zZWQgdG8gdGhlIGlzc3Vl
IHRoYXQgaGUgdGhvdWdodCBJIGhhZCBpbiBtaW5kIGFuZCB0aGF0IEJUVyB3ZSBhZ3JlZWQgd2Fz
IG5vdCBhbiBpc3N1ZS4uLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3VsQHV3bS5lZHVdIA0K
U2VudDogdmVuZHJlZGkgMTMgYXZyaWwgMjAxMiAwOTowMw0KVG86IFBhc2NhbCBUaHViZXJ0IChw
dGh1YmVydCkNCkNjOiBqcHZAY2lzY28uY29tOyByb2xsDQpTdWJqZWN0OiBSZTogW3JvbGxdICM4
NTogd2hpY2ggbGlmZXRpbWUgaXMgZm9yIHRoZSBlbmQgcG9pbnRzIChvcmlnaW4gYW5kIHRhcmdl
dCkgdnMuIGludGVybWVkaWF0ZSBub2Rlcy4NCg0KSGkgUGFzY2FsDQoNCk5vdyB3ZSBhcmUgb24g
dGhlIHNhbWUgcGFnZS4gSSBwcm9wb3NlIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGluIHNlY3Rp
b24gNi4xIG9mIFAyUC1SUEwgc3BlYzoNCg0KIlRoZSBEZWZhdWx0IExpZmV0aW1lIGFuZCBMaWZl
dGltZSBVbml0IHBhcmFtZXRlcnMgaW4gRE9EQUcNCiAgICAgIENvbmZpZ3VyYXRpb24gb3B0aW9u
IGluZGljYXRlIHRoZSBsaWZlIHRpbWUgb2YgdGhlIHN0YXRlIHRoZQ0KICAgICAgcm91dGVycyBt
YWludGFpbiBmb3IgYSBob3AtYnktaG9wIHJvdXRlIGVzdGFibGlzaGVkIHVzaW5nIFAyUC1SUEwN
CiAgICAgIGFuZCBtYXkgYmUgc2V0IGFzIGRlc2lyZWQuDQoNCiINCg0KYmUgcmVwbGFjZWQgYnkg
dGhlIGZvbGxvd2luZyB0ZXh0Og0KDQoiVGhlIG9yaWdpbiBzZXRzIHRoZSBEZWZhdWx0IExpZmV0
aW1lIGFuZCBMaWZldGltZSBVbml0IHBhcmFtZXRlcnMgaW4gRE9EQUcgQ29uZmlndXJhdGlvbiBv
cHRpb24gdG8gaW5kaWNhdGUgdGhlIGxpZmUgdGltZSBvZiB0aGUgc3RhdGUgdGhlIHJvdXRlcnMs
IGluY2x1ZGluZyB0aGUgb3JpZ2luIGFuZCB0aGUgdGFyZ2V0KHMpLCBtYWludGFpbiBmb3IgYSBo
b3AtYnktaG9wIG9yIGEgc291cmNlIHJvdXRlIGRpc2NvdmVyZWQgdXNpbmcgUDJQLVJQTC4NCiIN
Cg0KVGhhbmtzDQpNdWt1bA0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206
ICJQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPg0KVG86ICJN
dWt1bCBHb3lhbCIgPG11a3VsQHV3bS5lZHU+DQpDYzoganB2QGNpc2NvLmNvbSwgInJvbGwiIDxy
b2xsQGlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMSwgMjAxMiAxOjIyOjUyIEFN
DQpTdWJqZWN0OiBSRTogW3JvbGxdICM4NTogd2hpY2ggbGlmZXRpbWUgaXMgZm9yIHRoZSBlbmQg
cG9pbnRzIChvcmlnaW4gYW5kIHRhcmdldCkgdnMuIGludGVybWVkaWF0ZSBub2Rlcy4NCg0KTXVr
dWw6DQoNCldlIGhhdmUgYSBkaXNjb25uZWN0IGJlY2F1c2UgeW91IGluc2lzdCBpbiB0aGlua2lu
ZyB0aGF0IEkgcmVmZXIgdG8gdGhlIGxpZmV0aW1lIG9mIHRoZSB0ZW1wb3JhcnkgREFHIGFzIGlu
ZGljYXRlZCBpbiB0aGUgUkRPLg0KQnV0IG5vLiBJIHJld29yZGVkIHR3aWNlIGFuZCB1c2VkIHZl
cnkgc3BlY2lmaWMgd29yZHMgdGhpcyBsYXN0IHRpbWUuIA0KUGxlYXNlIHJlbW92ZSB0aGUgdGVt
cCBEYWcgZnJvbSB0aGUgZGlzY3Vzc2lvbiBhbmQgcmVhZCBhZ2FpbiBpbiB0aGUgbGlnaHQgdGhh
dCBJJ20gcmVhbGx5IHRhbGtpbmcgYWJvdXQgdGhlIHN0YXRlcyBIYkggcm91dGluZyBzdGF0ZXMg
YXMgSSB2ZXJ5IHNwZWNpZmljYWxseSBpbmRpY2F0ZS4NCklmIHRoYXQgZG9lcyBub3Qgd29yayB0
aGVuIHdlJ2xsIG5lZWQgYSBwaG9uZSBjYWxsIHRvIHJlc3luYy4NCg0KQ2hlZXJzLA0KDQpQYXNj
YWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTXVrdWwgR295YWwgW21h
aWx0bzptdWt1bEB1d20uZWR1XSANClNlbnQ6IG1lcmNyZWRpIDExIGF2cmlsIDIwMTIgMDE6NTkN
ClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpDYzoganB2QGNpc2NvLmNvbTsgcm9sbA0K
U3ViamVjdDogUmU6IFtyb2xsXSAjODU6IHdoaWNoIGxpZmV0aW1lIGlzIGZvciB0aGUgZW5kIHBv
aW50cyAob3JpZ2luIGFuZCB0YXJnZXQpIHZzLiBpbnRlcm1lZGlhdGUgbm9kZXMuDQoNCkhpIFBh
c2NhbA0KDQo+SSBkbyBub3Qgd2lzaCB0byBjaGFuZ2UgdGhlIERBRyBsaWZldGltZS4NCg0KPkkn
bSBwb2ludGluZyBvdXQgdGhhdCB0aGUgY29udmVyc2F0aW9uIGJldHdlZW4gdGhlIG9yaWdpbiBh
bmQgdGFyZ2V0IGNhbm5vdCB3b3JrIGxvbmdlciB0aGFuIHRoZSBsaWZldGltZSBvZiB0aGUgImhv
cC1ieS1ob3Agcm91dGluZyBzdGF0ZXMiIHdoaWNoIGl0IGRlcGVuZHMgb24uIFNvIHdoeSBub3Qg
dXNlIHRoYXQ/DQoNCllvdSBtZWFuIHN0YXRlIGFib3V0IHRoZSAidGVtcG9yYXJ5IERBRyIgYW5k
IG5vdCB0aGUgaG9wLWJ5LWhvcCBzdGF0ZSBmb3IgdGhlICJkaXNjb3ZlcmVkIHJvdXRlIj8gVGhl
eSBhcmUgdHdvIGRpZmZlcmVudCB0aGluZ3MuDQoNCj5JIHN1Z2dlc3QgdGhhdCB3ZSBjb252ZXJn
ZSB0aGUgdGltZSBkdXJhdGlvbiBzcGVjaWZpZWQgaW4gRE9EQUcgY29uZmlndXJhdGlvbiBvcHRp
b24gdG8gbWVhbiB0aGUgbWF4aW11bSBkdXJhdGlvbiBvZiBzdGF0ZXMgaW4gYWxsIG5vZGVzIHRo
YXQgbmVlZCB0byBrZWVwIHN0YXRlcywgaW5jbHVkaW5nIG9yaWdpbiBhbmQgdGFyZ2V0LCBhbmQg
aW4gc29tZSBjYXNlIGludGVybWVkaWF0ZSByb3V0ZXJzLg0KDQpXZSBhcmUgdXNpbmcgdGhlIHRp
bWUgZHVyYXRpb24gaW4gRE9EQUcgY29uZmlndXJhdGlvbiBvcHRpb24gdG8gc3BlY2lmeSB0aGUg
bGlmZXRpbWUgb2YgdGhlICJob3AtYnktaG9wIHN0YXRlIGZvciB0aGUgZGlzY292ZXJlZCByb3V0
ZSIgKGFuZCBub3QgdGhlIGxpZmV0aW1lIG9mIHRoZSAidGVtcG9yYXJ5IERBRyIpLiBBIGRpc2Nv
dmVyZWQgSGJIIHJvdXRlIG1heSBuZWVkIHRvIGJlIG1haW50YWluZWQgZm9yIGEgd2lkZSByYW5n
ZSBvZiB0aW1lIGR1cmF0aW9ucy4gSGVuY2UsIHdlIHdvdWxkIGxpa2UgdG8gc3BlY2lmeSB0aGUg
bGlmZXRpbWUgb2YgYSBkaXNjb3ZlcmVkIHJvdXRlIHVzaW5nIHRoZSByaWNoIHNlbWFudGljcyBw
cm92aWRlZCBieSB0aGUgdGltZSBkdXJhdGlvbiBmaWVsZHMgaW5zaWRlIHRoZSBET0RBRyBjb25m
aWd1cmF0aW9uIG9wdGlvbi4gT24gdGhlIG90aGVyIGhhbmQsIHRoZSBsaWZldGltZSBvZiBhIHRl
bXBvcmFyeSBEQUcgZG9lcyBub3QgbmVlZCB0byB2YXJ5IGEgd2hvbGUgbG90LiBTbywgd2UgcHJv
dmlkZSA0IG9wdGlvbnMgZm9yIHRoaXMgbGlmZXRpbWUgKDEsIDQsIDE2IGFuZCA2NCBzZWNvbmRz
KSBhbmQgc3BlY2lmeSB0aGlzIGxpZmV0aW1lIGluIGEgMi1iaXQgZmllbGQgaW5zaWRlIFAyUC1S
RE8uDQoNCkRvIHlvdSBhZ3JlZSB3aXRoIGhvdyB0aGUgdHdvIGxpZmV0aW1lcyAobGlmZXRpbWUg
b2YgREFHIGFuZCBsaWZldGltZSBvZiB0aGUgZGlzY292ZXJlZCByb3V0ZSkgYXJlIHNwZWNpZmll
ZCBpbiBQMlAtUlBMPw0KDQo+SU9XLCBpZiB0aGUgSGJIIHJvdXRlIGlzIHVzZWQsIHRoZSBsaWZl
dGltZSBpbiB0aGUgY29uZmlnIG9wdGlvbiBpcyBmb3IgYWxsIHN0YXRlcyBpbiBhbGwgbm9kZXMg
b24gdGhlIHBhdGgocykgaW5jbHVkaW5nIG9yaWdpbnMgYW5kIHRhcmdldChzKS4gSWYgSGJIIHJv
dXRpbmcgaXMgbm90IHVzZWQsIHRoZSBsaWZldGltZSBpbiB0aGUgY29uZmlnIG9wdGlvbiBpcyBz
dGlsbCB2YWxpZCBmb3IgdGhlIHNvdXJjZSBhbmQgdGhlIG9yaWdpbi4gWW91IG1heSBkZWZpbmUg
YSBkZWZhdWx0IHZhbHVlIHRoYXQgc3VpdCBjbGFzc2ljYWwgUDJQIHJvdXRlcyBpbiB0aGUgY2Fz
ZSB3aGVyZSBubyBjb25maWcgb2YgYW55IHNvcnQgaXMgcHJvdmlkZWQuIA0KDQpZb3Ugc2VlbSB0
byB3YW50IHRoZSBjb25maWcgb3B0aW9uIHRvIHNwZWNpZnkgdGhlIGxpZmV0aW1lIG9mIHRoZSB0
ZW1wb3JhcnkgREFHLiBUaGlzIHdvdWxkIGJlIGEgd2FzdGFnZSBvZiByaWNoIHNlbWFudGljIHBy
b3ZpZGVkIGJ5IHRob3NlIGZpZWxkcy4gSWYgeW91IGNvdWxkIGFncmVlIHRvIHNwZWNpZnlpbmcg
dGhlIHRlbXBvcmFyeSBEQUcgbGlmZXRpbWUgaW5zaWRlIFAyUC1SRE8gKHRoZSB3YXkgUDJQLVJQ
TCBjdXJyZW50bHkgZG9lcyksIEkgc2VlIG5vIHByb2JsZW0gd2hhdHNvZXZlci4gQWxsIG5vZGVz
IChpbmNsdWRpbmcgdGhlIG9yaWdpbiBhbmQgdGFyZ2V0KSBqb2luaW5nIHRoZSB0ZW1wb3Jhcnkg
REFHIG1haW50YWluIHN0YXRlIGZvciB0aGUgdGVtcG9yYXJ5IERBRyAod2hpY2ggaXMgbm90IHNh
bWUgYXMgdGhlIHN0YXRlIGZvciB0aGUgZGlzY292ZXJlZCBIYkggcm91dGUpIGZvciB0aGUgZHVy
YXRpb24gc3BlY2lmaWVkIGluIFAyUC1SRE8uIFdlIGNvdWxkIGZ1cnRoZXIgcmVxdWlyZSB0aGF0
IGFsbCBEUk8vRFJPLUFDSyBleGNoYW5nZSBNVVNUIGNvbXBsZXRlIHdpdGhpbiB0aGUgdGVtcG9y
YXJ5IERBRyBsaWZldGltZSAoc3BlY2lmaWVkIGluc2lkZSBQMlAtUkRPKS4gU28sIHRoZSB0ZW1w
b3JhcnkgREFHJ3MgbGlmZXRpbWUgaGFzIHRvIGJlIGNob3NlbiBjYXJlZnVsbHkuIEhhdmluZyBz
YWlkIHRoYXQsIEkgc3RpbGwgcHJlZmVyIGdpdmluZyBvcmlnaW4gYW5kIHRhcmdldCBleHRyYSB0
aW1lIChlcXVhbCB0byBvbmUgbW9yZSBsaWZldGltZSkgdG8gY29tcGxldGUgRFJPL0RSTy1BQ0sg
ZXhjaGFuZ2UuDQoNClRoYW5rcw0KTXVrdWwNCg0KPkFuZCB5ZXMsIGdyZWF0IHBvaW50LCB5b3Un
ZCBuZWVkIHRvIHNwZWNpZnkgdGhhdCB0aGUgbGlmZXRpbWUgaW4gdGhlIGNvbmZpZyBvcHRpb24g
bXVzdCBiZSBsYXJnZSBlbm91Z2ggdG8gYWNjb21tb2RhdGUgdGhlIHJldHJhbnNtaXNzaW9ucy4N
Cg0KPkRvIHdlIGNvbnZlcmdlPw0KDQo+UGFzY2FsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IE11a3VsIEdveWFsIFttYWlsdG86bXVrdWxAdXdtLmVkdV0gDQpTZW50OiBt
YXJkaSAxMCBhdnJpbCAyMDEyIDE0OjU1DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0K
Q2M6IGpwdkBjaXNjby5jb207IHJvbGwNClN1YmplY3Q6IFJlOiBbcm9sbF0gIzg1OiB3aGljaCBs
aWZldGltZSBpcyBmb3IgdGhlIGVuZCBwb2ludHMgKG9yaWdpbiBhbmQgdGFyZ2V0KSB2cy4gaW50
ZXJtZWRpYXRlIG5vZGVzLg0KDQpPUiB0aGUgc2ltcGxlciBvcHRpb24gd291bGQgYmUgdG8gcmVx
dWlyZSBEUk8vRFJPLUFDSyBleGNoYW5nZSB0byBjb21wbGV0ZSB3aXRoaW4gdGhlIERBRydzIGxp
ZmUgdGltZT8gSWYgd2Ugd2VyZSB0byBzcGVjaWZ5IGEgbmV3IHBhcmFtZXRlciBmb3IgdGhlIHRp
bWUgbGltaXQgb24gRFJPL0RSTy1BQ0sgZXhjaGFuZ2UsIGJvdGggdGFyZ2V0IGFuZCBvcmlnaW4g
d291bGQgbmVlZCB0byBhZ3JlZSBvbiB0aGUgdmFsdWUgb2YgdGhpcyBwYXJhbWV0ZXIuDQoNCk11
a3VsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJNdWt1bCBHb3lhbCIg
PG11a3VsQHV3bS5lZHU+DQpUbzogIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVy
dEBjaXNjby5jb20+DQpDYzoganB2QGNpc2NvLmNvbSwgInJvbGwiIDxyb2xsQGlldGYub3JnPg0K
U2VudDogVHVlc2RheSwgQXByaWwgMTAsIDIwMTIgNzo1MDoxNiBBTQ0KU3ViamVjdDogUmU6IFty
b2xsXSAjODU6IHdoaWNoIGxpZmV0aW1lIGlzIGZvciB0aGUgZW5kIHBvaW50cyAob3JpZ2luIGFu
ZCB0YXJnZXQpIHZzLiBpbnRlcm1lZGlhdGUgbm9kZXMuDQoNCkhpIFBhc2NhbA0KDQpIb3BlZnVs
bHkgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUgdGhpbmcuDQoNCj5ObywgaXQncyBub3Qg
Y2xvc2VkLiBXZSBhcmUgdGFsa2luZyBhYm91dCBhIGNvbnRyYWN0IGJldHdlZW4gbG93ZXIgbGF5
ZXJzIGluIGFsbCBub2RlcyBpbmNsdWRpbmcgdGhlIHNvdXJjZSBhbmQgb3JpZ2luIHRvIG1haW50
YWluIG5lY2Vzc2FyeSByZXNvdXJjZXMgYW5kIGFsbCBjb250cmFjdHMgbXVzdCBoYXZlIGEgbGlm
ZXRpbWUuDQoNCjEuIEEgbm9kZSB0aGF0IGpvaW5zIGEgdGVtcG9yYXJ5IFAyUC1SUEwgREFHIG1h
aW50YWlucyBzdGF0ZSBmb3IgdGhlIERBRyBmb3IgdGhlIHRpbWUgZHVyYXRpb24gc3BlY2lmaWVk
IGFzIERBRyBsaWZlIHRpbWUuDQoyLiBBIG5vZGUgdGhhdCBlc3RhYmxpc2hlcyBob3AtYnktaG9w
IHJvdXRpbmcgc3RhdGUgZm9yIGEgcm91dGUgZGlzY292ZXJlZCB1c2luZyBQMlAtUlBMIG1haW50
YWlucyB0aGlzIHN0YXRlIGZvciB0aGUgdGltZSBkdXJhdGlvbiBzcGVjaWZpZWQgaW4gRE9EQUcg
Y29uZmlndXJhdGlvbiBvcHRpb24uDQoNCk9yaWdpbiBhbmQgdGFyZ2V0IG5lZWQgdG8gZXhjaGFu
Z2UgRFJPcyBhbmQgRFJPLUFDS3MuIEkgY291bGQgc3BlY2lmeSBhIG5ldyBjb25maWd1cmFibGUg
cGFyYW1ldGVyIHRvIHNwZWNpZnkgdGhlIHRpbWUgbGltaXQgb24gdGhpcyBleGNoYW5nZS4gVGhp
cyBwYXJhbWV0ZXIncyB2YWx1ZSAgaGFzIHRvIGJlIG1vcmUgdGhhbiBEQUcgbGlmZSB0aW1lLiBP
bmUgb3B0aW9uIGlzIHRvIHNwZWNpZnkgaXQgaW4gdGVybXMgb2YgZXhpc3RpbmcgcGFyYW1ldGVy
czogREFHIGxpZmUgdGltZSArIChNQVhfRFJPX1JFVFJBTlNNSVNTSU9OUyArIDEpKkRST19BQ0tf
V0FJVF9USU1FLg0KDQpUaGFua3MNCk11a3VsDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t
DQpGcm9tOiAiUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0aHViZXJ0QGNpc2NvLmNvbT4N
ClRvOiAiTXVrdWwgR295YWwiIDxtdWt1bEB1d20uZWR1Pg0KQ2M6IGpwdkBjaXNjby5jb20NClNl
bnQ6IFR1ZXNkYXksIEFwcmlsIDEwLCAyMDEyIDQ6NDU6NDYgQU0NClN1YmplY3Q6IFJFOiBbcm9s
bF0gIzg1OiB3aGljaCBsaWZldGltZSBpcyBmb3IgdGhlIGVuZCBwb2ludHMgKG9yaWdpbiBhbmQg
dGFyZ2V0KSB2cy4gaW50ZXJtZWRpYXRlIG5vZGVzLg0KDQpIaSBNdWt1bCwNCg0KTm8sIGl0J3Mg
bm90IGNsb3NlZC4gV2UgYXJlIHRhbGtpbmcgYWJvdXQgYSBjb250cmFjdCBiZXR3ZWVuIGxvd2Vy
IGxheWVycyBpbiBhbGwgbm9kZXMgaW5jbHVkaW5nIHRoZSBzb3VyY2UgYW5kIG9yaWdpbiB0byBt
YWludGFpbiBuZWNlc3NhcnkgcmVzb3VyY2VzIGFuZCBhbGwgY29udHJhY3RzIG11c3QgaGF2ZSBh
IGxpZmV0aW1lLg0KSSBkbyBub3QgbWluZCB5b3Ugb3ZlcmxvYWQgdGhlIFJQTCBsaWZldGltZSBv
ZiB0aGUgcm91dGluZyBmb3IgdGhlIHN0YXRlcyBhdCBvcmlnaW4gYW5kIHRhcmdldCBhbmQgaWYg
eW91IGhhdmUgYSBzZW50ZW5jZSB0aGF0IG1ha2VzIGl0IGNsZWFyIHRoZW4gd2UnbGwgYmUgaW4g
YWdyZWVtZW50Lg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQpGcm9tOiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3VsQHV3bS5lZHVdIA0KU2VudDog
ZGltYW5jaGUgOCBhdnJpbCAyMDEyIDE3OjUyDQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0
KQ0KQ2M6IGpwdkBjaXNjby5jb20NClN1YmplY3Q6IFJlOiBbcm9sbF0gIzg1OiB3aGljaCBsaWZl
dGltZSBpcyBmb3IgdGhlIGVuZCBwb2ludHMgKG9yaWdpbiBhbmQgdGFyZ2V0KSB2cy4gaW50ZXJt
ZWRpYXRlIG5vZGVzLg0KDQpQYXNjYWwNCg0KQ2FuIHdlIGNvbnNpZGVyIHRoaXMgaXNzdWUgY2xv
c2VkPyBQbGVhc2Ugc2VlIG15IGxhc3QgcmVzcG9uc2UuDQoNClRoYW5rcw0KTXVrdWwNCg0KLS0t
LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogInJvbGwgaXNzdWUgdHJhY2tlciIgPHRy
YWMrcm9sbEB0cmFjLnRvb2xzLmlldGYub3JnPg0KVG86IG11a3VsQFVXTS5FRFUsIGpwdkBjaXNj
by5jb20NCkNjOiByb2xsQGlldGYub3JnDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDQsIDIwMTIg
ODowNjozMCBBTQ0KU3ViamVjdDogW3JvbGxdICM4NTogd2hpY2ggbGlmZXRpbWUgaXMgZm9yIHRo
ZSBlbmQgcG9pbnRzIChvcmlnaW4gYW5kIHRhcmdldCkgdnMuIGludGVybWVkaWF0ZSBub2Rlcy4N
Cg0KIzg1OiB3aGljaCBsaWZldGltZSBpcyBmb3IgdGhlIGVuZCBwb2ludHMgKG9yaWdpbiBhbmQg
dGFyZ2V0KSB2cy4gaW50ZXJtZWRpYXRlIG5vZGVzLg0KDQogUHJvYmxlbSAoY3VycmVudGx5IG9w
ZW4pDQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUDJQIGNyZWF0ZXMgdGVtcG9y
YXJ5IHN0YXRlcyBpbiB0aGUgdHJhbnNpZW50IERBRyBhbmQgbGVzcy1idXQtc3RpbGwgIHRlbXBv
cmFyeSBzdGF0ZXMgaW4gdGhlIGVuZHBvaW50cy4gVGhlc2UgYXJlIDIgZGlmZmVyZW50IGxpZmV0
aW1lcy4gVGhlICBzcGVjIGhhcyAyIGxpZmV0aW1lcywgb25lIGluIHRoZSBjb25maWcgb3B0aW9u
IGFuZCBvbmUgaW4gdGhlIFJETy4gVGhlICBzcGVjIGlzIG5vdCBzdWZmaWNpZW50bHkgY2xlYXIg
YWJvdXQgd2hpY2ggaXMgd2hpY2guIEluIGNhbiBhcHBlYXIgdG8gYmUgIGNvbmZsaWN0aW5nIHNp
bmNlIHRoZSBjb25maWcgb3B0aW9uIGlzIHN1cHBvc2VkIHRvIGFwcGx5IHRvIGFsbCByb3V0ZXJz
ICBvbiB0aGUgcGF0aC4gT24gdGhlIHNpZGUsIGFuZCBpbiBvcmRlciB0byBhbGxvdyB0aGUgcmV1
c2Ugb2YgaW5zdGFuY2UgIElELCB0aGUgb3JpZ2luIG11c3QgYmUgc3VyZSB0aGF0IGFsbCBzdGF0
ZXMgZm9yIGEgcHJldmlvdXMgdXNhZ2Ugb2YgdGhlICBzYW1lIHZhbHVlIGFyZSBnb25lLiBTbyB3
ZSBuZWVkIGEgY2xlYXIgY29udHJvbCAvIG5lZ290aWF0aW9uIG9mIHRoZSAgbGlmZXRpbWVzIG9u
IHRoZSBzdGF0ZXMgdGhhdCBjb21lIHdpdGggYW4gaW5zdGFuY2VJRC4gQWdhaW4gdGhpcyBpcyBu
b3QgIGNsZWFyIGVub3VnaCBpbiB0aGUgc3BlYy4NCg0KDQoNCiBbUGFzY2FsMl0NCiAyKSBTYW1l
IHF1ZXN0aW9uIGlmIHlvdSB3YW50IHRvIGNyZWF0ZSBzdGF0ZXMgYXQgdGhlIHRhcmdldCB0byBy
b3V0ZSAgYmFjay4gSG93IGxvbmcgZG9lcyB0aGUgdGFyZ2V0IG5lZWQgdG8gbWFpbnRhaW4gdGhl
IHJvdXRlPyBXaG8gY29udHJvbHMgIHRoYXQsIHRoZSBvcmlnaW4gb3IgdGhlIHRhcmdldD8gSSdk
IGV4cGVjdCB0byBmaW5kIGEgc3VnZ2VzdGVkIGxpZmV0aW1lICBpbiB0aGUgUkRPIHdpdGggYSBj
b25maXJtYXRpb24gaW4gdGhlIERSTyB0byBsZXQgdGhlIHRhcmdldCBhbWVuZCBpdC4NCg0KIFtN
dWt1bDJdDQogSWYgdGhlIHRhcmdldCB3YW50cyBEUk8tQUNLIGl0IG5lZWRzIHRvIG1haW50YWlu
IHN0YXRlIHVudGlsIERSTy1BQ0sgaXMgIHJlY2VpdmVkLiBPdGhlcndpc2UsIHRoZSB0YXJnZXQg
bmVlZHMgdG8gcmVtZW1iZXIgdGhpbmdzIHVudGlsIGl0IGlzICBkb25lIHNlbmRpbmcgYWxsIHRo
ZSBEUk9zLiBJIHdpbGwgYWRkIHRoZSB0ZXh0IHRvIHRoaXMgZWZmZWN0Lg0KDQogW1Bhc2NhbDNd
DQogSWYgeW91IGFyZSBzZXR0aW5nIHVwIGEgc2hvcnQgdGVybSBjb252ZXJzYXRpb24sIGhvdyBs
b25nIGV4YWN0bHkgaXMgIHRoYXQgYmVmb3JlIHRoZSBvcmlnaW4gaGFzIHRvIHJlZnJlc2ggdGhl
IHJvdXRlPyBXaGF0IGNvbnRyb2xzIGNsZWFuIHVwICBpbiBib3RoIHNpZGVzPyBVc3VhbGx5IHlv
dSB3YW50IGEgbGlmZXRpbWUgKHNlZSBNSVA2IGZvciBpbnN0YW5jZSkNCg0KIFtNdWt1bDNdDQog
SXMgaXQgdGhhdCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGxpZmV0aW1lIG9mIHRoZSBob3At
YnktaG9wIHJvdXRpbmcgIHN0YXRlPyBUaGF0IGlzIHNwZWNpZmllZCBpbiB0aGUgbGlmZSB0aW1l
IHBhcmFtZXRlcnMgaW4gdGhlIERPREFHICBjb25maWd1cmF0aW9uIG9wdGlvbi4gVGhlIGRyYWZ0
IHNheXMgdGhhdCBvbiBwYWdlIDkgd2hpbGUgZGVzY3JpYmluZyBob3cgIHRoZSBET0RBRyBjb25m
aWd1cmF0aW9uIG9wdGlvbiBzaG91bGQgYmUgc2V0IGluc2lkZSBhIFAyUCBtb2RlIERJTzoNCg0K
ICJUaGUgRGVmYXVsdCBMaWZldGltZSBhbmQgTGlmZXRpbWUgVW5pdCBwYXJhbWV0ZXJzIGluIERP
REFHDQogICAgICBDb25maWd1cmF0aW9uIG9wdGlvbiBpbmRpY2F0ZSB0aGUgbGlmZSB0aW1lIG9m
IHRoZSBzdGF0ZSB0aGUNCiAgICAgIHJvdXRlcnMgbWFpbnRhaW4gZm9yIGEgaG9wLWJ5LWhvcCBy
b3V0ZSBlc3RhYmxpc2hlZCB1c2luZyBQMlAtUlBMDQogICAgICBhbmQgbWF5IGJlIHNldCBhcyBk
ZXNpcmVkLg0KICINCg0KIFtQYXNjYWw0XSBNYXliZSB0aGF0J3Mgc28gYnV0IHRoZW4geW91IG5l
ZWQgdG8gcmV3b3JkIGEgbGl0dGxlIGJpdCBjYXVzZSAgeW91IGdvdCBtZSBxaXV0ZSBjb25mdXNl
ZC4gSSd2ZSBiZWVuIHRhbGtpbmcgb2YgdGhlIGxpZmV0aW1lIG9mIHRoZSAgc3RhdGVzIGF0IG9y
aWdpbiBhbmQgdGFyZ2V0IGZvciBvbmUgY29udmVyc2F0aW9uLiBTaW5jZSB0aGV5IG1pZ2h0IGJl
ICBoYXZpbmcgYSB0cmFuc2llbnQgY29udmVyc2F0aW9uLCBhbmQgdGhlIG9yaWdpbiBtaWdodCBy
ZXVzZSB0aGUgaW5zdGFuY2UgIElEIHNvb24sIHlvdSBuZWVkIHRvIGdpdmUgYSBsaW1pdCBpbiB0
aW1lIHRvIHRoZSBzdGF0ZXMgdGhhdCB5b3UgYXJlICBjcmVhdGluZy4gU3RpbGwgdGhhdCBjb252
ZXJzYXRpb24gaXMgbG9uZ2VyIHRoYW4gdGhlIHN0YXRlcyBpbiB0aGUgIGludGVybWVkaWF0ZSBy
b3V0ZXJzLiBTbyB5b3UgaGF2ZSAyIGxpZmV0aW1lcyBhbmQgeW91IGhhdmUgdG8gYmUgdmVyeSAg
Y2xlYXIgd2hpY2ggaXMgd2hpY2guIFBlcnNvbmFsbHksIEknZCBoYXZlIHVzZWQgdGhlIGxpZmV0
aW1lIGluIHRoZSAgY29uZmlndXJhdGlvbiBvcHRpb24gZm9yIGFsbCB0aGUgcm91dGVycyBvbiB0
aGUgd2F5IGFuZCBJJ2QgaGF2ZSB1c2VkICB0aGUgbmV3IGxpZmV0aW1lIGluIHRoZSBSRE8gYXMg
dGhlIGNvbnZlcnNhdGlvbiBsaWZldGltZSBpbiB0aGUgZW5kICBwb2ludHMgYmVjYXVzZToNCiAx
KSAgdGhhdCBpcyB0aGUgbmV3IGNvbmNlcHQuDQogMikgVGhpcyB3b3VsZCBhbGxvdyB0aGUgdGFy
Z2V0IHRvIGNvbmZpcm0gZXhhY3RseSBob3cgbG9uZyBpdCBsb2NrcyAgcmVzb3VyY2VzLA0KIDMp
IGFuZCB0aGlzIHdvdWxkIGJlIG1vcmUgY29tcGF0aWJsZSB3aXRoIHRoZSBkZXNjcmlwdGlvbiBv
ZiB0aGUgY29uZmlnICBvcHRpb24gaW4gUkZDIDY1NTAuDQoNCiBbTXVrdWw0XQ0KIFRoZXJlIGFy
ZSB0d28gbGlmZXRpbWVzOg0KIDEpIExpZmV0aW1lIG9mIHRoZSB0ZW1wb3JhcnkgREFHOiB0aGlz
IGlzIHNwZWNpZmllZCBpbnNpZGUgUDJQLVJETw0KIDIpIExpZmV0aW1lIG9mIHRoZSByb3V0aW5n
IHN0YXRlIGZvciB0aGUgaG9wLWJ5LWhvcCByb3V0ZSBlc3RhYmxpc2hlZCAgdXNpbmcgUDJQLVJQ
TDogdGhpcyBpcyBzcGVjaWZpZWQgaW5zaWRlIHRoZSBET0RBRyBjb25maWd1cmF0aW9uIG9wdGlv
bi4NCiBBbGwgcm91dGVycyBvbiB0aGUgZXN0YWJsaXNoZWQgcm91dGUgKGluY2x1ZGluZyB0aGUg
b3JpZ2luKSBtYWludGFpbiAgc3RhdGUgZm9yIHRoaXMgcm91dGUgZm9yIHRoaXMgbXVjaCB0aW1l
LiBUaGlzIHRpbWUgY291bGQgdmVyeSB3ZWxsIGJlICBpbmZpbml0eS4NCg0KIE5vdywgbGV0cyB0
YWxrIGFib3V0IHRoZSAic3RhdGVzIGF0IG9yaWdpbiBhbmQgdGFyZ2V0Ii4gVGhlIG9yaWdpbiBh
bmQgIHRoZSB0YXJnZXQgbWFpbnRhaW4gdGhlIHN0YXRlIGFib3V0IHRoZSB0ZW1wb3JhcnkgREFH
IGZvciB0aGUgREFHJ3MgbGlmZSAgdGltZS4gVGhpcyBpcyB0cnVlIGZvciBhbGwgdGhlIG5vZGVz
IHRoYXQgam9pbiB0aGlzIERBRy4gQWxsIHN1Y2ggbm9kZXMgIG1haW50YWluIHN0YXRlIGFib3V0
IHRoZSB0ZW1wb3JhcnkgREFHIHVudGlsIHRoZSBEQUcncyBsaWZlIHRpbWUgaXMgIG92ZXIuIEl0
IGlzIHRydWUgdGhhdCB0aGUgdGFyZ2V0IGFuZCB0aGUgb3JpZ2luIGV4Y2hhbmdlIERST3MgYW5k
ICBEUk8tQUNLcyBhbmQgdGhpcyBleGNoYW5nZSBjb3VsZCBjb25jZWl2YWJseSBnbyBvbiBldmVu
IGFmdGVyIHRoZSAgdGVtcG9yYXJ5IERBRydzIGRlbWlzZS4gSG93IGxvbmcgc2hvdWxkIHRoZSBv
cmlnaW4gYW5kIHRhcmdldCBpbmR1bGdlIGluICB0aGlzIGV4Y2hhbmdlIChhbmQgaGVuY2UgcmVt
ZW1iZXIgdGhlIHBvc3NpYmx5IGRlYWQgREFHKT8gSSB0aGluayBpdCBpcyAgcHVyZWx5IHRoZWly
IGNob2ljZSBhbmQgdGhlIGRyYWZ0IG5lZWQgbm90IGltcG9zZSBhbnkgYXJ0aWZpY2lhbCB0aW1l
ICBsaW1pdCBvbiB0aGlzLg0KDQogUGFzY2FsDQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICBqcHZA4oCm
ICAgICAgICAgICAgICAgICAgfCAgICAgIE93bmVyOiAgbXVrdWxA4oCmDQogICAgIFR5cGU6ICBk
ZWZlY3QgICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFq
b3IgICAgICAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBwMnAtcnBsICAg
ICAgICAgICAgICAgIHwgICAgVmVyc2lvbjoNCiBTZXZlcml0eTogIFN1Ym1pdHRlZCBXRyBEb2N1
bWVudCAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5p
ZXRmLm9yZy93Zy9yb2xsL3RyYWMvdGlja2V0Lzg1Pg0Kcm9sbCA8aHR0cDovL3Rvb2xzLmlldGYu
b3JnL3dnL3JvbGwvPg0KDQo=

From trac+roll@trac.tools.ietf.org  Fri Apr 13 02:00:56 2012
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 5926021F876E for ; Fri, 13 Apr 2012 02:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.894
X-Spam-Level: 
X-Spam-Status: No, score=-101.894 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, SARE_LWSHORTT=1.24, 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 6YC+0yKBEn3q for ; Fri, 13 Apr 2012 02:00:55 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1A78621F8606 for ; Fri, 13 Apr 2012 02:00:54 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIcN7-0004gy-Lf; Fri, 13 Apr 2012 05:00:49 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 09:00:49 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/85#comment:1
Message-ID: <070.21eac0e3afb24daa2fa90b84fcc630e5@trac.tools.ietf.org>
References: <055.04b63ad43f3bc000d32addde8cd227ef@trac.tools.ietf.org>
X-Trac-Ticket-ID: 85
In-Reply-To: <055.04b63ad43f3bc000d32addde8cd227ef@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 09:00:56 -0000

#85: which lifetime is for the end points (origin and target) vs. intermediate
nodes.

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Hi Mukul

 Perfect. As far as I'm concerned we can close this one...

  Mukul and I had a call where we fixed our disconnect.
 Mukul's proposal below addresses the issue that I had in mind - as opposed
 to the issue that he thought I had in mind and that BTW we agreed was not
 an issue...

 Cheers,

 Pascal


 -----Original Message-----
 From: Mukul Goyal [mailto:mukul@uwm.edu]
 Sent: vendredi 13 avril 2012 09:03
 To: Pascal Thubert (pthubert)
 Cc: jpv@cisco.com; roll
 Subject: Re: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 Hi Pascal

 Now we are on the same page. I propose that the following text in section
 6.1 of P2P-RPL spec:

 "The Default Lifetime and Lifetime Unit parameters in DODAG
      Configuration option indicate the life time of the state the
      routers maintain for a hop-by-hop route established using P2P-RPL
      and may be set as desired.

 "

 be replaced by the following text:

 "The origin sets the Default Lifetime and Lifetime Unit parameters in
 DODAG Configuration option to indicate the life time of the state the
 routers, including the origin and the target(s), maintain for a hop-by-hop
 or a source route discovered using P2P-RPL.
 "

 Thanks
 Mukul


 ----- Original Message -----
 From: "Pascal Thubert (pthubert)" 
 To: "Mukul Goyal" 
 Cc: jpv@cisco.com, "roll" 
 Sent: Wednesday, April 11, 2012 1:22:52 AM
 Subject: RE: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 Mukul:

 We have a disconnect because you insist in thinking that I refer to the
 lifetime of the temporary DAG as indicated in the RDO.
 But no. I reworded twice and used very specific words this last time.
 Please remove the temp Dag from the discussion and read again in the light
 that I'm really talking about the states HbH routing states as I very
 specifically indicate.
 If that does not work then we'll need a phone call to resync.

 Cheers,

 Pascal


 -----Original Message-----
 From: Mukul Goyal [mailto:mukul@uwm.edu]
 Sent: mercredi 11 avril 2012 01:59
 To: Pascal Thubert (pthubert)
 Cc: jpv@cisco.com; roll
 Subject: Re: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 Hi Pascal

 I do not wish to change the DAG lifetime.

 I'm pointing out that the conversation between the origin and target
 cannot work longer than the lifetime of the "hop-by-hop routing states"
 which it depends on. So why not use that?

 You mean state about the "temporary DAG" and not the hop-by-hop state for
 the "discovered route"? They are two different things.

 I suggest that we converge the time duration specified in DODAG
 configuration option to mean the maximum duration of states in all nodes
 that need to keep states, including origin and target, and in some case
 intermediate routers.

 We are using the time duration in DODAG configuration option to specify
 the lifetime of the "hop-by-hop state for the discovered route" (and not
 the lifetime of the "temporary DAG"). A discovered HbH route may need to
 be maintained for a wide range of time durations. Hence, we would like to
 specify the lifetime of a discovered route using the rich semantics
 provided by the time duration fields inside the DODAG configuration
 option. On the other hand, the lifetime of a temporary DAG does not need
 to vary a whole lot. So, we provide 4 options for this lifetime (1, 4, 16
 and 64 seconds) and specify this lifetime in a 2-bit field inside P2P-RDO.

 Do you agree with how the two lifetimes (lifetime of DAG and lifetime of
 the discovered route) are specified in P2P-RPL?

 IOW, if the HbH route is used, the lifetime in the config option is for
 all states in all nodes on the path(s) including origins and target(s). If
 HbH routing is not used, the lifetime in the config option is still valid
 for the source and the origin. You may define a default value that suit
 classical P2P routes in the case where no config of any sort is provided.

 You seem to want the config option to specify the lifetime of the
 temporary DAG. This would be a wastage of rich semantic provided by those
 fields. If you could agree to specifying the temporary DAG lifetime inside
 P2P-RDO (the way P2P-RPL currently does), I see no problem whatsoever. All
 nodes (including the origin and target) joining the temporary DAG maintain
 state for the temporary DAG (which is not same as the state for the
 discovered HbH route) for the duration specified in P2P-RDO. We could
 further require that all DRO/DRO-ACK exchange MUST complete within the
 temporary DAG lifetime (specified inside P2P-RDO). So, the temporary DAG's
 lifetime has to be chosen carefully. Having said that, I still prefer
 giving origin and target extra time (equal to one more lifetime) to
 complete DRO/DRO-ACK exchange.

 Thanks
 Mukul

 And yes, great point, you'd need to specify that the lifetime in the
 config option must be large enough to accommodate the retransmissions.

 Do we converge?

 Pascal


 -----Original Message-----
 From: Mukul Goyal [mailto:mukul@uwm.edu]
 Sent: mardi 10 avril 2012 14:55
 To: Pascal Thubert (pthubert)
 Cc: jpv@cisco.com; roll
 Subject: Re: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 OR the simpler option would be to require DRO/DRO-ACK exchange to complete
 within the DAG's life time? If we were to specify a new parameter for the
 time limit on DRO/DRO-ACK exchange, both target and origin would need to
 agree on the value of this parameter.

 Mukul

 ----- Original Message -----
 From: "Mukul Goyal" 
 To: "Pascal Thubert (pthubert)" 
 Cc: jpv@cisco.com, "roll" 
 Sent: Tuesday, April 10, 2012 7:50:16 AM
 Subject: Re: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 Hi Pascal

 Hopefully we are talking about the same thing.

 No, it's not closed. We are talking about a contract between lower layers
 in all nodes including the source and origin to maintain necessary
 resources and all contracts must have a lifetime.

 1. A node that joins a temporary P2P-RPL DAG maintains state for the DAG
 for the time duration specified as DAG life time.
 2. A node that establishes hop-by-hop routing state for a route discovered
 using P2P-RPL maintains this state for the time duration specified in
 DODAG configuration option.

 Origin and target need to exchange DROs and DRO-ACKs. I could specify a
 new configurable parameter to specify the time limit on this exchange.
 This parameter's value  has to be more than DAG life time. One option is
 to specify it in terms of existing parameters: DAG life time +
 (MAX_DRO_RETRANSMISSIONS + 1)*DRO_ACK_WAIT_TIME.

 Thanks
 Mukul
 ----- Original Message -----
 From: "Pascal Thubert (pthubert)" 
 To: "Mukul Goyal" 
 Cc: jpv@cisco.com
 Sent: Tuesday, April 10, 2012 4:45:46 AM
 Subject: RE: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 Hi Mukul,

 No, it's not closed. We are talking about a contract between lower layers
 in all nodes including the source and origin to maintain necessary
 resources and all contracts must have a lifetime.
 I do not mind you overload the RPL lifetime of the routing for the states
 at origin and target and if you have a sentence that makes it clear then
 we'll be in agreement.

 Cheers,

 Pascal


 -----Original Message-----
 From: Mukul Goyal [mailto:mukul@uwm.edu]
 Sent: dimanche 8 avril 2012 17:52
 To: Pascal Thubert (pthubert)
 Cc: jpv@cisco.com
 Subject: Re: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 Pascal

 Can we consider this issue closed? Please see my last response.

 Thanks
 Mukul

 ----- Original Message -----
 From: "roll issue tracker" 
 To: mukul@UWM.EDU, jpv@cisco.com
 Cc: roll@ietf.org
 Sent: Wednesday, April 4, 2012 8:06:30 AM
 Subject: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 #85: which lifetime is for the end points (origin and target) vs.
 intermediate nodes.

 Problem (currently open)
 ------------------------------
 P2P creates temporary states in the transient DAG and less-but-still
 temporary states in the endpoints. These are 2 different lifetimes. The
 spec has 2 lifetimes, one in the config option and one in the RDO. The
 spec is not sufficiently clear about which is which. In can appear to be
 conflicting since the config option is supposed to apply to all routers
 on the path. On the side, and in order to allow the reuse of instance  ID,
 the origin must be sure that all states for a previous usage of the  same
 value are gone. So we need a clear control / negotiation of the  lifetimes
 on the states that come with an instanceID. Again this is not  clear
 enough in the spec.



 [Pascal2]
 2) Same question if you want to create states at the target to route
 back. How long does the target need to maintain the route? Who controls
 that, the origin or the target? I'd expect to find a suggested lifetime
 in the RDO with a confirmation in the DRO to let the target amend it.

 [Mukul2]
 If the target wants DRO-ACK it needs to maintain state until DRO-ACK is
 received. Otherwise, the target needs to remember things until it is  done
 sending all the DROs. I will add the text to this effect.

 [Pascal3]
 If you are setting up a short term conversation, how long exactly is  that
 before the origin has to refresh the route? What controls clean up  in
 both sides? Usually you want a lifetime (see MIP6 for instance)

 [Mukul3]
 Is it that you are talking about the lifetime of the hop-by-hop routing
 state? That is specified in the life time parameters in the DODAG
 configuration option. The draft says that on page 9 while describing how
 the DODAG configuration option should be set inside a P2P mode DIO:

 "The Default Lifetime and Lifetime Unit parameters in DODAG
      Configuration option indicate the life time of the state the
      routers maintain for a hop-by-hop route established using P2P-RPL
      and may be set as desired.
 "

 [Pascal4] Maybe that's so but then you need to reword a little bit cause
 you got me qiute confused. I've been talking of the lifetime of the
 states at origin and target for one conversation. Since they might be
 having a transient conversation, and the origin might reuse the instance
 ID soon, you need to give a limit in time to the states that you are
 creating. Still that conversation is longer than the states in the
 intermediate routers. So you have 2 lifetimes and you have to be very
 clear which is which. Personally, I'd have used the lifetime in the
 configuration option for all the routers on the way and I'd have used  the
 new lifetime in the RDO as the conversation lifetime in the end points
 because:
 1)  that is the new concept.
 2) This would allow the target to confirm exactly how long it locks
 resources,
 3) and this would be more compatible with the description of the config
 option in RFC 6550.

 [Mukul4]
 There are two lifetimes:
 1) Lifetime of the temporary DAG: this is specified inside P2P-RDO
 2) Lifetime of the routing state for the hop-by-hop route established
 using P2P-RPL: this is specified inside the DODAG configuration option.
 All routers on the established route (including the origin) maintain
 state for this route for this much time. This time could very well be
 infinity.

 Now, lets talk about the "states at origin and target". The origin and
 the target maintain the state about the temporary DAG for the DAG's life
 time. This is true for all the nodes that join this DAG. All such nodes
 maintain state about the temporary DAG until the DAG's life time is  over.
 It is true that the target and the origin exchange DROs and  DRO-ACKs and
 this exchange could conceivably go on even after the  temporary DAG's
 demise. How long should the origin and target indulge in  this exchange
 (and hence remember the possibly dead DAG)? I think it is  purely their
 choice and the draft need not impose any artificial time  limit on this.

 Pascal

 --
 -----------------------------------+---------------------
 Reporter:  jpv@…                  |      Owner:  mukul@…
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
 Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
 -----------------------------------+---------------------

 Ticket URL: 
 roll 

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

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From trac+roll@trac.tools.ietf.org  Fri Apr 13 02:01:32 2012
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 5FF1521F877C for ; Fri, 13 Apr 2012 02:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.405
X-Spam-Level: 
X-Spam-Status: No, score=-101.405 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 1bVouHZL0EOs for ; Fri, 13 Apr 2012 02:01:31 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5983521F8778 for ; Fri, 13 Apr 2012 02:01:28 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIcNj-0004tt-C6; Fri, 13 Apr 2012 05:01:27 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 09:01:27 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/86#comment:4
Message-ID: <070.004bf738cb1975bfbcf68b6a31b9cc77@trac.tools.ietf.org>
References: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 86
In-Reply-To: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #86: G flag: do we need that text?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 09:01:32 -0000

#86: G flag: do we need that text?

Changes (by jpv@…):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 Hi Michael:

 I tend to agree that we are somewhat repurposing G... or extending it if
 that's a better word.
 The clear part of G's meaning is related to floating DAGs which is a
 concept that comes with global instances.
 Local instances were defined and reserved in RFC 6550 for use in P2P.
 RFC 6550 did not push as far as locking meaning for the G bit.
 It actually makes sense that the draft that really defines a use of
 local instances also defines what G does in that world.
 And here we thought is that instead of comparing DODAGs within a DAG
 associated to a global instance, G would now be used to compare DODAGs
 that are each a DAG associated to a local instance.
 The semantic shift is that now, G eventually compares the applicative
 value of different apps for a user as opposed to the routing value of
 various DODAGs for an application. We went up a level.
 That's actually not a bad idea since P2P is getting us deeper in the
 world of autonomic networks and thus into higher level abstractions.
 I do not see that there is any opposition in doing it. The wish here is
 that the text must indicate more clearly that we are doing this shift.
 I think that Mukul will provide the additional informative sentence that
 we'd like to see.
 In any case, I see no point in keeping that ticket open. Too much ML
 bandwidth was used on that discussion. Unless Richard speaks up again
 which I doubt, I think we really want the ticket and discussion closed.

 Cheers,

 Pascal


 -----Original Message-----
 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
 Michael Richardson
 Sent: jeudi 12 avril 2012 19:40
 To: roll@ietf.org
 Subject: Re: [Roll] Closure text for ticket #86


 "Richard" == Richard Kelsey  writes:
 "The origin sets the G flag to indicate the relative importance
 of the route discovery it is initiating. The G flag is set to one
 if this particular route discovery is more important from
 application's perspective than some other route discovery. In
 other words, the origin sets the G flag to one if this particular
 route discovery helps meet the application defined goal
 \cite{rpl}. Thus, the G flag setting helps an intermediate router
 choose which route discoveries to participate in if it cannot
 participate in all route discoveries. An intermediate router
 SHOULD participate in route discoveries with G flag set to one
 (in preference to ones with G flag set to zero)."

    Richard> If you want to repurpose the G flag in this way you need to
    Richard> be clear that the usage in RFC 6550 no longer applies.  I
    Richard> think that the best way to do this would be to say that
    Richard> clause 3 of 8.2.2.2 does not apply to P2P DAGs:

 I would like to understand why you feel that in the P2P case, setting
 G=1 is somehow repurposing the G flag.

    Richard> Not having floating DODAGs would mean that the original use
    Richard> of the G flag is no longer necessary.

 There is no use in floating DODAGs... *for the P2P case*.
 I think that floating DODAGs have many uses in the P2MP case, during
 DODAG construction and repair.

 --
 ]       He who is tired of Weird Al is tired of life!           |
 firewalls  [
 ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
 architect[
 ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
 driver[
   Kyoto Plus: watch the video
 
                        then sign the petition.


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

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From trac+roll@trac.tools.ietf.org  Fri Apr 13 02:02:32 2012
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 79A7621F853C for ; Fri, 13 Apr 2012 02:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.444
X-Spam-Level: 
X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 ZSFSY9cwZqEg for ; Fri, 13 Apr 2012 02:02:31 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2888B21F84D9 for ; Fri, 13 Apr 2012 02:02:31 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIcOk-00074r-Ec; Fri, 13 Apr 2012 05:02:30 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 09:02:30 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/90#comment:1
Message-ID: <070.6b430abfadd7e244ac454912f3fbb4a6@trac.tools.ietf.org>
References: <055.61fcc856b7b35899da82ce224df8d83b@trac.tools.ietf.org>
X-Trac-Ticket-ID: 90
In-Reply-To: <055.61fcc856b7b35899da82ce224df8d83b@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #90: use of transient instance ID
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 09:02:32 -0000

#90: use of transient instance ID

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Hello Mukul

 1.) I propose adding the following text at the end of Section 9.6
 (Processing a DRO at an Intermediate Router) in P2P-RPL spec:

 "The hop-by-hop routing state established on receiving a DRO MUST expire
 at the end of the lifetime specified by the Default Lifetime and Lifetime
 Unit parameters inside the DODAG Configuration Option used in P2P mode
 DIOs for this route discovery.
 A future version of this document may consider specifying a signalling
 mechanism that will allow the origin to extend (or shorten) the lifetime
 of a P2P-RPL hop-by-hop route following a suitable hint from an upper-
 layer protocol."

 [Pascal] Since we're shooting for experimental I'm fine with this. We'll
 have to effectively consider the mentioned addition when going standard
 track.

 2.) I propose replacing the following text in Section 9.5 (Additional
 Processing of a P2P mode DIO at the Target):

 "The target MAY store the route contained in the P2P-RDO in the received
 DIO for use as a source route to reach the origin."

 with the following text:

 "The target MAY store the route contained in the P2P-RDO in the received
 DIO for use as a source route to reach the origin. The lifetime of this
 source route is specified by the Default Lifetime and Lifetime Unit
 parameters inside the DODAG Configuration Option in the received DIO. This
 lifetime can be extended (or shortened) appropriately following a suitable
 hint from an upper-layer protocol."

 [Pascal] Works for me


 3.) I propose replacing the following text in Section 9.7 (Processing a
 DRO at the Origin):

 "If the P2P-RDO inside the DRO identifies the discovered route as a source
 route (H=0), the origin MUST store in its memory the
   discovered route contained in the Address vector."

 with the following text:

 "If the P2P-RDO inside the DRO identifies the discovered route as a source
 route (H=0), the origin MUST store in its memory the
   discovered route contained in the Address vector. The lifetime of this
 source route is specified by the Default Lifetime and Lifetime Unit
 parameters inside the DODAG Configuration Option used in P2P mode DIOs for
 this route discovery. This lifetime can be extended (or shortened)
 appropriately following a suitable hint from an upper-layer protocol."

 [Pascal] Works for me

 4.) One consequence of these changes is that the intermediate router or
 the origin MUST still belong to the temporary DAG in order to process a
 received DRO. This is because the intermediate router (or the origin)
 needs to know the lifetime (contained in the config option) to be
 associated with the HbH/source routing state it would establish on
 processing the DRO.


 [Pascal] Which is a constraint that you place on the admin that chooses
 the temporary DAG lifetime.  And there'll probably be a well-known default
 so that the config option is not required in which case storing that state
 is not required either. You may want a sentence to say that...

 Can we now consider the issue closed?

 [Pascal] yes, we can. (I always dreamed of saying this...)

 Thanks
 Mukul


 ----- Original Message -----
 From: "Pascal Thubert (pthubert)" 
 To: "Mukul Goyal" 
 Cc: roll@ietf.org
 Sent: Thursday, April 12, 2012 1:13:14 AM
 Subject: RE: [Roll] [roll] #90: use of transient instance ID

 Hi Mukul

 Don't worry! For the upper layers interaction I'm only asking for one
 sentence, not an API spec... Like:

 "The required lifetime for the routing states may be provided by the
 application via a hint from upper-layer protocols. Additional hints from
 upper-layer protocols can be used to tear down the remaining states at the
 origin and/or at the target as soon the application need of those states
 is terminated or the application detects that the states are not
 functional anymore. In a same fashion, an interaction with upper layers
 can be used to determine that the routing states are still valid and can
 be prolonged for an additional lifetime"

 That's all!

 For your questions please see inline. Also, as an example of existing art,
 RFC 4861 stays as abstract as I do above with text like:

      DELAY       The neighbor is no longer known to be reachable, and
                  traffic has recently been sent to the neighbor.
                  Rather than probe the neighbor immediately, however,
                  delay sending probes for a short while in order to
                  give upper-layer protocols a chance to provide
                  reachability confirmation.

 ...

 7.3.1. Reachability Confirmation


   A neighbor is considered reachable if the node has recently received
   a confirmation that packets sent recently to the neighbor were
   received by its IP layer.  Positive confirmation can be gathered in
   two ways: hints from upper-layer protocols that indicate a connection
   is making "forward progress", or receipt of a Neighbor Advertisement
   message that is a response to a Neighbor Solicitation message.


 Pascal

 -----Original Message-----

 [Pascal] Also, when there are no routing states in intermediate routers,
 an indication from upper layers can be used in the end points to consider
 that all states for an instanceID are now cleaned up.

 [Mukul] Not sure what you mean.

 [Pascal2] Let me reword:  if HbH routin gis not used, the only states with
 any persistence are on the origin and target(s). The upper layer protocol
 (ULP) in origin and target may know when they are done with their need for
 the routes. If they are done before (config option) lifetime is up, they
 can tear down the states. This requires a new cross layer interaction
 triggered by ULP, similar to IPv6 ND in DELAY state.

 [Mukul2]
 You think P2P-RPL needs to define this cross-layer interaction? This is
 simply the upper layer telling the network layer to chuck a source route.
 Isn't it? The upper/lower layers dont even need to remember that this
 route was discovered using P2P-RPL. Also, the origin (or the target) can
 use a source route as long as it wants. Why should the lifetime in config
 option dictate how long this route can be used?

 [Pascal3] In IPv6, by design, everything has a lifetime. Better fix this
 now than during IESG review. In the case of this draft, nodes commit
 resources which are by definition limited. Thus in the general case that
 the draft addresses they can't commit those resources forever. One end
 point might die, say out of battery. There must be something that in any
 case will ensure that all parties, end points and intermediate routers in
 HbH end up clean even if there is no (rst) signaling to achieve so.

 You can pick a large lifetime if you like for the light switch you have in
 mind; but there needs to be a lifetime, after which states must be
 revalidated. That can be rebuilding the DAG, this can be unicast like a
 ping, and this can by piggy backed with traffic. ND for instance uses
 upper layer hints to validate that the reachability without necessarily
 signaling everything. Since you are going for experimental, I'm asking for
 the bare minimum, a simple lifetime using existing means (the config
 option).

 If an application is responsible for setting up routing states, this
 application may also be clever enough to provide a hint on the lifetime,
 and to tear down the states that it caused when it does not need them
 anymore. If the application does not provide any hint whatsoever, the
 implementation at the origin will select a reasonable lifetime that will
 depend on the function of the object. I'm certainly not asking to define
 the interaction between upper layer and L3, this is internal and thus
 implementation.

 Cheers,

 Pascal

 ----- Original Message -----
 From: "Pascal Thubert (pthubert)" 
 To: "Mukul Goyal" , roll@ietf.org
 Sent: Tuesday, April 10, 2012 4:52:50 AM
 Subject: RE: [Roll] [roll] #90: use of transient instance ID

 Mukul:

 I meant a suggestion, not a capitalized word. I prefer the suggestion but
 I'm still OK with your proposal. If we get in agreement on the lifetime of
 the states (issue #85), then you can indicate that lifetime is one way to
 determine when all stale states can be considered gone. Also, when there
 are no routing states in intermediate routers, an indication from upper
 layers can be used in the end points to consider that all states for an
 instanceID are now cleaned up.

 Cheers,

 Pascal


 -----Original Message-----
 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
 Mukul Goyal
 Sent: dimanche 8 avril 2012 18:09
 To: roll@ietf.org
 Subject: Re: [Roll] [roll] #90: use of transient instance ID

 Hi Pascal

 Re-read your proposed resolution text. I am not sure that the draft should
 suggest rotating the instance ids. My proposed resolution is to simply
 suggest not using instance id that might be in use.

 " [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD
 NOT) against reusing instance ids for which the stale state might exist
 in the nodes."

 Thanks
 Mukul

 ----- Original Message -----
 From: "roll issue tracker" 
 To: mukul@UWM.EDU, jpv@cisco.com
 Cc: roll@ietf.org
 Sent: Wednesday, April 4, 2012 8:11:44 AM
 Subject: [roll] #90: use of transient instance ID

 #90: use of transient instance ID

 Problem (resolution agreed upon)
 ------------------------------
 P2P creates temporary states in the transient DAG with a transient
 instance ID. The protocol must ensure that if the instance ID is reused
 then the new operation it is not confused with states resulting from the
 previous use of the same instance ID. Suggestion is to propose a
 rotation.

 Discussion
 -------------

 [Pascal]
 "RPLInstanceID: RPLInstanceID MUST be a local value as described in
 Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the same
 RPLInstanceID in two or more concurrent route discoveries."

 I'd suggest that you enforce a round robin or an opaque circulation so
 that the new instanceID is the least recently used one out of the 64
 possible.

 [Mukul]
 I think we should leave it to the origin to decide which value it wants
 to use for RPLInstanceID. I know some implementations are planning to  use
 a fixed RPLInstanceID value for all route discoveries.

 [Pascal2] Changing the instance ID will help debug the network and avoid
 conflicts with stale states. What's really up to the device is the
 initial sequence. Leaving it up to the origin may help the origin defeat
 some attacks to some degree. OTOH, after all the instances have been
 played, LRU forces to replay the same sequence again so the shield  drops.
 My preferred approach would be a SHOULD that would say that the  next
 instance ID SHOULD NOT be one of the (16?) most recently used and  MUST
 NOT be one for which states might still exist in the network. IOW  either
 the states deletion was acknowledged, or all pending lifetimes  are
 exhausted.

 [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD
 NOT) against reusing instance ids for which the stale state might exist
 in the nodes. Using a "MUST NOT" may not be OK since a node may never be
 100% sure about non-existence of stale state with a particular instance
 id (thus, all possible instance id values will become suspect and hence
 unusable after a while).

 [Pascal3] Agreed. Note that a circulation is a bonus to defeat replays.
 And now we're back to the issue above. How does the device know that
 there is no state left? A lifetime definition would be very useful. That
 lifetime is different from the DAG's one in RDO. I think we have an open
 issue here.

 [Mukul3] As I mentioned above, the life time parameters inside the DODAG
 configuration option specify the life time of the hop-by-hop routing
 state for the routes discovered using P2P-RPL.

 [Pascal4] This boils down to the thread above. Only one issue really,
 which lifetime is which? So IMHO no need to log anything for this  thread.

 [Mukul4] OK.

 Pascal

 --
 -----------------------------------+---------------------
 Reporter:  jpv@…                  |      Owner:  mukul@…
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
 Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
 -----------------------------------+---------------------

 Ticket URL: 
 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

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From jpv@cisco.com  Fri Apr 13 02:03:55 2012
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 7234C21F8584 for ; Fri, 13 Apr 2012 02:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.507
X-Spam-Level: 
X-Spam-Status: No, score=-109.507 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_HI=-8, 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 DY6B+gtXAP0x for ; Fri, 13 Apr 2012 02:03:54 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 861FE21F8587 for ; Fri, 13 Apr 2012 02:03:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4829; q=dns/txt; s=iport; t=1334307834; x=1335517434; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=A+ctMKNELfcdm608noxEJCDt4poIF2fsb+K2CjSRm34=; b=EEH4BACLMDOZKUqovnIcDPcF1ry8yNI7yyDOqMujdHZeowzdHL07LNak LQwdIGYi3P3+ory47vGscNY1idzVUr6Ci83yllpY1eYL2uGR9NnPB8P3A i+bsJ8k9vYFU8D84PV29Z0XTJop9Usw4EGRlMMkJ80jUx4JYpxXd1ppX6 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtAFAJHrh0+rRDoG/2dsb2JhbABCgyi0XoEHggkBAQEEAQEBDwFbCwwECxEEAQEoBxwLHwkIBgESGQmHawELnkuRVIZEkHRjBIcKjmKBEYRhhi+CLIFpgmk
X-IronPort-AV: E=Sophos;i="4.75,415,1330905600"; d="scan'208";a="40396659"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 13 Apr 2012 09:03:54 +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 q3D93sPe015886; Fri, 13 Apr 2012 09:03:54 GMT
Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 13 Apr 2012 02:03:54 -0700
Received: from [10.60.114.227] ([10.60.114.227]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 13 Apr 2012 02:03:53 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: JP Vasseur 
In-Reply-To: <070.004bf738cb1975bfbcf68b6a31b9cc77@trac.tools.ietf.org>
Date: Fri, 13 Apr 2012 11:03:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org> <070.004bf738cb1975bfbcf68b6a31b9cc77@trac.tools.ietf.org>
To: roll WG , Richard Kelsey 
X-Mailer: Apple Mail (2.1257)
X-OriginalArrivalTime: 13 Apr 2012 09:03:53.0555 (UTC) FILETIME=[59A51230:01CD1954]
Subject: Re: [Roll] [roll] #86: G flag: do we need that text?
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, 13 Apr 2012 09:03:55 -0000

Ticket closed.
Richard can you jut explicitly mention that you are happy with the =
resolution ?
Thanks.

jP.

On Apr 13, 2012, at 11:01 AM, roll issue tracker wrote:

> #86: G flag: do we need that text?
>=20
> Changes (by jpv@=85):
>=20
> * status:  reopened =3D> closed
> * resolution:   =3D> fixed
>=20
>=20
> Comment:
>=20
> Hi Michael:
>=20
> I tend to agree that we are somewhat repurposing G... or extending it =
if
> that's a better word.
> The clear part of G's meaning is related to floating DAGs which is a
> concept that comes with global instances.
> Local instances were defined and reserved in RFC 6550 for use in P2P.
> RFC 6550 did not push as far as locking meaning for the G bit.
> It actually makes sense that the draft that really defines a use of
> local instances also defines what G does in that world.
> And here we thought is that instead of comparing DODAGs within a DAG
> associated to a global instance, G would now be used to compare DODAGs
> that are each a DAG associated to a local instance.
> The semantic shift is that now, G eventually compares the applicative
> value of different apps for a user as opposed to the routing value of
> various DODAGs for an application. We went up a level.
> That's actually not a bad idea since P2P is getting us deeper in the
> world of autonomic networks and thus into higher level abstractions.
> I do not see that there is any opposition in doing it. The wish here =
is
> that the text must indicate more clearly that we are doing this shift.
> I think that Mukul will provide the additional informative sentence =
that
> we'd like to see.
> In any case, I see no point in keeping that ticket open. Too much ML
> bandwidth was used on that discussion. Unless Richard speaks up again
> which I doubt, I think we really want the ticket and discussion =
closed.
>=20
> Cheers,
>=20
> Pascal
>=20
>=20
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =
Of
> Michael Richardson
> Sent: jeudi 12 avril 2012 19:40
> To: roll@ietf.org
> Subject: Re: [Roll] Closure text for ticket #86
>=20
>=20
> "Richard" =3D=3D Richard Kelsey  writes:
> "The origin sets the G flag to indicate the relative importance
> of the route discovery it is initiating. The G flag is set to one
> if this particular route discovery is more important from
> application's perspective than some other route discovery. In
> other words, the origin sets the G flag to one if this particular
> route discovery helps meet the application defined goal
> \cite{rpl}. Thus, the G flag setting helps an intermediate router
> choose which route discoveries to participate in if it cannot
> participate in all route discoveries. An intermediate router
> SHOULD participate in route discoveries with G flag set to one
> (in preference to ones with G flag set to zero)."
>=20
>    Richard> If you want to repurpose the G flag in this way you need =
to
>    Richard> be clear that the usage in RFC 6550 no longer applies.  I
>    Richard> think that the best way to do this would be to say that
>    Richard> clause 3 of 8.2.2.2 does not apply to P2P DAGs:
>=20
> I would like to understand why you feel that in the P2P case, setting
> G=3D1 is somehow repurposing the G flag.
>=20
>    Richard> Not having floating DODAGs would mean that the original =
use
>    Richard> of the G flag is no longer necessary.
>=20
> There is no use in floating DODAGs... *for the P2P case*.
> I think that floating DODAGs have many uses in the P2MP case, during
> DODAG construction and repair.
>=20
> --
> ]       He who is tired of Weird Al is tired of life!           |
> firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ =
|device
> driver[
>   Kyoto Plus: watch the video
> 
>                        then sign the petition.
>=20
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>=20
> --=20
> -----------------------------------+----------------------
> Reporter:  jpv@=85                  |       Owner:  mukul@=85
>     Type:  defect                 |      Status:  closed
> Priority:  major                  |   Milestone:
> Component:  p2p-rpl                |     Version:
> Severity:  Submitted WG Document  |  Resolution:  fixed
> Keywords:                         |
> -----------------------------------+----------------------
>=20
> Ticket URL: =

> roll 
>=20


From trac+roll@trac.tools.ietf.org  Fri Apr 13 02:06:01 2012
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 CC48A21F8596 for ; Fri, 13 Apr 2012 02:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.451
X-Spam-Level: 
X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 gvKE9Zk-Xk4S for ; Fri, 13 Apr 2012 02:06:01 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB0F21F8587 for ; Fri, 13 Apr 2012 02:06:01 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIcS8-0007pr-K7; Fri, 13 Apr 2012 05:06:00 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 09:06:00 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/96#comment:1
Message-ID: <070.283717890fa20da1c2a5749443ec9016@trac.tools.ietf.org>
References: <055.f7a4657c0332f6393eb09f355b0158eb@trac.tools.ietf.org>
X-Trac-Ticket-ID: 96
In-Reply-To: <055.f7a4657c0332f6393eb09f355b0158eb@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 09:06:02 -0000

#96: Can the draft recommend how much to wait before a target selects routes to
be sent back in DROs?

Changes (by jpv@…):

 * component:  applicability-ami => p2p-rpl


-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  new
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From trac+roll@trac.tools.ietf.org  Fri Apr 13 02:06:20 2012
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 D96CA21F8587 for ; Fri, 13 Apr 2012 02:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.457
X-Spam-Level: 
X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 MalinGbm8HWU for ; Fri, 13 Apr 2012 02:06:20 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6D87021F868A for ; Fri, 13 Apr 2012 02:06:20 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIcSR-0007qJ-OP; Fri, 13 Apr 2012 05:06:19 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 09:06:19 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/97#comment:1
Message-ID: <070.6df7610e700c670b26580f55dd7e392d@trac.tools.ietf.org>
References: <055.7d6225a737a857a571e335c8e6245a84@trac.tools.ietf.org>
X-Trac-Ticket-ID: 97
In-Reply-To: <055.7d6225a737a857a571e335c8e6245a84@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #97: A fixed value for DRO_ACK_WAIT_TIME not OK for all P2P-RPL deployments.
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 09:06:21 -0000

#97: A fixed value for DRO_ACK_WAIT_TIME not OK for all P2P-RPL deployments.

Changes (by jpv@…):

 * component:  applicability-ami => p2p-rpl


-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  new
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From pthubert@cisco.com  Fri Apr 13 02:13:52 2012
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 F3A9021F8608 for ; Fri, 13 Apr 2012 02:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.113
X-Spam-Level: 
X-Spam-Status: No, score=-10.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+DWITuk6LdS for ; Fri, 13 Apr 2012 02:13:51 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9B98A21F8606 for ; Fri, 13 Apr 2012 02:13:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3212; q=dns/txt; s=iport; t=1334308430; x=1335518030; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=3elICZWepC9tZPcDes2UCCD9MyhM39Ahx5+EWLRL4uQ=; b=Pb+rOPgHPVJthfxjV5F5rFe55+fmasLmZbm7DGwhyp3sBGFzjQlReQ87 AmuAB2VIjYOVwQ+e7u78cC4I96lgCPo15HG0Nf06TkN69NCPSEvmZmkzL rfQCBJCkEHZD0jguRiEfCNZ/PvWQgW0k4o6ThqTNdcSGIxpzMVBd9v6C0 E=;
X-IronPort-AV: E=Sophos;i="4.75,415,1330905600"; d="scan'208";a="135044573"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2012 09:13:49 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3D9DnUc018247; Fri, 13 Apr 2012 09:13:49 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);  Fri, 13 Apr 2012 11:13:49 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 13 Apr 2012 11:12:53 +0200
Message-ID: 
In-Reply-To: <131236703.1903578.1334198389674.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Closure text for ticket #88
Thread-Index: Ac0YVYrCS/LQ1RiHQ6iVrnOzTjyNhwA/+UXw
References: <984808904.1851138.1333900679203.JavaMail.root@mail17.pantherlink.uwm.edu> <131236703.1903578.1334198389674.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" , 
X-OriginalArrivalTime: 13 Apr 2012 09:13:49.0680 (UTC) FILETIME=[BCF68700:01CD1955]
Subject: Re: [Roll] Closure text for ticket #88
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, 13 Apr 2012 09:13:52 -0000

TXVrdWwsIA0KDQpJIGFncmVlIHdpdGggdGhpcyByZXNvbHV0aW9uLiBXZSBjYW4gY2xvc2UgdGhl
IHRpY2tldCBhbmQgSSdsbCByZXZpZXcgdGhlIHRleHQgb25jZSB5b3UgcHVibGlzaC4NCg0KUGFz
Y2FsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE11a3VsIEdveWFsIFtt
YWlsdG86bXVrdWxAdXdtLmVkdV0gDQpTZW50OiBqZXVkaSAxMiBhdnJpbCAyMDEyIDA0OjQwDQpU
bzogcm9sbEBpZXRmLm9yZw0KQ2M6IEpQIFZhc3NldXI7IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVy
dCkNClN1YmplY3Q6IENsb3N1cmUgdGV4dCBmb3IgdGlja2V0ICM4OA0KDQoNCiM4ODogRGF0YSBv
cHRpb24gYW5kIFVMUA0KDQogUHJvYmxlbQ0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KIEFuIG9wdGlvbiBleGlzdHMgZm9yIGNhcnJ5aW5nIHBheWxvYWQuIFRoZSB1c2Ugb2YgdGhl
IG9wdGlvbiAodHVubmVsLA0KIHRyYW5zcG9ydD8pIGlzIG5vdCBkZXNjcmliZWQgcHJvcGVybHku
DQoNCiBSZXNvbHV0aW9uDQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogQWRkIGEgbmV4dCBo
ZWFkZXIgYW5kIGEgc2VxdWVuY2UgdG8gdGhlIGRhdGEgb3B0aW9uIHNvIHVwcGVyIGxheWVycyBj
YW4gIGJlIGRldGVybWluZWQuDQoNCiBEaXNjdXNzaW9uDQogLS0tLS0tLS0tLS0tLQ0KDQogW1Bh
c2NhbF0NCiBDYW4gdGhlIGRhdGEgb3B0aW9uIGJlIGRpZmZlcmVudCBmcm9tIG9uZSBESU8gdG8g
dGhlIG5leHQ/DQoNCiBbTXVrdWxdDQogVGhlIGNvbnRlbnRzIG9mIHRoZSBkYXRhIG9wdGlvbiBh
cmUgc3BlY2lmaWVkIGJ5IHRoZSBvcmlnaW4gKGZvciB0aGUNCiBESU8pIG9yIHRoZSB0YXJnZXQg
KGZvciB0aGUgRFJPKS4gSW4gdGhlb3J5LCBhbiBvcmlnaW4gY2FuIHNlbmQgIGRpZmZlcmVudCBk
YXRhIG9wdGlvbnMgaW4gZGlmZmVyZW50IERJT3MgaXQgZ2VuZXJhdGVzIGZvciBhIHBhcnRpY3Vs
YXIgIHJvdXRlIGRpc2NvdmVyeSAoYXNzdW1pbmcgdGhhdCBpdCBkb2VzIGdlbmVyYXRlIG11bHRp
cGxlIERJT3M7IGl0IGlzICB2ZXJ5IG11Y2ggcG9zc2libGUgdGhhdCB0aGUgb3JpZ2luIGdlbmVy
YXRlcyBqdXN0IG9uZSBESU8gYW5kIHRoZW4gc2l0cyAgc2lsZW50KS4gQnV0LCB0aGVuIHRoZSBv
cmlnaW4gaXMgdGFraW5nIHRoZSByaXNrIHRoYXQgc29tZSBvZiB0aGUgZGF0YSAgb3B0aW9ucyB3
b3VsZCBuZXZlciBlYWNoIHRoZSB0YXJnZXQocykuIEkgZ3Vlc3MgdGhlIG9yaWdpbiBtaWdodCBk
byB0aGlzICBpZiB0aGUgZGF0YSBzZW50IGVhcmxpZXIgaXMgbm93IHN0YWxlIGFuZCB0aGUgb3Jp
Z2luIHdvdWxkIGxpa2UgdGhlDQogdGFyZ2V0KHMpIHRvIHJlY2VpdmUgbmV3ZXIgZGF0YS4NCg0K
DQogW1Bhc2NhbDJdIFRoaXMgc2hvdWxkIGJlIGRpc2N1c3NlZCBpbiB0aGUgZHJhZnQuIFlvdSBu
ZWVkIHRvIHNldCB0aGUgIGV4cGVjdGF0aW9uIGZvciB0aGUgdXBwZXIgbGF5ZXIocykuIElzIHRo
ZXJlIGEgd2F5IHRvIGRpZmZlcmVudGlhdGUgIGRpZmZlcmVudCBkYXRhIHNldHM/IEVnIGluc3Rh
bmNlIG9yIHNlcXVlbmNlIG5iPw0KIE15IHN1Z2dlc3Rpb24gc28gZmFyIGlzIHRoYXQgdGhlIGRh
dGEgc2hvdWxkIGhhdmUgMyBiaXRzIG9mIG5leHQgaGVhZGVyICBhbmQgNSBiaXRzIG9mIHNlcXVl
bmNlLg0KDQogW011a3VsMl0gVGhpcyBzb3VuZHMgZ29vZCB0byBtZS4gSSB3aWxsIGluY29ycG9y
YXRlIHRoaXMgaW4gdGhlIGRyYWZ0ICB1bmxlc3MgSSBoZWFyIGEgYmV0dGVyIHByb3Bvc2FsLg0K
DQogW1Bhc2NhbDNdIENvb2wuIFBsZWFzZSBtYWtlIHRoYXQgYW5vdGhlciBMQyBpc3N1ZSBhbmQg
dGhlIHByb3Bvc2VkICByZXNvbHV0aW9uLCBzZWUgaWYgdGhlcmUgaXMgYW55b25lIGFkZGluZyBh
bnl0aGluZyB0byBpdC4NCg0KIFtNdWt1bDNdIEFjdHVhbGx5LCBJIHdvdWxkIGxpa2UgdGhlIG5l
eHQgaGVhZGVyIHRvIGJlIDQgYml0cyBhbmQgdGhlICBzZXF1ZW5jZSBudW1iZXIgdG8gYmUgNCBi
aXRzLiA0LWJpdCBzZXF1ZW5jZSBudW1iZXIgd2lsbCBzdGlsbCBhbGxvdyB1cCAgdG8gMTYgZGlm
ZmVyZW50IG1lc3NhZ2VzIHRvIGJlIHNlbnQgZHVyaW5nIGEgUDJQLVJQTCBkaXNjb3ZlcnkuIDQg
Yml0ICBuZXh0IGhlYWRlciB3aWxsIGFsbG93IDE2IGRpZmZlcmVudCBwb3NzaWJpbGl0aWVzLiBX
ZSBjYW4gaGF2ZSBzbyBtYW55ICBkaWZmZXJlbnQgd2F5cyB0byBjb21wcmVzcyBVRFAvVENQIGhl
YWRlcnMuIEkgdGhpbmsgMyBiaXQgbmV4dCBoZWFkZXIgIG1heSBub3QgYmUgc3VmZmljaWVudC4N
Cg0KIFtQYXNjYWw0XSBDb29sLiBMZXQncyB1c2UgdGhhdCBhcyB0aGUgcHJvcG9zZWQgcmVzb2x1
dGlvbg0KDQo=

From trac+roll@trac.tools.ietf.org  Fri Apr 13 02:47:07 2012
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 12CA921F84D1 for ; Fri, 13 Apr 2012 02:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.468
X-Spam-Level: 
X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 nIFMTqWXBNyO for ; Fri, 13 Apr 2012 02:47:06 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7CD21F84CD for ; Fri, 13 Apr 2012 02:47:06 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIcSo-0007uJ-Py; Fri, 13 Apr 2012 05:06:42 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 09:06:42 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/98#comment:1
Message-ID: <070.3b1f253142a88dab5191c0c5985dc08c@trac.tools.ietf.org>
References: <055.31669a0f4b146ab9900adac19f97cc84@trac.tools.ietf.org>
X-Trac-Ticket-ID: 98
In-Reply-To: <055.31669a0f4b146ab9900adac19f97cc84@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #98: Who decides what metrics go in the metric container inside the Measurement Request?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 09:47:07 -0000

#98: Who decides what metrics go in the metric container inside the Measurement
Request?

Changes (by jpv@…):

 * component:  applicability-ami => p2p-rpl


-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  new
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From trac+roll@trac.tools.ietf.org  Fri Apr 13 02:47:07 2012
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 07D2521F84CF for ; Fri, 13 Apr 2012 02:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.463
X-Spam-Level: 
X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 wO9uPA9aIoPz for ; Fri, 13 Apr 2012 02:47:06 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5891621F84C8 for ; Fri, 13 Apr 2012 02:47:05 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIchG-0003kI-JZ; Fri, 13 Apr 2012 05:21:38 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 09:21:37 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/88#comment:1
Message-ID: <070.3a780a7501735afacd820d142eb72143@trac.tools.ietf.org>
References: <055.6ee5f9af0660881f34d198ae081e0ce4@trac.tools.ietf.org>
X-Trac-Ticket-ID: 88
In-Reply-To: <055.6ee5f9af0660881f34d198ae081e0ce4@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #88: Data option and ULP
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 09:47:07 -0000

#88: Data option and ULP

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Mukul,

 I agree with this resolution. We can close the ticket and I'll review the
 text once you publish.

 Pascal


 -----Original Message-----
 From: Mukul Goyal [mailto:mukul@uwm.edu]
 Sent: jeudi 12 avril 2012 04:40
 To: roll@ietf.org
 Cc: JP Vasseur; Pascal Thubert (pthubert)
 Subject: Closure text for ticket #88


 #88: Data option and ULP

 Problem
 ------------------------------
 An option exists for carrying payload. The use of the option (tunnel,
 transport?) is not described properly.

 Resolution
 ------------------------
 Add a next header and a sequence to the data option so upper layers can
 be determined.

 Discussion
 -------------

 [Pascal]
 Can the data option be different from one DIO to the next?

 [Mukul]
 The contents of the data option are specified by the origin (for the
 DIO) or the target (for the DRO). In theory, an origin can send  different
 data options in different DIOs it generates for a particular  route
 discovery (assuming that it does generate multiple DIOs; it is  very much
 possible that the origin generates just one DIO and then sits  silent).
 But, then the origin is taking the risk that some of the data  options
 would never each the target(s). I guess the origin might do this  if the
 data sent earlier is now stale and the origin would like the
 target(s) to receive newer data.


 [Pascal2] This should be discussed in the draft. You need to set the
 expectation for the upper layer(s). Is there a way to differentiate
 different data sets? Eg instance or sequence nb?
 My suggestion so far is that the data should have 3 bits of next header
 and 5 bits of sequence.

 [Mukul2] This sounds good to me. I will incorporate this in the draft
 unless I hear a better proposal.

 [Pascal3] Cool. Please make that another LC issue and the proposed
 resolution, see if there is anyone adding anything to it.

 [Mukul3] Actually, I would like the next header to be 4 bits and the
 sequence number to be 4 bits. 4-bit sequence number will still allow up
 to 16 different messages to be sent during a P2P-RPL discovery. 4 bit
 next header will allow 16 different possibilities. We can have so many
 different ways to compress UDP/TCP headers. I think 3 bit next header  may
 not be sufficient.

 [Pascal4] Cool. Let's use that as the proposed resolution

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

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From prvs=44399eb11=mukul@uwm.edu  Fri Apr 13 06:06:36 2012
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 B9DA321F8603 for ; Fri, 13 Apr 2012 06:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.303
X-Spam-Level: 
X-Spam-Status: No, score=-6.303 tagged_above=-999 required=5 tests=[AWL=0.296,  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 9drHYns5tGCK for ; Fri, 13 Apr 2012 06:06:36 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id DDAF921F85F0 for ; Fri, 13 Apr 2012 06:06:35 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0EAI0kiE9/AAAB/2dsb2JhbABFhWa0WQEBBSNWDA8RBAEBAwINGQJRCBkbh3MLpmSJdIkJgS+KA4UNgRgEiFqNEoERjyWDBYE2
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 33FE7E6A8D; Fri, 13 Apr 2012 08:06:17 -0500 (CDT)
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 4KTfYrNrakvB; Fri, 13 Apr 2012 08:06:16 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id B97EBE6A72; Fri, 13 Apr 2012 08:06:16 -0500 (CDT)
Date: Fri, 13 Apr 2012 08:06:16 -0500 (CDT)
From: Mukul Goyal 
To: roll@ietf.org
Message-ID: <180364329.15615.1334322376698.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <055.221455d39fc20c241b942c0dcb13bc22@trac.tools.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [129.89.7.91]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Subject: Re: [Roll] [roll] #89: Spec is limited to single interface intermediate routers
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, 13 Apr 2012 13:06:36 -0000

Hi Pascal,

I propose the following text to be placed inside the Applicability section:

"The participation in a P2P-RPL route discovery is currently limited to the=
 routers with IPv6 addresses that are reachable in both incoming and outgoi=
ng directions, which it quite typical in usual LLN routers with a single ra=
dio"

Can we close this ticket?

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" 
To: mukul@UWM.EDU, jpv@cisco.com
Cc: roll@ietf.org
Sent: Wednesday, April 4, 2012 8:11:10 AM
Subject: [roll] #89: Spec is limited to single interface intermediate route=
rs

#89: Spec is limited to single interface intermediate routers

 Problem (currently open)
 ------------------------------
 The spec does not allow for routers with multiple interfaces. It expects
 that an address is usable downwards and upwards.

 Discussion
 -------------

 [Pascal]
 "When an
 intermediate router adds itself to a route, it MUST ensure that the
 IPv6 address added to the route is reachable in both forward and
 backward directions."
 This is written with the vision that the router has a single interface
 and acts as a repeater.
 But really a router could have 2 interfaces on a same subnet in which
 case that clause does not fly.

 [Mukul]
 All I mean is that the accumulated route MUST NOT have an address that
 cannot be accessed in one of the directions. If the address cannot be
 accessed in the backward direction, then the DRO would not be able to
 travel to the origin.

 [Pascal2] Then you're preventing a router with 2 interfaces. That's sad.
 I'm fine for an experimental draft   but for standard track that will
 have to be changed.

 [Mukul2] OK, I am keeping it the way it is.

 [Pascal3] This also need to be logged as a last call issue and its
 proposed resolution. Nothing wrong with having limitations, yet I think
 we must have specific text to indicate that the spec so far is limited
 to devices with a single interface. When we make the Standard Track
 version, I expect we'll have to go beyond that limitation. The drawback
 is for experimental  implementations that may not be interoperable with
 the final solution.

 [Mukul3] Could you please explain how does the requirement regarding
 addresses to be accessible in both forward and backward directions
 limits P2P-RPL to only single interface devices? I think this
 requirement means that P2P-RPL cannot be used across link layers. Is
 that what you mean? I think allowing operation across link layers would
 require P2P-RDO to accumulate additional information (backward address
 to be used for forward addresses not accessible in backward direction).
 I think at the moment we want to avoid this complexity.

 [Pascal4] Because an IP address is associated to an interface. If you
 have 2 interfaces, even in a same subnet, there should be 2 addresses.

 [Mukul4] But, why would the two IP addresses the device has on the same
 subnet wont be accessible in both forward and backward directions?


 Pascal

--=20
-----------------------------------+---------------------
 Reporter:  jpv@=E2=80=A6                  |      Owner:  mukul@=E2=80=A6
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: 
roll 


From pthubert@cisco.com  Fri Apr 13 06:25:09 2012
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 9AFD921F8622 for ; Fri, 13 Apr 2012 06:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.131
X-Spam-Level: 
X-Spam-Status: No, score=-10.131 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfp-N7Eq4pFH for ; Fri, 13 Apr 2012 06:25:09 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C42ED21F858A for ; Fri, 13 Apr 2012 06:25:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=5530; q=dns/txt; s=iport; t=1334323508; x=1335533108; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4fP15wMUknp25ocYJ8h+DkXNsDgJATvF1rN8rAxS92w=; b=iYYIgpv0UW36K9KGMO+6xRg1O/45/84L0PnuZDwi5SHchIW7gpwsz0MK ob5+Jt0BTenh2MQqp0mbws7ss5HrFXuxog9vupdo3oAOx3u/lQFlVXNHp 9aSKCDxJDDeKlCifLAsaBf7xcjQlkyR2tqaM8l8PxfXemDsbDQoCNDI0L Q=;
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="74453612"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 13 Apr 2012 13:25:08 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rcdn-core2-1.cisco.com (8.14.5/8.14.3) with ESMTP id q3DDP4b6001832;  Fri, 13 Apr 2012 13:25:07 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);  Fri, 13 Apr 2012 15:25:07 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 13 Apr 2012 15:24:45 +0200
Message-ID: 
In-Reply-To: <180364329.15615.1334322376698.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [roll] #89: Spec is limited to single interface intermediate routers
Thread-Index: Ac0ZdkKOW5Su/TEuRIWYscaexKjQcQAAiOqw
References: <055.221455d39fc20c241b942c0dcb13bc22@trac.tools.ietf.org> <180364329.15615.1334322376698.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" , 
X-OriginalArrivalTime: 13 Apr 2012 13:25:07.0045 (UTC) FILETIME=[D7C5D950:01CD1978]
Subject: Re: [Roll] [roll] #89: Spec is limited to single interface intermediate routers
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, 13 Apr 2012 13:25:09 -0000

SGVsbG8gTXVrdWwNCg0KSSdkIHByZWZlciB0byB1c2UgdXB3YXJkIGFuZCBkb3dud2FyZCB3aGlj
aCBhcmUgdGhlIHRlcm1zIHRoYXQgUlBMIHRyYWRpdGlvbmFsbHkgdXNlcy4uLi4gDQoNCklzIHRo
YXQgT0sgd2l0aCB5b3U/IE90aGVyd2lzZSB5ZXMsIHRoaXMgdGV4dCBhZGRyZXNzZXMgbXkgaXNz
dWUuDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
CkZyb206IE11a3VsIEdveWFsIFttYWlsdG86bXVrdWxAdXdtLmVkdV0gDQpTZW50OiB2ZW5kcmVk
aSAxMyBhdnJpbCAyMDEyIDE1OjA2DQpUbzogcm9sbEBpZXRmLm9yZw0KQ2M6IGpwdkBjaXNjby5j
b207IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNClN1YmplY3Q6IFJlOiBbcm9sbF0gIzg5OiBT
cGVjIGlzIGxpbWl0ZWQgdG8gc2luZ2xlIGludGVyZmFjZSBpbnRlcm1lZGlhdGUgcm91dGVycw0K
DQpIaSBQYXNjYWwsDQoNCkkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRleHQgdG8gYmUgcGxhY2Vk
IGluc2lkZSB0aGUgQXBwbGljYWJpbGl0eSBzZWN0aW9uOg0KDQoiVGhlIHBhcnRpY2lwYXRpb24g
aW4gYSBQMlAtUlBMIHJvdXRlIGRpc2NvdmVyeSBpcyBjdXJyZW50bHkgbGltaXRlZCB0byB0aGUg
cm91dGVycyB3aXRoIElQdjYgYWRkcmVzc2VzIHRoYXQgYXJlIHJlYWNoYWJsZSBpbiBib3RoIGlu
Y29taW5nIGFuZCBvdXRnb2luZyBkaXJlY3Rpb25zLCB3aGljaCBpdCBxdWl0ZSB0eXBpY2FsIGlu
IHVzdWFsIExMTiByb3V0ZXJzIHdpdGggYSBzaW5nbGUgcmFkaW8iDQoNCkNhbiB3ZSBjbG9zZSB0
aGlzIHRpY2tldD8NCg0KVGhhbmtzDQpNdWt1bA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t
LS0tDQpGcm9tOiAicm9sbCBpc3N1ZSB0cmFja2VyIiA8dHJhYytyb2xsQHRyYWMudG9vbHMuaWV0
Zi5vcmc+DQpUbzogbXVrdWxAVVdNLkVEVSwganB2QGNpc2NvLmNvbQ0KQ2M6IHJvbGxAaWV0Zi5v
cmcNClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxMiA4OjExOjEwIEFNDQpTdWJqZWN0OiBb
cm9sbF0gIzg5OiBTcGVjIGlzIGxpbWl0ZWQgdG8gc2luZ2xlIGludGVyZmFjZSBpbnRlcm1lZGlh
dGUgcm91dGVycw0KDQojODk6IFNwZWMgaXMgbGltaXRlZCB0byBzaW5nbGUgaW50ZXJmYWNlIGlu
dGVybWVkaWF0ZSByb3V0ZXJzDQoNCiBQcm9ibGVtIChjdXJyZW50bHkgb3BlbikNCiAtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBUaGUgc3BlYyBkb2VzIG5vdCBhbGxvdyBmb3Igcm91
dGVycyB3aXRoIG11bHRpcGxlIGludGVyZmFjZXMuIEl0IGV4cGVjdHMgIHRoYXQgYW4gYWRkcmVz
cyBpcyB1c2FibGUgZG93bndhcmRzIGFuZCB1cHdhcmRzLg0KDQogRGlzY3Vzc2lvbg0KIC0tLS0t
LS0tLS0tLS0NCg0KIFtQYXNjYWxdDQogIldoZW4gYW4NCiBpbnRlcm1lZGlhdGUgcm91dGVyIGFk
ZHMgaXRzZWxmIHRvIGEgcm91dGUsIGl0IE1VU1QgZW5zdXJlIHRoYXQgdGhlDQogSVB2NiBhZGRy
ZXNzIGFkZGVkIHRvIHRoZSByb3V0ZSBpcyByZWFjaGFibGUgaW4gYm90aCBmb3J3YXJkIGFuZCAg
YmFja3dhcmQgZGlyZWN0aW9ucy4iDQogVGhpcyBpcyB3cml0dGVuIHdpdGggdGhlIHZpc2lvbiB0
aGF0IHRoZSByb3V0ZXIgaGFzIGEgc2luZ2xlIGludGVyZmFjZSAgYW5kIGFjdHMgYXMgYSByZXBl
YXRlci4NCiBCdXQgcmVhbGx5IGEgcm91dGVyIGNvdWxkIGhhdmUgMiBpbnRlcmZhY2VzIG9uIGEg
c2FtZSBzdWJuZXQgaW4gd2hpY2ggIGNhc2UgdGhhdCBjbGF1c2UgZG9lcyBub3QgZmx5Lg0KDQog
W011a3VsXQ0KIEFsbCBJIG1lYW4gaXMgdGhhdCB0aGUgYWNjdW11bGF0ZWQgcm91dGUgTVVTVCBO
T1QgaGF2ZSBhbiBhZGRyZXNzIHRoYXQgIGNhbm5vdCBiZSBhY2Nlc3NlZCBpbiBvbmUgb2YgdGhl
IGRpcmVjdGlvbnMuIElmIHRoZSBhZGRyZXNzIGNhbm5vdCBiZSAgYWNjZXNzZWQgaW4gdGhlIGJh
Y2t3YXJkIGRpcmVjdGlvbiwgdGhlbiB0aGUgRFJPIHdvdWxkIG5vdCBiZSBhYmxlIHRvICB0cmF2
ZWwgdG8gdGhlIG9yaWdpbi4NCg0KIFtQYXNjYWwyXSBUaGVuIHlvdSdyZSBwcmV2ZW50aW5nIGEg
cm91dGVyIHdpdGggMiBpbnRlcmZhY2VzLiBUaGF0J3Mgc2FkLg0KIEknbSBmaW5lIGZvciBhbiBl
eHBlcmltZW50YWwgZHJhZnQgICBidXQgZm9yIHN0YW5kYXJkIHRyYWNrIHRoYXQgd2lsbA0KIGhh
dmUgdG8gYmUgY2hhbmdlZC4NCg0KIFtNdWt1bDJdIE9LLCBJIGFtIGtlZXBpbmcgaXQgdGhlIHdh
eSBpdCBpcy4NCg0KIFtQYXNjYWwzXSBUaGlzIGFsc28gbmVlZCB0byBiZSBsb2dnZWQgYXMgYSBs
YXN0IGNhbGwgaXNzdWUgYW5kIGl0cyAgcHJvcG9zZWQgcmVzb2x1dGlvbi4gTm90aGluZyB3cm9u
ZyB3aXRoIGhhdmluZyBsaW1pdGF0aW9ucywgeWV0IEkgdGhpbmsgIHdlIG11c3QgaGF2ZSBzcGVj
aWZpYyB0ZXh0IHRvIGluZGljYXRlIHRoYXQgdGhlIHNwZWMgc28gZmFyIGlzIGxpbWl0ZWQgIHRv
IGRldmljZXMgd2l0aCBhIHNpbmdsZSBpbnRlcmZhY2UuIFdoZW4gd2UgbWFrZSB0aGUgU3RhbmRh
cmQgVHJhY2sgIHZlcnNpb24sIEkgZXhwZWN0IHdlJ2xsIGhhdmUgdG8gZ28gYmV5b25kIHRoYXQg
bGltaXRhdGlvbi4gVGhlIGRyYXdiYWNrICBpcyBmb3IgZXhwZXJpbWVudGFsICBpbXBsZW1lbnRh
dGlvbnMgdGhhdCBtYXkgbm90IGJlIGludGVyb3BlcmFibGUgd2l0aCAgdGhlIGZpbmFsIHNvbHV0
aW9uLg0KDQogW011a3VsM10gQ291bGQgeW91IHBsZWFzZSBleHBsYWluIGhvdyBkb2VzIHRoZSBy
ZXF1aXJlbWVudCByZWdhcmRpbmcgIGFkZHJlc3NlcyB0byBiZSBhY2Nlc3NpYmxlIGluIGJvdGgg
Zm9yd2FyZCBhbmQgYmFja3dhcmQgZGlyZWN0aW9ucyAgbGltaXRzIFAyUC1SUEwgdG8gb25seSBz
aW5nbGUgaW50ZXJmYWNlIGRldmljZXM/IEkgdGhpbmsgdGhpcyAgcmVxdWlyZW1lbnQgbWVhbnMg
dGhhdCBQMlAtUlBMIGNhbm5vdCBiZSB1c2VkIGFjcm9zcyBsaW5rIGxheWVycy4gSXMgIHRoYXQg
d2hhdCB5b3UgbWVhbj8gSSB0aGluayBhbGxvd2luZyBvcGVyYXRpb24gYWNyb3NzIGxpbmsgbGF5
ZXJzIHdvdWxkICByZXF1aXJlIFAyUC1SRE8gdG8gYWNjdW11bGF0ZSBhZGRpdGlvbmFsIGluZm9y
bWF0aW9uIChiYWNrd2FyZCBhZGRyZXNzICB0byBiZSB1c2VkIGZvciBmb3J3YXJkIGFkZHJlc3Nl
cyBub3QgYWNjZXNzaWJsZSBpbiBiYWNrd2FyZCBkaXJlY3Rpb24pLg0KIEkgdGhpbmsgYXQgdGhl
IG1vbWVudCB3ZSB3YW50IHRvIGF2b2lkIHRoaXMgY29tcGxleGl0eS4NCg0KIFtQYXNjYWw0XSBC
ZWNhdXNlIGFuIElQIGFkZHJlc3MgaXMgYXNzb2NpYXRlZCB0byBhbiBpbnRlcmZhY2UuIElmIHlv
dSAgaGF2ZSAyIGludGVyZmFjZXMsIGV2ZW4gaW4gYSBzYW1lIHN1Ym5ldCwgdGhlcmUgc2hvdWxk
IGJlIDIgYWRkcmVzc2VzLg0KDQogW011a3VsNF0gQnV0LCB3aHkgd291bGQgdGhlIHR3byBJUCBh
ZGRyZXNzZXMgdGhlIGRldmljZSBoYXMgb24gdGhlIHNhbWUgIHN1Ym5ldCB3b250IGJlIGFjY2Vz
c2libGUgaW4gYm90aCBmb3J3YXJkIGFuZCBiYWNrd2FyZCBkaXJlY3Rpb25zPw0KDQoNCiBQYXNj
YWwNCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGpwdkDigKYgICAgICAgICAgICAgICAgICB8ICAgICAg
T3duZXI6ICBtdWt1bEDigKYNCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAgICAgICAgfCAg
ICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAgIHwgIE1p
bGVzdG9uZToNCkNvbXBvbmVudDogIHAycC1ycGwgICAgICAgICAgICAgICAgfCAgICBWZXJzaW9u
Og0KIFNldmVyaXR5OiAgU3VibWl0dGVkIFdHIERvY3VtZW50ICB8ICAgS2V5d29yZHM6DQotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K
VGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3JvbGwvdHJhYy90aWNr
ZXQvODk+DQpyb2xsIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC8+DQoNCg==

From prvs=44399eb11=mukul@uwm.edu  Fri Apr 13 06:26:18 2012
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 285D821F857D for ; Fri, 13 Apr 2012 06:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.309
X-Spam-Level: 
X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[AWL=0.290,  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 lhh36SnHPuAv for ; Fri, 13 Apr 2012 06:26:17 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4112121F8584 for ; Fri, 13 Apr 2012 06:26:17 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAEcpiE9/AAAB/2dsb2JhbABChXK0ZQEBBSNWDA8RBAEBAwINFgMCSAkIBhMbh3MLq06JcoEhgS+KA4UNgRgEiFqNEoERjyWDBYE2
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 8E0A812E3C6; Fri, 13 Apr 2012 08:26:11 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu
Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1qfUn5AHfak; Fri, 13 Apr 2012 08:26:11 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 46F2612E3BE; Fri, 13 Apr 2012 08:26:11 -0500 (CDT)
Date: Fri, 13 Apr 2012 08:26:11 -0500 (CDT)
From: Mukul Goyal 
To: "Pascal Thubert (pthubert)" 
Message-ID: <63652812.15790.1334323571175.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.91]
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] #89: Spec is limited to single interface intermediate routers
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, 13 Apr 2012 13:26:18 -0000

Should we use forward and backward terms? I already define them in the draf=
t.

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" , roll@ietf.org
Cc: jpv@cisco.com
Sent: Friday, April 13, 2012 8:24:45 AM
Subject: RE: [roll] #89: Spec is limited to single interface intermediate r=
outers

Hello Mukul

I'd prefer to use upward and downward which are the terms that RPL traditio=
nally uses....=20

Is that OK with you? Otherwise yes, this text addresses my issue.

Cheers,

Pascal


-----Original Message-----
From: Mukul Goyal [mailto:mukul@uwm.edu]=20
Sent: vendredi 13 avril 2012 15:06
To: roll@ietf.org
Cc: jpv@cisco.com; Pascal Thubert (pthubert)
Subject: Re: [roll] #89: Spec is limited to single interface intermediate r=
outers

Hi Pascal,

I propose the following text to be placed inside the Applicability section:

"The participation in a P2P-RPL route discovery is currently limited to the=
 routers with IPv6 addresses that are reachable in both incoming and outgoi=
ng directions, which it quite typical in usual LLN routers with a single ra=
dio"

Can we close this ticket?

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" 
To: mukul@UWM.EDU, jpv@cisco.com
Cc: roll@ietf.org
Sent: Wednesday, April 4, 2012 8:11:10 AM
Subject: [roll] #89: Spec is limited to single interface intermediate route=
rs

#89: Spec is limited to single interface intermediate routers

 Problem (currently open)
 ------------------------------
 The spec does not allow for routers with multiple interfaces. It expects  =
that an address is usable downwards and upwards.

 Discussion
 -------------

 [Pascal]
 "When an
 intermediate router adds itself to a route, it MUST ensure that the
 IPv6 address added to the route is reachable in both forward and  backward=
 directions."
 This is written with the vision that the router has a single interface  an=
d acts as a repeater.
 But really a router could have 2 interfaces on a same subnet in which  cas=
e that clause does not fly.

 [Mukul]
 All I mean is that the accumulated route MUST NOT have an address that  ca=
nnot be accessed in one of the directions. If the address cannot be  access=
ed in the backward direction, then the DRO would not be able to  travel to =
the origin.

 [Pascal2] Then you're preventing a router with 2 interfaces. That's sad.
 I'm fine for an experimental draft   but for standard track that will
 have to be changed.

 [Mukul2] OK, I am keeping it the way it is.

 [Pascal3] This also need to be logged as a last call issue and its  propos=
ed resolution. Nothing wrong with having limitations, yet I think  we must =
have specific text to indicate that the spec so far is limited  to devices =
with a single interface. When we make the Standard Track  version, I expect=
 we'll have to go beyond that limitation. The drawback  is for experimental=
  implementations that may not be interoperable with  the final solution.

 [Mukul3] Could you please explain how does the requirement regarding  addr=
esses to be accessible in both forward and backward directions  limits P2P-=
RPL to only single interface devices? I think this  requirement means that =
P2P-RPL cannot be used across link layers. Is  that what you mean? I think =
allowing operation across link layers would  require P2P-RDO to accumulate =
additional information (backward address  to be used for forward addresses =
not accessible in backward direction).
 I think at the moment we want to avoid this complexity.

 [Pascal4] Because an IP address is associated to an interface. If you  hav=
e 2 interfaces, even in a same subnet, there should be 2 addresses.

 [Mukul4] But, why would the two IP addresses the device has on the same  s=
ubnet wont be accessible in both forward and backward directions?


 Pascal

--=20
-----------------------------------+---------------------
 Reporter:  jpv@=E2=80=A6                  |      Owner:  mukul@=E2=80=A6
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: 
roll 


From trac+roll@trac.tools.ietf.org  Fri Apr 13 06:32:21 2012
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 9380A21F872B for ; Fri, 13 Apr 2012 06:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.473
X-Spam-Level: 
X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 DVrirbzV2SBG for ; Fri, 13 Apr 2012 06:32:21 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 057A921F85F0 for ; Fri, 13 Apr 2012 06:32:20 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIgbo-0002HQ-0n; Fri, 13 Apr 2012 09:32:16 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 13:32:14 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/92#comment:1
Message-ID: <070.ffd44fa4b29b2617d67f7d2b7420e4a4@trac.tools.ietf.org>
References: <055.4f67aded0ee3d83f8b18258686aba080@trac.tools.ietf.org>
X-Trac-Ticket-ID: 92
In-Reply-To: <055.4f67aded0ee3d83f8b18258686aba080@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #92: Is it possible to make P2P-RPL independent of trickle algorithm
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 13:32:21 -0000

#92: Is it possible to make P2P-RPL independent of trickle algorithm

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Resolution:
 ----------------
 No. P2P-RPL depends on DAG creation for route discovery which inturn
 inherently depends on trickle algorithm.

 Discussion:
 -----------------

 [Cedric]
 Another point that has been discussed today during the ROLL meeting, is
 that some people may find other mechanisms than trickle more efficient to
 flood the RDO.
 Could we let the door opened to other flooding optimization mechanism, or
 explicitly say that the trickle mechanism MUST be used ?

 [Mukul]
 I think inherent dependence on the trickle mechanism is apparent because
 of the fact that the route discovery takes place by forming a temporary
 DAG. DAG creation (or DIO generation) depends on trickle algorithm. So,
 P2P-RPL also depends on trickle algorithm. P2P-RPL being an extension of
 core RPL, I dont think there is a way to separate P2P-RPL from trickle
 algorithm.

 [Cedric2]
 Fine. If this is needed for RPL compliancy, then I agree.

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From trac+roll@trac.tools.ietf.org  Fri Apr 13 06:33:01 2012
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 E27F221F873D for ; Fri, 13 Apr 2012 06:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.477
X-Spam-Level: 
X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 iHOnS5O-cY2l for ; Fri, 13 Apr 2012 06:33:00 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1376821F85F0 for ; Fri, 13 Apr 2012 06:33:00 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIgcO-00068V-Tj; Fri, 13 Apr 2012 09:32:52 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 13:32:52 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/95#comment:1
Message-ID: <070.a738fb0129d775830b7e90a1c7761421@trac.tools.ietf.org>
References: <055.011df19dbc537f65d6ae0f3e832587d1@trac.tools.ietf.org>
X-Trac-Ticket-ID: 95
In-Reply-To: <055.011df19dbc537f65d6ae0f3e832587d1@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 13:33:02 -0000

#95: Why need stop flag? Is the receipt of DRO not sufficient to indicate
completion of route discovery?

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Resolution:
 ------------

 No because multiple DROs would be generated if multiple source  routes are
 being discovered.

 Discussion:
 --------------

 p15 :  Stop (S): This flag, when set to one by a target, indicates that
 the P2P-RPL route discovery is over.

 [Cedric]
 Is this bit really usefull ? My guess is that it will be always set to 1.
 If you hear a DRO, this indeed means that the RDO has reached the target,
 so you could just stop processing RDO when you hear a DRO.
 Do we really need a flag to stop RDO processing or the hearing of a DRO
 type message could do the job ?

 [Mukul]
 A P2P-RPL invocation might involve discovery of multiple source routes. In
 that case, receipt of a DRO does not mean route discovery is over. Only
 when the target sets the stop flag in the DRO, a node could be sure that
 the route discovery is over.

 [Cedric2]
 OK fo multiple discovery.
 But if I want to discover a route to a multicast group of target. I set a
 multicast adress in the target field of the RDO. Then, do I received as
 many DRO message as the number of target reached ? In that case, would the
 first DRO with a "S" flag stop the RDO propagation to reach all the target
 included in the multicast group ?

 [Mukul2]
 A target cannot set the S flag to one in the DRO if the target address in
 the P2P-RDO specified a multicast address. See the following text at the
 end of page 21 in P2P-RPL-9:

 "The target MAY set the stop flag inside the DRO message to one if

 Goyal, et al.           Expires September 7, 2012              [Page 21]

 Internet-Draft         draft-ietf-roll-p2p-rpl-09             March 2012

 o  this router is the only target specified in the corresponding DIO,
    i.e., the corresponding DIO specified a unicast address of the
    router as the Target inside the P2P-RDO with no additional targets
    specified via RPL Target Options; and

 "

 [Cedric3]
 So how do you stop the RDO flooding when the target adress is mulicast ?

 [Mukul3]

 Stop flag cannot be used when the target address is multicast or when
 multiple unicast targets are there. The DIO generation will stop when the
 DAG dies. In the meanwhile, trickle algorithm would hopefully avoid
 unnecessary message generation. Note that the draft recommends a very
 small value for the redundancy constant.

 [Cedric4]
 So in this case, the RDO (I guess this is what you mean when you mentioned
 "DIO" in you previous message) generation to discover the route is never
 ending until the temporary DAG dies ?

 [Mukul4] Never ending wont be the correct description. The temporary DAG
 lasts for a few seconds only. Plus, the trickle algorithm would prevent
 the generation of many DIOs.

 [Cedric4]
 I guess the RDO flooding would stop according to the MaxRank/NH field  of
 the P2P-RDO message.

 [Mukul4]
 Yes, it would. MaxRank and other routing constraints would always limit
 the scope of route discovery. Note that there are two separate things:
 1) scope of discovery: how far the discovery message (P2P-RDO inside the
 DIO) travels. This is controlled by the routing constraints and the
 maxRank field inside the P2P-RDO.
 2) How many discovery messages are generated by the nodes that join the
 DAG: this is controlled by trickle timer and ultimately by the DAG life
 time. The stop flag in the DRO is an optimization that allows DIO
 generation to stop in the nodes that can hear the stop flag.

 [Cedric4]
 But if this field is set to 0 (meaning infinity according to section 7.1),
 we should find a mechanism to stop the discovery mechanism.
 What do you think ?

 [Mukul4]
 To tell the truth, MaxRank is basically a way to avoid putting a metric
 container in the DIO (when a limit on rank is the only constraint you want
 to specify). The scope of discovery is limited by both MaxRank as well as
 the routing constraints in the metric container.

 [Cedric5]
 Actually, the problem for stopping the discovery process without the "S"
 flag is also present with unicast addresses, because not all nodes will
 hear the DRO (Only the nodes in the neighborhood of DRO forwarders).
 So we ended with some nodes forming and maintaining a temporary DAG even
 is they are not included in the discovered path, until the temporary DAG
 dies.
 As you mentioned, the maxRank field, routing constraints, and trickle or
 DAG lifetime limit this overhead.
 The section 9.2 of this draft give useful guidelines for trickle operation
 using the P2P RPL mechanism, and limit the flooding of RDO messages.
 The only improvement we could add is to avoid the maintenance of some part
 of the temporary DAG that don't hear the DRO with the S flag.
 This nodes will still send out some DIO when the trickle timer fires.
 Though, thank's to the trickle's operation described in section 9.2, they
 won't be propagated.
 One possibility could be to state that : "if a DRO has not been heard
 within a certain period of time, then their node is not considered as a
 part of the discovered path and should leave the temporary DAG".

 [Mukul5]
 Two problems:
 1) An intermediate router has no idea how long the target wants to wait
 before generating DRO.

 [Cedric6]
 Correct.

 [Mukul5]
 2) If an intermediate router leaves the DAG early (ie before the DAG's
 lifetime is over), it might end up rejoining the DAG when it hears the
 DAG's DIO again.

 [Cedric6]
 Yes. So if I understand correctly, even if a mechanism enable nodes that
 are not along the discovered path to leave the temporary DAG, they will
 join it at some point due to the temporary DAG maintenance messages
 (DIOs).
 So in the end, the benefit I saw (Saving power, packets, state
 maintenance), is not there.
 Then if there is no benefit, there is no reason to change the spec.
 So if what I wrote above is correct, I'm OK to close the ticket and don't
 change anything about the "S" flag behavior.


 [Cedric5]
 This "certain period of time" could be determined according to the network
 topology, the application, or the network diameter for instance and let to
 the implementation.

 [Mukul5]
 It would be much easier if the origin could choose a small (yet
 reasonable) lifetime for the DAG.

 [Cedric6]
 I agree that this parameters will greatly impact on the RPL P2P cost.


 [Cedric5]
 I see a benefit in the case of a discovery process to a unicast target in
 a very large and sparse network. Here, a lot of nodes will maintain
 unnecessary states if they are not part of the discovered path.
 With the current spec, they will send periodic and unnessecary DIO. The
 handling of a "DRO timeout reception" could save packets, thus battery,
 bandwidth etc...

 [Mukul5]
 I am not sure this will work as I explained above.
 _______________________________________________
 Roll mailing list
 Roll@ietf.org
 https://www.ietf.org/mailman/listinfo/roll

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From trac+roll@trac.tools.ietf.org  Fri Apr 13 06:33:26 2012
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 10CDB21F878A for ; Fri, 13 Apr 2012 06:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.482
X-Spam-Level: 
X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 jnxUWN51o0+e for ; Fri, 13 Apr 2012 06:33:25 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFE221F8787 for ; Fri, 13 Apr 2012 06:33:25 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIgcu-00076F-Ny; Fri, 13 Apr 2012 09:33:24 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 13:33:24 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/94#comment:1
Message-ID: <070.99880ba1f6b363aa1d75c2aac786a74f@trac.tools.ietf.org>
References: <055.5e7958cf85282c164ccf1feb557bf9dc@trac.tools.ietf.org>
X-Trac-Ticket-ID: 94
In-Reply-To: <055.5e7958cf85282c164ccf1feb557bf9dc@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #94: Why does DRO travel by multicast.
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 13:33:26 -0000

#94: Why does DRO travel by multicast.

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Resolution:
 --------------
 Because we want the stop flag in DRO to reach as many nodes as  possible.

 Discussion:
 ---------------

 p14 :  A DRO message travels from the target to the origin via link-local
 multicast along the
   route specified inside the Address vector in the P2P-RDO.

 [Cedric]
 Why using multicast if you know every destinators ?
 Could we unicast packets to each destinators in the address vector ?

 [Mukul]
 DRO travels by link local multicast so that the nodes, that are on the
 temporary DAG but not necessarily on a discovered route, may know that the
 route discovery is over (via the stop flag) and there is no need to
 generate any more DIOs. This may lead to a significant reduction in the
 (unnecessary) DIOs generated. Only the routers on the discovered route do
 the multicast-based forwarding though.

 [Cedric2]
 Makes sense, thank's for clarification.
 This ticket can be closed.
 ______________________

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From pthubert@cisco.com  Fri Apr 13 06:33:55 2012
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 8B9A521F87A5 for ; Fri, 13 Apr 2012 06:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.148
X-Spam-Level: 
X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DODYw4FnZlQ for ; Fri, 13 Apr 2012 06:33:54 -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 53ACB21F87A2 for ; Fri, 13 Apr 2012 06:33:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=6458; q=dns/txt; s=iport; t=1334324034; x=1335533634; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ygrM1a84+CSjL/SHL+gaZbDKnUuFm7/RI8qbJsWL/pI=; b=hKC7DZO/R8DJDf92AqvgWaoyKzqFKlzRasdKb0jsI8B7gZd6xtLXbh/z ZE+aJwxohM72Lq1xI1mdx1aOTVKusf/oqUEVAz5kjnpuXGP4CPyIsKhDR rccv/h0JDqZ6hoZLi0f/1364Jv0kTRz6kL9M9Mb7L+ADlK+TWOwtSRWqt Y=;
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="70789687"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2012 13:33:53 +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 q3DDXrQu018817; Fri, 13 Apr 2012 13:33:53 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);  Fri, 13 Apr 2012 15:33:53 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 13 Apr 2012 15:32:15 +0200
Message-ID: 
In-Reply-To: <63652812.15790.1334323571175.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [roll] #89: Spec is limited to single interface intermediate routers
Thread-Index: Ac0ZeQJKAYRQ1eATR0iNyl7hVhtgBQAAMsjw
References:  <63652812.15790.1334323571175.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" 
X-OriginalArrivalTime: 13 Apr 2012 13:33:53.0067 (UTC) FILETIME=[114E6FB0:01CD197A]
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #89: Spec is limited to single interface intermediate routers
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, 13 Apr 2012 13:33:55 -0000

WWVzLCB0aGF0IHdvdWxkIGJlIHBlcmZlY3QNCg0KUGFzY2FsDQoNCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IE11a3VsIEdveWFsIFttYWlsdG86bXVrdWxAdXdtLmVkdV0gDQpT
ZW50OiB2ZW5kcmVkaSAxMyBhdnJpbCAyMDEyIDE1OjI2DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0
aHViZXJ0KQ0KQ2M6IGpwdkBjaXNjby5jb207IHJvbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb
cm9sbF0gIzg5OiBTcGVjIGlzIGxpbWl0ZWQgdG8gc2luZ2xlIGludGVyZmFjZSBpbnRlcm1lZGlh
dGUgcm91dGVycw0KDQpTaG91bGQgd2UgdXNlIGZvcndhcmQgYW5kIGJhY2t3YXJkIHRlcm1zPyBJ
IGFscmVhZHkgZGVmaW5lIHRoZW0gaW4gdGhlIGRyYWZ0Lg0KDQpUaGFua3MNCk11a3VsDQoNCi0t
LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJQYXNjYWwgVGh1YmVydCAocHRodWJl
cnQpIiA8cHRodWJlcnRAY2lzY28uY29tPg0KVG86ICJNdWt1bCBHb3lhbCIgPG11a3VsQHV3bS5l
ZHU+LCByb2xsQGlldGYub3JnDQpDYzoganB2QGNpc2NvLmNvbQ0KU2VudDogRnJpZGF5LCBBcHJp
bCAxMywgMjAxMiA4OjI0OjQ1IEFNDQpTdWJqZWN0OiBSRTogW3JvbGxdICM4OTogU3BlYyBpcyBs
aW1pdGVkIHRvIHNpbmdsZSBpbnRlcmZhY2UgaW50ZXJtZWRpYXRlIHJvdXRlcnMNCg0KSGVsbG8g
TXVrdWwNCg0KSSdkIHByZWZlciB0byB1c2UgdXB3YXJkIGFuZCBkb3dud2FyZCB3aGljaCBhcmUg
dGhlIHRlcm1zIHRoYXQgUlBMIHRyYWRpdGlvbmFsbHkgdXNlcy4uLi4gDQoNCklzIHRoYXQgT0sg
d2l0aCB5b3U/IE90aGVyd2lzZSB5ZXMsIHRoaXMgdGV4dCBhZGRyZXNzZXMgbXkgaXNzdWUuDQoN
CkNoZWVycywNCg0KUGFzY2FsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IE11a3VsIEdveWFsIFttYWlsdG86bXVrdWxAdXdtLmVkdV0gDQpTZW50OiB2ZW5kcmVkaSAxMyBh
dnJpbCAyMDEyIDE1OjA2DQpUbzogcm9sbEBpZXRmLm9yZw0KQ2M6IGpwdkBjaXNjby5jb207IFBh
c2NhbCBUaHViZXJ0IChwdGh1YmVydCkNClN1YmplY3Q6IFJlOiBbcm9sbF0gIzg5OiBTcGVjIGlz
IGxpbWl0ZWQgdG8gc2luZ2xlIGludGVyZmFjZSBpbnRlcm1lZGlhdGUgcm91dGVycw0KDQpIaSBQ
YXNjYWwsDQoNCkkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRleHQgdG8gYmUgcGxhY2VkIGluc2lk
ZSB0aGUgQXBwbGljYWJpbGl0eSBzZWN0aW9uOg0KDQoiVGhlIHBhcnRpY2lwYXRpb24gaW4gYSBQ
MlAtUlBMIHJvdXRlIGRpc2NvdmVyeSBpcyBjdXJyZW50bHkgbGltaXRlZCB0byB0aGUgcm91dGVy
cyB3aXRoIElQdjYgYWRkcmVzc2VzIHRoYXQgYXJlIHJlYWNoYWJsZSBpbiBib3RoIGluY29taW5n
IGFuZCBvdXRnb2luZyBkaXJlY3Rpb25zLCB3aGljaCBpdCBxdWl0ZSB0eXBpY2FsIGluIHVzdWFs
IExMTiByb3V0ZXJzIHdpdGggYSBzaW5nbGUgcmFkaW8iDQoNCkNhbiB3ZSBjbG9zZSB0aGlzIHRp
Y2tldD8NCg0KVGhhbmtzDQpNdWt1bA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpG
cm9tOiAicm9sbCBpc3N1ZSB0cmFja2VyIiA8dHJhYytyb2xsQHRyYWMudG9vbHMuaWV0Zi5vcmc+
DQpUbzogbXVrdWxAVVdNLkVEVSwganB2QGNpc2NvLmNvbQ0KQ2M6IHJvbGxAaWV0Zi5vcmcNClNl
bnQ6IFdlZG5lc2RheSwgQXByaWwgNCwgMjAxMiA4OjExOjEwIEFNDQpTdWJqZWN0OiBbcm9sbF0g
Izg5OiBTcGVjIGlzIGxpbWl0ZWQgdG8gc2luZ2xlIGludGVyZmFjZSBpbnRlcm1lZGlhdGUgcm91
dGVycw0KDQojODk6IFNwZWMgaXMgbGltaXRlZCB0byBzaW5nbGUgaW50ZXJmYWNlIGludGVybWVk
aWF0ZSByb3V0ZXJzDQoNCiBQcm9ibGVtIChjdXJyZW50bHkgb3BlbikNCiAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCiBUaGUgc3BlYyBkb2VzIG5vdCBhbGxvdyBmb3Igcm91dGVycyB3
aXRoIG11bHRpcGxlIGludGVyZmFjZXMuIEl0IGV4cGVjdHMgIHRoYXQgYW4gYWRkcmVzcyBpcyB1
c2FibGUgZG93bndhcmRzIGFuZCB1cHdhcmRzLg0KDQogRGlzY3Vzc2lvbg0KIC0tLS0tLS0tLS0t
LS0NCg0KIFtQYXNjYWxdDQogIldoZW4gYW4NCiBpbnRlcm1lZGlhdGUgcm91dGVyIGFkZHMgaXRz
ZWxmIHRvIGEgcm91dGUsIGl0IE1VU1QgZW5zdXJlIHRoYXQgdGhlDQogSVB2NiBhZGRyZXNzIGFk
ZGVkIHRvIHRoZSByb3V0ZSBpcyByZWFjaGFibGUgaW4gYm90aCBmb3J3YXJkIGFuZCAgYmFja3dh
cmQgZGlyZWN0aW9ucy4iDQogVGhpcyBpcyB3cml0dGVuIHdpdGggdGhlIHZpc2lvbiB0aGF0IHRo
ZSByb3V0ZXIgaGFzIGEgc2luZ2xlIGludGVyZmFjZSAgYW5kIGFjdHMgYXMgYSByZXBlYXRlci4N
CiBCdXQgcmVhbGx5IGEgcm91dGVyIGNvdWxkIGhhdmUgMiBpbnRlcmZhY2VzIG9uIGEgc2FtZSBz
dWJuZXQgaW4gd2hpY2ggIGNhc2UgdGhhdCBjbGF1c2UgZG9lcyBub3QgZmx5Lg0KDQogW011a3Vs
XQ0KIEFsbCBJIG1lYW4gaXMgdGhhdCB0aGUgYWNjdW11bGF0ZWQgcm91dGUgTVVTVCBOT1QgaGF2
ZSBhbiBhZGRyZXNzIHRoYXQgIGNhbm5vdCBiZSBhY2Nlc3NlZCBpbiBvbmUgb2YgdGhlIGRpcmVj
dGlvbnMuIElmIHRoZSBhZGRyZXNzIGNhbm5vdCBiZSAgYWNjZXNzZWQgaW4gdGhlIGJhY2t3YXJk
IGRpcmVjdGlvbiwgdGhlbiB0aGUgRFJPIHdvdWxkIG5vdCBiZSBhYmxlIHRvICB0cmF2ZWwgdG8g
dGhlIG9yaWdpbi4NCg0KIFtQYXNjYWwyXSBUaGVuIHlvdSdyZSBwcmV2ZW50aW5nIGEgcm91dGVy
IHdpdGggMiBpbnRlcmZhY2VzLiBUaGF0J3Mgc2FkLg0KIEknbSBmaW5lIGZvciBhbiBleHBlcmlt
ZW50YWwgZHJhZnQgICBidXQgZm9yIHN0YW5kYXJkIHRyYWNrIHRoYXQgd2lsbA0KIGhhdmUgdG8g
YmUgY2hhbmdlZC4NCg0KIFtNdWt1bDJdIE9LLCBJIGFtIGtlZXBpbmcgaXQgdGhlIHdheSBpdCBp
cy4NCg0KIFtQYXNjYWwzXSBUaGlzIGFsc28gbmVlZCB0byBiZSBsb2dnZWQgYXMgYSBsYXN0IGNh
bGwgaXNzdWUgYW5kIGl0cyAgcHJvcG9zZWQgcmVzb2x1dGlvbi4gTm90aGluZyB3cm9uZyB3aXRo
IGhhdmluZyBsaW1pdGF0aW9ucywgeWV0IEkgdGhpbmsgIHdlIG11c3QgaGF2ZSBzcGVjaWZpYyB0
ZXh0IHRvIGluZGljYXRlIHRoYXQgdGhlIHNwZWMgc28gZmFyIGlzIGxpbWl0ZWQgIHRvIGRldmlj
ZXMgd2l0aCBhIHNpbmdsZSBpbnRlcmZhY2UuIFdoZW4gd2UgbWFrZSB0aGUgU3RhbmRhcmQgVHJh
Y2sgIHZlcnNpb24sIEkgZXhwZWN0IHdlJ2xsIGhhdmUgdG8gZ28gYmV5b25kIHRoYXQgbGltaXRh
dGlvbi4gVGhlIGRyYXdiYWNrICBpcyBmb3IgZXhwZXJpbWVudGFsICBpbXBsZW1lbnRhdGlvbnMg
dGhhdCBtYXkgbm90IGJlIGludGVyb3BlcmFibGUgd2l0aCAgdGhlIGZpbmFsIHNvbHV0aW9uLg0K
DQogW011a3VsM10gQ291bGQgeW91IHBsZWFzZSBleHBsYWluIGhvdyBkb2VzIHRoZSByZXF1aXJl
bWVudCByZWdhcmRpbmcgIGFkZHJlc3NlcyB0byBiZSBhY2Nlc3NpYmxlIGluIGJvdGggZm9yd2Fy
ZCBhbmQgYmFja3dhcmQgZGlyZWN0aW9ucyAgbGltaXRzIFAyUC1SUEwgdG8gb25seSBzaW5nbGUg
aW50ZXJmYWNlIGRldmljZXM/IEkgdGhpbmsgdGhpcyAgcmVxdWlyZW1lbnQgbWVhbnMgdGhhdCBQ
MlAtUlBMIGNhbm5vdCBiZSB1c2VkIGFjcm9zcyBsaW5rIGxheWVycy4gSXMgIHRoYXQgd2hhdCB5
b3UgbWVhbj8gSSB0aGluayBhbGxvd2luZyBvcGVyYXRpb24gYWNyb3NzIGxpbmsgbGF5ZXJzIHdv
dWxkICByZXF1aXJlIFAyUC1SRE8gdG8gYWNjdW11bGF0ZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9u
IChiYWNrd2FyZCBhZGRyZXNzICB0byBiZSB1c2VkIGZvciBmb3J3YXJkIGFkZHJlc3NlcyBub3Qg
YWNjZXNzaWJsZSBpbiBiYWNrd2FyZCBkaXJlY3Rpb24pLg0KIEkgdGhpbmsgYXQgdGhlIG1vbWVu
dCB3ZSB3YW50IHRvIGF2b2lkIHRoaXMgY29tcGxleGl0eS4NCg0KIFtQYXNjYWw0XSBCZWNhdXNl
IGFuIElQIGFkZHJlc3MgaXMgYXNzb2NpYXRlZCB0byBhbiBpbnRlcmZhY2UuIElmIHlvdSAgaGF2
ZSAyIGludGVyZmFjZXMsIGV2ZW4gaW4gYSBzYW1lIHN1Ym5ldCwgdGhlcmUgc2hvdWxkIGJlIDIg
YWRkcmVzc2VzLg0KDQogW011a3VsNF0gQnV0LCB3aHkgd291bGQgdGhlIHR3byBJUCBhZGRyZXNz
ZXMgdGhlIGRldmljZSBoYXMgb24gdGhlIHNhbWUgIHN1Ym5ldCB3b250IGJlIGFjY2Vzc2libGUg
aW4gYm90aCBmb3J3YXJkIGFuZCBiYWNrd2FyZCBkaXJlY3Rpb25zPw0KDQoNCiBQYXNjYWwNCg0K
LS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCiBSZXBvcnRlcjogIGpwdkDigKYgICAgICAgICAgICAgICAgICB8ICAgICAgT3duZXI6
ICBtdWt1bEDigKYNCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAgICAgICAgfCAgICAgU3Rh
dHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgICAgIHwgIE1pbGVzdG9u
ZToNCkNvbXBvbmVudDogIHAycC1ycGwgICAgICAgICAgICAgICAgfCAgICBWZXJzaW9uOg0KIFNl
dmVyaXR5OiAgU3VibWl0dGVkIFdHIERvY3VtZW50ICB8ICAgS2V5d29yZHM6DQotLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0
IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3JvbGwvdHJhYy90aWNrZXQvODk+
DQpyb2xsIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC8+DQoNCg==

From trac+roll@trac.tools.ietf.org  Fri Apr 13 06:34:00 2012
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 6E82121F87A9 for ; Fri, 13 Apr 2012 06:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.485
X-Spam-Level: 
X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 QcoXM2xVG0LK for ; Fri, 13 Apr 2012 06:33:59 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id BD97121F87B6 for ; Fri, 13 Apr 2012 06:33:59 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIgdS-0008Nj-TT; Fri, 13 Apr 2012 09:33:58 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 13:33:58 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/96#comment:2
Message-ID: <070.699db57ed1dee8d2a22b5d9efba94741@trac.tools.ietf.org>
References: <055.f7a4657c0332f6393eb09f355b0158eb@trac.tools.ietf.org>
X-Trac-Ticket-ID: 96
In-Reply-To: <055.f7a4657c0332f6393eb09f355b0158eb@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 13:34:00 -0000

#96: Can the draft recommend how much to wait before a target selects routes to
be sent back in DROs?

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Resolution:
 -----------------
 This is purely a local decision at the target. The draft  should not make
 any recommendation in this regard.

 Discussion:
 -----------------
 p21 :  Example methods include selecting each route that meets the
 specified routing constraints
   until the desired number have been selected or selecting the best
   routes discovered over a certain time period.

 [Cedric]
 How could we know the time to wait until we get all the RDO ?
 Is there a way to evaluate it according to some parameters related to the
 network (diameter of the network for instance) ?

 [Mukul] This has to be a local decision. Perhaps, the target can look at
 the aggregated values of the routing metrics from the origin and determine
 its distance from the origin. This distance estimate, along with trickle
 parameters, could perhaps give it a better idea of how much to wait. I
 dont think that the draft should talk about this.

 [Cedric2]
 OK, let's say it is up to the implementation and should be deterinied
 according to the specific set of metric/contraints in use.
 A target from a DAG based on a latency metric could wait just a few ms
 after receiving the first RDO  and select the best path according to the
 latency metric.
 A target from a DAG based on a energy metric could wait much more time
 after receiving the first RDO to be sure to use an energy efficient path,
 that could be discovered after some time, because of duty cycling nodes
 for instance.

 [Mukul2] Choosing the wait time on the basis of specific metrics being
 used in route discovery could be one option. However, when an origin wants
 to discover low latency routes, it does not necessarily mean that the
 latency of the route discovery process has to be low as well. :) So, in
 general, I think that the time a target waits before sending DROs (which
 determines to some extent the latency of the route discovery process) is
 independent of the specific metrics/constraints being used in route
 discovery process. As I said before, I think the target should decide for
 itself how much should it wait before sending DRO(s). It may not be wise
 to make any suggestions in this regard in the P2P-RPL specs beyond what
 the draft already says - the draft does suggest two sample methods: 1)
 select routes on FCFS basis 2) choose the best routes discovered over an
 interval.

 [Cedric3]
 Yes good point. So I think the draft is generic enough regarding this
 parameter.

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From trac+roll@trac.tools.ietf.org  Fri Apr 13 06:34:31 2012
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 BC6B221F87C8 for ; Fri, 13 Apr 2012 06:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.489
X-Spam-Level: 
X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 Xk+SMABxa+c3 for ; Fri, 13 Apr 2012 06:34:31 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2B37B21F87B6 for ; Fri, 13 Apr 2012 06:34:31 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIgdy-00012o-CY; Fri, 13 Apr 2012 09:34:30 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 13:34:30 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/97#comment:2
Message-ID: <070.793aa93f6c2e5929e90219272cb3259d@trac.tools.ietf.org>
References: <055.7d6225a737a857a571e335c8e6245a84@trac.tools.ietf.org>
X-Trac-Ticket-ID: 97
In-Reply-To: <055.7d6225a737a857a571e335c8e6245a84@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #97: A fixed value for DRO_ACK_WAIT_TIME not OK for all P2P-RPL deployments.
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 13:34:31 -0000

#97: A fixed value for DRO_ACK_WAIT_TIME not OK for all P2P-RPL deployments.

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Resolution:
 ------------------------
 Make DRO_ACK_WAIT_TIME as well as MAX_DRO_RETRANSMISSIONS  configurable
 parameters.

 Discussion:
 -------------------------
 p25 :  o DRO_ACK_WAIT_TIME: The time duration a target waits for the DRO-
 ACK before retransmitting a DRO message. DRO_ACK_WAIT_TIME has a
      value of 1 second.

 [Cedric]
 I'm not sure it is compliant with all RPL deployments.
 Could we adapt it to the characteristics of the network used ?

 [Mukul]
 I am OK with making DRO_ACK_WAIT_TIME as well as MAX_DRO_RETRANSMISSIONS
 configurable parameters.

 [Cedric2]
 Safe enough.

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From prvs=44399eb11=mukul@uwm.edu  Fri Apr 13 06:39:06 2012
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 80DDD21F8630 for ; Fri, 13 Apr 2012 06:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.315
X-Spam-Level: 
X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=0.284,  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 fyo07Opp3o1q for ; Fri, 13 Apr 2012 06:39:05 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id C8A9B21F8622 for ; Fri, 13 Apr 2012 06:39:05 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAHUriE9/AAAB/2dsb2JhbABFhWa0bCNWNQINGQJZBi6Hc6ZiiW+JCYEvigOFDYEYBIhajRKQNoMFgTY
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 1ACBEE6A8E; Fri, 13 Apr 2012 08:39:05 -0500 (CDT)
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 2GcV1j+XaI6s; Fri, 13 Apr 2012 08:39:04 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id D78A4E6A8D; Fri, 13 Apr 2012 08:39:04 -0500 (CDT)
Date: Fri, 13 Apr 2012 08:39:04 -0500 (CDT)
From: Mukul Goyal 
To: JP Vasseur 
Message-ID: <856340696.15964.1334324344794.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.91]
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] Closure text for ticket #89
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, 13 Apr 2012 13:39:06 -0000

#89: Spec is limited to single interface intermediate routers

 Problem
 ------------------------------
 The spec does not allow for routers with multiple interfaces. It expects  that an address is usable downwards and upwards.

Resolution:
-----------------------------
Add the following text to the Applicability section:

"The participation in a P2P-RPL route discovery is currently limited to the routers with IPv6 addresses that are reachable in both forward and backward directions, which it quite typical in usual LLN routers with a single radio"

 Discussion
 -------------

 [Pascal]
 "When an
 intermediate router adds itself to a route, it MUST ensure that the
 IPv6 address added to the route is reachable in both forward and  backward directions."
 This is written with the vision that the router has a single interface  and acts as a repeater.
 But really a router could have 2 interfaces on a same subnet in which  case that clause does not fly.

 [Mukul]
 All I mean is that the accumulated route MUST NOT have an address that  cannot be accessed in one of the directions. If the address cannot be  accessed in the backward direction, then the DRO would not be able to  travel to the origin.

 [Pascal2] Then you're preventing a router with 2 interfaces. That's sad.
 I'm fine for an experimental draft   but for standard track that will
 have to be changed.

 [Mukul2] OK, I am keeping it the way it is.

 [Pascal3] This also need to be logged as a last call issue and its  proposed resolution. Nothing wrong with having limitations, yet I think  we must have specific text to indicate that the spec so far is limited  to devices with a single interface. When we make the Standard Track  version, I expect we'll have to go beyond that limitation. The drawback  is for experimental  implementations that may not be interoperable with  the final solution.

 [Mukul3] Could you please explain how does the requirement regarding  addresses to be accessible in both forward and backward directions  limits P2P-RPL to only single interface devices? I think this  requirement means that P2P-RPL cannot be used across link layers. Is  that what you mean? I think allowing operation across link layers would  require P2P-RDO to accumulate additional information (backward address  to be used for forward addresses not accessible in backward direction).
 I think at the moment we want to avoid this complexity.

 [Pascal4] Because an IP address is associated to an interface. If you  have 2 interfaces, even in a same subnet, there should be 2 addresses.

 [Mukul4] But, why would the two IP addresses the device has on the same  subnet wont be accessible in both forward and backward directions?

[Mukul5]
I propose the following text to be placed inside the Applicability section:

"The participation in a P2P-RPL route discovery is currently limited to the routers with IPv6 addresses that are reachable in both incoming and outgoing directions, which it quite typical in usual LLN routers with a single radio"

Can we close this ticket?

[Pascal5]

I'd prefer to use upward and downward which are the terms that RPL traditionally uses.... 

Is that OK with you? Otherwise yes, this text addresses my issue.

[Mukul6]
Should we use forward and backward terms? I already define them in the draft.

[Pascal6]
Yes, that would be perfect



From trac+roll@trac.tools.ietf.org  Fri Apr 13 06:41:25 2012
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 0D4DC21F87DB for ; Fri, 13 Apr 2012 06:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.493
X-Spam-Level: 
X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 hOx8ak9vWqYp for ; Fri, 13 Apr 2012 06:41:24 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4519221F87D8 for ; Fri, 13 Apr 2012 06:41:24 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIgkd-0007aL-Gt; Fri, 13 Apr 2012 09:41:23 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 13:41:23 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/89#comment:1
Message-ID: <070.50649f02d4c9fcf20a0cd7d1aafb041c@trac.tools.ietf.org>
References: <055.221455d39fc20c241b942c0dcb13bc22@trac.tools.ietf.org>
X-Trac-Ticket-ID: 89
In-Reply-To: <055.221455d39fc20c241b942c0dcb13bc22@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #89: Spec is limited to single interface intermediate routers
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 13:41:25 -0000

#89: Spec is limited to single interface intermediate routers

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 #89: Spec is limited to single interface intermediate routers

 Problem
 ------------------------------
 The spec does not allow for routers with multiple interfaces. It expects
 that an address is usable downwards and upwards.

 Resolution:
 -----------------------------
 Add the following text to the Applicability section:

 "The participation in a P2P-RPL route discovery is currently limited to
 the routers with IPv6 addresses that are reachable in both forward and
 backward directions, which it quite typical in usual LLN routers with a
 single radio"

 Discussion
 -------------

 [Pascal]
 "When an
 intermediate router adds itself to a route, it MUST ensure that the
 IPv6 address added to the route is reachable in both forward and  backward
 directions."
 This is written with the vision that the router has a single interface
 and acts as a repeater.
 But really a router could have 2 interfaces on a same subnet in which
 case that clause does not fly.

 [Mukul]
 All I mean is that the accumulated route MUST NOT have an address that
 cannot be accessed in one of the directions. If the address cannot be
 accessed in the backward direction, then the DRO would not be able to
 travel to the origin.

 [Pascal2] Then you're preventing a router with 2 interfaces. That's sad.
 I'm fine for an experimental draft   but for standard track that will
 have to be changed.

 [Mukul2] OK, I am keeping it the way it is.

 [Pascal3] This also need to be logged as a last call issue and its
 proposed resolution. Nothing wrong with having limitations, yet I think
 we must have specific text to indicate that the spec so far is limited  to
 devices with a single interface. When we make the Standard Track  version,
 I expect we'll have to go beyond that limitation. The drawback  is for
 experimental  implementations that may not be interoperable with  the
 final solution.

 [Mukul3] Could you please explain how does the requirement regarding
 addresses to be accessible in both forward and backward directions  limits
 P2P-RPL to only single interface devices? I think this  requirement means
 that P2P-RPL cannot be used across link layers. Is  that what you mean? I
 think allowing operation across link layers would  require P2P-RDO to
 accumulate additional information (backward address  to be used for
 forward addresses not accessible in backward direction).
 I think at the moment we want to avoid this complexity.

 [Pascal4] Because an IP address is associated to an interface. If you
 have 2 interfaces, even in a same subnet, there should be 2 addresses.

 [Mukul4] But, why would the two IP addresses the device has on the same
 subnet wont be accessible in both forward and backward directions?

 [Mukul5]
 I propose the following text to be placed inside the Applicability
 section:

 "The participation in a P2P-RPL route discovery is currently limited to
 the routers with IPv6 addresses that are reachable in both incoming and
 outgoing directions, which it quite typical in usual LLN routers with a
 single radio"

 Can we close this ticket?

 [Pascal5]

 I'd prefer to use upward and downward which are the terms that RPL
 traditionally uses....

 Is that OK with you? Otherwise yes, this text addresses my issue.

 [Mukul6]
 Should we use forward and backward terms? I already define them in the
 draft.

 [Pascal6]
 Yes, that would be perfect


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

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: 
roll 


From pthubert@cisco.com  Fri Apr 13 06:54:21 2012
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 F2B1F21F87F8 for ; Fri, 13 Apr 2012 06:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.164
X-Spam-Level: 
X-Spam-Status: No, score=-10.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPmQIGrFiGAd for ; Fri, 13 Apr 2012 06:54:20 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A52A821F87F7 for ; Fri, 13 Apr 2012 06:54:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3798; q=dns/txt; s=iport; t=1334325259; x=1335534859; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MCmPXlMPkZQsw26yZWpqMwJVgRG+uK1ADbn21oUQsM4=; b=L6IZe0xsq5kakWrckG170E9qPugVv8e6DrXPlaD/+L8TDWYKl1fr4Mq0 JIy/rLulqvrp1GlmOJy3WCCUT4bUd5KiV5THzTGI/h5oApBQAAZk9M6Qh 9W5im1XY2XzIAsIx09352Baz1WkozTFrChHO8rcHRSCqVqtsChxYRq60l o=;
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="135088027"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2012 13:54:18 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3DDsInh000613; Fri, 13 Apr 2012 13:54:18 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);  Fri, 13 Apr 2012 15:54:18 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Apr 2012 15:53:33 +0200
Message-ID: 
In-Reply-To: <856340696.15964.1334324344794.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Closure text for ticket #89
Thread-Index: Ac0ZetQ9dYenKTPgSKy93R/6yjrDBAAAfaKQ
References:  <856340696.15964.1334324344794.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" , "JP Vasseur" 
X-OriginalArrivalTime: 13 Apr 2012 13:54:18.0755 (UTC) FILETIME=[EBDF9530:01CD197C]
Cc: roll 
Subject: Re: [Roll] Closure text for ticket #89
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, 13 Apr 2012 13:54:21 -0000

Perfect : )

Pascal


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Mukul Goyal
Sent: vendredi 13 avril 2012 15:39
To: JP Vasseur
Cc: roll
Subject: [Roll] Closure text for ticket #89


#89: Spec is limited to single interface intermediate routers

 Problem
 ------------------------------
 The spec does not allow for routers with multiple interfaces. It
expects  that an address is usable downwards and upwards.

Resolution:
-----------------------------
Add the following text to the Applicability section:

"The participation in a P2P-RPL route discovery is currently limited to
the routers with IPv6 addresses that are reachable in both forward and
backward directions, which it quite typical in usual LLN routers with a
single radio"

 Discussion
 -------------

 [Pascal]
 "When an
 intermediate router adds itself to a route, it MUST ensure that the
 IPv6 address added to the route is reachable in both forward and
backward directions."
 This is written with the vision that the router has a single interface
and acts as a repeater.
 But really a router could have 2 interfaces on a same subnet in which
case that clause does not fly.

 [Mukul]
 All I mean is that the accumulated route MUST NOT have an address that
cannot be accessed in one of the directions. If the address cannot be
accessed in the backward direction, then the DRO would not be able to
travel to the origin.

 [Pascal2] Then you're preventing a router with 2 interfaces. That's
sad.
 I'm fine for an experimental draft   but for standard track that will
 have to be changed.

 [Mukul2] OK, I am keeping it the way it is.

 [Pascal3] This also need to be logged as a last call issue and its
proposed resolution. Nothing wrong with having limitations, yet I think
we must have specific text to indicate that the spec so far is limited
to devices with a single interface. When we make the Standard Track
version, I expect we'll have to go beyond that limitation. The drawback
is for experimental  implementations that may not be interoperable with
the final solution.

 [Mukul3] Could you please explain how does the requirement regarding
addresses to be accessible in both forward and backward directions
limits P2P-RPL to only single interface devices? I think this
requirement means that P2P-RPL cannot be used across link layers. Is
that what you mean? I think allowing operation across link layers would
require P2P-RDO to accumulate additional information (backward address
to be used for forward addresses not accessible in backward direction).
 I think at the moment we want to avoid this complexity.

 [Pascal4] Because an IP address is associated to an interface. If you
have 2 interfaces, even in a same subnet, there should be 2 addresses.

 [Mukul4] But, why would the two IP addresses the device has on the same
subnet wont be accessible in both forward and backward directions?

[Mukul5]
I propose the following text to be placed inside the Applicability
section:

"The participation in a P2P-RPL route discovery is currently limited to
the routers with IPv6 addresses that are reachable in both incoming and
outgoing directions, which it quite typical in usual LLN routers with a
single radio"

Can we close this ticket?

[Pascal5]

I'd prefer to use upward and downward which are the terms that RPL
traditionally uses....=20

Is that OK with you? Otherwise yes, this text addresses my issue.

[Mukul6]
Should we use forward and backward terms? I already define them in the
draft.

[Pascal6]
Yes, that would be perfect


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

From mcr@sandelman.ca  Fri Apr 13 07:06:01 2012
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 BB37F21F8762 for ; Fri, 13 Apr 2012 07:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.413
X-Spam-Level: 
X-Spam-Status: No, score=-1.413 tagged_above=-999 required=5 tests=[AWL=0.541,  BAYES_00=-2.599, 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 5UdPvzS7gSGO for ; Fri, 13 Apr 2012 07:06:01 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2A32F21F873A for ; Fri, 13 Apr 2012 07:06:00 -0700 (PDT)
Received: from sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 92077885E; Fri, 13 Apr 2012 10:05:57 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id C35B698AC6; Fri, 13 Apr 2012 10:05:58 -0400 (EDT)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BA90B98AAE; Fri, 13 Apr 2012 10:05:58 -0400 (EDT)
From: Michael Richardson 
To: roll@ietf.org
In-Reply-To: <180364329.15615.1334322376698.JavaMail.root@mail17.pantherlink.uwm.edu>
References: <180364329.15615.1334322376698.JavaMail.root@mail17.pantherlink.uwm.edu>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 13 Apr 2012 10:05:58 -0400
Message-ID: <20762.1334325958@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] [roll] #89: Spec is limited to single interface intermediate routers
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, 13 Apr 2012 14:06:01 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Mukul" =3D=3D Mukul Goyal  writes:
    Mukul> I propose the following text to be placed inside the
    Mukul> Applicability section:

    Mukul> "The participation in a P2P-RPL route discovery is currently
    Mukul> limited to the routers with IPv6 addresses that are reachable
    Mukul> in both incoming and outgoing directions, which it quite
    Mukul> typical in usual LLN routers with a single radio"

I'm happy with this.

It likely covers the many cases where the P2P route crosses into a
backbone and then across ethernet.  There many some corner cases where
such a network is not functional, but the only way I can get to those
corner cases is due to bad implementation decisions.

=2D-=20
]       He who is tired of Weird Al is tired of life!           |  firewall=
s  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net archit=
ect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri=
ver[
   Kyoto Plus: watch the video 
	               then sign the petition.=20

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQCVAwUAT4gyxoqHRg3pndX9AQJ+VgQAmSwQWyJ33fmmAGhplIdTjLV28aRd3oUO
Ig2J9VWIuQes7cYrxgrzpSoBGdSok/NXwdYSPXpWvWFdfHvC1R2OJORRzPC5+ObT
8CfF2jlmXX6PR9QlJIx3BfaWTQp9MaUuOvtndLomNbgU9bgJXagEfD2/WOxr3jSd
bBXB5dfITvk=
=1R0T
-----END PGP SIGNATURE-----
--=-=-=--

From ietf@thomasclausen.org  Fri Apr 13 11:24:57 2012
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 7B4CF21F86F2 for ; Fri, 13 Apr 2012 11:24:57 -0700 (PDT)
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 9MSHPIJK0+P7 for ; Fri, 13 Apr 2012 11:24:57 -0700 (PDT)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0508721F86D3 for ; Fri, 13 Apr 2012 11:24:57 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id D0A0FA31CD for ; Fri, 13 Apr 2012 11:24:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id F195D220513 for ; Fri, 13 Apr 2012 11:24:55 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from [192.240.4.46] (unknown [192.240.4.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id D62F1220512 for ; Fri, 13 Apr 2012 11:24:55 -0700 (PDT)
From: Thomas Heide Clausen 
Content-Type: text/plain; charset=us-ascii
X-Mailer: iPad Mail (9B176)
Message-Id: 
Date: Fri, 13 Apr 2012 11:25:39 -0700
To: "roll@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: [Roll] RPL-P2P - status & update
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, 13 Apr 2012 18:24:58 -0000

Hello folks,

I've been trying to follow the many mails exchanged as a consequence of the W=
GLC of RPL-P2P.

Given the volume of changes to the document, I would like to ask that - once=
 the authors estimate that a version of the I-D folding in all proposed chan=
ges is ready - the WG be given another 1-2 weeks WGLC before bouncing it off=
 to the ADs?

This just to ensure that the WG gets to give the final version a good review=
 before seeing it off.

Thoughts?

Thomas

--=20
Thomas Heide Clausen
http://www.thomasclausen.org/

"Any simple problem can be made insoluble if enough meetings are held to
 discuss it."
   -- Mitchell's Law of Committees


From mcr@sandelman.ca  Fri Apr 13 11:35:19 2012
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 6314A11E80C0 for ; Fri, 13 Apr 2012 11:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.593
X-Spam-Level: 
X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=0.361,  BAYES_00=-2.599, 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 3p-xDULybhSJ for ; Fri, 13 Apr 2012 11:35:18 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id A8B3511E80BE for ; Fri, 13 Apr 2012 11:35:18 -0700 (PDT)
Received: from sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 049B588CE; Fri, 13 Apr 2012 14:35:13 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id A8CB498C08; Fri, 13 Apr 2012 14:35:14 -0400 (EDT)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 97E2098C07; Fri, 13 Apr 2012 14:35:14 -0400 (EDT)
From: Michael Richardson 
To: Thomas Heide Clausen 
In-Reply-To: 
References: 
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 13 Apr 2012 14:35:14 -0400
Message-ID: <22563.1334342114@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: "roll@ietf.org" 
Subject: Re: [Roll] RPL-P2P - status & update
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, 13 Apr 2012 18:35:19 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Thomas" =3D=3D Thomas Heide Clausen  writes:
    Thomas> I've been trying to follow the many mails exchanged as a
    Thomas> consequence of the WGLC of RPL-P2P.=20

Yes, using a good threaded reader is a good idea.
The IETF lists are also http://news.gmane.org/gmane.network.protocols.rpl
and you can access it via nntp://news.gmane.org/gmane.network.protocols.rpl
with a usenet newsreader.

    Thomas> Given the volume of changes to the document, I would like to
    Thomas> ask that - once the authors estimate that a version of the
    Thomas> I-D folding in all proposed changes is ready - the WG be
    Thomas> given another 1-2 weeks WGLC before bouncing it off to the
    Thomas> ADs?=20

I think that we will do this.
Once a new draft is complete, I will remind the list with a link to the
datatracker ID diff tool.

You aren't the only one who wants to read all the changes again.

=2D-=20
]       He who is tired of Weird Al is tired of life!           |  firewall=
s  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net archit=
ect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri=
ver[
   Kyoto Plus: watch the video 
	               then sign the petition.=20

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQCVAwUAT4hx4oqHRg3pndX9AQJfTgQA3NJp+4zCOLyMMf7qRiDMGmJ58jcfnhb9
bBKgI7sRQ2vZgxphy/joPu2SjYw5GzUW4eCTKKho+1umOzy1j0VQzMXswsuf+SK8
vt2ZWs0qWyE2thlBMQtuQEzrEV39C+flcTzo4cTGuqSpC+xycypJUHd0eYNdtn18
sPvanTC2h2o=
=bmmO
-----END PGP SIGNATURE-----
--=-=-=--

From ietf@thomasclausen.org  Fri Apr 13 11:39:01 2012
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 4E01111E80A4 for ; Fri, 13 Apr 2012 11:39:01 -0700 (PDT)
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 PpNOFHv2Tu27 for ; Fri, 13 Apr 2012 11:39:00 -0700 (PDT)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id DDACA11E8098 for ; Fri, 13 Apr 2012 11:39:00 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id CBCFB557F53 for ; Fri, 13 Apr 2012 11:39:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E76A32206C7; Fri, 13 Apr 2012 11:38:52 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from [192.240.4.46] (unknown [192.240.4.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C79A22206C4; Fri, 13 Apr 2012 11:38:52 -0700 (PDT)
References:  <22563.1334342114@marajade.sandelman.ca>
In-Reply-To: <22563.1334342114@marajade.sandelman.ca>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: 
X-Mailer: iPad Mail (9B176)
From: Thomas Heide Clausen 
Date: Fri, 13 Apr 2012 11:39:37 -0700
To: Michael Richardson 
Cc: "roll@ietf.org" 
Subject: Re: [Roll] RPL-P2P - status & update
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, 13 Apr 2012 18:39:01 -0000

Lovely, thanks Michael!

Thomas

--=20
Thomas Heide Clausen
http://www.thomasclausen.org/

"Any simple problem can be made insoluble if enough meetings are held to
 discuss it."
   -- Mitchell's Law of Committees


On 13 Apr 2012, at 11:35, Michael Richardson  wrote:

>=20
>>>>>> "Thomas" =3D=3D Thomas Heide Clausen  writes:=

>    Thomas> I've been trying to follow the many mails exchanged as a
>    Thomas> consequence of the WGLC of RPL-P2P.=20
>=20
> Yes, using a good threaded reader is a good idea.
> The IETF lists are also http://news.gmane.org/gmane.network.protocols.rpl
> and you can access it via nntp://news.gmane.org/gmane.network.protocols.rp=
l
> with a usenet newsreader.
>=20
>    Thomas> Given the volume of changes to the document, I would like to
>    Thomas> ask that - once the authors estimate that a version of the
>    Thomas> I-D folding in all proposed changes is ready - the WG be
>    Thomas> given another 1-2 weeks WGLC before bouncing it off to the
>    Thomas> ADs?=20
>=20
> I think that we will do this.
> Once a new draft is complete, I will remind the list with a link to the
> datatracker ID diff tool.
>=20
> You aren't the only one who wants to read all the changes again.
>=20
> --=20
> ]       He who is tired of Weird Al is tired of life!           |  firewal=
ls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net archi=
tect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dr=
iver[
>   Kyoto Plus: watch the video 
>                   then sign the petition.=20

From prvs=44399eb11=mukul@uwm.edu  Fri Apr 13 11:59:54 2012
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 7B67911E80A2 for ; Fri, 13 Apr 2012 11:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.32
X-Spam-Level: 
X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=0.279,  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 zaUnpfHKvCrZ for ; Fri, 13 Apr 2012 11:59:53 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id C316C11E8095 for ; Fri, 13 Apr 2012 11:59:53 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAFR3iE9/AAAB/2dsb2JhbABFhWayPwEBAQQBAQEgSwsMDxEEAQEDAg0ZAh4LKAgGExkBh3QLplGEQoUjiQmBL48QgRgEhwqBUI0SgRGLEIQVgwU
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 0C08F2B3F0A; Fri, 13 Apr 2012 13:59:53 -0500 (CDT)
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 Lzl-FvRd5H2H; Fri, 13 Apr 2012 13:59:52 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 9DA1F2B3F08; Fri, 13 Apr 2012 13:59:52 -0500 (CDT)
Date: Fri, 13 Apr 2012 13:59:52 -0500 (CDT)
From: Mukul Goyal 
To: Michael Richardson 
Message-ID: <954135049.21268.1334343592521.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <22563.1334342114@marajade.sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.91]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Cc: roll@ietf.org
Subject: Re: [Roll] RPL-P2P - status & update
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, 13 Apr 2012 18:59:54 -0000

>You aren't the only one who wants to read all the changes again.

I just wanted to mention that the changes are not that many or substantial in spite of the mailing list traffic we managed to generate. Most changes are basically textual clarifications.

Thanks
Mukul 

----- Original Message -----
From: "Michael Richardson" 
To: "Thomas Heide Clausen" 
Cc: roll@ietf.org
Sent: Friday, April 13, 2012 1:35:14 PM
Subject: Re: [Roll] RPL-P2P - status & update


>>>>> "Thomas" == Thomas Heide Clausen  writes:
    Thomas> I've been trying to follow the many mails exchanged as a
    Thomas> consequence of the WGLC of RPL-P2P. 

Yes, using a good threaded reader is a good idea.
The IETF lists are also http://news.gmane.org/gmane.network.protocols.rpl
and you can access it via nntp://news.gmane.org/gmane.network.protocols.rpl
with a usenet newsreader.

    Thomas> Given the volume of changes to the document, I would like to
    Thomas> ask that - once the authors estimate that a version of the
    Thomas> I-D folding in all proposed changes is ready - the WG be
    Thomas> given another 1-2 weeks WGLC before bouncing it off to the
    Thomas> ADs? 

I think that we will do this.
Once a new draft is complete, I will remind the list with a link to the
datatracker ID diff tool.

You aren't the only one who wants to read all the changes again.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
	               then sign the petition. 

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

From jpv@cisco.com  Fri Apr 13 12:05:02 2012
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 1DCF621F8646 for ; Fri, 13 Apr 2012 12:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.057
X-Spam-Level: 
X-Spam-Status: No, score=-110.057 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 jgOVOCuOA5K3 for ; Fri, 13 Apr 2012 12:05:01 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCE921F85E3 for ; Fri, 13 Apr 2012 12:05:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2898; q=dns/txt; s=iport; t=1334343901; x=1335553501; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=F+Opu3VCNqQwl61UfDOP7hfqrdIxaB7L7yFmM4wL8ao=; b=DXAKzEzigOwTsElNV+TcZjsWTk1PCLAYr/uHtmjJy77HrESNGJJfoXAY mCisPILUStaatXtdr3/nZ0FZ83bDUNwTN8+C3WeCBqJiLds5yG1QI2cBK QybSibJA5FpcoDmpLT/wxIUEGMDpg/PTJcFx919ccpynzhDP3krqLp64J k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApgFAEB4iE+Q/khR/2dsb2JhbABFgxyxeYEHggkBAQEDAQEBAQ8BWwsFCwsEAUEnMAYTCRmHZwULmUGffpB0YwSVbIVyiFuBaYJp
X-IronPort-AV: E=Sophos;i="4.75,418,1330905600";  d="scan'208,217";a="135125173"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2012 19:04:59 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3DJ4xvQ018448; Fri, 13 Apr 2012 19:04:59 GMT
Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 13 Apr 2012 21:04:59 +0200
Received: from [10.60.114.227] ([10.60.114.227]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Apr 2012 21:04:58 +0200
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2784EAF0-9C1A-4D14-BFA7-CEBBAE39A838"
From: JP Vasseur 
In-Reply-To: 
Date: Fri, 13 Apr 2012 21:03:21 +0200
Message-Id: 
References: 
To: Thomas Heide Clausen 
X-Mailer: Apple Mail (2.1257)
X-OriginalArrivalTime: 13 Apr 2012 19:04:58.0928 (UTC) FILETIME=[52484300:01CD19A8]
Cc: "roll@ietf.org" 
Subject: Re: [Roll] RPL-P2P - status & update
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, 13 Apr 2012 19:05:02 -0000

--Apple-Mail=_2784EAF0-9C1A-4D14-BFA7-CEBBAE39A838
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Thomas,

Absolutely, the plan was to run another incremental Last Call, on the =
new revision.

Cheers.

JP.

On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen wrote:

> Hello folks,
>=20
> I've been trying to follow the many mails exchanged as a consequence =
of the WGLC of RPL-P2P.
>=20
> Given the volume of changes to the document, I would like to ask that =
- once the authors estimate that a version of the I-D folding in all =
proposed changes is ready - the WG be given another 1-2 weeks WGLC =
before bouncing it off to the ADs?
>=20
> This just to ensure that the WG gets to give the final version a good =
review before seeing it off.
>=20
> Thoughts?
>=20
> Thomas
>=20
> --=20
> Thomas Heide Clausen
> http://www.thomasclausen.org/
>=20
> "Any simple problem can be made insoluble if enough meetings are held =
to
> discuss it."
>   -- Mitchell's Law of Committees
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


--Apple-Mail=_2784EAF0-9C1A-4D14-BFA7-CEBBAE39A838
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
Thomas,

Absolutely, the plan was to run another =
incremental Last Call, on the new =
revision.

Cheers.

JP.

On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen =
wrote:

Hello folks,

I've been trying to follow the =
many mails exchanged as a consequence of the WGLC of =
RPL-P2P.

Given the volume of changes to the document, I would =
like to ask that - once the authors estimate that a version of the I-D =
folding in all proposed changes is ready - the WG be given another 1-2 =
weeks WGLC before bouncing it off to the ADs?

This just to ensure =
that the WG gets to give the final version a good review before seeing =
it off.

Thoughts?

Thomas

-- 
Thomas Heide =
Clausen
http://www.thomasclausen.org/
"Any simple problem can be made insoluble if enough meetings are =
held to
 discuss it."
   -- Mitchell's Law of =
Committees

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

=

--Apple-Mail=_2784EAF0-9C1A-4D14-BFA7-CEBBAE39A838--

From jpv@cisco.com  Fri Apr 13 14:18:25 2012
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 D7D8B21F864F for ; Fri, 13 Apr 2012 14:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.237
X-Spam-Level: 
X-Spam-Status: No, score=-110.237 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 hL2o6Z6Kk5kf for ; Fri, 13 Apr 2012 14:18:25 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C09AD21F864E for ; Fri, 13 Apr 2012 14:18:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4429; q=dns/txt; s=iport; t=1334351904; x=1335561504; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=ChFeKT2nQ9L50AuuEcFzuKCwcJ54hWY6dQTw7yh2Lg0=; b=kLljqBbLq9eY7w3ikKZxrquZDUBV+NuoPRXa1rkth1iReo9ygZ7DpzPq wSfr+DII3hmTTrL05BK2l/IOhI7lerwNKyZAxGC3/G2yF3s3N6EXoelZB v1MDJZwKNGasbcLSVlcb3e+hMrTC+9PuO3FQZNEwHkDjwCj+A5n6pwwbd o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AokGAAWXiE+Q/khR/2dsb2JhbABFgxyxe4EHggkBAQEDAQEBAQ8BWwsFCwsEFC4nMAYTCRmHZwULmUOfeZBmYwSVbIVyiFuBaYJp
X-IronPort-AV: E=Sophos;i="4.75,419,1330905600";  d="scan'208,217";a="135131569"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2012 21:18:23 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3DLINMw008852; Fri, 13 Apr 2012 21:18:23 GMT
Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 13 Apr 2012 23:18:23 +0200
Received: from [10.60.114.227] ([10.60.114.227]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Apr 2012 23:18:23 +0200
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_12A7070D-8142-4030-AA87-3E22250A8C9A"
From: JP Vasseur 
In-Reply-To: 
Date: Fri, 13 Apr 2012 23:16:54 +0200
Message-Id: 
References:  
To: Thomas Heide Clausen 
X-Mailer: Apple Mail (2.1257)
X-OriginalArrivalTime: 13 Apr 2012 21:18:23.0323 (UTC) FILETIME=[F54602B0:01CD19BA]
Cc: "roll@ietf.org WG" 
Subject: Re: [Roll] RPL-P2P - status & update
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, 13 Apr 2012 21:18:26 -0000

--Apple-Mail=_12A7070D-8142-4030-AA87-3E22250A8C9A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi Thomas,

Clarifying a bit more =85 what I meant =85

Plan is:
* Close on the last open ticket
* Authors will post a new revision of the document, possibly =
highlighting the changes
* Issue another WG LC to make sure that the WG is comfortable with the =
new revision

Thanks, have a good week-end.

JP.

On Apr 13, 2012, at 9:03 PM, JP Vasseur wrote:

> Hi Thomas,
>=20
> Absolutely, the plan was to run another incremental Last Call, on the =
new revision.
>=20
> Cheers.
>=20
> JP.
>=20
> On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen wrote:
>=20
>> Hello folks,
>>=20
>> I've been trying to follow the many mails exchanged as a consequence =
of the WGLC of RPL-P2P.
>>=20
>> Given the volume of changes to the document, I would like to ask that =
- once the authors estimate that a version of the I-D folding in all =
proposed changes is ready - the WG be given another 1-2 weeks WGLC =
before bouncing it off to the ADs?
>>=20
>> This just to ensure that the WG gets to give the final version a good =
review before seeing it off.
>>=20
>> Thoughts?
>>=20
>> Thomas
>>=20
>> --=20
>> Thomas Heide Clausen
>> http://www.thomasclausen.org/
>>=20
>> "Any simple problem can be made insoluble if enough meetings are held =
to
>> discuss it."
>>   -- Mitchell's Law of Committees
>>=20
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


--Apple-Mail=_12A7070D-8142-4030-AA87-3E22250A8C9A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Hi =
Thomas,

Clarifying a bit more =85 what I meant =
=85

Plan is:
* Close on the last open =
ticket
* Authors will post a new revision of the document, =
possibly highlighting the changes
* Issue another WG LC to =
make sure that the WG is comfortable with the new =
revision

Thanks, have a good =
week-end.

JP.

On Apr =
13, 2012, at 9:03 PM, JP Vasseur wrote:

Hi =
Thomas,

Absolutely, the plan was to run another =
incremental Last Call, on the new =
revision.

Cheers.

JP.

On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen =
wrote:

Hello folks,

I've been trying to follow the =
many mails exchanged as a consequence of the WGLC of =
RPL-P2P.

Given the volume of changes to the document, I would =
like to ask that - once the authors estimate that a version of the I-D =
folding in all proposed changes is ready - the WG be given another 1-2 =
weeks WGLC before bouncing it off to the ADs?

This just to ensure =
that the WG gets to give the final version a good review before seeing =
it off.

Thoughts?

Thomas

-- 
Thomas Heide =
Clausen
http://www.thomasclausen.org/
"Any simple problem can be made insoluble if enough meetings are =
held to
 discuss it."
   -- Mitchell's Law of =
Committees

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

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

=

--Apple-Mail=_12A7070D-8142-4030-AA87-3E22250A8C9A--

From ietf@thomasclausen.org  Fri Apr 13 14:21:03 2012
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 7AE3F21F86EA for ; Fri, 13 Apr 2012 14:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level: 
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=0.698,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SMK9mSUabA9Z for ; Fri, 13 Apr 2012 14:21:02 -0700 (PDT)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id DD9A421F86C5 for ; Fri, 13 Apr 2012 14:21:02 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C12EA558070 for ; Fri, 13 Apr 2012 14:21:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 9F79D24155B; Fri, 13 Apr 2012 14:21:02 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from [192.240.4.49] (unknown [192.240.4.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 2257C24155A; Fri, 13 Apr 2012 14:21:02 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_4BB68997-850D-4568-A3D5-71C9483C98B8"
From: Thomas Heide Clausen 
In-Reply-To: 
Date: Fri, 13 Apr 2012 14:21:00 -0700
Message-Id: <9850315F-B3E6-4A29-AAD5-B53E6C978F69@thomasclausen.org>
References:   
To: JP Vasseur 
X-Mailer: Apple Mail (2.1257)
Cc: "roll@ietf.org WG" 
Subject: Re: [Roll] RPL-P2P - status & update
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, 13 Apr 2012 21:21:03 -0000

--Apple-Mail=_4BB68997-850D-4568-A3D5-71C9483C98B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Dear JP,

Sounds quite reasonable.

Have a pleasant weekend you too - I will be spending mine recovering =
from week-long meetings in the bay area...

Best,

Thomas

On Apr 13, 2012, at 14:16 , JP Vasseur wrote:

> Hi Thomas,
>=20
> Clarifying a bit more =85 what I meant =85
>=20
> Plan is:
> * Close on the last open ticket
> * Authors will post a new revision of the document, possibly =
highlighting the changes
> * Issue another WG LC to make sure that the WG is comfortable with the =
new revision
>=20
> Thanks, have a good week-end.
>=20
> JP.
>=20
> On Apr 13, 2012, at 9:03 PM, JP Vasseur wrote:
>=20
>> Hi Thomas,
>>=20
>> Absolutely, the plan was to run another incremental Last Call, on the =
new revision.
>>=20
>> Cheers.
>>=20
>> JP.
>>=20
>> On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen wrote:
>>=20
>>> Hello folks,
>>>=20
>>> I've been trying to follow the many mails exchanged as a consequence =
of the WGLC of RPL-P2P.
>>>=20
>>> Given the volume of changes to the document, I would like to ask =
that - once the authors estimate that a version of the I-D folding in =
all proposed changes is ready - the WG be given another 1-2 weeks WGLC =
before bouncing it off to the ADs?
>>>=20
>>> This just to ensure that the WG gets to give the final version a =
good review before seeing it off.
>>>=20
>>> Thoughts?
>>>=20
>>> Thomas
>>>=20
>>> --=20
>>> Thomas Heide Clausen
>>> http://www.thomasclausen.org/
>>>=20
>>> "Any simple problem can be made insoluble if enough meetings are =
held to
>>> discuss it."
>>>   -- Mitchell's Law of Committees
>>>=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
>=20


--Apple-Mail=_4BB68997-850D-4568-A3D5-71C9483C98B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Dear =
JP,

Sounds quite =
reasonable.

Have a pleasant weekend you too - I =
will be spending mine recovering from week-long meetings in the bay =
area...

Best,

Thomas

On Apr 13, 2012, at 14:16 , JP Vasseur =
wrote:

Hi =
Thomas,

Clarifying a bit more =85 what I meant =
=85

Plan is:
* Close on the last open =
ticket
* Authors will post a new revision of the document, =
possibly highlighting the changes
* Issue another WG LC to =
make sure that the WG is comfortable with the new =
revision

Thanks, have a good =
week-end.

JP.

On Apr =
13, 2012, at 9:03 PM, JP Vasseur wrote:

Hi =
Thomas,

Absolutely, the plan was to run another =
incremental Last Call, on the new =
revision.

Cheers.

JP.

On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen =
wrote:

Hello folks,

I've been trying to follow the =
many mails exchanged as a consequence of the WGLC of =
RPL-P2P.

Given the volume of changes to the document, I would =
like to ask that - once the authors estimate that a version of the I-D =
folding in all proposed changes is ready - the WG be given another 1-2 =
weeks WGLC before bouncing it off to the ADs?

This just to ensure =
that the WG gets to give the final version a good review before seeing =
it off.

Thoughts?

Thomas

-- 
Thomas Heide =
Clausen
http://www.thomasclausen.org/
"Any simple problem can be made insoluble if enough meetings are =
held to
 discuss it."
   -- Mitchell's Law of =
Committees

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

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


=

--Apple-Mail=_4BB68997-850D-4568-A3D5-71C9483C98B8--

From pthubert@cisco.com  Sat Apr 14 02:53:38 2012
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 ED6FD21F8618 for ; Sat, 14 Apr 2012 02:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.178
X-Spam-Level: 
X-Spam-Status: No, score=-10.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNCmaWWagrne for ; Sat, 14 Apr 2012 02:53:38 -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 F145221F84B2 for ; Sat, 14 Apr 2012 02:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2911; q=dns/txt; s=iport; t=1334397218; x=1335606818; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ekH0+MXMakR3y/YaybVe+sF3CnYMLHBjhlbxxbFq96I=; b=LRkO6Q/Y35cmPzlGLELePQnxS61g0aqZkKC5qLmwW5rJNlv+br539EnF vugdSxCNcnirb7vE0lZlvMTQ5mjE6CO9tpkdXFg1viJagpo3QAfMbVLTW fTByNqG/efSAnH4xBvuJor+X4I3//rot87i09J1GNti5jaZRoUa3OALOP s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAJ9IiU+Q/khL/2dsb2JhbABEDrUIgQeCCQEBAQQBAQEPAR0KNAsMBAIBCBEEAQELBhcBBgEbCx8JCAEBBAESCBEBCIdsC54zkVSGLZBmYwSHCo90iw+CLIFpgjA5
X-IronPort-AV: E=Sophos;i="4.75,422,1330905600"; d="scan'208";a="70849027"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 14 Apr 2012 09:53:36 +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 q3E9rawI022778; Sat, 14 Apr 2012 09:53:36 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);  Sat, 14 Apr 2012 11:53:36 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 14 Apr 2012 11:52:33 +0200
Message-ID: 
In-Reply-To: <954135049.21268.1334343592521.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] RPL-P2P - status & update
Thread-Index: Ac0Zp5/JTQOLl9S0Se6B1CUwsfpCHQAe84GQ
References: <22563.1334342114@marajade.sandelman.ca> <954135049.21268.1334343592521.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" , "Michael Richardson" 
X-OriginalArrivalTime: 14 Apr 2012 09:53:36.0703 (UTC) FILETIME=[762714F0:01CD1A24]
Cc: roll@ietf.org
Subject: Re: [Roll] RPL-P2P - status & update
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, 14 Apr 2012 09:53:39 -0000

Hi:

For the changes I suggested, I certainly agree with Mukul.=20

Those changes provide crisper definitions and clearer limitations, but
mostly should not impact an existing implementation - unless an
implementation already used the upper layer data delivery in which case
a few lines of code might need to be changed.=20

Like others I wish to review the final text, in particular for the
things related to upper layer protocols. But the routing piece which is
core appeared sound already in the WLC version of the doc.

Cheers,

Pascal


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Mukul Goyal
Sent: vendredi 13 avril 2012 21:00
To: Michael Richardson
Cc: roll@ietf.org
Subject: Re: [Roll] RPL-P2P - status & update

>You aren't the only one who wants to read all the changes again.

I just wanted to mention that the changes are not that many or
substantial in spite of the mailing list traffic we managed to generate.
Most changes are basically textual clarifications.

Thanks
Mukul=20

----- Original Message -----
From: "Michael Richardson" 
To: "Thomas Heide Clausen" 
Cc: roll@ietf.org
Sent: Friday, April 13, 2012 1:35:14 PM
Subject: Re: [Roll] RPL-P2P - status & update


>>>>> "Thomas" =3D=3D Thomas Heide Clausen  =
writes:
    Thomas> I've been trying to follow the many mails exchanged as a
    Thomas> consequence of the WGLC of RPL-P2P.=20

Yes, using a good threaded reader is a good idea.
The IETF lists are also
http://news.gmane.org/gmane.network.protocols.rpl
and you can access it via
nntp://news.gmane.org/gmane.network.protocols.rpl
with a usenet newsreader.

    Thomas> Given the volume of changes to the document, I would like to
    Thomas> ask that - once the authors estimate that a version of the
    Thomas> I-D folding in all proposed changes is ready - the WG be
    Thomas> given another 1-2 weeks WGLC before bouncing it off to the
    Thomas> ADs?=20

I think that we will do this.
Once a new draft is complete, I will remind the list with a link to the
datatracker ID diff tool.

You aren't the only one who wants to read all the changes again.

--=20
]       He who is tired of Weird Al is tired of life!           |
firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
driver[
   Kyoto Plus: watch the video

	               then sign the petition.=20

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

From prvs=446f555b9=mukul@uwm.edu  Mon Apr 16 07:59:41 2012
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 8B51D21F85F7 for ; Mon, 16 Apr 2012 07:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.433
X-Spam-Level: 
X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 xuxXYYG-yoQt for ; Mon, 16 Apr 2012 07:59:40 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id BACED21F85BB for ; Mon, 16 Apr 2012 07:59:39 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EABUzjE9/AAAB/2dsb2JhbABDhXKwYQEBAQQBAQEgSwQHDA8RBAEBAwINGQIpKAgGE4gOC6pyiSCBHQSBL4oEhH6BGASIWo0TkDWDBYE2ARY
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id C069212E3BF; Mon, 16 Apr 2012 09:59:38 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu
Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpVGqG7q8dxt; Mon, 16 Apr 2012 09:59:38 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 20FE312E3C0; Mon, 16 Apr 2012 09:59:38 -0500 (CDT)
Date: Mon, 16 Apr 2012 09:59:38 -0500 (CDT)
From: Mukul Goyal 
To: JP Vasseur 
Message-ID: <843656433.9245.1334588377995.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <723690941.1887908.1334112685750.JavaMail.root@mail17.pantherlink.uwm.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - [unknown] (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Cc: roll , Michael Richardson 
Subject: Re: [Roll] Closure text for ticket #86
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, 16 Apr 2012 14:59:41 -0000

Hi all

On further thoughts, I think we should defer for the time being using G bit to indicate route discovery priority. There is no real usecase for this at the moment. We can reconsider adding this functionality when we go standards track. So, I propose modifying the resolution text to the following:

"The origin always sets the G flag to one. Unlike a global RPL instance, the concept of a floating DAG, used to provide connectivity within a sub-DAG detached from a grounded DAG, does not apply to a local RPL instance. Hence, an origin MUST always set the G flag to one when initiating a P2P-RPL route discovery. Further, a node MUST NOT initiate a new DAG (with G flag set to zero) if it does not have any parent left in a P2P-RPL DAG."

Thanks
Mukul

----- Original Message -----
From: "Mukul Goyal" 
To: "JP Vasseur" 
Cc: "roll" , "Michael Richardson" 
Sent: Tuesday, April 10, 2012 9:51:25 PM
Subject: [Roll] Closure text for ticket #86

#86: G flag: do we need that text?

Problem
------------------------------
 Disagreement on the meaning of 'G' bit and imposed setting to 0;

Proposed resolution
---------------------------
Add the following text to the draft:

"The origin sets the G flag to indicate the relative importance of the route discovery it is initiating. The G flag is set to one if this particular route discovery is more important from application's perspective than some other route discovery. In other words, the origin sets the G flag to one if this particular route discovery helps meet the application defined goal \cite{rpl}. Thus, the G flag setting helps an intermediate router choose which route discoveries to participate in if it cannot participate in all route discoveries. An intermediate router SHOULD participate in route discoveries with G flag set to one (in preference to ones with G flag set to zero)."

Discussion:
-----------------

 [Pascal]
 " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in
 nature, is created solely for the purpose of P2P-RPL route discovery and
 MUST NOT be used for packet routing."

 On the contrary I'd set it to 1. The goal -being to reach the origin- is
 actually achieved by this DAG.

 [Mukul]
 Actually, the DAG is temporary in nature and vanishes after a short
 while. Even when it exists, it must/should not be used for routing
 packets back to the origin. So, I think the Grounded flag should be
 zero.

 [Pascal2] Please revisit RFC 6650 page 12.
 G means that a goal is achieved. So first you define the goal and then
 the bit becomes obvious. What's your goal?
 Can there be P2P DAGs that achieve the goal and others that make sense
 to build and yet do not achieve the goal?
 If you accept that your operation can actually depend on OF logic, then
 the setting of the goal influences that logic.
 By forcing a value to the goal in the PTP spec, we actually limit the
 applicability of the draft.
 Maybe you can define a default goal and a default setting. But do not
 MUST that it is set to 0...

 [Mukul2]
 When a node joins a temporary P2P DAG, it does not get any additional
 routing information. The DAG is going to disappear after some time,
 should not be used for routing while it exists and which nodes end up
 being on the discovered route is not known until the DRO message comes
 back. So, I think, by default, the G flag has to be zero. However, if
 the setting of G flag may affect how an intermediate node may calculate
 its rank (as per the OF being used), the origin should have the
 flexibility of setting the flag to 1. So, I could modify the text to say
 that "the origin sets the G flag based on its perception of how the
 flag's value would affect the rank calculation under the OF being used.
 By default, the G flag is set to zero given the temporary nature of the
 DAG being created."

 [Pascal3] Why do you feel the need to add anything above what RFC 6550
 says? I do not see any benefit or additional clarity from doing this.

 [Mukul3] RFC 6550 is actually kind of confusing in this regard. On page
 9, it says

 "A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data)."

 This seems to associate the goal with both OF and reachability to
 certain hosts. Later invocations of the term "goal" seem to refer just
 to the connectivity aspect, e.g., on page 18 RFC 6550 says

 "A grounded DODAG offers connectivity to hosts that are
   required for satisfying the application-defined goal."

 So, my understanding so far was that the "goal" defines connectivity to
 a certain hosts. The relation to objective function is not clear at all
 (if one restricts oneself to reading RFC 6550). The temporary DAGs
 created in P2P-RPL route discovery provide no connectivity whatsoever to
 the joining nodes. So, the only reason to set the G flag to 1 would be
 to allow correct use of an OF. So, I think P2P-RPL spec should use the
 text I offered above (and repeat below):

 "The origin sets the G flag based on its perception of whether joining
 how the flag's value would affect the rank calculation under the OF
 being used. By default, the G flag is set to zero given the temporary
 nature of the DAG being created."

 What do you think?

 [Pascal4] If you think this adds value, I will not oppose. Let's keep
 that as the proposed resolution

 [Mukul4] Sounds good.

Proposed resolution text:

"The origin sets the G flag based on its perception of whether joining
 how the flag's value would affect the rank calculation under the OF
 being used. By default, the G flag is set to zero given the temporary
 nature of the DAG being created."

[Richard5]
I disagree with the proposed resolution.  It adds needless confusion.
The G flag is 0 if and only if the DODAG is floating.
There is no point to allowing floating DODAGs with a P2P-RDO option.  I suggest that the G bit be set to 1 and that routers be explicitly prohibited from creating floating DODAGs with a P2P-RDO option.

[Mukul5]
>The G flag is 0 if and only if the DODAG is floating.

I think that the G flag is 1 if and only if the DODAG is grounded. The temporary DAGs used in P2P-RPL are not grounded, they are temporary. I think that all transient/temporary DAGs are floating by their very nature.

[Michael5]
> I think we need to determine what a grounded DODAG is.
> Does it mean that a node announcing such a thing is attached to the Internet? (In which case P2P usage should G=0)
> Or does it mean that a node is attached to the resource named in the DIO? (In which case origin P2P should G=1)
> 

[Phillip5]
The text in 6550 is pretty clear: 

   Goal: The Goal is an application-specific goal that is defined
         outside the scope of RPL.  Any node that roots a DODAG will
         need to know about this Goal to decide whether or not the Goal
         can be satisfied.  A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data).

   Grounded: A DODAG is grounded when the DODAG root can satisfy the
         Goal.

   Floating: A DODAG is floating if it is not grounded.  A floating
         DODAG is not expected to have the properties required to
         satisfy the goal.  It may, however, provide connectivity to
         other nodes within the DODAG.

The common case of the Goal is "has connectivity to the Internet" but that's not the only case. I think given the Goal for P2P traffic, I agree with Pascal and Richard that it should be 1.


[Pascal6]
Floating vs. Grounded depends on the goal of the DODAG. I asked you and will ask again what is your goal?
If the goal is to reach the root, then G is 1... If you want to signal something to the OF using the G bit, leave it  open.

[Mukul6]
>If the goal is to reach the root, then G is 1...

I have told you multiple times that joining a P2P-RPL DAG does not give any sort of connectivity to the node.

[Pascal7]
I think we disagree because of the definition of goal itself. The goal is an abstraction. Same goes for the term Objective in OF. RFC 6550 only gives examples of what G could be used for but that is not limiting. Certainly the abstraction may for instance mean that external nodes are reachable via the root. But it could be something else entirely. For instance it could designate a root that can aggregate data.

In practice, G is used to favor a root that reaches the goal vs. one that does not. But that's senseless for local instances that have by definition a single root.

So whatever you set it to does not make a difference for RFC 6550 operations. I figure it could be used for signaling a "transient goal" information to an OF that could use it for a purpose I can't fathom.

In any case, as I suggested earlier and as Richard also suggest now, G SHOULD probably be 1 by default but MAY be set otherwise.

[Mukul7]
Richard wants the flag to always be either 0 or 1. He prefers it to be always 1 but would settle for it being always zero.

I think this is not a critical point. I am OK with whatever resolution you and Richard arrive at. Kindly provide me the resolution text I should put in the draft.

[Pascal8]
I suggest a sentence that says that:

1) For a local instance there can be only one root and one DODAG. G bit cannot and is not used for DODAG selection within an instance. 
2) In a given deployment, a goal can be defined that some P2P DODAGs achieve and others do not. The roots that achieve that goal will set the G bit in their P2P DAGs.
3) the default goal is to create connectivity between origin and target. So by default G should be set to 1.
4) if an intermediate router does not have enough resources to participate to all DODAGs then it should favor DODAGs with the G bit on.

The exact wording is yours...

[Mukul8]
>1) For a local instance there can be only one root and one DODAG. G bit cannot and is not used for DODAG selection within an instance. 

The statement above seems to be at odds with following two statements

>2) In a given deployment, a goal can be defined that some P2P DODAGs achieve and others do not. The roots that achieve that goal will set the G bit in their P2P DAGs.
3) the default goal is to create connectivity between origin and target. So by default G should be set to 1.

As per statement 1, the G flag can never be 1 for P2P-RPL DAGs because they use local instance ids.
As per statement 2/3, the G flag could be 1 and is 1 by default.

I am OK with setting G flag to 1 always (as you, Richard and Phil seem to prefer) but I dont know how to reason this. Do we need to provide a reason at all?

[Pascal9]
Statement 1 does not say that at all. Can't fathom how you concluded that... Let me try to reword: There is only what DODAG for a given local instance so there cannot be a selection => G cannot be used for a selection that cannot happen.

>As per statement 2/3, the G flag could be 1 and is 1 by default.

Yes. I added an item to help the device prioritize when it is asker to participate to many DODAGs (for many P2P flows that it happens to be on the path of). In that case, and if the device cannot particpater to all the P2P DODAGs, then the G bit could be use to decide which are the most important. 

If you define a default goal that the DODAG fills, then you set G to one. For instance, G could mean 'important stuff' like swithing a light on. You'd set it for switching lights but not for reporting the hygrometry of your orchids, which anyway will be retried in a half hour. As a result, if the 2 DAG formations collide, the light on will have precedence...

[Mukul9]
How about the following text:

"The origin sets the G flag to indicate the relative importance of the route discovery it is initiating. The G flag is set to one if this particular route discovery is more important from application's perspective than some other route discovery. In other words, the origin sets the G flag to one if this particular route discovery helps meet the application defined goal \cite{rpl}. Thus, the G flag setting helps an intermediate router choose which route discoveries to participate in if it cannot participate in all route discoveries. An intermediate router SHOULD participate in route discoveries with G flag set to one (in preference to ones with G flag set to zero)."

[Pascal10]
As far as I'm concerned you've captured it and I'm happy with this text.

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

From pthubert@cisco.com  Mon Apr 16 09:41:44 2012
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 5B05511E80AB for ; Mon, 16 Apr 2012 09:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.109
X-Spam-Level: 
X-Spam-Status: No, score=-9.109 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 lLViH1fLg0ze for ; Mon, 16 Apr 2012 09:41:42 -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 C127A11E80AC for ; Mon, 16 Apr 2012 09:41:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=13627; q=dns/txt; s=iport; t=1334594502; x=1335804102; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=VxAyiXb4Tp+8QFvyBcml/ezX5fAdwiMMwpqB/RCkB0g=; b=IkDBiS6QeXuRJXExHkQVxlkZCPBEWWkrwemhD8zUw61iJY3G6QC6E/s3 mg/63CABpE5p2axVMofE+dKDjEhs6B0UCAq/zA1kzNLT+02t0k4OVKbiN yvnDpqvFx7/JvBDHipSSQ+dtlxVGt4H9BjDcI8KPQ0fluJtWz8ygbwlsE U=;
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="70994592"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 16 Apr 2012 16:41:40 +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 q3GGfesX020734; Mon, 16 Apr 2012 16:41:40 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);  Mon, 16 Apr 2012 18:41:41 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 16 Apr 2012 18:40:28 +0200
Message-ID: 
In-Reply-To: <843656433.9245.1334588377995.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Closure text for ticket #86
Thread-Index: Ac0b4ZH+VZhhrl3ETEyd9i3UrqArCAADgGqw
References: <723690941.1887908.1334112685750.JavaMail.root@mail17.pantherlink.uwm.edu> <843656433.9245.1334588377995.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" 
To: "Mukul Goyal" , "JP Vasseur" 
X-OriginalArrivalTime: 16 Apr 2012 16:41:41.0223 (UTC) FILETIME=[CCE3D770:01CD1BEF]
Cc: roll , Michael Richardson 
Subject: Re: [Roll] Closure text for ticket #86
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, 16 Apr 2012 16:41:44 -0000

I'm fine with that...

Thanks for the hard work, Mukul;

Pascal


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Mukul Goyal
Sent: lundi 16 avril 2012 17:00
To: JP Vasseur
Cc: roll; Michael Richardson
Subject: Re: [Roll] Closure text for ticket #86

Hi all

On further thoughts, I think we should defer for the time being using G
bit to indicate route discovery priority. There is no real usecase for
this at the moment. We can reconsider adding this functionality when we
go standards track. So, I propose modifying the resolution text to the
following:

"The origin always sets the G flag to one. Unlike a global RPL instance,
the concept of a floating DAG, used to provide connectivity within a
sub-DAG detached from a grounded DAG, does not apply to a local RPL
instance. Hence, an origin MUST always set the G flag to one when
initiating a P2P-RPL route discovery. Further, a node MUST NOT initiate
a new DAG (with G flag set to zero) if it does not have any parent left
in a P2P-RPL DAG."

Thanks
Mukul

----- Original Message -----
From: "Mukul Goyal" 
To: "JP Vasseur" 
Cc: "roll" , "Michael Richardson" 
Sent: Tuesday, April 10, 2012 9:51:25 PM
Subject: [Roll] Closure text for ticket #86

#86: G flag: do we need that text?

Problem
------------------------------
 Disagreement on the meaning of 'G' bit and imposed setting to 0;

Proposed resolution
---------------------------
Add the following text to the draft:

"The origin sets the G flag to indicate the relative importance of the
route discovery it is initiating. The G flag is set to one if this
particular route discovery is more important from application's
perspective than some other route discovery. In other words, the origin
sets the G flag to one if this particular route discovery helps meet the
application defined goal \cite{rpl}. Thus, the G flag setting helps an
intermediate router choose which route discoveries to participate in if
it cannot participate in all route discoveries. An intermediate router
SHOULD participate in route discoveries with G flag set to one (in
preference to ones with G flag set to zero)."

Discussion:
-----------------

 [Pascal]
 " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in
nature, is created solely for the purpose of P2P-RPL route discovery and
MUST NOT be used for packet routing."

 On the contrary I'd set it to 1. The goal -being to reach the origin-
is  actually achieved by this DAG.

 [Mukul]
 Actually, the DAG is temporary in nature and vanishes after a short
while. Even when it exists, it must/should not be used for routing
packets back to the origin. So, I think the Grounded flag should be
zero.

 [Pascal2] Please revisit RFC 6650 page 12.
 G means that a goal is achieved. So first you define the goal and then
the bit becomes obvious. What's your goal?
 Can there be P2P DAGs that achieve the goal and others that make sense
to build and yet do not achieve the goal?
 If you accept that your operation can actually depend on OF logic, then
the setting of the goal influences that logic.
 By forcing a value to the goal in the PTP spec, we actually limit the
applicability of the draft.
 Maybe you can define a default goal and a default setting. But do not
MUST that it is set to 0...

 [Mukul2]
 When a node joins a temporary P2P DAG, it does not get any additional
routing information. The DAG is going to disappear after some time,
should not be used for routing while it exists and which nodes end up
being on the discovered route is not known until the DRO message comes
back. So, I think, by default, the G flag has to be zero. However, if
the setting of G flag may affect how an intermediate node may calculate
its rank (as per the OF being used), the origin should have the
flexibility of setting the flag to 1. So, I could modify the text to say
that "the origin sets the G flag based on its perception of how the
flag's value would affect the rank calculation under the OF being used.
 By default, the G flag is set to zero given the temporary nature of the
DAG being created."

 [Pascal3] Why do you feel the need to add anything above what RFC 6550
says? I do not see any benefit or additional clarity from doing this.

 [Mukul3] RFC 6550 is actually kind of confusing in this regard. On page
9, it says

 "A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data)."

 This seems to associate the goal with both OF and reachability to
certain hosts. Later invocations of the term "goal" seem to refer just
to the connectivity aspect, e.g., on page 18 RFC 6550 says

 "A grounded DODAG offers connectivity to hosts that are
   required for satisfying the application-defined goal."

 So, my understanding so far was that the "goal" defines connectivity to
a certain hosts. The relation to objective function is not clear at all
(if one restricts oneself to reading RFC 6550). The temporary DAGs
created in P2P-RPL route discovery provide no connectivity whatsoever to
the joining nodes. So, the only reason to set the G flag to 1 would be
to allow correct use of an OF. So, I think P2P-RPL spec should use the
text I offered above (and repeat below):

 "The origin sets the G flag based on its perception of whether joining
how the flag's value would affect the rank calculation under the OF
being used. By default, the G flag is set to zero given the temporary
nature of the DAG being created."

 What do you think?

 [Pascal4] If you think this adds value, I will not oppose. Let's keep
that as the proposed resolution

 [Mukul4] Sounds good.

Proposed resolution text:

"The origin sets the G flag based on its perception of whether joining
how the flag's value would affect the rank calculation under the OF
being used. By default, the G flag is set to zero given the temporary
nature of the DAG being created."

[Richard5]
I disagree with the proposed resolution.  It adds needless confusion.
The G flag is 0 if and only if the DODAG is floating.
There is no point to allowing floating DODAGs with a P2P-RDO option.  I
suggest that the G bit be set to 1 and that routers be explicitly
prohibited from creating floating DODAGs with a P2P-RDO option.

[Mukul5]
>The G flag is 0 if and only if the DODAG is floating.

I think that the G flag is 1 if and only if the DODAG is grounded. The
temporary DAGs used in P2P-RPL are not grounded, they are temporary. I
think that all transient/temporary DAGs are floating by their very
nature.

[Michael5]
> I think we need to determine what a grounded DODAG is.
> Does it mean that a node announcing such a thing is attached to the=20
> Internet? (In which case P2P usage should G=3D0) Or does it mean that =
a=20
> node is attached to the resource named in the DIO? (In which case=20
> origin P2P should G=3D1)
>=20

[Phillip5]
The text in 6550 is pretty clear:=20

   Goal: The Goal is an application-specific goal that is defined
         outside the scope of RPL.  Any node that roots a DODAG will
         need to know about this Goal to decide whether or not the Goal
         can be satisfied.  A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data).

   Grounded: A DODAG is grounded when the DODAG root can satisfy the
         Goal.

   Floating: A DODAG is floating if it is not grounded.  A floating
         DODAG is not expected to have the properties required to
         satisfy the goal.  It may, however, provide connectivity to
         other nodes within the DODAG.

The common case of the Goal is "has connectivity to the Internet" but
that's not the only case. I think given the Goal for P2P traffic, I
agree with Pascal and Richard that it should be 1.


[Pascal6]
Floating vs. Grounded depends on the goal of the DODAG. I asked you and
will ask again what is your goal?
If the goal is to reach the root, then G is 1... If you want to signal
something to the OF using the G bit, leave it  open.

[Mukul6]
>If the goal is to reach the root, then G is 1...

I have told you multiple times that joining a P2P-RPL DAG does not give
any sort of connectivity to the node.

[Pascal7]
I think we disagree because of the definition of goal itself. The goal
is an abstraction. Same goes for the term Objective in OF. RFC 6550 only
gives examples of what G could be used for but that is not limiting.
Certainly the abstraction may for instance mean that external nodes are
reachable via the root. But it could be something else entirely. For
instance it could designate a root that can aggregate data.

In practice, G is used to favor a root that reaches the goal vs. one
that does not. But that's senseless for local instances that have by
definition a single root.

So whatever you set it to does not make a difference for RFC 6550
operations. I figure it could be used for signaling a "transient goal"
information to an OF that could use it for a purpose I can't fathom.

In any case, as I suggested earlier and as Richard also suggest now, G
SHOULD probably be 1 by default but MAY be set otherwise.

[Mukul7]
Richard wants the flag to always be either 0 or 1. He prefers it to be
always 1 but would settle for it being always zero.

I think this is not a critical point. I am OK with whatever resolution
you and Richard arrive at. Kindly provide me the resolution text I
should put in the draft.

[Pascal8]
I suggest a sentence that says that:

1) For a local instance there can be only one root and one DODAG. G bit
cannot and is not used for DODAG selection within an instance.=20
2) In a given deployment, a goal can be defined that some P2P DODAGs
achieve and others do not. The roots that achieve that goal will set the
G bit in their P2P DAGs.
3) the default goal is to create connectivity between origin and target.
So by default G should be set to 1.
4) if an intermediate router does not have enough resources to
participate to all DODAGs then it should favor DODAGs with the G bit on.

The exact wording is yours...

[Mukul8]
>1) For a local instance there can be only one root and one DODAG. G bit
cannot and is not used for DODAG selection within an instance.=20

The statement above seems to be at odds with following two statements

>2) In a given deployment, a goal can be defined that some P2P DODAGs
achieve and others do not. The roots that achieve that goal will set the
G bit in their P2P DAGs.
3) the default goal is to create connectivity between origin and target.
So by default G should be set to 1.

As per statement 1, the G flag can never be 1 for P2P-RPL DAGs because
they use local instance ids.
As per statement 2/3, the G flag could be 1 and is 1 by default.

I am OK with setting G flag to 1 always (as you, Richard and Phil seem
to prefer) but I dont know how to reason this. Do we need to provide a
reason at all?

[Pascal9]
Statement 1 does not say that at all. Can't fathom how you concluded
that... Let me try to reword: There is only what DODAG for a given local
instance so there cannot be a selection =3D> G cannot be used for a
selection that cannot happen.

>As per statement 2/3, the G flag could be 1 and is 1 by default.

Yes. I added an item to help the device prioritize when it is asker to
participate to many DODAGs (for many P2P flows that it happens to be on
the path of). In that case, and if the device cannot particpater to all
the P2P DODAGs, then the G bit could be use to decide which are the most
important.=20

If you define a default goal that the DODAG fills, then you set G to
one. For instance, G could mean 'important stuff' like swithing a light
on. You'd set it for switching lights but not for reporting the
hygrometry of your orchids, which anyway will be retried in a half hour.
As a result, if the 2 DAG formations collide, the light on will have
precedence...

[Mukul9]
How about the following text:

"The origin sets the G flag to indicate the relative importance of the
route discovery it is initiating. The G flag is set to one if this
particular route discovery is more important from application's
perspective than some other route discovery. In other words, the origin
sets the G flag to one if this particular route discovery helps meet the
application defined goal \cite{rpl}. Thus, the G flag setting helps an
intermediate router choose which route discoveries to participate in if
it cannot participate in all route discoveries. An intermediate router
SHOULD participate in route discoveries with G flag set to one (in
preference to ones with G flag set to zero)."

[Pascal10]
As far as I'm concerned you've captured it and I'm happy with this text.

_______________________________________________
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 internet-drafts@ietf.org  Fri Apr 20 20:50:07 2012
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 70BC221E8012; Fri, 20 Apr 2012 20:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.466
X-Spam-Level: 
X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 pg29lShXUd6W; Fri, 20 Apr 2012 20:50:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0503D21F84F0; Fri, 20 Apr 2012 20:50:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120421035003.7486.91815.idtracker@ietfa.amsl.com>
Date: Fri, 20 Apr 2012 20:50:03 -0700
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-08.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, 21 Apr 2012 03:50:07 -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           : The Minimum Rank with Hysteresis Objective Function
	Author(s)       : Omprakash Gnawali
                          Philip Levis
	Filename        : draft-ietf-roll-minrank-hysteresis-of-08.txt
	Pages           : 13
	Date            : 2012-04-20

   The Routing Protocol for Low Power and Lossy Networks (RPL) uses
   objective functions to construct routes that optimize or constrain
   the routes it selects and uses.  This specification describes the
   Minimum Rank with Hysteresis Objective Function (MRHOF), an objective
   function that selects routes that minimize a metric, while using
   hysteresis to reduce churn in response to small metric changes.
   MRHOF works with metrics that are additive along a route, and the
   metric it uses is determined by the metrics RPL Destination
   Information Object (DIO) messages advertise.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-0=
8.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-minrank-hysteresis-of-08=
.txt


From jpv@cisco.com  Sat Apr 21 01:23:48 2012
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 ADA5321F85AF for ; Sat, 21 Apr 2012 01:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.44
X-Spam-Level: 
X-Spam-Status: No, score=-109.44 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_HI=-8, 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 deP3jcgb-4kE for ; Sat, 21 Apr 2012 01:23:44 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 48B2721F8598 for ; Sat, 21 Apr 2012 01:23:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=14063; q=dns/txt; s=iport; t=1334996624; x=1336206224; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=WjlJk+EbmCtC4zQ6PYkk0nBUbcJF5H90KuovUZodWGk=; b=Tyu8xvo8Au8tBLuMN+xRqWMiIo5r3sbFQ3FeEgrFhH6Qu94P4p3oTuNb 9KXAnSQnxqmPWB04IIR+19KXXwn+Bzsyk40UI1izOvVpzj2F85SiUJy5x bqMw9jfr3OvnweJUl0fffFXTRg3DvlKpnVE6FIs8hY7LZMTddgg2XPlxV M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAPptkk+rRDoI/2dsb2JhbABFDrExgQeCCQEBAQMBAQEBDwFbBAcFBwQLEQQBAS8nKAgGARIih2gEAQuaV6ADBIlogQuFXWMElXqOVYFpgjA7gVIBFg
X-IronPort-AV: E=Sophos;i="4.75,458,1330905600"; d="scan'208";a="41464419"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 21 Apr 2012 08:23:43 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3L8Nh2c031344; Sat, 21 Apr 2012 08:23:43 GMT
Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 21 Apr 2012 01:23:43 -0700
Received: from sjc-vpn6-1523.cisco.com ([10.21.125.243]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 21 Apr 2012 01:23:42 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: JP Vasseur 
In-Reply-To: <843656433.9245.1334588377995.JavaMail.root@mail17.pantherlink.uwm.edu>
Date: Sat, 21 Apr 2012 10:23:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <843656433.9245.1334588377995.JavaMail.root@mail17.pantherlink.uwm.edu>
To: Mukul Goyal , roll 
X-Mailer: Apple Mail (2.1257)
X-OriginalArrivalTime: 21 Apr 2012 08:23:42.0863 (UTC) FILETIME=[1010A9F0:01CD1F98]
Cc: Michael Richardson 
Subject: Re: [Roll] Closure text for ticket #86
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, 21 Apr 2012 08:23:48 -0000

I sort of reached the same conclusion =85
ROLL WG, let us know by April 27th if there is a disagreement.

Thanks.

JP.

On Apr 16, 2012, at 4:59 PM, Mukul Goyal wrote:

> Hi all
>=20
> On further thoughts, I think we should defer for the time being using =
G bit to indicate route discovery priority. There is no real usecase for =
this at the moment. We can reconsider adding this functionality when we =
go standards track. So, I propose modifying the resolution text to the =
following:
>=20
> "The origin always sets the G flag to one. Unlike a global RPL =
instance, the concept of a floating DAG, used to provide connectivity =
within a sub-DAG detached from a grounded DAG, does not apply to a local =
RPL instance. Hence, an origin MUST always set the G flag to one when =
initiating a P2P-RPL route discovery. Further, a node MUST NOT initiate =
a new DAG (with G flag set to zero) if it does not have any parent left =
in a P2P-RPL DAG."
>=20
> Thanks
> Mukul
>=20
> ----- Original Message -----
> From: "Mukul Goyal" 
> To: "JP Vasseur" 
> Cc: "roll" , "Michael Richardson" 
> Sent: Tuesday, April 10, 2012 9:51:25 PM
> Subject: [Roll] Closure text for ticket #86
>=20
> #86: G flag: do we need that text?
>=20
> Problem
> ------------------------------
> Disagreement on the meaning of 'G' bit and imposed setting to 0;
>=20
> Proposed resolution
> ---------------------------
> Add the following text to the draft:
>=20
> "The origin sets the G flag to indicate the relative importance of the =
route discovery it is initiating. The G flag is set to one if this =
particular route discovery is more important from application's =
perspective than some other route discovery. In other words, the origin =
sets the G flag to one if this particular route discovery helps meet the =
application defined goal \cite{rpl}. Thus, the G flag setting helps an =
intermediate router choose which route discoveries to participate in if =
it cannot participate in all route discoveries. An intermediate router =
SHOULD participate in route discoveries with G flag set to one (in =
preference to ones with G flag set to zero)."
>=20
> Discussion:
> -----------------
>=20
> [Pascal]
> " Grounded (G) Flag: MUST be set to zero since this DAG is temporary =
in
> nature, is created solely for the purpose of P2P-RPL route discovery =
and
> MUST NOT be used for packet routing."
>=20
> On the contrary I'd set it to 1. The goal -being to reach the origin- =
is
> actually achieved by this DAG.
>=20
> [Mukul]
> Actually, the DAG is temporary in nature and vanishes after a short
> while. Even when it exists, it must/should not be used for routing
> packets back to the origin. So, I think the Grounded flag should be
> zero.
>=20
> [Pascal2] Please revisit RFC 6650 page 12.
> G means that a goal is achieved. So first you define the goal and then
> the bit becomes obvious. What's your goal?
> Can there be P2P DAGs that achieve the goal and others that make sense
> to build and yet do not achieve the goal?
> If you accept that your operation can actually depend on OF logic, =
then
> the setting of the goal influences that logic.
> By forcing a value to the goal in the PTP spec, we actually limit the
> applicability of the draft.
> Maybe you can define a default goal and a default setting. But do not
> MUST that it is set to 0...
>=20
> [Mukul2]
> When a node joins a temporary P2P DAG, it does not get any additional
> routing information. The DAG is going to disappear after some time,
> should not be used for routing while it exists and which nodes end up
> being on the discovered route is not known until the DRO message comes
> back. So, I think, by default, the G flag has to be zero. However, if
> the setting of G flag may affect how an intermediate node may =
calculate
> its rank (as per the OF being used), the origin should have the
> flexibility of setting the flag to 1. So, I could modify the text to =
say
> that "the origin sets the G flag based on its perception of how the
> flag's value would affect the rank calculation under the OF being =
used.
> By default, the G flag is set to zero given the temporary nature of =
the
> DAG being created."
>=20
> [Pascal3] Why do you feel the need to add anything above what RFC 6550
> says? I do not see any benefit or additional clarity from doing this.
>=20
> [Mukul3] RFC 6550 is actually kind of confusing in this regard. On =
page
> 9, it says
>=20
> "A typical Goal is to construct the DODAG
>         according to a specific Objective Function and to keep
>         connectivity to a set of hosts (e.g., to use an Objective
>         Function that minimizes a metric and is connected to a =
specific
>         database host to store the collected data)."
>=20
> This seems to associate the goal with both OF and reachability to
> certain hosts. Later invocations of the term "goal" seem to refer just
> to the connectivity aspect, e.g., on page 18 RFC 6550 says
>=20
> "A grounded DODAG offers connectivity to hosts that are
>   required for satisfying the application-defined goal."
>=20
> So, my understanding so far was that the "goal" defines connectivity =
to
> a certain hosts. The relation to objective function is not clear at =
all
> (if one restricts oneself to reading RFC 6550). The temporary DAGs
> created in P2P-RPL route discovery provide no connectivity whatsoever =
to
> the joining nodes. So, the only reason to set the G flag to 1 would be
> to allow correct use of an OF. So, I think P2P-RPL spec should use the
> text I offered above (and repeat below):
>=20
> "The origin sets the G flag based on its perception of whether joining
> how the flag's value would affect the rank calculation under the OF
> being used. By default, the G flag is set to zero given the temporary
> nature of the DAG being created."
>=20
> What do you think?
>=20
> [Pascal4] If you think this adds value, I will not oppose. Let's keep
> that as the proposed resolution
>=20
> [Mukul4] Sounds good.
>=20
> Proposed resolution text:
>=20
> "The origin sets the G flag based on its perception of whether joining
> how the flag's value would affect the rank calculation under the OF
> being used. By default, the G flag is set to zero given the temporary
> nature of the DAG being created."
>=20
> [Richard5]
> I disagree with the proposed resolution.  It adds needless confusion.
> The G flag is 0 if and only if the DODAG is floating.
> There is no point to allowing floating DODAGs with a P2P-RDO option.  =
I suggest that the G bit be set to 1 and that routers be explicitly =
prohibited from creating floating DODAGs with a P2P-RDO option.
>=20
> [Mukul5]
>> The G flag is 0 if and only if the DODAG is floating.
>=20
> I think that the G flag is 1 if and only if the DODAG is grounded. The =
temporary DAGs used in P2P-RPL are not grounded, they are temporary. I =
think that all transient/temporary DAGs are floating by their very =
nature.
>=20
> [Michael5]
>> I think we need to determine what a grounded DODAG is.
>> Does it mean that a node announcing such a thing is attached to the =
Internet? (In which case P2P usage should G=3D0)
>> Or does it mean that a node is attached to the resource named in the =
DIO? (In which case origin P2P should G=3D1)
>>=20
>=20
> [Phillip5]
> The text in 6550 is pretty clear:=20
>=20
>   Goal: The Goal is an application-specific goal that is defined
>         outside the scope of RPL.  Any node that roots a DODAG will
>         need to know about this Goal to decide whether or not the Goal
>         can be satisfied.  A typical Goal is to construct the DODAG
>         according to a specific Objective Function and to keep
>         connectivity to a set of hosts (e.g., to use an Objective
>         Function that minimizes a metric and is connected to a =
specific
>         database host to store the collected data).
>=20
>   Grounded: A DODAG is grounded when the DODAG root can satisfy the
>         Goal.
>=20
>   Floating: A DODAG is floating if it is not grounded.  A floating
>         DODAG is not expected to have the properties required to
>         satisfy the goal.  It may, however, provide connectivity to
>         other nodes within the DODAG.
>=20
> The common case of the Goal is "has connectivity to the Internet" but =
that's not the only case. I think given the Goal for P2P traffic, I =
agree with Pascal and Richard that it should be 1.
>=20
>=20
> [Pascal6]
> Floating vs. Grounded depends on the goal of the DODAG. I asked you =
and will ask again what is your goal?
> If the goal is to reach the root, then G is 1... If you want to signal =
something to the OF using the G bit, leave it  open.
>=20
> [Mukul6]
>> If the goal is to reach the root, then G is 1...
>=20
> I have told you multiple times that joining a P2P-RPL DAG does not =
give any sort of connectivity to the node.
>=20
> [Pascal7]
> I think we disagree because of the definition of goal itself. The goal =
is an abstraction. Same goes for the term Objective in OF. RFC 6550 only =
gives examples of what G could be used for but that is not limiting. =
Certainly the abstraction may for instance mean that external nodes are =
reachable via the root. But it could be something else entirely. For =
instance it could designate a root that can aggregate data.
>=20
> In practice, G is used to favor a root that reaches the goal vs. one =
that does not. But that's senseless for local instances that have by =
definition a single root.
>=20
> So whatever you set it to does not make a difference for RFC 6550 =
operations. I figure it could be used for signaling a "transient goal" =
information to an OF that could use it for a purpose I can't fathom.
>=20
> In any case, as I suggested earlier and as Richard also suggest now, G =
SHOULD probably be 1 by default but MAY be set otherwise.
>=20
> [Mukul7]
> Richard wants the flag to always be either 0 or 1. He prefers it to be =
always 1 but would settle for it being always zero.
>=20
> I think this is not a critical point. I am OK with whatever resolution =
you and Richard arrive at. Kindly provide me the resolution text I =
should put in the draft.
>=20
> [Pascal8]
> I suggest a sentence that says that:
>=20
> 1) For a local instance there can be only one root and one DODAG. G =
bit cannot and is not used for DODAG selection within an instance.=20
> 2) In a given deployment, a goal can be defined that some P2P DODAGs =
achieve and others do not. The roots that achieve that goal will set the =
G bit in their P2P DAGs.
> 3) the default goal is to create connectivity between origin and =
target. So by default G should be set to 1.
> 4) if an intermediate router does not have enough resources to =
participate to all DODAGs then it should favor DODAGs with the G bit on.
>=20
> The exact wording is yours...
>=20
> [Mukul8]
>> 1) For a local instance there can be only one root and one DODAG. G =
bit cannot and is not used for DODAG selection within an instance.=20
>=20
> The statement above seems to be at odds with following two statements
>=20
>> 2) In a given deployment, a goal can be defined that some P2P DODAGs =
achieve and others do not. The roots that achieve that goal will set the =
G bit in their P2P DAGs.
> 3) the default goal is to create connectivity between origin and =
target. So by default G should be set to 1.
>=20
> As per statement 1, the G flag can never be 1 for P2P-RPL DAGs because =
they use local instance ids.
> As per statement 2/3, the G flag could be 1 and is 1 by default.
>=20
> I am OK with setting G flag to 1 always (as you, Richard and Phil seem =
to prefer) but I dont know how to reason this. Do we need to provide a =
reason at all?
>=20
> [Pascal9]
> Statement 1 does not say that at all. Can't fathom how you concluded =
that... Let me try to reword: There is only what DODAG for a given local =
instance so there cannot be a selection =3D> G cannot be used for a =
selection that cannot happen.
>=20
>> As per statement 2/3, the G flag could be 1 and is 1 by default.
>=20
> Yes. I added an item to help the device prioritize when it is asker to =
participate to many DODAGs (for many P2P flows that it happens to be on =
the path of). In that case, and if the device cannot particpater to all =
the P2P DODAGs, then the G bit could be use to decide which are the most =
important.=20
>=20
> If you define a default goal that the DODAG fills, then you set G to =
one. For instance, G could mean 'important stuff' like swithing a light =
on. You'd set it for switching lights but not for reporting the =
hygrometry of your orchids, which anyway will be retried in a half hour. =
As a result, if the 2 DAG formations collide, the light on will have =
precedence...
>=20
> [Mukul9]
> How about the following text:
>=20
> "The origin sets the G flag to indicate the relative importance of the =
route discovery it is initiating. The G flag is set to one if this =
particular route discovery is more important from application's =
perspective than some other route discovery. In other words, the origin =
sets the G flag to one if this particular route discovery helps meet the =
application defined goal \cite{rpl}. Thus, the G flag setting helps an =
intermediate router choose which route discoveries to participate in if =
it cannot participate in all route discoveries. An intermediate router =
SHOULD participate in route discoveries with G flag set to one (in =
preference to ones with G flag set to zero)."
>=20
> [Pascal10]
> As far as I'm concerned you've captured it and I'm happy with this =
text.
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From pal@cs.stanford.edu  Sat Apr 21 08:53:58 2012
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 14EDF21F85D5 for ; Sat, 21 Apr 2012 08:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.216
X-Spam-Level: 
X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383,  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 ekWoaj+1KdNX for ; Sat, 21 Apr 2012 08:53:57 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id BD79921F85D7 for ; Sat, 21 Apr 2012 08:53:55 -0700 (PDT)
Received: from [76.14.66.110] (helo=[192.168.0.111]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SLcdE-0002Xi-N9; Sat, 21 Apr 2012 08:53:52 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: <20120421035003.7486.91815.idtracker@ietfa.amsl.com>
Date: Sat, 21 Apr 2012 08:53:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <890C802D-BEDF-44F5-85A9-35669C48F9C4@cs.stanford.edu>
References: <20120421035003.7486.91815.idtracker@ietfa.amsl.com>
To: adrian@olddog.co.uk, " WG" , Michael Richardson , JP Vasseur 
X-Mailer: Apple Mail (2.1257)
X-Scan-Signature: b64bce576883819501cf77c9371f4538
Subject: Re: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-08.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, 21 Apr 2012 15:53:58 -0000

On Apr 20, 2012, at 8:50 PM, internet-drafts@ietf.org wrote:

>=20
> 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.
>=20
> 	Title           : The Minimum Rank with Hysteresis Objective =
Function
> 	Author(s)       : Omprakash Gnawali
>                          Philip Levis
> 	Filename        : draft-ietf-roll-minrank-hysteresis-of-08.txt
> 	Pages           : 13
> 	Date            : 2012-04-20


Om and I have submitted a version of the draft (-08) that now addresses =
all of the comments that arose during IETF last call, including:

- Clear Rank vs DAGRank confusion cleared through a note in the
terminology section

- A node setting its Rank to next higher Integral Rank rather than
plus one of the parent's Rank

Phil


From admin@ipv6it.org  Sat Apr 21 09:15:02 2012
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 7341A21F8617 for ; Sat, 21 Apr 2012 09:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001,  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 Zs6xW+fsq4Ay for ; Sat, 21 Apr 2012 09:14:58 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9EE21F8611 for ; Sat, 21 Apr 2012 09:14:58 -0700 (PDT)
Received: by werb10 with SMTP id b10so8186574wer.31 for ; Sat, 21 Apr 2012 09:14:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=+QtwqLHPuf2PZy2EPUbkymfMJt8dbAjmozGr+WMtmIs=; b=Ko0e1sJxgNe/BbbizNRSBb6Yta+gBNsATCGaeliDDvCZt6o8Na+piq7yYvCdGi3UUT 82swzkEpH/AQeb8yM91g/Te/QeWyyl3atNfBADCV/MVUVo2NDG5HYRxKRe6wtyX2Uy2O zlqK5d2dfFPhrOkZEIkludt3gogj1gakC4IkXalLlO8eaP81AyFfJ+HcHnoB5XmE7sdD k1Y4daUWtXf+d5gNhX7LOLUQXgTBPnaz0t9qAPDEx7q2ozUs8oDJemCUXXIxYSE5n+Uu avxESfCAv1waiFHSYkpS08bQ4x3PIPFgalkLqXRcDPBnIsbSogl95LjO/H3n++hll97U UbIg==
Received: by 10.180.104.65 with SMTP id gc1mr7089560wib.13.1335024894087; Sat, 21 Apr 2012 09:14:54 -0700 (PDT)
Received: from [127.0.0.1] (host136-59-dynamic.56-82-r.retail.telecomitalia.it. [82.56.59.136]) by mx.google.com with ESMTPS id gd4sm10845098wib.6.2012.04.21.09.14.52 (version=SSLv3 cipher=OTHER); Sat, 21 Apr 2012 09:14:53 -0700 (PDT)
Message-ID: <4F92DCF8.5080503@ipv6it.org>
Date: Sat, 21 Apr 2012 18:14:48 +0200
From: Federico Consoli 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Roll@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkuZSZu8pieFajj9qNjywQ6ds6ytsLYSvhC6QA56aCtDyCv7y/4zG5ulH7eUW1YkQTjg7T6
Subject: [Roll] MRHOF draft-08 comments
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, 21 Apr 2012 16:15:02 -0000

Hi,
I think that the problem discussed here 
http://www.ietf.org/mail-archive/web/roll/current/msg06747.html is still 
present.

-- 
Consoli Federico


From pal@cs.stanford.edu  Sat Apr 21 11:25:26 2012
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 8494321F85C4 for ; Sat, 21 Apr 2012 11:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.312
X-Spam-Level: 
X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.288,  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 h6gEr2C7b-Er for ; Sat, 21 Apr 2012 11:25:22 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9344D21F85AE for ; Sat, 21 Apr 2012 11:25:22 -0700 (PDT)
Received: from [76.14.66.110] (helo=[192.168.0.111]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SLezn-0008KL-MW; Sat, 21 Apr 2012 11:25:22 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: <4F92DCF8.5080503@ipv6it.org>
Date: Sat, 21 Apr 2012 11:25:27 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <572CF290-6FBF-4E94-83DA-2EB2B9EECC95@cs.stanford.edu>
References: <4F92DCF8.5080503@ipv6it.org>
To: Federico Consoli 
X-Mailer: Apple Mail (2.1257)
X-Scan-Signature: 2c238adc2661b13b123d68c6db09dced
Cc: Roll@ietf.org
Subject: Re: [Roll] MRHOF draft-08 comments
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, 21 Apr 2012 18:25:26 -0000

You are right -- I'm sorry, we missed this (I conflated it with the =
DODAG Root advertising MinHopRankIncrease rather than MIN_PATH_COST). =
We'll submit a new draft shortly.

Phil

On Apr 21, 2012, at 9:14 AM, Federico Consoli wrote:

> Hi,
> I think that the problem discussed here =
http://www.ietf.org/mail-archive/web/roll/current/msg06747.html is still =
present.
>=20
> --=20
> Consoli Federico
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>=20


Phil


From internet-drafts@ietf.org  Sun Apr 22 22:16:06 2012
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 79A0721F8552; Sun, 22 Apr 2012 22:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.436
X-Spam-Level: 
X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 IGS6ffZnwf8x; Sun, 22 Apr 2012 22:16:05 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D799821F84FF; Sun, 22 Apr 2012 22:16:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120423051605.4810.3372.idtracker@ietfa.amsl.com>
Date: Sun, 22 Apr 2012 22:16:05 -0700
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-09.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, 23 Apr 2012 05:16:06 -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           : The Minimum Rank with Hysteresis Objective Function
	Author(s)       : Omprakash Gnawali
                          Philip Levis
	Filename        : draft-ietf-roll-minrank-hysteresis-of-09.txt
	Pages           : 13
	Date            : 2012-04-22

   The Routing Protocol for Low Power and Lossy Networks (RPL) uses
   objective functions to construct routes that optimize or constrain
   the routes it selects and uses.  This specification describes the
   Minimum Rank with Hysteresis Objective Function (MRHOF), an objective
   function that selects routes that minimize a metric, while using
   hysteresis to reduce churn in response to small metric changes.
   MRHOF works with metrics that are additive along a route, and the
   metric it uses is determined by the metrics RPL Destination
   Information Object (DIO) messages advertise.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-0=
9.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-minrank-hysteresis-of-09=
.txt


From pal@cs.stanford.edu  Sun Apr 22 22:17:42 2012
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 C2D8521F84CD for ; Sun, 22 Apr 2012 22:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.369
X-Spam-Level: 
X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230,  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 NwJHyQIv8C-J for ; Sun, 22 Apr 2012 22:17:42 -0700 (PDT)
Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id DE08C21F84C4 for ; Sun, 22 Apr 2012 22:17:41 -0700 (PDT)
Received: from [76.14.66.110] (helo=[192.168.0.111]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SMBef-0007YE-Bz for roll@ietf.org; Sun, 22 Apr 2012 22:17:41 -0700
From: Philip Levis 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sun, 22 Apr 2012 22:17:45 -0700
References: <20120423051605.4810.3372.idtracker@ietfa.amsl.com>
To: " WG" 
Message-Id: <087953A0-B607-421E-B141-FF22CEB75CE9@cs.stanford.edu>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
X-Scan-Signature: f824399eb00b5943f8bdbe5dd24fccda
Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-minrank-hysteresis-of-09.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, 23 Apr 2012 05:17:43 -0000

This version of the draft (-09) addresses the comment we missed in -08; =
it now addresses all of the comments raised in IETF last call. Many =
thanks to everyone for their detailed reading and consideration.

Phil

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: [Roll] I-D Action: =
draft-ietf-roll-minrank-hysteresis-of-09.txt
> Date: April 22, 2012 10:16:05 PM PDT
> To: i-d-announce@ietf.org
> Cc: roll@ietf.org
>=20
>=20
> 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.
>=20
> 	Title           : The Minimum Rank with Hysteresis Objective =
Function
> 	Author(s)       : Omprakash Gnawali
>                          Philip Levis
> 	Filename        : draft-ietf-roll-minrank-hysteresis-of-09.txt
> 	Pages           : 13
> 	Date            : 2012-04-22
>=20
>   The Routing Protocol for Low Power and Lossy Networks (RPL) uses
>   objective functions to construct routes that optimize or constrain
>   the routes it selects and uses.  This specification describes the
>   Minimum Rank with Hysteresis Objective Function (MRHOF), an =
objective
>   function that selects routes that minimize a metric, while using
>   hysteresis to reduce churn in response to small metric changes.
>   MRHOF works with metrics that are additive along a route, and the
>   metric it uses is determined by the metrics RPL Destination
>   Information Object (DIO) messages advertise.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-=
09.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-roll-minrank-hysteresis-of-0=
9.txt
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>=20


Phil


From admin@ipv6it.org  Mon Apr 23 01:11:15 2012
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 4522B21F861F for ; Mon, 23 Apr 2012 01:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 GMpV8dBAbZtS for ; Mon, 23 Apr 2012 01:11:12 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADE321F84E4 for ; Mon, 23 Apr 2012 01:11:12 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so10281637bku.31 for ; Mon, 23 Apr 2012 01:11:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=8Jq9mJRACh1tdF9IDp+JqF+kwm83HrxDcl0t/cCxbsc=; b=SJovhrEjPPsxQ9wCy6/gKsoulMXWPCkKziHPdcbMWsOTC8Z/gn7K6QqByqwxyMfdQk /vKRQw0l5RpauCF7HPlGWsVjmn2OpjYhBVSwDlDLKLujh0rKBhmrteW7OqDi0VvXBOQ5 PtaASao1EPOd+1YkTkpeXs4Q5rVb7wb7expixfxEZydEpI1mGRHo6aszDDhP8bY3JIbp 6/ZzdHdmvNCSE8Kx4UV4nRxeVAvbguUFfbYjjwztYBGwrf1G6t6Fw2PF4leHAnizvz6X MbB5J4m7h09HcF4jXimgsoK//ghKIq8oX9scSsW73nj70tXZJbeulYvrOr2nmDtJi/2j E5zA==
Received: by 10.204.156.215 with SMTP id y23mr4774148bkw.35.1335168671155; Mon, 23 Apr 2012 01:11:11 -0700 (PDT)
Received: from [127.0.0.1] (host136-59-dynamic.56-82-r.retail.telecomitalia.it. [82.56.59.136]) by mx.google.com with ESMTPS id f5sm22998555bke.9.2012.04.23.01.11.08 (version=SSLv3 cipher=OTHER); Mon, 23 Apr 2012 01:11:10 -0700 (PDT)
Message-ID: <4F950E98.9080304@ipv6it.org>
Date: Mon, 23 Apr 2012 10:11:04 +0200
From: Federico Consoli 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Roll@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQldfAWAA2p4cGbX54vEFtLLXn9TTpt+ABsysGZjdglxdVUYt6bkB4MC8lLYXxw4WtjHgw7p
Subject: [Roll] MRHOF draft-09 comments
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, 23 Apr 2012 08:11:16 -0000

Hi, I'm sorry but I think that it's still wrong. I think that you missed 
the "MRHOF draft-07 comments" post where you said:

"I think the issue here is the MRHOF draft is not clear: A (a root) 
should advertise a Rank of 256, and B, following 3.3, would advertise a 
Rank of 256 + MinHopRankIncrease (case 3 of 3.3)."

Infact now:
MHROF-09 section 6.1
"RPL's Rank advertisement rules can require a DODAG Root to advertise a 
Rank higher than its corresponding ETX value, as a DODAG Root advertises 
a Rank of MinHopRankIncrease. "

That it's correct.

But
MHROF-09 Section 3.4
" DODAG Roots advertise a metric value which computes to a cost of 
MIN_PATH_COST."
And
MHROF-09 Section 5.
" MIN_PATH_COST: 0. At root, the expected transmission count is 0."

I think that to be compliant with 6.1. MIN_PATH_COST variable should be 
removed and "DODAG Roots advertise a metric value which computes to a 
cost of MinHopRankIncrease".

-- 
Regards
Consoli Federico


From mcr@sandelman.ca  Mon Apr 23 06:53:42 2012
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 8B10021F862B for ; Mon, 23 Apr 2012 06:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level: 
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=-0.744,  BAYES_05=-1.11, 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 plez7auwTPQK for ; Mon, 23 Apr 2012 06:53:41 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 44D7421F862A for ; Mon, 23 Apr 2012 06:53:40 -0700 (PDT)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 60E3C81AC for ; Mon, 23 Apr 2012 09:53:14 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id E387698C09; Mon, 23 Apr 2012 09:53:38 -0400 (EDT)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DE66798C08 for ; Mon, 23 Apr 2012 09:53:38 -0400 (EDT)
From: Michael Richardson 
To: " WG" 
In-Reply-To: <890C802D-BEDF-44F5-85A9-35669C48F9C4@cs.stanford.edu>
References: <20120421035003.7486.91815.idtracker@ietfa.amsl.com> <890C802D-BEDF-44F5-85A9-35669C48F9C4@cs.stanford.edu>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
Date: Mon, 23 Apr 2012 09:53:38 -0400
Message-ID: <11073.1335189218@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-08.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, 23 Apr 2012 13:53:42 -0000

http://tools.ietf.org/rfcdiff?url1=draft-ietf-roll-minrank-hysteresis-of-07&difftype=--html&submit=Go%21&url2=draft-ietf-roll-minrank-hysteresis-of-09

This shows differences between -07 and -08/-09.

80% of the differences are due to ietf-roll-routing-metrics becoming
RFC6551, and this is in 08 to 09 mostly.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
	               then sign the petition. 



From pal@cs.stanford.edu  Mon Apr 23 10:23:13 2012
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 0B07121F8734 for ; Mon, 23 Apr 2012 10:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.238
X-Spam-Level: 
X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361,  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 I4hhuRthKTib for ; Mon, 23 Apr 2012 10:23:12 -0700 (PDT)
Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8678D21F86DE for ; Mon, 23 Apr 2012 10:23:12 -0700 (PDT)
Received: from dn0a210307.sunet ([10.33.3.7]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SMMyk-0004wa-Gc; Mon, 23 Apr 2012 10:23:10 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: <4F950E98.9080304@ipv6it.org>
Date: Mon, 23 Apr 2012 10:23:16 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <908FB74E-73C7-49B2-83F1-48796118A233@cs.stanford.edu>
References: <4F950E98.9080304@ipv6it.org>
To: Federico Consoli 
X-Mailer: Apple Mail (2.1257)
X-Scan-Signature: 078eb853d78558c6c655f7b6c94b391a
Cc: " WG" 
Subject: Re: [Roll] MRHOF draft-09 comments
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, 23 Apr 2012 17:23:13 -0000

On Apr 23, 2012, at 1:11 AM, Federico Consoli wrote:

> Hi, I'm sorry but I think that it's still wrong. I think that you =
missed the "MRHOF draft-07 comments" post where you said:
>=20
> "I think the issue here is the MRHOF draft is not clear: A (a root) =
should advertise a Rank of 256, and B, following 3.3, would advertise a =
Rank of 256 + MinHopRankIncrease (case 3 of 3.3)."
>=20
> Infact now:
> MHROF-09 section 6.1
> "RPL's Rank advertisement rules can require a DODAG Root to advertise =
a Rank higher than its corresponding ETX value, as a DODAG Root =
advertises a Rank of MinHopRankIncrease. "
>=20
> That it's correct.
>=20
> But
> MHROF-09 Section 3.4
> " DODAG Roots advertise a metric value which computes to a cost of =
MIN_PATH_COST."
> And
> MHROF-09 Section 5.
> " MIN_PATH_COST: 0. At root, the expected transmission count is 0."
>=20
> I think that to be compliant with 6.1. MIN_PATH_COST variable should =
be removed and "DODAG Roots advertise a metric value which computes to a =
cost of MinHopRankIncrease".


I think these edits are the best resolution to the =
MinHopRankIncrease/DODAG metric issue. If there are no objections then I =
will apply them in the (hopefully final) edit. Federico, your detailed =
feedback has be invaluable. Thank you.

Phil


From admin@ipv6it.org  Tue Apr 24 00:54:48 2012
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 36ACB21F86A0 for ; Tue, 24 Apr 2012 00:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id senHJRW9ZioO for ; Tue, 24 Apr 2012 00:54:47 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0936921F86A7 for ; Tue, 24 Apr 2012 00:54:46 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so287173bku.31 for ; Tue, 24 Apr 2012 00:54:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=6so93zfoVZPhjSlEmhP45Tn2W/iWi/iVCrqo9C1g55Q=; b=RVCjJzJ/SC+0PAN4I+hVy3tBCdDo6qJ9lmQ4IolHAu4HcTquWvmNLvwVCLBviYg9lC J8j93ubbTLgCelzZ4xjygZcP+X1V7QgwBwdBmiAoet5F2GgI1lGNH6Ku9a13lM3g8sA4 b52Rxwed85YfwdLzpBmYaigfzBMOHhJa8Pq/2nj3uOfOG9zIFgq8iw+HTxnsfb8ugvpS MN2Rh7E21HijelBx8AzUO9bb5B9JvydJ/67xfOHuDWuZ/PBHUZEKt28sltVMoNnx4zvF bDVqPlJMIwJPkr23AdqTieV6Xws+svGg0WQr/jswzYWSW1o35DGl8p+hpizXjl5aW2+D liyw==
Received: by 10.204.154.12 with SMTP id m12mr4781953bkw.56.1335254085867; Tue, 24 Apr 2012 00:54:45 -0700 (PDT)
Received: from [127.0.0.1] (myskyn.iet.unipi.it. [131.114.59.252]) by mx.google.com with ESMTPS id hq5sm26883882bkc.8.2012.04.24.00.54.44 (version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 00:54:44 -0700 (PDT)
Message-ID: <4F965C40.9050706@ipv6it.org>
Date: Tue, 24 Apr 2012 09:54:40 +0200
From: Federico Consoli 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Roll@ietf.org
References: <4F950E98.9080304@ipv6it.org> <908FB74E-73C7-49B2-83F1-48796118A233@cs.stanford.edu>
In-Reply-To: <908FB74E-73C7-49B2-83F1-48796118A233@cs.stanford.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnSwaM7jhOsd4072ztJgOt8/C8NmVAGrWhma0XOPfgAqf9aEk3VHUR/K7iqGgYCIdc94Rdg
Subject: Re: [Roll] MRHOF draft-09 comments
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, 24 Apr 2012 07:54:48 -0000

Il 23/04/2012 19.23, Philip Levis ha scritto:
> On Apr 23, 2012, at 1:11 AM, Federico Consoli wrote:
>
>> Hi, I'm sorry but I think that it's still wrong. I think that you missed the "MRHOF draft-07 comments" post where you said:
>>
>> "I think the issue here is the MRHOF draft is not clear: A (a root) should advertise a Rank of 256, and B, following 3.3, would advertise a Rank of 256 + MinHopRankIncrease (case 3 of 3.3)."
>>
>> Infact now:
>> MHROF-09 section 6.1
>> "RPL's Rank advertisement rules can require a DODAG Root to advertise a Rank higher than its corresponding ETX value, as a DODAG Root advertises a Rank of MinHopRankIncrease."
>>
>> That it's correct.
>>
>> But
>> MHROF-09 Section 3.4
>> " DODAG Roots advertise a metric value which computes to a cost of MIN_PATH_COST."
>> And
>> MHROF-09 Section 5.
>> " MIN_PATH_COST: 0. At root, the expected transmission count is 0."
>>
>> I think that to be compliant with 6.1. MIN_PATH_COST variable should be removed and "DODAG Roots advertise a metric value which computes to a cost of MinHopRankIncrease".
>
> I think these edits are the best resolution to the MinHopRankIncrease/DODAG metric issue. If there are no objections then I will apply them in the (hopefully final) edit. Federico, your detailed feedback has be invaluable. Thank you.
>
> Phil
>
Hi,
I got no objections. You're Welcome.

-- 
Regards
Consoli Federico


From jpv@cisco.com  Tue Apr 24 18:24:55 2012
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 BF31B21F8683 for ; Tue, 24 Apr 2012 18:24:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.464
X-Spam-Level: 
X-Spam-Status: No, score=-110.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 sIqxx91cX6qJ for ; Tue, 24 Apr 2012 18:24:55 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 07F2D21F867A for ; Tue, 24 Apr 2012 18:24:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=317; q=dns/txt; s=iport; t=1335317095; x=1336526695; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=bPj5p7JQ3nWDeNWCyHwSnRGbjmdd2Z3d+Nu5DgU7X7Y=; b=b0I0xkjzPx8p9EHw0RXfsdfSwsd70UkB+PBSfy4dZzyVunb1yoPw1Wex lSyYr/+UtyM98JX+icMOq9YR2NmYUPmJYhjvwdKQDDe4oyj6osYRblTrZ nLGpT/0Zg62ueQ0dkxZQ975e2qMw4kfxxgqoIEm27fVE+TlMJZ8T47mZ3 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEAFhRl0+rRDoJ/2dsb2JhbABEsWqBB4IOFAEnP4E+HBmHbAELmiWgJZAPYwSIY40XjlWBaYMJ
X-IronPort-AV: E=Sophos;i="4.75,476,1330905600"; d="scan'208";a="41944827"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 25 Apr 2012 01:24:54 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3P1OsfI020171; Wed, 25 Apr 2012 01:24:54 GMT
Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 24 Apr 2012 18:24:53 -0700
Received: from sjc-vpn6-721.cisco.com ([10.21.122.209]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 24 Apr 2012 18:24:53 -0700
From: JP Vasseur 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Apr 2012 18:24:50 -0700
Message-Id: <38808DC5-827B-4911-B770-21ABCB0431EE@cisco.com>
To: roll WG 
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
X-OriginalArrivalTime: 25 Apr 2012 01:24:53.0359 (UTC) FILETIME=[375DA7F0:01CD2282]
Cc: Michael Richardson 
Subject: [Roll] Draft IETF-83 ROLL WG minutes
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, 25 Apr 2012 01:24:55 -0000

Dear all,

Thanks to Dan for having taken the minutes !

The draft of minutes for our ROLL WG meeting IETF-83 has been posted: =
http://www.ietf.org/proceedings/83/minutes/minutes-83-roll.pdf

Please let us know no later than May 1st at noon ET if you have any =
comments.

Many Thanks.

JP and Michael.


From internet-drafts@ietf.org  Thu Apr 26 09:57:11 2012
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 B0D8E21E80D2; Thu, 26 Apr 2012 09:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.508
X-Spam-Level: 
X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 z1tJNS7jCAlu; Thu, 26 Apr 2012 09:57:11 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B9D21F864C; Thu, 26 Apr 2012 09:57:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.01p1
Message-ID: <20120426165711.26991.14152.idtracker@ietfa.amsl.com>
Date: Thu, 26 Apr 2012 09:57:11 -0700
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-10.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: Thu, 26 Apr 2012 16:57:12 -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           : The Minimum Rank with Hysteresis Objective Function
	Author(s)       : Omprakash Gnawali
                          Philip Levis
	Filename        : draft-ietf-roll-minrank-hysteresis-of-10.txt
	Pages           : 13
	Date            : 2012-04-26

   The Routing Protocol for Low Power and Lossy Networks (RPL) uses
   objective functions to construct routes that optimize or constrain
   the routes it selects and uses.  This specification describes the
   Minimum Rank with Hysteresis Objective Function (MRHOF), an objective
   function that selects routes that minimize a metric, while using
   hysteresis to reduce churn in response to small metric changes.
   MRHOF works with metrics that are additive along a route, and the
   metric it uses is determined by the metrics RPL Destination
   Information Object (DIO) messages advertise.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-1=
0.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-minrank-hysteresis-of-10=
.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/


From pal@cs.stanford.edu  Thu Apr 26 09:59:08 2012
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 4D5D421F8664 for ; Thu, 26 Apr 2012 09:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.732
X-Spam-Level: 
X-Spam-Status: No, score=-5.732 tagged_above=-999 required=5 tests=[AWL=0.867,  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 qXrP37dSm7H1 for ; Thu, 26 Apr 2012 09:59:07 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id C812021F8658 for ; Thu, 26 Apr 2012 09:59:07 -0700 (PDT)
Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SNS27-0003XS-GO for roll@ietf.org; Thu, 26 Apr 2012 09:59:07 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1257)
From: Philip Levis 
In-Reply-To: <20120426165711.26991.14152.idtracker@ietfa.amsl.com>
Date: Thu, 26 Apr 2012 09:59:08 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <69C1D820-2C41-4C7B-9373-605CC5D42E7D@cs.stanford.edu>
References: <20120426165711.26991.14152.idtracker@ietfa.amsl.com>
To: " WG" 
X-Mailer: Apple Mail (2.1257)
X-Scan-Signature: 47150f6aa31409442f7db1cf5c00e98a
Subject: Re: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-10.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: Thu, 26 Apr 2012 16:59:08 -0000

This version addresses Federico's final comment, relating to the metric =
value a DODAG root should advertise.

Phil

On Apr 26, 2012, at 9:57 AM, internet-drafts@ietf.org wrote:

>=20
> 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.
>=20
> 	Title           : The Minimum Rank with Hysteresis Objective =
Function
> 	Author(s)       : Omprakash Gnawali
>                          Philip Levis
> 	Filename        : draft-ietf-roll-minrank-hysteresis-of-10.txt
> 	Pages           : 13
> 	Date            : 2012-04-26
>=20
>   The Routing Protocol for Low Power and Lossy Networks (RPL) uses
>   objective functions to construct routes that optimize or constrain
>   the routes it selects and uses.  This specification describes the
>   Minimum Rank with Hysteresis Objective Function (MRHOF), an =
objective
>   function that selects routes that minimize a metric, while using
>   hysteresis to reduce churn in response to small metric changes.
>   MRHOF works with metrics that are additive along a route, and the
>   metric it uses is determined by the metrics RPL Destination
>   Information Object (DIO) messages advertise.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-=
10.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-roll-minrank-hysteresis-of-1=
0.txt
>=20
> The IETF datatracker page for this Internet-Draft is:
> =
https://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>=20


Phil


From internet-drafts@ietf.org  Mon Apr 30 15:08:12 2012
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 DA21521F8680; Mon, 30 Apr 2012 15:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.496
X-Spam-Level: 
X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 YYe4FFYJqGT5; Mon, 30 Apr 2012 15:08:11 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721D521F867A; Mon, 30 Apr 2012 15:08:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.02
Message-ID: <20120430220811.12928.30308.idtracker@ietfa.amsl.com>
Date: Mon, 30 Apr 2012 15:08:11 -0700
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-applicability-ami-06.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, 30 Apr 2012 22:08:12 -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           : Applicability Statement for the Routing Protocol for Low=
 Power and Lossy Networks (RPL) in AMI Networks
	Author(s)       : Daniel Popa
                          Jorjeta Jetcheva
                          Nicolas Dejean
                          Ruben Salazar
                          Jonathan W. Hui
                          Kazuya Monden
	Filename        : draft-ietf-roll-applicability-ami-06.txt
	Pages           : 18
	Date            : 2012-04-30

   This document discusses the applicability of RPL in Advanced Metering
   Infrastructure (AMI) networks.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-06.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-applicability-ami-06.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/