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

Alvaro Retana <> Thu, 24 October 2019 16:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79F91120013; Thu, 24 Oct 2019 09:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
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, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sa9WNV-1NE-r; Thu, 24 Oct 2019 09:27:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8FE45120052; Thu, 24 Oct 2019 09:27:10 -0700 (PDT)
Received: by with SMTP id p4so26805368wrm.8; Thu, 24 Oct 2019 09:27:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=TbhQxbEbRmHza3pMBOi50z4fM43f3zVRBLrFCH351CY=; b=eNhvZfbd1Jehf5hZvpJGvR4GQtp+tVMFXdOZbiFg++oWQsa92fTs7GKXlZafeeUnqQ osHoM+pFF3OvRG8O4N9rUSHdsrq/4/uaHXuF4HEQPpxNSQ4PQn0/R1l3xMr2XB1BLgYd dtpZSyXHyZMJkzim+twKG69lkggRPM4W7bah2lnKtuHbHwL7X2mA0Nby36nx45cyj8DJ 1ASQWaXADBAtXyL3qx/DZ4RRRaWRXvWSsHfxLXXqqTQOlxEcpnE5TbysuZnVhTcyo59Q 1tiWWDgWwUj6LYVU+cywZ3JJTRodtPJhc86zHY7uab4oqYx8c/HK6WxWlcwt0fUxnIQV 6Tlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=TbhQxbEbRmHza3pMBOi50z4fM43f3zVRBLrFCH351CY=; b=cKKwDZaz8plZ5oe6w9qzwWpNuXo16CfjmIgASI7j5zWAeLEJLMePTXcCd7t8eJmcTV vixNO+wZC5E3nHx2xdVWEevUIj8cQrk8vOKDI8F2c2Z5hSWEyzzn4KvxP0j/xdWn6IMu heeeTcBfpqXfgUiS/S3PStXQuOi0VD7v3GDzImX81bLoHeHYYBZTBinQfbZPrL6mGHEk eCjkYJ571xmfY6Z8hjMGj9Au3eMPddZvcHsperakRbH9S3tYH2wBlToeu1vBPLHFEkQb GR2OfUXujwmcApGlQjTNr604L0zMVjMcjfjqJ2ByvXp4pYfFAQhatoyQ+dqLf0QusVri VPGQ==
X-Gm-Message-State: APjAAAXJrtjacVRjIYSQoKWvzd92LWZjt7IJGoxYKqq7IJyMVTwuj8ef 3BxIvdzkA3uL0MvDtYPQdKYU5jiI17qQXK0pdvU=
X-Google-Smtp-Source: APXvYqxxAorl0kW/Cj9HiT9pyRqoEbK0ztJtm7Ha9YCUH3EsILDpUM7y7Or3kai0sB+hpzAIDkSDEvTPoigDmqFBUPk=
X-Received: by 2002:adf:8481:: with SMTP id 1mr5018512wrg.189.1571934427227; Thu, 24 Oct 2019 09:27:07 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 24 Oct 2019 09:27:06 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Thu, 24 Oct 2019 09:27:06 -0700
Message-ID: <>
To: "Pascal Thubert (pthubert)" <>, "" <>
Cc: "" <>, roll <>, Peter van der Stok <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Roll] AD Review of draft-ietf-roll-efficient-npdao-16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Oct 2019 16:27:14 -0000

On October 21, 2019 at 1:34:54 PM, Pascal Thubert
(pthubert)( wrote:



> ...
> 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.
> I agree that we are making it a "reason". This is consistent with the
> evolution of the status and its use in RFC 8505, more below.
> > 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?
> We have complex flows where the 6LBR proxies the 6LN's registration to the
> 6BBR ( so
> that in turn the 6BBR does ND proxy for the 6LN on the backbone. We use RFC
> 8505 between the 6LN and the 6LR, and between the 6LBR and the 6BBR. In case
> of a bad RC from the 6BBR to the 6LBR, the 6LBR needs to send the information
> back to the 6LR so the 6LR returns it to the 6LN using RFC 8505. We use NP
> DAO for that and for that reason, yes, we stretch the meaning. As you see the
> point is not to save a registry but to homogenize the RPL and the RFC 8505
> status.
> See and
> : )
> When the address moves on the backbone, the RPL state in the old DODAG is
> Cleaned from the 6LBR down. And the status from 6BBR to 6LBR is moved so the
> expectation is that it percolates down. The rejection is mostly to cleanup
> RPL since the leaf is expected to be long gone and registered in a different
> DODAG across the backbone.

I think I understand -- homogenizing is not a bad thing. :-)

However, I am still concerned about a couple of things:

(1) the values are not the same...for example, "moved" in rfc8505 has
a value of 3, not 130.  Why not use the same value?  The answer to
this question overflows into my second concern...

(2) draft-ietf-roll-unaware-leaves doesn't update the allocation
guidelines from rfc6550 (§6.5.1) for the Status, which then lands
"moved" in the "Rejection" range.  IOW, the meaning is changed, but
the original meaning of the DAO-ACK Status is not updated...

[We are not reviewing draft-ietf-roll-unaware-leaves here, so some of
these comments can be saved for later. ;-)]

Needless to say, I don't like this approach.  But if the WG wants to
go forward this way, then I want to make this document Normatively
depend on draft-ietf-roll-unaware-leaves because that is where the
registry and meaning for the Status values are defined.  I also think
that because of that, we will want to hold sending this document back
to the RFC Editor until we get the final text for
draft-ietf-roll-unaware-leaves (and decide that we don't need
additional review for this document).

One more thing, in reading through rfc8505, I found this text (which I
had completely missed before):

   If the receiver of the message has registration state corresponding
to the related address, it SHOULD propagate the status down the
forwarding path to the Registered Node (e.g., reversing an existing
RPL [RFC6550] path as prescribed in [Efficient-NPDAO]).

So...if the rfc8505 status is "moved" (which is actually the topic of
the paragraph from where the text above was taken in §5.7), what
should be propagated using the DCO?  130?  Where is that specified?

> > [major] "the RPL Status MUST NOT be 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?
> We wish the information to be known by all nodes, and this is a provision
> that we can reliably act differently per status value all the along the DODAG
> in the future. So we see this as protecting the future. Is that a problem?

Sorry...let me try again.  I see two problems:

(1) The values are informative, but Normatively are not to change.
How can the "MUST NOT" be enforced in the network?  How would a
receiver know if the value was changed (or not)?  You added that "we
can reliably act differently per status value" (but the text currently
reads: "value is informative and does not affect the behavior of the
receiver") -- having a consistent/reliable behavior can be achieved
only if it can be guaranteed that the value didn't change.  If it did
change, what is the expected behavior?

(2) If only values > 128 are expected, then what should a receiver do
if a value < 128 is received?  Should the DCO not be propagated

> > ...
> 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...
> Agreed, let's look at this.