On 02/08/2017 12:38, Michael Richardson wrote: > > Brian, I opened issue https://github.com/anima-wg/anima-bootstrap/issues/23 > to close the question about how the BRSKI proxy finds the Join Registrar. > > 1) Toerless needs to remove that text from ACP document. It does not belong.
I agree. (I am in the middle of typing in my comments about ACP draft -08.) > BTW, I was reviewing https://www.rfc-editor.org/cluster_info.php?cid=C325 > and GRASP is going to wait for the ACP document. Ick. I thought it was > just CDDL. It was, but Eric Rescorla insisted on the ACP becoming normative, and I think he was correct. I don't think it matters much in practice; we need the ACP done anyway! > The more speculative text that can be removed from the ACP document, the > faster it will progress. > > 2) M_FLOOD vs M_DISCOVER. Your issue > https://github.com/anima-wg/anima-bootstrap/issues/22 point 3, about how > we did things wrong is well taken. > > I think that I prefer to use M_DISCOVER to find the Registrar, as the > information about it is most likely cached in a nearby node. > > Toerless has instead written the M_FLOOD mechanism. > We started a thread a few weeks ago about this... what happened to it, I > would have to look. In either case, I would like to please discuss this > in the context of the BRSKI document, not the ACP. Sure. My understanding was discover/synchronize which is what I put in draft-carpenter-anima-ani-objectives-03 (and in the latest demo code if anyone cares: https://github.com/becarpenter/graspy/blob/master/brski-demo.pdf ). But this needs to be a firm consensus in the BRSKI team. > Brian, we selected M_DISCOVER/M_NEG_SYN method because: > a) we didn't think the location of the Registrar would change frequently, > or perhaps ever. Of course the responses have TTLs, so it's not really > a big deal. > > b) your experiences with mcast at IETF98 has made me concerned that we > should not use flooding if we don't have to. > OTOH, the proxy is going to discover the registrar over the ACP, > and we won't have any L2 switches directly in the path to like we > had at IETF98. > > > The process is supposed to be: > proxy: M_DISCOVER---> > neighbor: M_DISCOVER---> > registrar > <--- M_RESPONSE-- > neighbor (caches) > <--- M_RESPONSE-- > > I think. I don't know anymore... > > Do we want: > o a discovery objective option (Section 2.10.1). That only gets you the address. > o a negotiation objective option (Section 2.10.1). That implies the proxy has something to discuss with the registrar. > o a synchronization objective option That implies that the registrar has something to announce to the proxy (such as "I support foobar and barfoo"). > > ?? > > I think that I concluded we needed the third option, which is why I think > that I wound up into M_REQ_SYN. I concur. Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
