On 26-Aug-22 08:59, Michael Richardson wrote:
Brian E Carpenter wrote:
> (b) but it could be implemented *on top* of the current
> definition of GRASP, if the floods in question were issued with a loop
> count of 1 (so they would never be relayed per RFC8990), and there was
Brian E Carpenter wrote:
> (b) but it could be implemented *on top* of the current
> definition of GRASP, if the floods in question were issued with a loop
> count of 1 (so they would never be relayed per RFC8990), and there was
> a flood consolidator - effectively just a special
On 26-Aug-22 03:58, Michael Richardson wrote:
Toerless Eckert wrote:
> Could as well simply be a function which buffers flood-messages over a
> period of e.g.: 60 seconds and coalesces them together, so it's
> transparent to the originators (loose coupling).
> So, now i hav
Toerless Eckert wrote:
> I can not link ICN to the use-cases you describe. I could however
> easily map the resilient light-switch use-case to multicast and GRASP:
okay.
> Light switches could M_FLOOD instructions, such as in old building
> automation: GROUP_123 on/off. And ligh
Toerless Eckert wrote:
> Could as well simply be a function which buffers flood-messages over a
> period of e.g.: 60 seconds and coalesces them together, so it's
> transparent to the originators (loose coupling).
> So, now i have a single flood-message with multiple objectives, e
Toerless Eckert wrote:
> On Wed, Aug 24, 2022 at 08:33:43PM -0400, Michael Richardson wrote:
>>
>> Brian E Carpenter wrote: > I need to
>> understand epochs a bit better. I wonder whether an epoch > boundary
>> should define when session-id repetition becomes OK (even if > hi
Changing subject because i think this is a broader/different
discussion than GRASP signature/extensions
I can not link ICN to the use-cases you describe. I could however easily map
the resilient light-switch use-case to multicast and GRASP:
Light switches could M_FLOOD instructions, such as in o