Re: [Roll] draft-ietf-roll-unaware-leaves (WAS: AD Review of draft-ietf-roll-efficient-npdao-16)

Ines Robles <mariainesrobles@googlemail.com> Thu, 31 October 2019 11:57 UTC

Return-Path: <mariainesrobles@googlemail.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 EB72B120859 for <roll@ietfa.amsl.com>; Thu, 31 Oct 2019 04:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
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 Vc-AiPvstavA for <roll@ietfa.amsl.com>; Thu, 31 Oct 2019 04:57:40 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B06120817 for <roll@ietf.org>; Thu, 31 Oct 2019 04:57:40 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id p6so6385451iod.7 for <roll@ietf.org>; Thu, 31 Oct 2019 04:57:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xxx1XptVSDSbumS1sLElfQzuMiV5fMNLdsIQEtvuQZc=; b=U/2OomkCxd9+jcEbr1cGmkQ3h7BQ9ekH/tu69nNkUR1C06vA03fXaxrsRRg8TERBMi /5vunCAsa60m2QwPoIR9BSWi4ZBsfNfOHyc6ufO8Dnz+0z+tWrBcfkIUwquED+pwmmLm Z+3+bPRWiYJQBiWkuz9x5dixL3xxAnOh84NeVWtr1L9aXUeEzygOuzFf3fBNtT51Hdtw sJzyWoagbQM9D5iqRoXu3qWCAfZcGemxjHCiht/plyH3PWjbYRD6rd+2ICa31SOUHpg4 uJw2/HlKoZ41rli7N7BAYHhRsk2Cbjg80ZafxHAvJPu8wUky1ixbuvvioFhCJN5cfkvs Lpjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xxx1XptVSDSbumS1sLElfQzuMiV5fMNLdsIQEtvuQZc=; b=YopXzSudcLefB5f7rHxkfVGRQ/sxbtbfb5P9dFU5+sj7nFSDPmdwaT1qSaUMD9/3Rj 7uljNYy6igko0M/PW5IOuKcWY5L3N+g+3Z0+KwKCKjc9iCYCc8Wn1wMoN1dsGuSARUlU hglbiL/3LXb7NxqT9BETTsDXQUjn1trjRjca5jYRYLb28xVxAd1ZJ/aSyGm1ZzE81QNY /Ku29FU3eSwa53IFR0d5FNuoP6yFPutwKxQ50PbmWtXTMppgWZyrkXb3ptf1gVal2n22 uUNoCHeUPa9eu75tufFkRPR/aWTkw4ATL8AlGGf8VtLhnEqSYO0k/qPiw4EDpQ2JsjIU rgyQ==
X-Gm-Message-State: APjAAAWzK31LzG3TOc7azRjS3HbnA0umWrS82RXsPDAPpYHBoF9A+Nw+ eonTQtKZuCPGFvjPokbl1ZktAM7cWQdht8tGo3qH+DQr
X-Google-Smtp-Source: APXvYqx9w5KvPzsqCxqQZgTnEkKrt19GoeS4jIi7EZQ/0lc/OEwfEqo1YQejmM0alJ79pYBwYqr+wEjTafAUHyz3ERM=
X-Received: by 2002:a5d:83d7:: with SMTP id u23mr4494126ior.27.1572523059420; Thu, 31 Oct 2019 04:57:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESswgX8YynN=tehXDMg+suOiiaCTpnoP9LxoH3orG06_Trw@mail.gmail.com> <MN2PR11MB3565181C2DDC7A3FB7DFCB2FD8690@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMMESsz_MJSC+Sx5hPsTFVufqEGUYjuTJFt7pJs7mut_7nHRxA@mail.gmail.com> <MN2PR11MB3565998D4CD88FF786E892AED8650@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMMESsxBriytQmDELLgOBw4zL8EWKbPKf0i6gztTbuvHDBxWZQ@mail.gmail.com> <MN2PR11MB356591018987E7D4FA6215A6D8610@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMMESswv7rj56RXsV-OWcoDJUf0wDmUpPdAqo1Ev5udzEHVdeQ@mail.gmail.com> <MN2PR11MB35656761C27560189BFFA40ED8600@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMMESszgF8EG6KpZoC_WUEcE+4FgmgmNEbFxDivv6d8v1VoZzw@mail.gmail.com>
In-Reply-To: <CAMMESszgF8EG6KpZoC_WUEcE+4FgmgmNEbFxDivv6d8v1VoZzw@mail.gmail.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Thu, 31 Oct 2019 13:57:02 +0200
Message-ID: <CAP+sJUcqyVH8MQP2E5KM+fPEv3ZHE5CrSiMuiDxGgBODZM7QEg@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005ba0e70596338e74"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/s5pt6vJq8naTDdTmWz7TmMI32is>
Subject: Re: [Roll] draft-ietf-roll-unaware-leaves (WAS: AD Review of draft-ietf-roll-efficient-npdao-16)
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: Thu, 31 Oct 2019 11:57:43 -0000

Hi Pascal,

Agree with the status codes.

