Re: [Roll] [roll] #87: Can't we split the target from the RDO ?

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 10 April 2012 09:48 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.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 <roll@ietfa.amsl.com>; 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 <roll@ietfa.amsl.com>; 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 <roll@ietf.org>; 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: <BDF2740C082F6942820D95BAEB9E1A84016A80E6@XMB-AMS-108.cisco.com>
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)" <pthubert@cisco.com>
To: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>, mcr@sandelman.ca
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 <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 09:48:32 -0000

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" <trac+roll@trac.tools.ietf.org>
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: <https://svn.tools.ietf.org/wg/roll/trac/ticket/87>
roll <http://tools.ietf.org/wg/roll/>

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