Subject: [Anima] proxy discovery of registrar

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Aug 2017 20:38:41 -0400

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-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Aug 2017 13:04:06 +1200

> 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.)

>    and GRASP is going to wait for the ACP document. Ick.  I thought it was

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!

>    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.

>    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").

> that I wound up into M_REQ_SYN.

I concur.

     Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Aug 2017 15:46:30 -0400

> But this needs to be a firm consensus in the BRSKI team.

I did take a look at the code yesterday in the end, and I'll like run it
sometime soon, but I decided I didn't want to reverse engineer the spec from
the code :-)

    > the proxy (such as "I support foobar and barfoo").

Do we have some preference for "AN_join_register" (and AN_Proxy and AN_ACP),
or is the AN_ prefix unwanted?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Aug 2017 08:25:04 +1200

> or is the AN_ prefix unwanted?

It's only a name, so we can do what we want. I put the prefix just to mark the
fact that they are ANI components but I have no strong feelings about it.

    Brian