Subject: Re: [Roll] IPSO Interop event - Feed-back welcome

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Thu, 8 Apr 2010 10:16:23 +0200

Dear All,

Following the discussion on the mailing list I just wanted to clarify a few
things so that we can find the best way to interact in the future.

- We were proposed a slot to announce this first interop event during the
ROLL WG meeting, future events may be advertised only on an IPSO web-site if
this is preferred by the WG.
- IPSO is not defining standards. It is organizing interop events to ensure
that different implementations of the same standard do work together. The
current status is that you have to pay a membership fee to participate in
these events (and indeed these events take work, prior preparation, and
money to organize). 
- We understand (at least) some people are still interested in interop event
feedback. This will be given on individual, voluntary, basis by the
participants of the interop event. 

Best,
Mathilde

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: vendredi, 26. mars 2010 03:55
To: Mathilde Durvy (mdurvy)
Cc: ROLL WG
Subject: IPSO Interop event - Feed-back welcome

Hi,

Just re-enforcing my comments during the ROLL WG meeting ... any feed- back
from the IPSO interop about any issues that you may have found would be
extremely useful to continue to improve our spec. Feel free to also share
good news.

Thanks.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 08 Apr 2010 10:26:01 +0200

Le 08/04/2010 10:16, Mathilde Durvy (mdurvy) a écrit :
[...]
> - We understand (at least) some people are still interested in
> interop event feedback. This will be given on individual, voluntary,
> basis by the participants of the interop event.

Who should I ask?

I need to know which implementations were present and who interoperated
with whom.

Thanks,

Alex

>
> Best, Mathilde
>
>
> -----Original Message----- From: JP Vasseur [mailto:[email-masked]]
> Sent: vendredi, 26. mars 2010 03:55 To: Mathilde Durvy (mdurvy) Cc:
> ROLL WG Subject: IPSO Interop event - Feed-back welcome
>
> Hi,
>
> Just re-enforcing my comments during the ROLL WG meeting ... any
> feed- back from the IPSO interop about any issues that you may have
> found would be extremely useful to continue to improve our spec. Feel
> free to also share good news.
>
> Thanks.
>
> JP.
>
>
>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Thu, 8 Apr 2010 15:45:42 +0200

Hi Alex,

What I meant in that the companies that participated in the interop event
will give their own feedback on the ROLL mailing list. 

Best,
Mathilde

PS: The list of participating companies was included in the presentation I
gave during the Anaheim ROLL meeting. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: jeudi, 8. avril 2010 10:26
To: [email-masked]
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome

> - We understand (at least) some people are still interested in interop 
> event feedback. This will be given on individual, voluntary, basis by 
> the participants of the interop event.

Who should I ask?

I need to know which implementations were present and who interoperated with
whom.

Thanks,

Alex

> [email-masked] https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Navneet Agarwal (navagar)" <[email-masked]>
Date: Sun, 11 Apr 2010 10:51:36 +0530

Hi:
I have two feedbacks from the router testing perspective.

Feedback-I:
DAO rank: It seems there very couple of different interpretations for
setting this value. 
A. Several implementations were setting the DAO rank to be equal to the
node rank (value sent in DIO rank). Each node relays this info in the
DAO towards the root. However this does not convey any differentiating
info to the receiving nodes when the DAOs are received thru multiple
paths in order to install the best route.
B. The other implementation was to set the value to 0 (or 1) by the node
and have the intermediate nodes increment it as the DAO rides up to the
root. The DAO rank in this case is more of a hop count and the receiving
nodes can make a decision based on the lowest value received when
installing the DAO route.
Pros: Decision is optimized based on hopcount. Relatively simple.
Cons: Hopcount does not take link cost into account.
C. A third proposal was to set the DAO rank equal to the node rank and a
link cost in the metric container as each nodes propagates the DAO. The
receiving nodes would make a decision based on the link cost.
Pros: Decision is optimized based on link cost
Cons: The DAOs would need to carry additional info in the packet (bigger
DAOs) and more processing needed in the nodes to parse and process.

I think we need some more details the spec for describing the value to
be set in DAO rank.

