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

[Alvaro Retana <[e-mail]>]

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. :-)