Dear all,
During today's webex call, I presented a slide where
the comments below were going to be addressed on the next
version of the draft.
However, I raised the point about:
Ø 4. Rules for CellList
Why is this here? Which cell are allocated is not SF0 ‘s business, is it?
OTOH, the semantics of the ADD that is mentioned should be somewhere, and I
think, in this document.
-> This section is recommended by the 6top-protocol draft, and AFAIK it
defines which cells are offered and which are selected for allocation.
Ø 7. Node Behavior at Boot
Again this is describing 6P not SF0 behavior. Note that the clear should be
done at link up in case
-> This section is also recommended by the 6top-protocol draft, and it
should include any type of pre-configuration and expected initial state on
the SF.
-> From the comment from Pascal on today's webex: "What if a node has a big
storage and it can keep all configuration after a crash?" The SF can
use that info to reconstruct all the configuration and recover instead of
issuing a clear command. However, there must be a timeout period for
recover;
if this timeout expires, then all the cells from the crashed node shall be
released.
Rules for CellList and Node Behaviour at boot are
recommended on Sec. 5.3 of draft-ietf-6tisch-6top-
protocol-00
2016-04-18 13:48 GMT-03:00 Pascal Thubert (pthubert) <pthub...@cisco.com>:
> Dear authors:
>
>
>
> Please find my review of the SF0 draft; but since last call is pending
> please do not make **any** changes till after draft-ietf-*- 00 is
> published.
>
>
>
>
>
>
>
> Ø This document addresses the requirements for a scheduling function
>
> listed in [I-D.wang-6tisch-6top-sublayer
> <https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#ref-I-D.wang-6tisch-6top-sublayer>],
> Section 4.2, and follows
>
> the recommended outline from Section 4.3
> <https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#section-4.3>.
>
>
>
> I would expect that this doc is the reference for SF and is the one that
> requests the creation of the SF registry by IANA (text to be added in the
> IANA section).
>
> This reference to sublayer should go away since we are not promoting the
> draft at the moment – or should we be doing so?
>
>
>
>
>
>
>
> Ø
>
> Ø 3.1. SF0 Triggering Events
>
> Ø
>
> Ø We RECOMMEND SF0 to be triggered at least by the following events:
>
>
>
> The term ‘We’ is probably inappropriate. Better formulate this like “ It
> is RECOMMENDED that…”
>
>
>
> Also shouldn’t there be an event when:
>
>
>
> - Connectivity to the neighbor is lost. A L3 Link down event
> should free up resources. The question for 6P is how both sides agree at
> the same time that the link is down.
>
> - A threshold of unused time slots is reached so they should be
> freed
>
>
>
>
>
> Ø 6. If the RAB is less than the Minimum Remaining Bandwidth (MRB),
>
> Add MRB to the NOB: NOB=NOB+MRB
>
>
>
> Shouldn’t this be
>
> NOB=MRB
>
>
>
>
>
>
>
> Ø 4. Rules for CellList
>
>
>
> Why is this here? Which cell are allocated is not SF0 ‘s business, is it?
> OTOH, the semantics of the ADD that is mentioned should be somewhere, and I
> think, in this document.
>
>
>
>
>
> Ø 7. Node Behavior at Boot
>
>
>
> Again this is describing 6P not SF0 behavior. Note that the clear should
> be done at link up in case
>
>
>
>
>
>
>
>
>
> Ø 11. Examples
>
> Ø
>
> Ø TODO
>
> Ø
>
> Ø 12. Implementation Status
>
>
>
> These sections probably belong to annexes
>
>
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
