[Roll] Closure text for ticket #87
Mukul Goyal <mukul@uwm.edu> Thu, 12 April 2012 02:44 UTC
Return-Path: <prvs=4421d3a9b=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 2598511E80E6 for <roll@ietfa.amsl.com>; 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 <roll@ietfa.amsl.com>; 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 <roll@ietf.org>; 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
From: Mukul Goyal <mukul@uwm.edu>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Message-ID: <1034499059.1903619.1334198651843.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <BDF2740C082F6942820D95BAEB9E1A84016A80E6@XMB-AMS-108.cisco.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 #87
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: 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
- [Roll] [roll] #87: Can't we split the target from… roll issue tracker
- Re: [Roll] [roll] #87: Can't we split the target … Mukul Goyal
- Re: [Roll] [roll] #87: Can't we split the target … Pascal Thubert (pthubert)
- [Roll] Closure text for ticket #87 Mukul Goyal
- Re: [Roll] [roll] #87: Can't we split the target … roll issue tracker