Re: [Roll] Iotdir last call review of draft-ietf-roll-unaware-leaves-23

["Pascal Thubert (pthubert)" <[e-mail]>]

It is indeed Peter;

Note that the goal is to specify the new operation by the RPL router.

As a side effect we need to precise which subset of WiND the 6LN needs to implement to get the router to inject the routes as expected. But that’s still operating within RFC 8505 ans 8928.

Also note that the tool is not the only way. I often send my comments directly and feed the tool retrospectively.

Take care,

Pascal

Le 10 déc. 2020 à 09:03, Peter van der Stok <[e-mail]> a écrit :

 HI Pascal,


My hope is that my comments, in spite of the mistakes, did not add to the confusion.
The layout that you received certainly did not help.
It was a real struggle to go from word format to txt that comformed to the iotdir review format. (4 tries);
But what I saw as final result was different again from what you show.....

The text of the draft is certainly simplified at several places.

I regret that that the term RUL/6LN is still needed. I found that very confusing; and that triggred my suggestions.
The point being that it was unclear when 6LN spec was repeated and when new RUL behavior was specified.
Apparently, it is too convoluted to define the RUL such that 6LN is only mentioned in section 2.
But the 6LN RUL separation is clearer in the new text.

cheerio,
all the best,

Peter




Pascal Thubert (pthubert) schreef op 2020-12-09 19:42:

Dear Peter

Many thanks for your deep review!

I submitted the proposed changes as rev 24 so you can investigate what I did in the diffs:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-24

Let's see below.


Reviewer: Peter Van der Stok
Review result: Ready with Issues

IOT_DIR review of  draft-ietf-roll-unaware-leaves-23 Many thanks for this
document that will certainly help developers of products with very high
energy constraints. The draft reads rather easily from a linguistic perspective.
Unfortunately, some terminology is very difficult to understand. Especially
page 4 needs some improvement. This review mainly suggests a simplified
terminology; I hope that it helps to reduce the complexity of the draft.

peter van der stok
__________________________________________________________________
____________
Another introduction of terms is suggested for page 4  like:
Replace the first three Alineas of page 4 with:

Useofrplinfo introduces the terms Ripple Aware Leaf and Ripple Unaware
Leaf.  A Ripple Aware Leaf is part of a RPL DODAG. A Ripple Unaware Leaf
(RUL) is not. A RUL is connected to a 6Lowpan Router (6LR) to send packets
over the DODAG that the 6LR belongs to. This note specifies how the RUL
communicates with the 6LR and the connected DODAG. In this specification
the RUL MUST be a 6lowpan Node (6LN). In contrast, other Ripple Unaware
Nodes (RUN) are not 6LNs. In the

Does that really help, Peter?
1) Your proposal changes the rule to elaborate the acronym on first use.
2) Injecting route is something that people understand beyond the world of RPL. Adding the DODAG and 6LowPAN terminology makes things even harder to figure, doesn't it? All this comes later.
3) The definition In https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-42#section-2 is purely RPL based and does not imply 6LoWPAN. A RUL could use a non-6LoWPAN method to attach to the LLN, e.g., another IGP. The draft presents one such method that is indeed based on 6LoWPAN ND.
4) we also debated on whether it is a 6LoWPAN node acting as a RUL or the other way around; we settled for one side and I would not reopen the wound.

Still I see the need to simplify. What about
"
   Section 2 of [USEofRPLinfo] defines the terms RPL Leaf, RPL-Aware-
   Leaf (RAL) and RPL-Unaware Leaf (RUL).  A RPL Leaf is a Host attached
   to one or more RPL router(s); as such, it relies on the RPL router(s)
   to forward its traffic across the RPL domain but does not forward
   traffic from another node.  As opposed to the RAL, the RUL does not
   participate to RPL, and relies on its RPL router(s) also to inject
   the routes to its IPv6 addresses in the RPL domain.

...

   This document specifies how the Router injects the Host routes in the
   RPL domain on behalf of the RUL.  Section 5 details how the RUL can
   leverage 6LoWPAN ND to obtain the routing services from the router.
   In that model, the RUL is also a 6LoWPAN Node (6LN) and the RPL-Aware
   router is also a 6LoWPAN Router (6LR).  Using the 6LoWPAN ND Address
   Registration mechanism, the RUL signals that the router must inject a
   Host route for the Registered Address.
"

Note that there's a formatting issue in the notes as I received them, so I'm doing my best; also that I have concerns with many of the proposed changes because they word the operation from a 6LoWPAN standpoint and this is still a ROLL spec. All in all I picked what I could extract from the below.

Alinea: ‘examples …..and/or metering’: s/lightly powered/ severely energy
constrained/

Done

And add: The connection of the RUL to the DODAG makes use of
the NON-Storing Mechanism even when the DODAG is operated in Storing
mode. The unicast forwarding of a RUL packet from the 6LR onwards is
described in section
4.1 of useofrplinfo. s/ RPL router/6RL/ page 5 s/6LN/RUL/ s/This document
often uses/This document uses/ page 6. After al 1 add: 6LN can be a RAL or
RUL. A 6LR is Ripple Aware per definition. Remove ‘This document…  RPL by
itself’ Page 7, section 3, Introduce the term: The start-6LR is the 6LR that is
connected to the RUL. Page 7 everywhere,  s/routers/6LR/ Section 3, Alinea 3:
s/the root and the 6LR/the root and the start-6LR/ I don’t understand phrase:

That's actually wrong. Most routers are not 6LRs. They are RPL routers. Only the attachment router that connects the RUL using this spec needs to be a 6LR as well.

