Subject: [Roll] RPL spec v6: request for minor clarifications (nits)

From: Phoebus Chen <[email-masked]>
Date: Wed, 03 Mar 2010 19:37:49 +0100

Hello RPL authors,

Here are my list of nits and other minor suggestions for clarification 
on RPL draft 6.  These are points that I think I understand more clearly 
in the document ;).

(pg. 10, Sec. 3.1.1) Rank should not be listed as a 'Topology Identifier'

(pg. 16, Sec. 3.4.6)
"Nodes provision routing table entries, for the destinations
specified by the DIO, via their DODAG parents in the DODAG
iteration."
What is meant by 'via their DODAG parents'?  Change wording.

(pg. 18, Sec. 3.6.1) 'strong global convergence' has not been defined.

(pg. 20, Sec. 3.6.2.1) 'minHopRankIncrease' was first used here in the 
document.  But it is more clearly "defined" in (pg. 59, Sec. 10)
"The increase in rank must be at least MinHopRankIncrease."
That text should be moved further up in the document.

(pg. 21, Sec. 3.6.2.2)
"... entails the probability of creating a loop"
Replace 'probability' with 'chance'.  Probability should be associated 
with a number.
"... appropriate to the objective code point being used within the DODAG."
Replace 'objective code point' with 'objective function'

(pg. 25, Sec. 5.1.2) point #3, shouldn't Destination Advertisements 
Stored (S) also be in the list of fields that a node may update at each hop?

(pg. 28, Sec. 5.1.3.5)
"The Destination Prefix suboption is used when the DODAG root, or
another node located upwards along the DODAG on the path to the DODAG
root, needs to indicate that it offers connectivity to destination
prefixes other than the default."
Is the default destination prefix the DODAGID?  Maybe you can put that 
in parentheses here.  Otherwise, how is the default prefix specified 
(i.e. what messages are used, is the Destination Prefix suboption also 
used to specify the default prefix?)?

(pg. 30, Sec. 5.3.2)
"Second, the parent set is a restricted subset of the candidate neighbor 
set."
remove 'restricted'.

(pg. 31, Sec. 5.3.3.1) Point #1.  Maybe also say that the sibling set 
may belong to different DODAG iterations?  Or must they belong to the 
same DODAG iteration?

(pg. 32, Sec. 5.3.3.1) Point #6
"(i.e. with the same DODAGID and a lower DODAGSequenceNumber)"
Insert 'same RPLInstanceID and the' before "same DODAGID."

(pg. 32, Sec. 5.3.3.1) This is the first mention of the parent set 
'being depleted' on a node.  The reader needs to make the connection 
that this is from parents jumping to the next iteration, that the node 
must remove those parents from its parent set.  Perhaps it can be 
reworded more clearly.

(pg. 32, Sec. 5.3.3.1)
"...DODAG information should not be suppressed..."
Clarify what is meant by suppressing the DODAG information.

(pg. 37, Sec. 5.3.5)
"If a node is not a member of a DODAG, it MUST suppress transmission of 
DIO messages."
Replace 'suppress transmission' with 'not transmit'.

(pg. 38, Sec. 5.3.5.1.2)
"The node receives a modified DIO message from a DODAG parent"
Clarify that 'modified' above means not matching a previously cached 
version of the DIO message from that DODAG parent.

(pg. 40, Sec. 5.6) 'Race Condition' might be better than "Collision," 
since there are no collision of packets.

(pg. 54, Sec. 7.2.2.2)
"... packet that is flagged with a given RPLInstanceID"
Replace 'flagged' with 'marked.'

(pg. 56, Sec. 8) MLD is undefined and does not have a reference.

(pg. 58, Sec. 10) "compute the DODAG" should be 'construct the DODAG' or 
'optimize the DODAG'

(pg. 59, Sec. 10) Remove sentence:
"(This prevents the creation of a path of sibling links connecting a 
child with its parent.)"
since it is no longer applicable with 1-hop sibling routing

(pg. 59, Sec. 10)
"Candidate neighbors that would cause self's rank to increase are ignored"
Ignored for what?  Parent Selection?  Not for computing your own rank... 
remove this?

(pg. 59, Sec. 10) What are "policy functions"?

(pg. 60, Sec. 10) Remove sentence
"Candidate neighbors of an equal rank to self (siblings) are ignored"
since neighbors of equal rank are considered for siblings.

(pg. 60, Sec. 11) ZERO_LIFETIME is not used anywhere else in the document.

(pg. 61, Sec. 11) The timers do not belong in the "RPL Constants and 
Variables" section.

