Re: [Anima] proxy discovery of registrar

[Brian E Carpenter <[e-mail]>]

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