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

Alvaro Retana <aretana.ietf@gmail.com> Wed, 30 October 2019 15:43 UTC

Return-Path: <aretana.ietf@gmail.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 69A8712087F for <roll@ietfa.amsl.com>; Wed, 30 Oct 2019 08:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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, UNPARSEABLE_RELAY=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=gmail.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 pqdFQnwVFkkr for <roll@ietfa.amsl.com>; Wed, 30 Oct 2019 08:43:11 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 4A151120110 for <roll@ietf.org>; Wed, 30 Oct 2019 08:43:07 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id v3so4550831wmh.1 for <roll@ietf.org>; Wed, 30 Oct 2019 08:43:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=gnW6P8lEJx5ToU8fjekB0tlP3/AW+QEgzJhWujtji8Q=; b=iByxiSKtiNbM7DozZ24IT380QsOe3KsbTx1lxhfWhJch+ZeXomYW2dzsCMsofjxlMx fk0WaqoYZN2AV9zT1d4Y0FcGOEAxUqXPCpG3ZrXKnD8Tq/oVR5Ib+0KIj6Og+05cSMKv /xzAoW8K+cqjJ9HKYtC40wIt2ItuqNwONHv9b2VezkMkMvEInW5l7pIwpWsE1wJlqLO0 3bNPbEzngKh+k+uXFpr9ilQyQeJU+PQXmfSV2v96WsAFMarpKv3sa1rMVMxeuyVP4uSW tBGwZ6KXRM0wRRNVHEtwsGiTpOYkvuAmaKbMjA+k5ruioJcjBDGBTBsaX5FlRVIPYlGQ CMOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=gnW6P8lEJx5ToU8fjekB0tlP3/AW+QEgzJhWujtji8Q=; b=I1EtgCgFp9Lt2uNZbYXFjzXO3nzIulmx8MjPoAcX1XGuksTN9Bx/yjoC9AaBHdYc8m jP6PMSZeTSmxkvUDmt8I+LUSp0CO97A22B9JJYml73vIGzelomzPmYrXZMqNCximetsJ OFjjAmOxVwj/iV9LI7wV6HWTRhbw3UBt+9j2rnF55AjF1BSzyGh8nqaMyQGCup4apokW mpDs/xUC8Q/PdT6JNfv1rgbdR/XQGVLwT84i878xOPvj0FKoDkq/LzR6emQR3oUDGgLg mR0wDCh0yO5+1sIuBQFD28GkBvSnPNc9rX9lkbPk0Hfzb9G4/WQuREWCne77ONciC9oN caBA==
X-Gm-Message-State: APjAAAV+hyg5CCNA2IOxPmNAXjxMtuA30flDzemTx8wz7ltg6wyfTgEw nOXisvqGXEz7yxAVXB8w72ajBET6w+YwdmOFr/I=
X-Google-Smtp-Source: APXvYqxufWrjYxCyFGU7eP40rPegy94CimO0pVsCz56uL7ryF2eXMW+uysjkieGrvXg1+nQsSByIiqaCCpBok0xzPBo=
X-Received: by 2002:a05:600c:2551:: with SMTP id e17mr94045wma.51.1572450185785; Wed, 30 Oct 2019 08:43:05 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 30 Oct 2019 08:43:05 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <MN2PR11MB35656761C27560189BFFA40ED8600@MN2PR11MB3565.namprd11.prod.outlook.com>
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>
MIME-Version: 1.0
Date: Wed, 30 Oct 2019 08:43:04 -0700
Message-ID: <CAMMESszgF8EG6KpZoC_WUEcE+4FgmgmNEbFxDivv6d8v1VoZzw@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, roll <roll@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c0368f0596229672"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/TrS6Q2ziajjxxMuil9H00d8Jj5E>
Subject: [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: Wed, 30 Oct 2019 15:43:14 -0000

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.