Feedback-II:
DIO Sequence number: The issue was what should be the initial value of
this field. The spec is not clear on what should be the initial value
set by the root. This has implications at the LBR in reload/reboot
conditions. For example, if the initial value is set to 1 and is
incremented to say 10. When the LBR reloads/reboots, it would start the
sequence number with 1 but its DIOs will be rejected by the nodes as
having stale sequence number. The LBR can store the sequence in
persistent memory. An easier option could be use 255 as the starting
sequence number. Using this value will make sure that the sequence
number is always valid.

Comments?

Thanks

Regards,
Navneet

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mathilde Durvy (mdurvy)
> Sent: Thursday, April 08, 2010 1:46 PM
> To: JP Vasseur
> Cc: ROLL WG
> Following the discussion on the mailing list I just wanted to 
> clarify a few things so that we can find the best way to 
> interact in the future.
> 
> - We were proposed a slot to announce this first interop 
> event during the ROLL WG meeting, future events may be 
> advertised only on an IPSO web-site if this is preferred by the WG.
> - IPSO is not defining standards. It is organizing interop 
> events to ensure that different implementations of the same 
> standard do work together. The current status is that you 
> have to pay a membership fee to participate in these events 
> (and indeed these events take work, prior preparation, and 
> money to organize). 
> - We understand (at least) some people are still interested 
> in interop event feedback. This will be given on individual, 
> voluntary, basis by the participants of the interop event. 
> 
> Best,
> Mathilde
>  
> 
> Just re-enforcing my comments during the ROLL WG meeting ... 
> any feed- back from the IPSO interop about any issues that 
> you may have found would be extremely useful to continue to 
> improve our spec. Feel free to also share good news.
> 
> Thanks.
> 
> JP.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 11 Apr 2010 17:40:26 +0200

Hi Navneet:

For issue 1), the most recent discussion tends to remove the DAO rank
and metrics completely. The reason is that with RPL, the node selects
its DAO parent and thus decides of the routing.
Passing a simple preference provides a better indication that the
parents (or the root in source route mode) can only root along the most
preferred path as the nodes have decided it.

Regarding issue 2) I think we should use a traditional lollipop and then
Serial Number Arithmetic as defined in RFC 1982. The straight part of
the lollipop could use sequence 0 to 15, and then the number would
increment skipping those values as it wraps, what do you think?

Cheers;

Pascal

> Navneet Agarwal (navagar)
> Sent: Sunday, April 11, 2010 7:22 AM
> To: ROLL WG
setting
> this value.
DAO
> towards the root. However this does not convey any differentiating
info to
> the receiving nodes when the DAOs are received thru multiple paths in
order
> to install the best route.
> B. The other implementation was to set the value to 0 (or 1) by the
node and
> have the intermediate nodes increment it as the DAO rides up to the
root.
> The DAO rank in this case is more of a hop count and the receiving
nodes can
> make a decision based on the lowest value received when installing the
DAO
> route.
> C. A third proposal was to set the DAO rank equal to the node rank and
a link
> cost in the metric container as each nodes propagates the DAO. The
receiving
> nodes would make a decision based on the link cost.
be set
> in DAO rank.
this
> field. The spec is not clear on what should be the initial value set
by the root.
> This has implications at the LBR in reload/reboot conditions. For
example, if
> the initial value is set to 1 and is incremented to say 10. When the
LBR
> reloads/reboots, it would start the sequence number with 1 but its
DIOs will
> be rejected by the nodes as having stale sequence number. The LBR can
> store the sequence in persistent memory. An easier option could be use
255
> as the starting sequence number. Using this value will make sure that
the
> sequence number is always valid.
> 
> Comments?
> 
> Thanks
> 
> Regards,
> Navneet
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Mathilde Durvy (mdurvy)
clarify
> > a few things so that we can find the best way to interact in the
> > future.
> >
> > - We were proposed a slot to announce this first interop event
during
> > the ROLL WG meeting, future events may be advertised only on an IPSO
> > web-site if this is preferred by the WG.
> > - IPSO is not defining standards. It is organizing interop events to
> > ensure that different implementations of the same standard do work
> > together. The current status is that you have to pay a membership
fee
> > to participate in these events (and indeed these events take work,
> > prior preparation, and money to organize).
interop
> > any feed- back from the IPSO interop about any issues that you may
> > have found would be extremely useful to continue to improve our
spec.
> > Feel free to also share good news.
> >
> > Thanks.
> >
> > JP.
> >

---

From: JP Vasseur <[email-masked]>
Date: Sun, 11 Apr 2010 19:42:35 +0200

> its DAO parent and thus decides of the routing.

Let's still discuss on having the metric in DAO as an option though.

> Of

---

From: "Navneet Agarwal (navagar)" <[email-masked]>
Date: Mon, 12 Apr 2010 13:45:36 +0530

Hi: 

> Sent: Sunday, April 11, 2010 11:13 PM
> To: Pascal Thubert (pthubert)
> Cc: Navneet Agarwal (navagar); ROLL WG
> > parents (or the root in source route mode) can only root along the 
> > most preferred path as the nodes have decided it.
NAV> How would the node decide the preference value?. I was thinking
that if a metric is explicitly defined in the DAO it may be more
transparent for decision making in a mixed environment...imo. What do
you think?

> >
> > Regarding issue 2) I think we should use a traditional lollipop and 
> > then Serial Number Arithmetic as defined in RFC 1982. The straight 
> > part of the lollipop could use sequence 0 to 15, and then 
> the number 
> > would increment skipping those values as it wraps, what do 
> you think?
NAV> Is using 255 as the starting sequence number simpler than using the
above logic?

Thx

Regards,
Navneet
> >> I think we need some more details the spec for describing 
> the value 
> >> to
> > be set
> >> in DAO rank.
> >>
> >>
> >> Feedback-II:
> >> DIO Sequence number: The issue was what should be the 
> initial value 
> >> of
> > this

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Mon, 12 Apr 2010 10:15:39 +0200

Hi Navneet,

Thanks for your feedback. I fully agree with the issues you described. I
just wanted to mention that our interop event was based on revision 05 of
the RPL draft.

My general impression is that the "DIO part" of RPL is stable, working well,
and it's probably a good time to freeze the specs there. Concerning the "DAO
part", we could only test the "fully storing" mode. What I observed was that
except for the "DAO rank" issue below, there was no interop problems but the
scalability of the solution needs to be improved  (the first think to do
would be to agree on a way to include several prefixes in a DAO packet).
Also I think RPL is currently at the right level of complexity for the
platforms it's targeting however we should be careful not to add to much
extra features.

Best,
Mathilde

-----Original Message-----
From: Navneet Agarwal (navagar) 
Sent: dimanche, 11. avril 2010 07:22
To: ROLL WG
Cc: Mathilde Durvy (mdurvy); JP Vasseur; Navneet Agarwal (navagar)
Subject: RE: [Roll] IPSO Interop event - Feed-back welcome

Hi:

Feedback-I:
DAO rank: It seems there very couple of different interpretations for
setting this value. 
A. Several implementations were setting the DAO rank to be equal to the node
rank (value sent in DIO rank). Each node relays this info in the DAO towards
the root. However this does not convey any differentiating info to the
receiving nodes when the DAOs are received thru multiple paths in order to
install the best route.
B. The other implementation was to set the value to 0 (or 1) by the node and
have the intermediate nodes increment it as the DAO rides up to the root.
The DAO rank in this case is more of a hop count and the receiving nodes can
make a decision based on the lowest value received when installing the DAO
route.
Pros: Decision is optimized based on hopcount. Relatively simple.
Cons: Hopcount does not take link cost into account.
C. A third proposal was to set the DAO rank equal to the node rank and a
link cost in the metric container as each nodes propagates the DAO. The
receiving nodes would make a decision based on the link cost.
Pros: Decision is optimized based on link cost
Cons: The DAOs would need to carry additional info in the packet (bigger
DAOs) and more processing needed in the nodes to parse and process.

I think we need some more details the spec for describing the value to be
set in DAO rank.

Feedback-II:
DIO Sequence number: The issue was what should be the initial value of this
field. The spec is not clear on what should be the initial value set by the
root. This has implications at the LBR in reload/reboot conditions. For
example, if the initial value is set to 1 and is incremented to say 10. When
the LBR reloads/reboots, it would start the sequence number with 1 but its
DIOs will be rejected by the nodes as having stale sequence number. The LBR
can store the sequence in persistent memory. An easier option could be use
255 as the starting sequence number. Using this value will make sure that
the sequence number is always valid.

Comments?

Thanks

Regards,
Navneet

> Following the discussion on the mailing list I just wanted to clarify 
> - We were proposed a slot to announce this first interop event during 
> together. The current status is that you have to pay a membership fee 
> have found would be extremely useful to continue to improve our spec.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Apr 2010 10:58:02 +0200

Hi Navneet:

Please reread the thread with Roger and others.
http://www.ietf.org/mail-archive/web/roll/current/msg03426.html 

A Node selects its parents based on the metrics it gets from them and
from whatever L2 trigger info it has about the link to those parents.
Once the node has selected its parents and in particular the subset that
are DAO parents, the reverse DAG to reach the node is decided.
All the rest, and in particular the DAO flooding back, is about
informing the parent(s) and the root of that decision. 
This is true in both stateful and stateless modes.

Now, it might happen that in the interest of getting multipath, the DAO
to a destination is fanned out, that is passed to multiple parents.
In that case, it is good to be able to track the preferred parent path
for a number of reasons:
- prefer that path
- minimize stretch
- control fan out within acceptable stretch

With the current spec, we give the impression that the routing can be
done again by the parents, because we give them metrics. 
It is particularly harmful in stateful mode when we give the impression
that we are doing some form of Link State operation at the root.
In fact all the root needs is to recursively follow the track of
preferred parent, and limit the stretch when that cannot be done.

All the information we need to do this is the usual preference that we
inherited from RFC 4191 and use in a number of places in RPL already.

The metrics, OF, etc... is only needed in DIO processing when the DAG is
built. The rest of RPL can be and should be completely generic.
If we want to control the complexity, I strongly suggest we leave it at
that.

Pascal

> Sent: Monday, April 12, 2010 10:16 AM
> To: JP Vasseur; Pascal Thubert (pthubert)
> Cc: ROLL WG
that
> if a metric is explicitly defined in the DAO it may be more
transparent for
> decision making in a mixed environment...imo. What do you think?
> 
> 
> 
> > >
> > >> A. Several implementations were setting the DAO rank to be equal
to
> > >> make a decision based on the lowest value received when
installing
> > >> C. A third proposal was to set the DAO rank equal to the node
rank
> > >> and
> > >> store the sequence in persistent memory. An easier option could
be
> > >> use
> > >>> event feedback. This will be given on individual, voluntary,
basis
> > > by

---

From: "Roger Alexander" <[email-masked]>
Date: Mon, 12 Apr 2010 12:03:01 -0400

Hi Navneet, Mathilde,

Thanks for the feedback on the interop event.

Roger

> Mathilde Durvy (mdurvy)
> Sent: Monday, April 12, 2010 4:16 AM
> To: Navneet Agarwal (navagar); ROLL WG
> Thanks for your feedback. I fully agree with the issues you described.
> I just wanted to mention that our interop event was based on revision
> 05 of the RPL draft.
> 
> My general impression is that the "DIO part" of RPL is stable, working
> well, and it's probably a good time to freeze the specs there.
> Concerning the "DAO part", we could only test the "fully storing" mode.
> What I observed was that except for the "DAO rank" issue below, there
> was no interop problems but the scalability of the solution needs to be
> improved  (the first think to do would be to agree on a way to include
> several prefixes in a DAO packet).

I would very strongly endorse this direction of multiple prefixes (the
option to carry full or partial sub-DAG stack) within the DAO message. This
capability together with the ability to support incremental update of
changes between a node and its DAO parents will greatly improve the
scalability of the solution for networks with storing nodes where nodes can
take advantage of acknowledged/cached information to limit repetitive DAO
transmissions.

> platforms it's targeting however we should be careful not to add to
> much extra features.
> 
> Best,
> Mathilde
> 
> node and have the intermediate nodes increment it as the DAO rides up
> to the root.
> a link cost in the metric container as each nodes propagates the DAO.
> The receiving nodes would make a decision based on the link cost.
> persistent memory. An easier option could be use
> 255 as the starting sequence number. Using this value will make sure
> that the sequence number is always valid.
> 
> Comments?
> 
> Thanks
> 
> Regards,
> Navneet
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Apr 2010 18:23:10 +0200

Hi Roger:

