I'd like to keep 6P simple, and just have a mechanism to detect
inconsistencies. I believe roll-back to a previous schedule generation adds
too much complexity. From an implementation point of view, cells that are
in the process of being reserved (i.e. 6P add request sent but no response
received y
In thread "Node Behavior at Boot in SF0" (
https://www.ietf.org/mail-archive/web/6tisch/current/msg04883.html), we
ended up discussing the following paragraph
https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-10:
In order to define a known state after the node is restarted, a C
Yatch,
Agreed. Let's me start a different thread where I summarize your suggestion
and ask for WG consensus.
Thomas
On Mon, Nov 21, 2016 at 5:10 PM, Michael Richardson
wrote:
>
> Yasuyuki Tanaka wrote:
> >> Sending an explicit CLEAR will speed things up, and avoid for the
> >> previous
Hi Yatch,
my 2 cents inline
> I've been thinking about how to handle inconsistencies. I know the
> current draft has an inconsistency detection mechanism with generation
> management; just wondering if there is another way or a supplemental
> mechanism to deal with such a situation.
>
> We decide
Hi all,
I'd like to bring up Nicola's idea, 6P ACK, which came out on the
thread of "SF Timeout calculation (Ticket #53)":
https://www.ietf.org/mail-archive/web/6tisch/current/msg04866.html
A 6P ack would make the 6P negotiation reliable. B can 'half' open
the RX side after receiving the mac
Yasuyuki Tanaka wrote:
>> Sending an explicit CLEAR will speed things up, and avoid for the
>> previous preferred parent to waste energy listening to those. A CLEAR
>> wouldn't hurt, right?
> This is right. But, I don't think it's a SF0 job. The thing is that SF0
> knows noth
peter van der Stok wrote:
> which meeting do you want me to join?
You are welcome at both. The 6tisch is probably more important in some ways,
The EST/CoAP discussion will be easier to have in the anima group.
(I will post to ace about that this week)
--
Michael Richardson , Sandelman Soft
Thank you, Diego.
I believe I have correct understanding as you explained.
Best,
Yatch
On 2016/11/21 14:26, Prof. Diego Dujovne wrote:
Yatch,
From my point of view, the only entities allowed
to talk to 6P are the SFs, so a clear command should
be triggered by the SF. From the point of
Hi Thomas,
Could we say something to the effect that, if SF0 realizes
connection to a particular neighbor is no longer needed (for example
a change in parent by the routing protocol) SF0 MAY send CLEAR
requests to neighbor to speed up the cleanup process of the cells
with that neighbors?
I gue
cool, thanks
On Mon, Nov 21, 2016 at 2:45 PM, Xavi Vilajosana Guillen <
xvilajos...@uoc.edu> wrote:
> yep, makes sense. We thought it in the wrong way then.
>
> I update minimal right now.
>
> thanks for the quick response!
> X
>
> 2016-11-21 14:29 GMT+01:00 Thomas Watteyne :
>
>> Tero,
>>
>> You
yep, makes sense. We thought it in the wrong way then.
I update minimal right now.
thanks for the quick response!
X
2016-11-21 14:29 GMT+01:00 Thomas Watteyne :
> Tero,
>
> Your explanation about setting the cell to ADVERTISING makes sense.
>
> Xavi?
>
> Thomas
>
> On Mon, Nov 21, 2016 at 1:26
Tero,
Your explanation about setting the cell to ADVERTISING makes sense.
Xavi?
Thomas
On Mon, Nov 21, 2016 at 1:26 PM, Tero Kivinen wrote:
> Xavi Vilajosana Guillen writes:
> > We discussed this. We said to use NORMAL in order to support any type of
> > packet in the minimal cell/s and not o
Yatch,
From my point of view, the only entities allowed
to talk to 6P are the SFs, so a clear command should
be triggered by the SF. From the point of view of the
SF, there will be no more effectively used cells towards
that particular neighbour, thus reducing the number of
cells to the OV
Yatch,
Hmm, good point. I'm with you that have SF0 be independent from higher
layer stuff is the right design approach.
But SF0 doesn't really offer any API for upper-layers (it would be against
its "minimal" nature). Could we say something to the effect that, if SF0
realizes connection to a part
Michael, all,
Please find below my review of draft-richardson-6lo-ra-in-ie-00.
Since interesting for both 6lo and 6TISCH, sending to both MLs.
Typos fixed directly in line (please use diff), discussion points started
at newline with "TW>" prefix.
Since short draft, send review in body directly.
Xavi Vilajosana Guillen writes:
> We discussed this. We said to use NORMAL in order to support any type of
> packet in the minimal cell/s and not only EBs. From our discussions, I think
> that we all understood (at least is what I captured in the minimal text) that
> if the type is NORMAL we can al
Hi Thomas,
Sending an explicit CLEAR will speed things up, and avoid for the
previous preferred parent to waste energy listening to those. A
CLEAR wouldn't hurt, right?
This is right. But, I don't think it's a SF0 job. The thing is that
SF0 knows nothing about RPL.
If SF0 provided an API to s
Hi Michael,
which meeting do you want me to join?
Peter
Michael Richardson schreef op 2016-11-18 04:30:
The 6tisch security design team will meet every two weeks starting on
November 29th at 14:00 UTC. The meeting is anchored to UTC, not EST,
but
that will matter only in March.
The nov. 29
18 matches
Mail list logo
