IETF Logo Mail Archive

Re: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 10 December 2019 16:36 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 1E21F12080E for <roll@ietfa.amsl.com>; Tue, 10 Dec 2019 08:36:17 -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 j_FDnKRaZi_J for <roll@ietfa.amsl.com>; Tue, 10 Dec 2019 08:36:15 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73FD1200E0 for <roll@ietf.org>; Tue, 10 Dec 2019 08:36:14 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 716E33897C for <roll@ietf.org>; Tue, 10 Dec 2019 11:32:27 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AEA1868B for <roll@ietf.org>; Tue, 10 Dec 2019 11:36:13 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <CAO0Djp1K18CGXv+YC9H4qgCgyH=fkon4ihFAUmgfKwdYQy38dQ@mail.gmail.com>
References: <CAO0Djp1K18CGXv+YC9H4qgCgyH=fkon4ihFAUmgfKwdYQy38dQ@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, 10 Dec 2019 11:36:13 -0500
Message-ID: <10903.1575995773@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/y40_JnzDkrXOi1KUQJJZZty6jwg>
Subject: Re: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage
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, 10 Dec 2019 16:36:17 -0000

Rahul Jadhav <rahul.ietf@gmail.com> wrote:
    > Hello Pascal, Michael, All,

    > I would like to open the discussion about carrying the ND Status as
    > part of the RPL Status as mentioned in the Unaware-leaves draft [1].

    > The proposition by Unaware-leaves draft wrt RPL status is:
    > Use of RPL status to carry ND status. ND Status (RFC 8505) is 8bits,

Forgive my slowness, new documents don't always seep into my brain quickly.
Is this RFC8505 section 9.4, ARO Status Values?
I can't find ND status in 8505 :-)
I re-read section 7 of unaware leaves, but I'm afraid I'm having difficulties
knitting all the pieces together.
(I suppose it is time to write code, it's the only way stuff sinks in for me)

    > and RPL status is 8bits. RPL status MSB is already used to indicate
    > outright rejection. Unaware-leaves draft dedicates 2nd MSB in RPL
    > status to indicate ND status. This means only lower 6-bits of ND
    > Status can be at most carried in RPL status.

    > The RPL Status carrying ND Status seems not adequate,
    > 1) RPL Status can carry only lower 6bits of the 8bits of ND Status
    > 2) RPL Status and ND Status may not always be correlated.

    > How about using a different ND Option in RPL messaging to keep the ND
    > handling segregated? The unaware draft can say that this option can be
    > carried in DCO or any other RPL message it requires. ND status/option
    > may have to be carried only in specific cases which involves unaware
    > leaves and as such the control overhead due to option header may not
    > be much.

    > This ND option could also be easily extended for future purposes since
    > we may have additional fields in the future from ND to be carried with
    > RPL.


    > [1] https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-07


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email