Seems i dropped the ball on these:
I am not sure i see the crucial need to be able to optimize the number of
packets of periodic ACP and BRSKI announcements.
Assume BRSKI, ACP and GRASP are diferent ASAs. We'd need a GRASP API feature to
request coalescion of announcement. How would you define that API feature...
The idea was to use M_FLOOD for BRSKI because that would allow the pledge to be
quiet. Which is more secure because pledge is potentially easy to attack.
For ACP i also have M_FLOOD in the text because thats the solution with just
one message. No need for two-way handshake.
Check out brians ani-objective. The alternative to M_FLOOD he lines out are
more complicated.
Cheers
Toerless
On Mon, Jun 19, 2017 at 09:36:04AM -0400, Michael Richardson wrote:
>
> Brian E Carpenter <[email protected]> wrote:
> >> If a node doesn't want to announce itself as a proxy, it would omit
> that
> >> objective.
> >>
> >> As for implementation, I've done it. It's a question of about a page
> >> of C
> >> code (given a cbor library), or about ten lines of ruby. Probably a
> >> similar
> >> number of lines of python.
>
> > I'm thinking that if we want to make a tiny extension to GRASP syntax
> for
> > this special purpose, we can do so in the BRSKI document. That's yet
> > another benefit of using CBOR.
>
> flood-message = [M_FLOOD, session-id, initiator, ttl,
> +[objective, (locator-option / [])]]
>
> You added the +[] there so that we can announce multiple objectives.
> I don't think that there is anything more to do in GRASP.
>
> All we need to do is define the AN_Proxy objective, and ACP has to
> define the AN_ACP objective. I just don't see any problem here.
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
