IETF Logo Mail Archive

Re: [Roll] DAO-Projection and new MOPs

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Wed, 19 December 2018 06:33 UTC

Return-Path: <rahul.jadhav@huawei.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 1769B12D84D for <roll@ietfa.amsl.com>; Tue, 18 Dec 2018 22:33:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 cNhD8p6Wj42M for <roll@ietfa.amsl.com>; Tue, 18 Dec 2018 22:33:22 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342F5124408 for <roll@ietf.org>; Tue, 18 Dec 2018 22:33:22 -0800 (PST)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 36DD1ADCD5CD2 for <roll@ietf.org>; Wed, 19 Dec 2018 06:33:18 +0000 (GMT)
Received: from BLREML702-CAH.china.huawei.com (10.20.4.171) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 19 Dec 2018 06:33:19 +0000
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.149]) by blreml702-cah.china.huawei.com ([::1]) with mapi id 14.03.0415.000; Wed, 19 Dec 2018 12:03:08 +0530
From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] DAO-Projection and new MOPs
Thread-Index: AQHUimibpgJS52fpKESIdA4u6tiTBqWEdWsAgAE8iVA=
Date: Wed, 19 Dec 2018 06:33:07 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5DD4E008@BLREML503-MBX.china.huawei.com>
References: <CAO0Djp0wiHUg15SfLzqXRF6Ko9JBbeL7C9CLZ6HRXcNxf+=Gew@mail.gmail.com> <9098.1545152446@localhost>
In-Reply-To: <9098.1545152446@localhost>
Accept-Language: en-IN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.157.44]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/41YlYLZKMXZ3ZCfnvQ3bPIa4_CY>
Subject: Re: [Roll] DAO-Projection and new MOPs
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: Wed, 19 Dec 2018 06:33:24 -0000

Actually this (new ICMP code) would have worked very nicely but as you mentioned the legacy nodes won't send back any response for unknown codes.

I checked whether 6550 has an explicit statement and it does.

Section 6:
 "If a node receives a RPL control message with an unknown Code field,
   the node MUST discard the message without any further processing, MAY
   raise a management alert, and MUST NOT send any messages in response."


> -----Original Message-----
> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson
> Sent: 18 December 2018 22:31
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: [Roll] DAO-Projection and new MOPs
> 
> 
> Rahul Jadhav <rahul.ietf@gmail.com> wrote:
>     > To begin with, I was wondering, do we really need new MOPs for
>     > dao-projection?  Can we handle dao-projection as something which can
> be
>     > incrementally added to existing MOPs? For e.g. if the network is
>     > established in NS-MOP (non-storing MOP=1) then we can use P-DAO to
>     > project routes down the network and if the destination legacy node does
>     > not understand P-DAO then it should send a negative ACK for the DAO.
>     > Problem is, right now i don't see how legacy nodes (who dont
> understand
>     > new RPO options) can distinguish between P-DAO and normal DAO.  As i
>     > understand, the new MOP is required because of this new mandatory
>     > handling required for P-DAOs. Is it possible to have P-DAO such that
>     > legacy nodes generate negative ACK if they cannot handle it?
> 
> We have lots of ICMP code fields available, we could do:
> 
>    o  0x04: Projected Destination Advertisement Object
> 
> If we want to be able to incrementally deploy P-DAO, then we need to be
> sure that devices will send some kind of negative statement back for ICMP
> codes that are unknown.  It's supposed to be an ICMP parameter error, but
> maybe not everything does that.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>

v2.23.0 | Report a Bug | By Email