Re: [Roll] Adopting turnon 8138

Carsten Bormann <cabo@tzi.org> Tue, 05 November 2019 08:27 UTC

Return-Path: <cabo@tzi.org>
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 6AC8E1201E4 for <roll@ietfa.amsl.com>; Tue, 5 Nov 2019 00:27:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQUdy1Ui9C6A for <roll@ietfa.amsl.com>; Tue, 5 Nov 2019 00:27:01 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F54A12006E for <roll@ietf.org>; Tue, 5 Nov 2019 00:27:01 -0800 (PST)
Received: from client-0123.vpn.uni-bremen.de (client-0123.vpn.uni-bremen.de [134.102.107.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 476jSg30Hnzyg1; Tue, 5 Nov 2019 09:26:59 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <76EB15DE-5CCD-4088-AE87-FF68436BC267@cisco.com>
Date: Tue, 5 Nov 2019 09:26:58 +0100
X-Mao-Original-Outgoing-Id: 594635217.342867-a30e7de06dfc98fd33a921958dade502
Content-Transfer-Encoding: quoted-printable
Message-Id: <268BA36A-AC92-4988-B971-A850CEB7EB39@tzi.org>
References: <MN2PR11MB3565D8323B4C7860396B2F8DD8610@MN2PR11MB3565.namprd11.prod.outlook.com> <CADnDZ8-p+HiLw9eoq8zKnRh9PqiT4HGYXdg_Cqid=eGQmd=V5g@mail.gmail.com> <CAP+sJUebKNAAEixtJQ-BFTDt3Aq9X2=MvgYJw_NrCrbtd1P3=g@mail.gmail.com> <76EB15DE-5CCD-4088-AE87-FF68436BC267@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/knD6Zg3BFeF0RGfa2_VHpOMOdjo>
Subject: Re: [Roll] Adopting turnon 8138
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 05 Nov 2019 08:27:03 -0000

We generally signal compression capabilities using 6CIO (see RFC 7400).

I think this discussion is a symptom of ROLL trying to usurp some of the neighbor discovery functions, so in the end we never know where to put what.  Of course piggybacking routing setup into neighbor setup is a good optimization, but doing neighbor setup implicitly based on having seen routing setup is creating this problem.  Maybe we can clean this up at some point.

Grüße, Carsten


> On Nov 5, 2019, at 08:31, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
> DODAG configuration as it’s name indicates is configuration. The goal is to tell dynamically how the protocol is operated as opposed to configuring all nodes separately. 
> 
> RPL operates in control plane and data plane. It does proactive route setup and reactive invalidation. These are all trade offs that are chosen to optimize energy and bandwidth efficiency vs. some theoretical perfection.
> 
> The current proposal does not generate any additional transmission. Defining a new protocol to set one bit might appear more perfect but would require bandwidth and code footprint that we do not have.
> 
> You are very free to propose an alternate solution with enough details so we can understand it, even push a draft, and then the WG will make the best of all it sees.
> 
> Pascal 
> 
> ---------- Forwarded message ---------
>> From: Abdussalam Baryun <abdussalambaryun@gmail.com>
>> Date: Fri, Nov 1, 2019 at 11:55 AM
>> Subject: Re: [Roll] Adopting turnon 8138
>> To: Routing Over Low power and Lossy networks <roll@ietf.org>
>> 
>> 
>> I don't think it is the right approach, why using the DODAG configuration for compression? this compression turn on/off is not for the DODAG construction but for packets. I think we should separate configurations of the RPL routing standards and of the packet compression standards. We may add another configuration option per DODAG or another way.
>> 
>> What do you think?
>> 
>> AB 
>> 
>> On Tue, Oct 29, 2019 at 4:34 PM Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>> Dear all
>> 
>>  
>> 
>> https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-03 is a simple draft that completes RFC 8138 with bits in the config option to enable turning it on in an brown field.
>> 
>> There’s no black magic and it would be good to progress it in the background rather than forget it.. Could we consider adoption?
>> 
>>  
>> 
>> All the best
>> 
>>  
>> 
>> Pascal
>> 
>> _______________________________________________
>> 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
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll