Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt

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

Salut Mathilde,

 

How are things in ROLLe?

 

Q if node (42) had siblings, they would also be part of its shadow cone, correct?

Correct. I think we ended up with the definition of shadow cone vs. subdag with the notion that the subdag is still a DAG so it does not encompass sibling paths whereas the shadow cone as pure dark AND grey zones, the grey parts being siblings. 

http://www.nasaimages.org/luna/servlet/detail/NVA2~4~4~4868~105394:Shadow-Cone-of-a-Total-Solar-Eclips

 

Q - Must all nodes in a DAG use the same metric(s)  as suggested by section 3.3.1.4.? This seems to conflict with the last paragraphs of section 4.1. What do you mean by consistent parent selection? Does it mean that a node should not join a DAG if it's metric logic does not agree with the metric logic of other nodes in the DAG?

 

Please see my text posted on this list a few minutes ago. The Langua Franca 'depth' metric can be used to preferred parent selection but this does not have to be. The degenerated case where that metric is the only thing used for the parent selection takes us back to a lot closer to classical DV. With the current draft, nodes may have completely independent metric logics. This is debated. If we could make broad families, then nodes might prefer to join a DAG that belongs to the same family, in particular share optimization objectives.

 

Q  3.3.1.4.1. I guess Node (N) may also forward traffic via Node (C) if something goes wrong with Node (B) and (E), correct?

 

Correct. C is a sibling. 

 

Q 3.4.3 Do you use the state (INCOMPLETE, REACHABLE, STALE, DELAY, PROBE) contained in the neighbor cache table? One way to maintain routing adjacencies would be to use a relatively low reachable time which means that the neighbors will be in STALE state rapidly. Once a neighbor is in this state, any packet for this neighbor will trigger a NS/NA exchange to confirm reachability. However, the data packet will be send before the NS is sent...

 

We are binding our protocol on ND. Could be bound on other neighboring protocols, though ND seems a good fit on the occasion, in particular for it reactive properties in particular for NUD. So we should not use directly the ND state but be aware of changes in their properties. We are interested in triggers for neighbors going reachable and then removed. We are not interested in going stale, delay or probe though we should probably hint an implementation to reduce the delay time to zero. We should specify a little better the binding so further down the road, other bindings can be achieved.

 

Q - 3.3.3.1. " Note that further details of the message and its triggers are still under investigation, including whether or not the DAO should be a IPv6 Hop-By-Hop option or a Neighbor Discovery option." Is it still under investigation given that section 5.5.1.1 speaks only of NA?

 

The whole draft is under investigation anyway J NA makes sense so it is the proposal on the table. NA represents better the relationship that a node has with the router that it is attached to than RA does. So we build the routing structure propagating information in RAs outwards and then paint the graph propagating information in NAs inwards along that routing structure.

 

Q - 5.4 Item 3. I guess you are talking only about a LBR not any LLN router

 

Maybe we lack some string language but any router doing our stuff should use RA-DIO. The absence of it is a signal of a legacy router that we assume as a wired power-savvy router.

 

Q - 5.4.3.1 " When a new DAG is discovered, the candidate parent that advertises the new DAG is placed in a held up state for the duration of a DAG Hop timer".  What if the node want to be part of both DAGs (its original DAG and the new one), I guess this does not apply.

 

It does apply; The main goal is for all nodes that would wish to do the same thing to do it orderly. When A attaches to the new tree, it offers a new opportunity for others to do so to. The hop timer lets nodes that join higher in the new tree to do it first, so nodes joining deeper can see the final set of opportunities before they can jump in turn.

 

Bonne journée J

 

Pascal

From: [e-mail] [mailto:[e-mail]] On Behalf Of Mathilde Durvy (mdurvy)
Sent: jeudi 2 juillet 2009 13:36
To: [e-mail]
Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt

 

Hi All,

 

Thanks for this nice draft! 

A few comments/questions:

 

- 3.3.1.2 shadow cone. In the example given, if node (42) had siblings, they would also be part of its shadow cone, correct?

 

- Must all nodes in a DAG use the same metric(s)  as suggested by section 3.3.1.4.? This seems to conflict with the last paragraphs of section 4.1. What do you mean by consistent parent selection? Does it mean that a node should not join a DAG if it's metric logic does not agree with the metric logic of other nodes in the DAG?

 

- 3.3.1.4.1. I guess Node (N) may also forward traffic via Node (C) if something goes wrong with Node (B) and (E), correct?

 

- 3.3.3.1. " Note that further details of the message and its triggers are still under investigation, including whether or not the DAO should be a IPv6 Hop-By-Hop option or a Neighbor Discovery option." Is it still under investigation given that section 5.5.1.1 speaks only of NA?

 

- 3.4.3 Do you use the state (INCOMPLETE, REACHABLE, STALE, DELAY, PROBE) contained in the neighbor cache table? One way to maintain routing adjacencies would be to use a relatively low reachable time which means that the neighbors will be in STALE state rapidly. Once a neighbor is in this state, any packet for this neighbor will trigger a NS/NA exchange to confirm reachability. However, the data packet will be send before the NS is sent...

 

- 5.4 Item 3. I guess you are talking only about a LBR not any LLN router

 

- 5.4.3.1 " When a new DAG is discovered, the candidate parent that advertises the new DAG is placed in a held up state for the duration of a DAG Hop timer".  What if the node want to be part of both DAGs (its original DAG and the new one), I guess this does not apply.

 

Typos:

- DAG Sibling definition page 5: neighboring node node

- 3.2.4: able to ... discover

- 3.3.1.2: I guess you mean 'consider Node (42)'

- 3.3.1.2: 'the node rooting the DAG may is not'

- 3.3.1.4: lessor -> lesser

- 3.3.4.5: Node (51), (41), (42) and (54)

- 5.1.1.1.5: "this may be useful in cases where more than one LBR"

- 5.2: "candidate neighbor set(, bounded), and"

- 5.5.1.1: "RRcount: 8-bit unsigned integer"

- 5.5.2.1 "The DelayNA timer has a duration that is DEF_NA_LATENCY divided by 2 with the DAG depth". Does this mean 2^(DAG depth)?

 

Durvy Mathilde
Software Engineer
Technology center

[e-mail] <mailto:[e-mail]> 
Phone: [phone]
Mobile: [phone]

Cisco Systems International Sàrl
Av. des Uttins, 5
CH-1180 Rolle

Cisco home page <http://www.cisco.com/> 

 

 

 Think before you print.

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.