I do believe like you do that incremental updates will be a nice feature
and I'll support it in due time. I'm unsure we can fit that in the
current RPL version though, because even if it works better in a large
scale stable network, it has probably a less generic applicability than
the simple repeat over and over method that RPL uses today. But that's
just my vote.

For the steps that will make it possible (ask the DAO and multiple
targets in a DAO) I think they make sense in the current RPL for merits
of their own. My suggestion here is to have a target option that would
be valid in both DIO and DAO. In the DIO, the use would be the targeted
DIO that we discussed for P2P and so on, and in the DAO, that would be
advertising that target (eventually as a response to the DIO above).

What do you think?

Pascal

Of
> Roger Alexander
> Sent: Monday, April 12, 2010 6:03 PM
> To: Mathilde Durvy (mdurvy); Navneet Agarwal (navagar); 'ROLL WG'
> > was no interop problems but the scalability of the solution needs to
> > be improved  (the first think to do would be to agree on a way to
> > include several prefixes in a DAO packet).
> 
option
> to carry full or partial sub-DAG stack) within the DAO message. This
capability
> together with the ability to support incremental update of changes
between
> a node and its DAO parents will greatly improve the scalability of the
solution
> for networks with storing nodes where nodes can take advantage of
> acknowledged/cached information to limit repetitive DAO transmissions.
> 
> 
> > A. Several implementations were setting the DAO rank to be equal to
> > the node rank (value sent in DIO rank). Each node relays this info
in
> > the DAO towards the root. However this does not convey any
> > differentiating info to the receiving nodes when the DAOs are
received
> > thru multiple paths in order to install the best route.
> > incremented to say 10. When the LBR reloads/reboots, it would start
> > the sequence number with 1 but its DIOs will be rejected by the
nodes
> > as having stale sequence number. The LBR can store the sequence in
Behalf
> > > clarify a few things so that we can find the best way to interact
in
> > > the future.
> > > during the ROLL WG meeting, future events may be advertised only
on
> > > an IPSO web-site if this is preferred by the WG.
> > > fee to participate in these events (and indeed these events take
> > > work, prior preparation, and money to organize).
> > > event feedback. This will be given on individual, voluntary, basis
> > > by the participants of the interop event.
> > >
> > > Best,
> > > Mathilde
> > >
> > >
spec.

---

From: "Roger Alexander" <[email-masked]>
Date: Mon, 12 Apr 2010 14:08:34 -0400

Hi Navneet, Pascal,

Thanks again for the feedback on the interop and the issues highlighted.

> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Monday, April 12, 2010 4:58 AM
> To: Navneet Agarwal (navagar); JP Vasseur; Roger Alexander
> Cc: ROLL WG

Indeed, by selecting its DAO Parents, nodes are dictating the final hop of
the downward path and influencing the overall downward path selection.

> - control fan out within acceptable stretch

One consequence of maintaining multiple DAO parents is the potential fan out
of routing paths. With path fan out a node may have multiple downward next
hop addresses for a given target destination address. Without some path
preference indication there is no information available if a storing node
(including the root) wishes to limit the number of downward next hops
maintained for a given address. It is thus desirable to have some means of
path control to limit fan out as well as a preference indication that can
work in conjunction with the hop-by-hop DAO exchanges. 

See the Figure below for an example in which nodes maintain two DAO Parents
each, where in the worst case the fan out that occurs after three hops
results in eight next hop downward paths from the DODAG root (LBR) to a
target node (41). Even with the hop-by-hop DAO mechanism it would be
desirable to be able to limit fan out as well as to identify path preference
and diversity at the root or other intermediate storing node. 

                    (------------LBR------------)
                    /    /   / |     | \    \   \ 
                   /    /   /  |     |  \    \   \
                  /    /   /   |     |   \    \   \
                 /    /   /    |     |    \    \   \
              (11) (12) (13) (14)   (15) (16) (17) (18)
                 \   |    |    /     \    |    |   /
                  \  |    |   /       \   |    |  /
                   \ |    |  /         \  |    | /
                  (21)   (22)           (23)  (24)
                      \    |            |    /
                       \   |            |   /
                        \  |            |  /
                         (31)          (32)
                             \        /  
                              \      /    
                               \    /      
                                (41) 

A simple path control bitmap associated with the advertised Destination
Address can be included within the DAO to address the issue of path
preference as well as control of fan out. For a network of 'non-storing'
nodes the preference indication would be processed only at the root.

