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. 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. 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. 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). o a negotiation objective option (Section 2.10.1). o a synchronization objective option ?? I think that I concluded we needed the third option, which is why I think that I wound up into M_REQ_SYN. -- 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
