Opened 5 years ago

Closed 3 months ago

#180 closed defect (fixed)

13 issues to address in dao projection draft (lifetime, MOP, retransmissions, route cleanup)

Reported by: mariainesrobles@… Owned by: pthubert@…
Priority: major Milestone:
Component: dao-projection Version:
Severity: Active WG Document Keywords:
Cc: mcr+ietf@…

Description

Source: https://www.ietf.org/mail-archive/web/roll/current/msg10069.html

Michael Richardson wrote on 12-24-2016

Hi, I had intended to finish this as part of the adoption call, having previously read the document, but was late.  These comments are probably more useful now anyway.  I can open tickets as appropriate if chairs direct.

Let me leave editorial comments to the end of this email.

1) Didn't we have an errata about default lifetime units when there was no

configuration option?

No, we didn't.  I wonder if this plagues us everywhere, that 6550 should have specified a default Lifetime units in the absense of a Configuration option.

2) RFC6551 reference:

or the RPL routing extensions specified in Routing for Path Calculation in LLNs [RFC6551].  Based on that information, the root

huh? the title of 6551 is: Routing Metrics Used for Path Calculation in

Low-Power and Lossy Networks

so, what exactly did you mean here?

3) does dao-lifetime eclipse need for no path dao?

4) resource calculations

"but how the root figures the amount of

resources that are available is out of scope."

I disagree. I would like some mechanism to be in scope.

And you suggest NMS and 6551 later on... which seems to make it in scope. I'm not sure how 6551 can be used here.

5) section 4 needs subsections! Too many concepts in one heading.

6) On the use of a new MOP.

Are we sure that we need a new MOP?  Could we use Non-Storing MOP, with some indication of which nodes speak DAO-Projection?  Could that work?

Or do you really want to force a forklift upgrade here? Why does the entire network need to be aware of this new mode?

7) page 8 is too dense!

8) I just didn't understand the english here.

I think that "last node" needs a better term.  Maybe colour the nodes or otherwise mark them and use those terms?

The last node in the segment may have another information to reach the target(s), such as a connected route or an already installed projected route.  If it does not have such a route then the node

9) running out of resources:

it seems that it ought to be said that the new node might not be one that the last node had previously talked to.  There is the issue of both routing storage (from storing mode), but also neighbor cache resources.

10) more hard to understand statements...

For the targets that could be located, last node in the segment generates a DAO to its loose predecessor in the segment as indicated in the list of Via Information options.

woe!  What?

11) create new section on route cleanup

A NULL lifetime in the Via Information option along the segment is used to clean up the state.

needs new 4.x section on cleanup.

12) move / replicate diagrams into this section, and use numbered diagrams

In the example below, say that there is a lot of traffic to nodes 55

new section, move diagram here.

make figure 5 and 6 more like figure 3, numbered, etc.

13) Q: retransmission timers, etc. appropriate for these projected DAO messages?

How do we handle packet loss?

Change History (3)

comment:1 Changed 3 years ago by pthubert@…

About 2) the text was removed on 3) the no path dao goes down the DODAG, so it's different

comment:2 Changed 3 years ago by pthubert@…

  • Status changed from new to assigned

comment:3 Changed 3 months ago by pthubert@…

  • Resolution set to fixed
  • Status changed from assigned to closed

Ines pointed out an active ticket https://trac.ietf.org/trac/roll/ticket/179 and https://trac.ietf.org/trac/roll/ticket/180 against the DAO projection draft. It was logged at adoption call time and I failed to respond properly.

This was against https://datatracker.ietf.org/doc/html/draft-thubert-roll-dao-projection-03 , water under the bridge so I tried to sort things out and published https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projection-18 as a result.

In more details:

Michael Richardson wrote on 12-24-2016 Hi, I had intended to finish this as part of the adoption call, having previously read the document, but was late. These comments are probably more useful now anyway. I can open tickets as appropriate if chairs direct. Let me leave editorial comments to the end of this email.

1) Didn't we have an errata about default lifetime units when there was no configuration option? No, we didn't. I wonder if this plagues us everywhere, that 6550 should have specified a default Lifetime units in the absence of a Configuration option.

I think that was by design. RPL can be used in a great many environments with lots of diversity, from high speed wires in ANIMA to 2Kps LLNs. Couple that with any size of netwoks, with cases of ~10K sometimes. A default value can be programmed for a particular use case, say Wi-SUN, and in that case the SDO that leverages RPL will define it for its own purpose.

2) http://tools.ietf.org/html/rfc6551 reference: “or the RPL routing extensions specified in Routing for Path Calculation in LLNs [RFC6551]. Based on that information, the root “ huh? the title of 6551 is: Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks so, what exactly did you mean here?

I'd read this as: Additional metrics used for routing decision - indirectly, via the Rank computation by the OF But then I could not find that text in early or current versions, so I guess this issue disappeared?

3) does dao-lifetime eclipse need for no path dao?

Same as main RPL. Some users might let the route die if signaling is expensive.

4) resource calculations "but how the root figures the amount of resources that are available is out of scope." I disagree. I would like some mechanism to be in scope. And you suggest NMS and 6551 later on... which seems to make it in scope. I'm not sure how 6551 can be used here.

We agree. The capabilities draft will do that when we find time to work on it.

5) section 4 needs subsections! Too many concepts in one heading.

This was " 4. Loose Source Routing in Non-storing Mode ". It is now " A.1. Loose Source Routing " only 4 paragraphs. The rest was spread as suggested

6) On the use of a new MOP. Are we sure that we need a new MOP? Could we use Non-Storing MOP, with some indication of which nodes speak DAO-Projection? Could that work? Or do you really want to force a forklift upgrade here? Why does the entire network need to be aware of this new mode?

Agreed, this is gone now

7) page 8 is too dense!

Was split and expanded. I consider that fixed

8) I just didn't understand the english here. I think that "last node" needs a better term. Maybe colour the nodes or otherwise mark them and use those terms? The last node in the segment may have another information to reach the target(s), such as a connected route or an already installed projected route. If it does not have such a route then the node

This is gone

9) running out of resources: it seems that it ought to be said that the new node might not be one that the last node had previously talked to. There is the issue of both routing storage (from storing mode), but also neighbor cache resources.

Can't find the related text in any version. But the neighbor cache is created before the sibling is advertised, so the lack of it os not found at route creation time.

10) more hard to understand statements... For the targets that could be located, last node in the segment generates a DAO to its loose predecessor in the segment as indicated in the list of Via Information options. woe! What?

I hope the explanation is better now. The storing mode DAO flows from egress to ingress as a the normal DAO flows from leaf to root.

11) create new section on route cleanup A NULL lifetime in the Via Information option along the segment is used to clean up the state. needs new 4.x section on cleanup.

Please see "7.3.1. Storing-Mode P-Route" in -18. I split as suggested

12) move / replicate diagrams into this section, and use numbered diagrams In the example below, say that there is a lot of traffic to nodes 55 new section, move diagram here. make figure 5 and 6 more like figure 3, numbered, etc.

done

13) Q: retransmission timers, etc. appropriate for these projected DAO messages? How do we handle packet loss?

Added text "

The process continues till the P-DAO is propagated to ingress router of the Segment, which answers with a DAO-ACK to the Root. The Root always expects a DAO-ACK, either from the Track Ingress with a positive status or from any node along the segment with a negative status. If the DAO-ACK is not received, the Root may retry the DAO with the same TID, or tear down the route.

"

Note: See TracTickets for help on using tickets.