(pg. 62, Sec. 12.1.2)
"logical equivalent of the DODAG table that contains all the records 
about a DODAG is suppressed"
Replace "suppressed" with 'marked as invalid.'

(pg. 63, Sec. 12.1.6)
Is "administrative preference" here the same as route preference in 
Figure 9 on pg. 27?  I think the term 'administrative preference' has 
been used loosely throughout the document.

-- 
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.kth.se/~phoebus

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 5 Mar 2010 16:56:44 +0100

Hi Phoebus 

Thanks a huge bunch for your comments. You'll find some
answers/discussion below. 
We'll be pushing an 07 shortly and are trying to incorporate as much as
we can for this.

For clarity, I'd appreciate a bit more info on the following:

(pg. 16, Sec. 3.4.6)
"Nodes provision routing table entries, for the destinations specified
by the DIO, via their DODAG parents in the DODAG iteration."
What is meant by 'via their DODAG parents'?  Change wording.

[Pascal] A RIB route has the general form of 'this aggregate of
destinations' via 'that router' with fancy metadata when we care. A FIB
route has the general form of  'this aggregate of destinations' via
'that next_hop',the latter being usually expressed as a link local. As
it goes, the DODAG parent is both the via_router and the next_hop for
the default route, but we do not expect that the routers necessarily
support a FIB so we use the via terminology. Since I fail to see what
your issue is, I'd appreciate that you suggest an alternate text that
could be more appropriate and address your concern?

(pg. 28, Sec. 5.1.3.5)

[Pascal] Actually, the 'G' bit used to tell you whether to install a
default or not. Implicitly it could still, if the Goal of the DAG is to
build a default. But considering how the meaning of the 'G' bit has been
amended, that has become only remotely related and it makes sense to
remove the 'other than default'. Still, we have the potential issue of a
DAO conflicting with the DIO suboption by announcing the same
reachability. Any suggestion here?

[Pascal] You can only compare Ranks within an iteration, that's the
scope of the Rank.
A node is a leaf in an iteration that it has not joined yet. If you mean
sibling in a different DODAG of the same instance, there are use cases
where you could do that and other where you could not, for instance
depending on whether the root consumes the data or not. Today we do not
allow that, but we could leave that up to the OF. 

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Phoebus Chen
> Sent: Wednesday, March 03, 2010 7:38 PM
> To: [email-masked]
> Subject: [Roll] RPL spec v6: request for minor clarifications (nits)
> 
> Hello RPL authors,
> 
on RPL
> draft 6.  These are points that I think I understand more clearly in
the
> document ;).
> "Nodes provision routing table entries, for the destinations specified
by the
> DIO, via their DODAG parents in the DODAG iteration."
> document.  But it is more clearly "defined" in (pg. 59, Sec. 10) "The
increase in
> rank must be at least MinHopRankIncrease."
with a
> number.
Stored (S)
> also be in the list of fields that a node may update at each hop?
> 
> (pg. 28, Sec. 5.1.3.5)
another
> node located upwards along the DODAG on the path to the DODAG root,
> needs to indicate that it offers connectivity to destination prefixes
other than
> the default."
in
> parentheses here.  Otherwise, how is the default prefix specified
(i.e. what
> messages are used, is the Destination Prefix suboption also used to
specify
> the default prefix?)?
> 
> (pg. 30, Sec. 5.3.2)
> "Second, the parent set is a restricted subset of the candidate
neighbor set."
> (pg. 31, Sec. 5.3.3.1) Point #1.  Maybe also say that the sibling set
may belong
> to different DODAG iterations?  Or must they belong to the same DODAG
> iteration?
> 
'being
> depleted' on a node.  The reader needs to make the connection that
this is
> from parents jumping to the next iteration, that the node must remove
> those parents from its parent set.  Perhaps it can be reworded more
clearly.
> Clarify that 'modified' above means not matching a previously cached
version
> of the DIO message from that DODAG parent.
> 
child with
> its parent.)"
about a
> DODAG is suppressed"
Figure 9
> on pg. 27?  I think the term 'administrative preference' has been used
loosely
> throughout the document.
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Phoebus Chen <[email-masked]>
Date: Sat, 06 Mar 2010 20:41:43 +0100

Pascal,
	I'm glad to help.  Thanks for taking my comments into consideration. 
You guys are doing a great job making progress on RPL... not an easy 
task to come up with one protocol to meet all the requirements.  As for 
your questions, see my comments inline below.

> could be more appropriate and address your concern?

When I wrote this, I thought the phrase just needed some grammar 
correction.  Is "via_router" or "via router" standard terminology?  If 
so, then maybe the phrase "via their DODAG parents" is fine as it is... 
I've just never heard of it before.

