On 09/01/2017 06:27, Michael Richardson 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. 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. 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. 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. Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
