Brian E Carpenter <[email protected]> wrote: >> We want to use GRASP to permit the bootstrap proxy to discover where >> the Registrar(s) are. As far as I can see there are really two >> options, and they might not be mutually exclusive. >> >> a) start a multicast M_DISCOVERY which will be propagated forward and >> can be answered from caches. b) listen for an M_FLOOD. >> >> As I see it there are advantages and disadvantages to each. >> >> My take before was that M_DISCOVERY was to be preferred in most cases. >> I'm really just writing to confirm this belief.
> As always, it's a tradeoff. My impression after discussions some months
> ago was the the BRSKI team preferred M_FLOOD, but I have no strong
> opinion.
We want M_FLOOD for discovery *OF* the proxy.
I'm asking about discovery *BY* the proxy *OF* the registrar.
> Firstly, I assume that the registrar/proxy hookup can take place over
> the ACP, because the nodes involved already have certificates and the
> ACP has formed itself. (This will occur as an expanding circle around
> the registrar, which will proxy for itself on its own link-local
> interfaces.) So from a security viewpoint, there isn't much difference.
Agreed.
> Secondly, the methods aren't mutually exclusive. If the "normal" method
> is flooding an objective that I've called "AN_registrar" in my toy
> code, nothing prevents discovery/synchronize being used as a backup.
Question: should all the internal objectives be AN_ ??
> That said, it seems that once a proxy has found a registrar, there's no
> need for a regular refresh, so discovery seems appropriate. (Don't
> forget that the discovery cache will time out, but that's standard.)
> Send comments on
> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives We
> assumed the flooding model for registrar/proxy there, but described
> both models for the pledge/proxy hookup.
I intend to contribute to it this week.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