With the path control byte associated with each DAO destination address, a
node will be able to specify preference among DAO parent paths and can
convey limits on the number of downward paths. This is an opportunity for
nodes to further influence the downward paths that are established and
maintained. Consistent with the DV-based RPL operation this DAO path control
mechanism must operate hop-by-hop avoiding any requirement for end-to-end
path coordination. To avoid overloading this email thread I will initiate a
separate discussion on how a path control element may be included within the
DAO. 

> preferred parent, and limit the stretch when that cannot be done.

I do agree entirely and would reiterate that from the perspective of a
network with storing nodes there is no requirement for metric or Rank
information to be included in the DAO. Rank information is not required in
conjunction with routing table entries and if included at all within the DAO
would satisfy only a local need to reconfirm the Parent-Child relationship
to account for changes that may have occurred between the time of sending of
a DIO and the receipt of a new DAO (potentially as part of the acknowledged
DAO exchange).
 
> If we want to control the complexity, I strongly suggest we leave it at

+1 on maintaining metrics, OF, and other items of general protocol
configuration within the DIO only.

---

From: "Roger Alexander" <[email-masked]>
Date: Mon, 12 Apr 2010 14:28:19 -0400

Hi Pascal,

> Sent: Monday, April 12, 2010 12:23 PM
> To: Roger Alexander; Mathilde Durvy (mdurvy); Navneet Agarwal
> (navagar); ROLL WG

In the interest of continued movement on the core spec. this item can be
addressed as part of a specific domain applicability provided there are
elements in the base DAO/DIO structure that will permit later inclusion.

> of their own. 

I certainly support the DAO Acknowledgment and the option to include
multiple targets in a DAO message as capabilities that can have general
applicability.

My suggestion here is to have a target option that would
> advertising that target (eventually as a response to the DIO above).

Sure. To the extent that these measures can be defined in ways to address
requirements across the multiple RPL domain constituents that would indeed
be the preferred way to proceed.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 Apr 2010 09:47:14 +0200

Hi Roger:

I'm 100% with you. Let's see what others say...

Pascal

> From: Roger Alexander [mailto:[email-masked]]
> Sent: Monday, April 12, 2010 8:28 PM
> To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy); Navneet
Agarwal
> (navagar); 'ROLL WG'
> > I do believe like you do that incremental updates will be a nice
> > feature and I'll support it in due time. I'm unsure we can fit that
in
> > the current RPL version though, because even if it works better in a
> > large scale stable network, it has probably a less generic
> > applicability than the simple repeat over and over method that RPL
> > uses today. But that's just my vote.
> 
> > targets in a DAO) I think they make sense in the current RPL for
> > merits of their own.
> 
> > be valid in both DIO and DAO. In the DIO, the use would be the
> > targeted DIO that we discussed for P2P and so on, and in the DAO,
that
> > would be advertising that target (eventually as a response to the
DIO
> above).
Behalf
> > > > Concerning the "DAO part", we could only test the "fully
storing"
> > mode.
> > > > was no interop problems but the scalability of the solution
needs
> > > > Also I think RPL is currently at the right level of complexity
for
> > the
> > > > platforms it's targeting however we should be careful not to add
> > > > to much extra features.
> > > >
> > > > Best,
> > > > Mathilde
> > > >
> > > > DAO rank: It seems there very couple of different
interpretations
> > for
> > > > to the node rank (value sent in DIO rank). Each node relays this
> > > > info
> > in
> > > > B. The other implementation was to set the value to 0 (or 1) by
> > > > the node and have the intermediate nodes increment it as the DAO
> > > > rides
> > up
> > > > to the root.
rank
> > > > I think we need some more details the spec for describing the
> > > > value
> > to
> > > > be set in DAO rank.
> > > >
> > > >
> > > > Feedback-II:
> > > > DIO Sequence number: The issue was what should be the initial
> > > > value
> > of
> > > > incremented to say 10. When the LBR reloads/reboots, it would
> > > > start the sequence number with 1 but its DIOs will be rejected
by
> > > > > interact
> > > > > events
> > > > > together. The current status is that you have to pay a
> > > > > membership fee to participate in these events (and indeed
these
> > > > > events take work, prior preparation, and money to organize).