‘A RUL is an
example ….Host route’ Replace ‘so unless    .. serves the RUL)’ by: If the
packet from the RUL has no RPI, the 6LR tunnels it to the Root to add an RPI.
Page 8 s/ inner packet/encapsulated packet/ Remove ‘[USEofRPLinfo] expects
….to a Host.’ (Unnecessary phrase, RUL is 6LN)

And what is the expectation on a 6LN? There's no document like requirements on a 6LN like RFC 8504 is there?

The purpose of Sections 4.2.1,
4.2.2 and 4.2.3 is very unclear.

The whole section 4 is a description of the pieces of 6LoWPAN ND that the reader may need.
I added text at the beginning of section 4:
"

4.  6LoWPAN Neighbor Discovery

   This section goes through the 6LoWPAN ND mechanisms that are
   leveraged in this specification as a non-normative reference to the
   reader.  The normative text is to be found in [RFC6775], [RFC8505],
   and [RFC8928].
"

In my perception, nowhere is an extension to
RUL described.

The specification is for the 6LR operation. There is a requirement on how the 6LN uses RFC 8505 as well, but the normative text for the 6LN operation is in RFC 8505.
The explanation is reworded in the intro as:
"
   This document specifies how the Router injects the Host routes in the
   RPL domain on behalf of the RUL.  Section 5 details how the RUL can
   leverage 6LoWPAN ND to obtain the routing services from the router.
"

 When referring to multicast, I assume you mean link
broadcast?

Well the text says multicast rightfully but you're correct that behind the seen the L3 multicast because a L1/2 broadcast.

6LN and 6LR need not be written out.

I do not understand this?


In section 4.2.2 there is a
reference to RUL, but specification is deferred to 5.1 Section 4.3,line 3, I
expect that 6LN should be replaced by RUL. Al 3: S /across the LLN/between
RUL and Root/

Actually between the 6LR and the root. The intention of the formulation is to emphasize the cost.


Section 5, page 11,  s /obtain routing services/obtain RPL

Ne. the full sentence is
"
This section describes
   the minimal RPL-independent functionality that the RUL needs to
   implement to obtain routing services for its addresses.
"

The whole point is that from the RUL perspective it is not RPL. It is routing.

services/ (2x) s /Router/6LR/ page 12, first phrase:



This a double negation, and impossible to understand.

Turned it to an "only if" form. Concerned that other people may find it actually harder. Both versions are correct.
"
   The RUL is expected to request routing services from a Router only if that router originates RA messages with a CIO that has the L, P, and E flags all set
"
Page 12 al 2:
S /A RUL that ………………services./
A RUL MUST register to at least one or all the 6LRs from which it desires RPL
services. Al 4, S /The RUL needs to/The RUL MUST/

This belongs to RFC 8505 and is there; This doc must not paraphrase normatively.

Section 5.2 s/must be able
to decapsulate/MUST decapsulate/

Same; plus that hhere we do not describe the operation but the capability to perform that operation. Text is correct.

 Suppress ‘Unless it is aware ….by
[RFC8504]’; (How will the root be aware? Not this year anyway.)

By other means, as said. This includes configuration, or the general standard that encompasses this spec, like a Thread that imposes that all leaves support IP in IP

Page 13,
s/leaves that are not aware of RPL/RULs/

That was voluntary, to emphasize the point


 Remove ‘outside the RPL domain
eg.’ 2nd al. s/on behalf …. functionality in/for any RUL. Section 7 s/RAN/6LR/
Section 9.1 s/6LN/RUL/ Page 19 every where s/6LN/RUL/ In fig 6 and 7
s/’6LN/RUL’/RUL; (having defined that a RUL is a 6LN) Page 21, Section 9.2.1
title: Perspective of the RUL First

Actually you're countermanding a conscious decision.

The RUL does not know it is a RUL. It knows it is a 6LN. So it is a 6LN Acting as RUL, though probably it does not know. What we describe is what it knows, that is a 6LN behaviour.


phrase: This specification specifies the RUL operation that is conform to the
6LN operation. s/6LN/RUL/ on page 21, 22, 23 , 25, 26 everywhere page 22
point
4 remove ‘a 6LN acting as’ page 27 s/6LN/RUL/ what does ‘maintain the
binding’

Again, that is something that was discussed and agreed upon in earlier reviews. I'm not saying that your point of view is invalid. But we went for the other option.

mean? Page 28 section 10. I don’t understand al 2 ‘The RPL support …..listener

I reread but cannot find how to clarify moore. This is MLD.

6LN’ Page 18 s/6LN/RUL/ Figure 10,11 6LN/RUL ->RUL Section 11 Shorter
Suggestion: Only RPL aware nodes can effectuate a RPL based attack in the
network. Consequently, nodes that are not part of the DODAG can only attack
the RPL network when they are RULs. Page 31,32 s/6LN/RUL/ and
s/rogue/rogue RUL/

Yes I added this all the way back to the intro

"
   A RUL may be unable to participate because it is very energy-constrained,
   code-space constrained, or because it would be unsafe to let it inject
   routes in RPL. Using 6LoWPAN ND as opposed to RPL as the Host-to-Router
   interface limits the surface of the possible attacks by the RUL against the
   RPL domain, and can protect RUL for its address ownership.
"

Many thanks again Peter.

The main thing I did not act upon is the change 6LN->RUL. The conscious behavior by the node is that of a 6LN, not that of a RUL; we found it logical to present the RUL as a 6LN in the sections where it uses 6LoWPAN ND. Thus the text as it stands.

Again, many thanks for your review!

Please let me know if we are good, and keep safe;

Pascal