Questions:

1- In the  Table 1: RPL Status per RFC 6550, when the status is zero, would
it be good to add between  brackets (Success/Unqualified acceptance -since
you mentioned it when explaining bit E -) like: ,

                  +---------+---------------------------+

                  | Range   | Meaning                   |

                  +=========+===========================+

                  | 0       | RFC 6550 (Success)        |

                  +---------+---------------------------+



2- where states "...When the 'A' flag is reset," should it be better "When the
'A' flag is not set," ?

Thank you,

Ines.

On Wed, Oct 30, 2019 at 5:43 PM Alvaro Retana <aretana.ietf@gmail.com>
wrote:

> Just for clarity.
>
> The changes proposed here are for draft-ietf-roll-unaware-leaves
> (not draft-ietf-roll-efficient-npdao).  I changed the subject to reflect
> that.
>
> Alvaro.
>
> On October 30, 2019 at 6:37:15 AM, Pascal Thubert (pthubert) (
> pthubert@cisco.com) wrote:
>
> Dear all :
>
>
>
> There is a need in the RUL draft to carry a 6LoWPAN ND status inside a RPL
> status so we can avoid duplicating DAR/DAC and DAO/DAO-ACK through the
> network. This also allows async communication down the DODAG through DCO
> (efficient NPDAO).
>
>
>
> Alvaro pointed out that mapping one  status in the other as proposed so
> far was not too clean. The change proposed herein addresses this concern.
> The change would be adding another control bit in the RPL status and
> formalizing the format as follows:
>
>
>
> 7.  Updated RPL Status
>
>
>
>    The RPL Status is defined in section 6.5.1. of [RFC6550] for use in
>
>    the DAO-Ack message and values are assigned as follows:
>
>
>
>                   +---------+---------------------------+
>
>                   | Range   | Meaning                   |
>
>                   +=========+===========================+
>
>                   | 0       | RFC 6550                  |
>
>                   +---------+---------------------------+
>
>                   | 1-127   | Not an outright rejection |
>
>                   +---------+---------------------------+
>
>                   | 128-255 | Rejection                 |
>
>                   +---------+---------------------------+
>
>
>
>                       Table 1: RPL Status per RFC 6550
>
>
>
>    This specification extends the scope of the RPL status to be used in
>
>    RPL DCO messages.  Furthermore, this specification enables to carry
>
>    the status values defined for use in the IPv6 ND Extended Address
>
>    Registration Option (EARO) and listed in table 1 of [RFC8505].  Only
>
>    EARO status values in the range 0-63 can be transported.
>
>
>
>    The resulting RPL status is as follows:
>
>
>
>                         0 1 2 3 4 5 6 7
>
>                       +-+-+-+-+-+-+-+-+
>
>                        |E|A|  Value    |
>
>                        +-+-+-+-+-+-+-+-+
>
>
>
>                         Figure 2: RPL status Format
>
>
>
>    RPL Status subfields:
>
>
>
>    E:  1-bit flag.  Set to indicate a rejection.  When not set, a value
>
>       of 0 indicates success and other values indicate an non-outright-
>
>       rejection as per RFC 6550.
>
>
>
>    A:  1-bit flag.  Indicates the type of the status value.
>
>
>
>    Status Value:  6-bit unsigned integer.  If the 'A' flag is set this
>
>       field transports a status value defined for IPv6 ND EARO.  When
>
>       the 'A' flag is reset, the status value is defined in a RPL
>
>       extension
>
>
>
>    When building a DCO message upon an IPv6 ND NA or DAC message, the
>
>    root MUST place the ARO status unchanged in a mapped DCO with the 'A'
>
>    bit set.  Conversely the 6LR MUST place the ARO status unchanged in
>
>    the NA(EARO) that is built upon a DCO with the 'A' bit set.
>
>
>
> Comments welcome (and urgent!). Unless I see opposition I plan to publish
> before cutoff so we can discuss it at IETF 106.
>
>
>
> All the best;
>
>
>
> Pascal
>
>
>
> *From:* Alvaro Retana <aretana.ietf@gmail.com>
> *Sent:* mardi 29 octobre 2019 23:10
> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>om>;
> draft-ietf-roll-efficient-npdao@ietf.org
> *Cc:* roll-chairs@ietf.org; roll <roll@ietf.org>rg>; Peter van der Stok <
> consultancy@vanderstok.org>
> *Subject:* RE: AD Review of draft-ietf-roll-efficient-npdao-16
>
>
>
> Hi!
>
>
>
> I’m fine with the changes proposed to draft-ietf-roll-efficient-npdao.
>
>
>
> I want to see the WG reach consensus on the changes related
> to draft-ietf-roll-unaware-leaves.
>
>
>
> Thanks!
>
>
>
> Alvaro.
>
>
>
> On October 29, 2019 at 5:52:13 AM, Pascal Thubert (pthubert) (
> pthubert@cisco.com) wrote:
>
>  If you agree with the proposed line above I'll make editions and come
> back to you for more comments and/or approval.
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>