Re: [Roll] AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont)

Alvaro Retana <aretana.ietf@gmail.com> Fri, 06 November 2020 22:10 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 AA1813A0DBF; Fri, 6 Nov 2020 14:10:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 gBVpo_k9mOJ0; Fri, 6 Nov 2020 14:10:22 -0800 (PST)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 C22F33A0DAD; Fri, 6 Nov 2020 14:10:21 -0800 (PST)
Received: by mail-ed1-x534.google.com with SMTP id o20so2801138eds.3; Fri, 06 Nov 2020 14:10:21 -0800 (PST)
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:content-transfer-encoding; bh=4AjVJVb7tQphaupwH+5pvOtrrZeuzVJaMP1wcm6RE90=; b=PKUxmN1DDlk8Ho8mFIFc0Y+9gwp0Xh3Xlzgi3JvAV6Ho11xGMLkBRjzTvgqo6ynIKk noIPQbiyQ680y1kwTzV2vCznCKMhwp8fGuaCV7b7uDjectzbORHN1wX6N6qkshE9QGrT Mu6D+dKz/DAlsFQqtfuDOZ8Np9Sk8g8b40TrZPGRAK6Y8tAtg8nJaLL2bp7U0yQq7OX+ ZyJF2mhzShYWTRoXicge7aPpnpjsCSrMBFggnAxSpVFHATj2YxhBpkQA0/kHCF1+kYTK 3mpJ8jM8np2MENma0TDxSQKJtSFSgl5xlWycAHofasdQOmsA1+/Katne5qVlJRhFjsGR gzbw==
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:content-transfer-encoding; bh=4AjVJVb7tQphaupwH+5pvOtrrZeuzVJaMP1wcm6RE90=; b=iz3KV4QLAhklhoYtsrVodzTZ67JRew5/nofWanqp87xtOta49gm103bxwJRMpso2zP 14UlEcsCQP/iZKRSz1pBfc7mREYtTku5A1vZ7HVS4M7PaLVzBLsWcsw2EbJ5bC3eOyKE jv3yEhl10cbbbgWwYl72Ru5dP3JjqTuWGUi5ssYbbka3S3ccjv/Rw7oPkL0HvmstDMJE m1FWNlnINKBFxGpSTmSFyZPSquL2xnjAXyljArOY09n3b+S8YzJdxbgfdhNqXY5i5KhO WZ03+Q+2u4C30fT7k6fhSYlnKZT5/yEspD7zgM+ZV/+DqE67Mwuns3wPAOA8+X+qOeY1 eqQw==
X-Gm-Message-State: AOAM530gtg8RFr2/PTcbOgIeXsmorVxYNSVZHeOg7TswkB6M/EF9djxX AlgiQfDuJ24AymQkEXDcGujt0x39Qpr2ss9sA7o=
X-Google-Smtp-Source: ABdhPJzjBrs4kdxveTcO4rAyKt9+kMbZdYHx3JRF8TnPb3izg8QYi06C1iR+DZav5hFX7O5lEf3jCE4RoeiEkF9L0CE=
X-Received: by 2002:a05:6402:b8e:: with SMTP id cf14mr4172302edb.86.1604700619940; Fri, 06 Nov 2020 14:10:19 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 6 Nov 2020 17:10:18 -0500
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CY4PR11MB135293C625696CFC5997520ED8170@CY4PR11MB1352.namprd11.prod.outlook.com>
References: <CY4PR11MB135293C625696CFC5997520ED8170@CY4PR11MB1352.namprd11.prod.outlook.com>
MIME-Version: 1.0
Date: Fri, 6 Nov 2020 17:10:18 -0500
Message-ID: <CAMMESsx6mF9W1+O0fpCy-Q-0jbmvc4UBo_HG7TCKcennv-Dr+w@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "draft-ietf-roll-unaware-leaves@ietf.org" <draft-ietf-roll-unaware-leaves@ietf.org>
Cc: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, Rahul Jadhav <rahul.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Pb5orRLlGZ2YkF6bfr61V2XzOio>
Subject: Re: [Roll] AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont)
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: Fri, 06 Nov 2020 22:10:24 -0000

