Re: [Anima] Use of M_FLOOD for discovery of Proxy

[Toerless Eckert <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>