[Roll] AD Review of draft-ietf-roll-efficient-npdao-16

Alvaro Retana <aretana.ietf@gmail.com> Thu, 17 October 2019 18:39 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E385A120B93; Thu, 17 Oct 2019 11:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dNa86U5JGmLB; Thu, 17 Oct 2019 11:39:51 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 A8202120B90; Thu, 17 Oct 2019 11:39:50 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id h2so2592925edn.3; Thu, 17 Oct 2019 11:39:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=40IoND01lXyJ419S/4W5GOIrG82lDd29HhV0YEd8XxI=; b=kSNFum5LJIscrDq9QlIU5gM6XERrB2/PAcAqDdNUVYQTvSdnSF4P0cU4HyNlwCa0HI AYLqUHvyNsLYUKrX8S+lNdWpc0BCxulARKY/RJH6a3aWGm6imLdGJAxzacobrxcQyOw4 tgHbc3THJ2TpMhmCs6YczsuYly3G+6gI0vhJSioUp0d3yasYi3Cp2JToo6y3wd/EtUD/ awUTNGFJHgDzNtXGBZLU+XJ6o5+jCfYKog8hqMARXMzBEwTRkokO04R2XW3vohXL9sjQ pr9VApHyWYTMfAn3x7fZcuOS9rVzbPBv7TAInxoI9c8KtPWUqnKALBG1/6XrU4G35EnB iuyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=40IoND01lXyJ419S/4W5GOIrG82lDd29HhV0YEd8XxI=; b=MZyPY7Zw2yTsFIodr+/PjBrreHxjbnVbD0rillnUMwuo/i2CAoAmoU3ER3rnDFA8B2 waL5ukN1U8PoQf4+R3saTOjmj0G1MXh9O/ZocEIczO/MNsXXAzDPUeGgoBonuZpUltw5 DM+dZr2NzTg2IpbIWRCuTkeYIJoqH+ZuRL5WKVkyqHqoOedKi1H8QkmMgX7LUqr43k/G hDeJ+zXFM+imJAVEb0rYh3pFe0HA69afDUZAqgn+Vr2OvlKtA+mqDmp9OI362228xhsM F2nlM9G+zbXIPzfY7dV38yIqLV5EdWC9cSMlHriv6hO1CTdoiN2m0q+1nIA0rul/wZee XPIQ==
X-Gm-Message-State: APjAAAX2mZnsjPhR0xnxA4SVjyj1A+Hs626eZvgtPdduMcBOkCT2D4s2 xO5ChLrnVUffItvUBhFA/5YdvX7KxcOn5uZbH9vLMA==
X-Google-Smtp-Source: APXvYqz9hHM8R9FrGVC8iRdGKwY4DEn/993Mx27HgiEI/x1DJMH8PnWXHjb6OKJwFabSCvUDy0tARR0zjiKLXi+VleU=
X-Received: by 2002:a17:906:7f04:: with SMTP id d4mr5035709ejr.178.1571337588922; Thu, 17 Oct 2019 11:39:48 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 17 Oct 2019 11:39:48 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Thu, 17 Oct 2019 11:39:48 -0700
Message-ID: <CAMMESswgX8YynN=tehXDMg+suOiiaCTpnoP9LxoH3orG06_Trw@mail.gmail.com>
To: draft-ietf-roll-efficient-npdao@ietf.org
Cc: Peter van der Stok <consultancy@vanderstok.org>, roll-chairs@ietf.org, roll <roll@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/cxyoy9uUtWQoUsHc0ge8VUx-6KY>
Subject: [Roll] 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, 17 Oct 2019 18:39:54 -0000

Dear authors:

I reviewed the changes (only) and have some comments/questions.
Please take a look below.

I would like for my concerns to be addressed before sending the
document back to the RFC Editor.



[Line numbers from idnits.]

384	4.3.  Destination Cleanup Object (DCO)
393	     0                   1                   2                   3
394	     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
395	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
396	     | RPLInstanceID |K|D|   Flags   |  RPL  Status  | DCOSequence   |
397	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
398	     |                                                               |
399	     +                                                               +
400	     |                                                               |
401	     +                            DODAGID(optional)                  +
402	     |                                                               |
403	     +                                                               +
404	     |                                                               |
405	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
406	     |   Option(s)...
407	     +-+-+-+-+-+-+-+-+

[nit] s/RPL  Status/RPL Status   To make it easier to search, please
eliminate the extra space.

434	   RPL Status: The RPL Status as defined in section 6.5.1 of [RFC6550].
435	   Indicative of the reason why the DCO happened, the RPL Status MUST
436	   NOT be changed as the DCO is propagated down the route being
437	   invalidated.  This value is informative and does not affect the
438	   behavior of the receiver.  In particular, unknown values are ignored
439	   by the receiver.  Only Rejection Codes (values of 128 and above) are
440	   expected in a DCO.

[major] rfc6550 defines a field called "Status" (not "RPL Status") for
the DAO-ACK, which "Indicates the completion", and not "the reason why
the DCO happened".  Also, the value of "130 indicating that the
address has moved" is not consistent with what seems to be intent in
the DAO-ACK: "Rejection; the node sending the DAO-ACK is unwilling to
act as a parent."   While the interpretation could be stretched, it
seems to me that it would be better to simply create a new "RPL
Status" field/registry that applies specifically to the DCO.

>From the discussion on the list, it was proposed that a common
registry can be defined in draft-ietf-roll-unaware-leaves.  Looking at
that draft, and the fact that it defines "RPL Status values for use in
DAO-ACK and DCO that map the 6LoWPAN ND values defined in Table 1 of
[RFC8505]", where 130 is called "Moved", but the definition in rfc8505
refers to a stale registration...  IOW, the use of 130 doesn't seem to
map well to the definitions in rfc8505.  This seems to be another
reason to create an independent field/registry.

Is there a strong reason for the reuse?

[major] "the RPL Status MUST NOT be changed...is informative and does
not affect the behavior of the receiver...unknown values are
ignored...Only Rejection Codes (values of 128 and above) are expected
in a DCO."

If the value doesn't matter (informative) and unknown ones are
ignored, why specify that it MUST NOT change?  What is the Normative
value of that?  Specifically, if the value was changed to something <
128, what should the receiver do?

574	4.5.  Unsolicited DCO

576	   A 6LR may generate an unsolicited DCO to unilaterally cleanup the
577	   path on behalf of the target entry.  The 6LR has all the state
578	   information, namely, the Target address and the Path Sequence,
579	   required for generating DCO in its routing table.  The conditions why
580	   6LR may generate an unsolicited DCO are beyond the scope of this
581	   document but some possible reasons could be:

583	   1.  On route expiry of an entry, a 6LR may decide to graciously
584	       cleanup the entry by initiating DCO.
585	   2.  6LR needs to entertain higher priority entries in case the
586	       routing table is full, thus resulting in eviction of an existing
587	       routing entry.  In this case the eviction can be handled
588	       graciously using DCO.

590	   Note that if the 6LR initiates a unilateral path cleanup using DCO
591	   and if it has the latest state for the target then the DCO would
592	   finally reach the target node.  Thus the target node would be
593	   informed of its invalidation.

[] This section wasn't changed, but it seems to me that there's an
opportunity to indicate these known reasons as Status in the DCO.
Among other things, the target node would be able to identify the
reason for the unsolicited DCO...