On October 28, 2020 at 5:29:25 PM, Pascal Thubert wrote:


Hi Pascal!


There are just a couple of remaining comments...nothing major.  I will
start the IETF LC when you upload an update. :-)

Thanks!!

Alvaro.



...
> > > But we're also merging the statis with the DCO-ACK Status In that we
> > > deprecate
> > > https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-dco-ack-status
> >
> > That is new!! I don't even see DCO-ACK mentioned in the document at all.
> >
> > Does this mean that §12.5 should also be changed to include the DCO-ACK
> > message in it?
>
> Not sure I understand. §12.5 Has the only DCO status, status 1.

§12.5 says this:

   This specification creates a new Subregistry for the RPL Non-
   Rejection Status values for use in the RPL DAO-ACK and DCO messages
   with the 'A' flag reset, under the RPL registry.

s/DAO-ACK and DCO/DAO-ACK, DCO, and DCO-ACK



...
> > [major] What should the receiver do if a different value is used?
> >
> Added
> "
> ROVRsz (ROVR Size): Indicates the Size of the ROVR. It SHOULD be 1,
> 2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits,
> respectively. If a legacy Target Option is used, then the value
> must remain 0, as specified in [RFC6550]; In case of a value above
> 4, the size of the ROVR is undetermined and this node cannot
> validate the ROVR; an implementation SHOULD propagate the whole
> Target Option upwards as received to enable the verification by an
> ancestor that would support the upgraded ROVR.
> "

[nit] s/[RFC6550]; In/[RFC6550]. In


[major] "value above 4, the size of the ROVR is undetermined and this
node cannot validate the ROVR; an implementation SHOULD propagate the
whole Target Option upwards as received to enable the verification by
an ancestor that would support the upgraded ROVR."

Several points:

1- Maybe I missed it, but I didn't see anywhere that a RPL node would
validate the ROVR.  Is that implicit somehow?  Note that I'm referring
to RPL functionality since we're talking about the Target Option (not
from rfc8505's point of view).

2- It seems to me that both the 6LR and then the Root simply copy the
ROVR from/to the EDAR.  IOW, there doesn't seem to be another RPL
ancestor who would do anything with it.

3- Assuming that the 6LR somehow originated a bad Target Option (with
a ROVRsz > 4), then it looks like the Root wouldn't be able to send an
EDAR.  What should it do?  I'm guessing it should send a failure
signal back to the 6LR.

4- We're making assumptions about an "upgraded ROVR".


To solve all this maybe just delete starting with "In case of a value
above 4..."   If RPL is just carrying the information then that seems
more an rfc8505 issue...



...
> Nothing prevents a packet coming in a RPL domain to carry an RPI. E.g.,
> that packet escaped another RPL domain, which is now valid. The border
> router (typically the root) must rewrite it. the question is whether we
> assume that the RUL placed a meaningful one. I'd say that cannot be
> assumed in all cases, e.g., if instead of a leaf we have another RPKL
> network.
> But when it is useful, the 6LR should have a policy to know so it knows
> how to use it.
...
> I added
> "
> If the packet from the RUL has an RPI, the 6LR as a RPL border router
> MUST rewrite the RPI to indicate the selected Instance and set the flags,
> but it does not need to encapsulate the packet.
> "
>
> Also added
>
> "
> It is up to the 6LR (e.g., by policy) to use the
> RPLInstanceID information provided by the RUL or rewrite it to the selected
> RPLInstanceID for forwarding inside the RPL domain.
> "

Good...except that I think there's a Normative conflict: "the
6LR...MUST rewrite the RPI" vs "up to the 6LR...to use...or rewrite".
 s/MUST/SHOULD

Should any of this be also in UseofRPLInfo?  Or maybe it should be
explained there and referenced form here.  UseofRPLInfo talks about
always inserting the RPI at the 6LR, no exceptions.



...
> I'm wondering if there again the end of your message was lost?

Nope, that was it. :-)