Re: [Roll] [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.
Mukul Goyal <mukul@uwm.edu> Tue, 10 April 2012 12:55 UTC
Return-Path: <prvs=440167eea=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 A722C21F85D5 for <roll@ietfa.amsl.com>; 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 <roll@ietfa.amsl.com>; 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 <roll@ietf.org>; 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
From: Mukul Goyal <mukul@uwm.edu>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
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 <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
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: 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 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" <mukul@uwm.edu> To: "Pascal Thubert (pthubert)" <pthubert@cisco.com> Cc: jpv@cisco.com, "roll" <roll@ietf.org> 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)" <pthubert@cisco.com> To: "Mukul Goyal" <mukul@uwm.edu> 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" <trac+roll@trac.tools.ietf.org> 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: <http://trac.tools.ietf.org/wg/roll/trac/ticket/85> roll <http://tools.ietf.org/wg/roll/>
- [Roll] [roll] #85: which lifetime is for the end … roll issue tracker
- Re: [Roll] [roll] #85: which lifetime is for the … Mukul Goyal
- Re: [Roll] [roll] #85: which lifetime is for the … Mukul Goyal
- Re: [Roll] [roll] #85: which lifetime is for the … Mukul Goyal
- Re: [Roll] [roll] #85: which lifetime is for the … Pascal Thubert (pthubert)
- Re: [Roll] [roll] #85: which lifetime is for the … Mukul Goyal
- Re: [Roll] [roll] #85: which lifetime is for the … Pascal Thubert (pthubert)
- Re: [Roll] [roll] #85: which lifetime is for the … Mukul Goyal
- Re: [Roll] [roll] #85: which lifetime is for the … Pascal Thubert (pthubert)
- Re: [Roll] [roll] #85: which lifetime is for the … roll issue tracker