On 26-Aug-22 03:58, Michael Richardson wrote:
Toerless Eckert <t...@cs.fau.de> 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, each
> objective requiring its own signature, because it comes from a
> different originator/certificate.
I can buy this example.
I think that the cost of the flood across the wired/powered part of the
network is low, and the number of messages we can coalesce is not that
many. at least ~50 bytes per message, given a 32-byte EcDSA signature.
That's still a 20:1 ratio though, and nothing to sneeze at.
I'll just observe that
(a) this would be a fundamental change to the definition of M_FLOOD and how
it works, if it was designed as a GRASP feature.
(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 ASA as far as GRASP is concerned - that sent out consolidated floods.
Brian
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