As for alternate text, I think it would be clearer to add a reference to 
the actual data structures described in Section 12.

My comments on the document have mostly ignored DAOs and downwards 
routing since, as I understand, that part of the protocol is still under 
heavy revisioning.  But since you ask me to try to clarify the wording, 
I'll have to give my interpretation of how some of the DAO mechanisms 
work before proposing how I'd revise the sentence.

(pg. 16, Section 3.5.1), and the rest of the document says that unicast 
DAOs propagate upwards along the DODAG, and never downwards.  In order 
for any nodes besides your DODAG ancestors to hear your
destination prefix advertisement, at some point your destination prefix 
must be crammed into a DIO Destination Prefix suboption so it can 
traverse downwards.  Which means that not all destination prefixes 
advertised in a DIO are offered by ("located at") the root.  There 
doesn't seem to be a field in the DAG Destination Prefix Suboption to 
distinguish between prefixes offered by the root and prefixes offered by 
other nodes.  I haven't thought this through to see if it matters for 
correct protocol operation, but it might matter for what type of routing 
table entry you store.

My understanding is that there are two types of routing tables described 
in Section 12.3:

(pg. 64, Sec. 12.3.2) DAG Table (more than just a routing table)
for destination prefixes advertised by the DODAG root

(pg. 65, Sec. 12.3.3) Routing Table
for destination prefixes advertised by other nodes in the DODAG

I suppose one could also put destination prefixes offered by the DODAG 
root into the routing table, but I think it would be redundant (unless 
you wanted to associate a lifetime timer with each destination prefix 
offered by the root... I think adding a lifetime to the DAG Destination 
Prefix Suboption was discussed earlier but not yet decided?).

If I were to reword the sentence, I would break it up into two bullet 
points:

"Nodes provision DODAG table entries for the destinations offered by the 
DODAG root specified by the DIO (Section 12.3.2).  A node creates a 
separate DODAG parent entry for each of its DODAG parents."

"Nodes provision routing table entries for the destinations offered by 
non-root nodes specified by the DIO (Section 12.3.3).  A node creates a 
separate routing table entry for each destination and DODAG parent that 
can serve as the next hop to that destination."

I've written this based on the routing table described on (pg. 65, Sec. 
12.3.3).  I didn't mention the word "route" because the routing table 
entry doesn't refer to a single path through the network (after the 
first hop, there may be multiple paths available).  Actually, Section 
12.3.3 uses the word "route" even though the entries don't correspond to 
single-path routes, which confused me a little.  And as I understand, 
each destination prefix can be associated with multiple routing table 
entries, since there is only one "Next Hop" field per routing table entry.

If you think this is too much detail for Section 3.4.6 and you do intend 
to create a routing table (Section 12.3.3) entry for each destination 
regardless of whether it is offered by the root, then you can just 
replace the text with:

"Nodes provision routing table entries for the destinations specified by 
the DIO.  A node creates a separate routing table entry for each 
destination and DODAG parent that can serve as the next hop to that 
destination."

> reachability. Any suggestion here?

I'm okay with removing the "other than default."  I'm not sure I follow 
what you mean by a DAO conflicting with a DIO suboption by announcing 
the same reachability.  Do you mean when they both advertise the same 
destination prefix?  Like when a destination prefix in a multicast DAO 
is propagated by a unicast DAO upwards (pg. 51, Section 6.2.9 point #4) 
and then back downwards in a DIO to a node that received the original 
multicast DAO?  Is this a problem of not being able to compare DIO ranks 
and metrics to DAO ranks and metrics to choose a preferred route when 
you are given two options?

> allow that, but we could leave that up to the OF.

You're right, it's a lot less confusing if we restrict siblings to the 
same DODAG iteration.  Maybe that's better.

When I was suggesting that the sibling set may belong to different DODAG 
iterations, I was thinking of what would be least restrictive but still 
have the protocol work.  When your parents join the next DODAG iteration 
(same DODAG, new sequence number), you can still route packets to them 
if they are your 'future parents.'  If your siblings join the next DODAG 
iteration before you, you will lose your siblings during the transition 
period.  Do they automatically become 'future parents' until you join 
the next DODAG iteration?  Or should there be some notion of 'future 
siblings'?

When I wrote my comment, I wasn't thinking of routing to siblings in a 
different DODAG of the same instance.  I agree that if we allow a node 
to only join one DODAG and it's parents to only be from one DODAG, it's 
less confusing if you only allow siblings to be in one DODAG.