IETF Logo Mail Archive

Re: [Roll] DAO-Projection and new MOPs

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 18 December 2018 17:00 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 DDD17131147 for <roll@ietfa.amsl.com>; Tue, 18 Dec 2018 09:00:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 5KJ75-rHFHCi for <roll@ietfa.amsl.com>; Tue, 18 Dec 2018 09:00:48 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12CC413112B for <roll@ietf.org>; Tue, 18 Dec 2018 09:00:48 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D70562008C for <roll@ietf.org>; Tue, 18 Dec 2018 12:00:39 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 151E1B5D; Tue, 18 Dec 2018 12:00:46 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 12D0D2BA for <roll@ietf.org>; Tue, 18 Dec 2018 12:00:46 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <CAO0Djp0wiHUg15SfLzqXRF6Ko9JBbeL7C9CLZ6HRXcNxf+=Gew@mail.gmail.com>
References: <CAO0Djp0wiHUg15SfLzqXRF6Ko9JBbeL7C9CLZ6HRXcNxf+=Gew@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 18 Dec 2018 12:00:46 -0500
Message-ID: <9098.1545152446@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/_6PIal4UIgtJHbaNZzM1epJbItE>
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: Tue, 18 Dec 2018 17:00:50 -0000

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