Re: [Roll] [roll] #90: use of transient instance ID
Mukul Goyal <mukul@uwm.edu> Wed, 11 April 2012 01:39 UTC
Return-Path: <prvs=441eb7f02=mukul@uwm.edu>
X-Original-To: roll@ietfa.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 <roll@ietfa.amsl.com>; 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 <roll@ietfa.amsl.com>; 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 <roll@ietf.org>; 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
From: Mukul Goyal <mukul@uwm.edu>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Message-ID: <1728662895.1887339.1334108343320.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <BDF2740C082F6942820D95BAEB9E1A84016A80ED@XMB-AMS-108.cisco.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] #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 <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
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 determine when all stale states can be considered gone. Sounds good. >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. Not sure what you mean. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" <pthubert@cisco.com> To: "Mukul Goyal" <mukul@uwm.edu>, 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" <trac+roll@trac.tools.ietf.org> 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: <https://svn.tools.ietf.org/wg/roll/trac/ticket/90> roll <http://tools.ietf.org/wg/roll/> _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
- [Roll] [roll] #90: use of transient instance ID roll issue tracker
- Re: [Roll] [roll] #90: use of transient instance … Mukul Goyal
- Re: [Roll] [roll] #90: use of transient instance … Pascal Thubert (pthubert)
- Re: [Roll] [roll] #90: use of transient instance … Mukul Goyal
- Re: [Roll] [roll] #90: use of transient instance … Pascal Thubert (pthubert)
- Re: [Roll] [roll] #90: use of transient instance … Mukul Goyal
- Re: [Roll] [roll] #90: use of transient instance … Pascal Thubert (pthubert)
- Re: [Roll] [roll] #90: use of transient instance … Mukul Goyal
- Re: [Roll] [roll] #90: use of transient instance … Pascal Thubert (pthubert)
- Re: [Roll] [roll] #90: use of transient instance … roll issue tracker