Regards Brian Carpenter
On 09/01/2017 13:57, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> 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. Understood (now, but not when I wrote my toy code or the draft). > > 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_ ?? Personally I think that would be a helpful convention, but I'm not sure we should have a *rule*. > > 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. Great. And where the assumptions are false, don't hesitate to say so. Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
