[Anima-bootstrap] mDNS or GRASP? [was: peer and domain [was BRSKI State Machine]]

["Michael Behringer (mbehring)" <[e-mail]>]

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: 18 October 2016 21:46
> To: Michael Behringer (mbehring) <[e-mail]>; Max Pritikin
> (pritikin) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: peer and domain [was BRSKI State Machine]
> 
> On 18/10/2016 21:03, Michael Behringer (mbehring) wrote:
> >> -----Original Message-----
> >> From: Brian E Carpenter [mailto:[e-mail]]
> >> Sent: 18 October 2016 01:18
> >> To: Max Pritikin (pritikin) <[e-mail]>; Michael Behringer
> >> (mbehring) <[e-mail]>
> >> Cc: [e-mail]
> >> Subject: peer and domain [was BRSKI State Machine]
> >>
> >>
> >>
> >> On 18/10/2016 12:05, Max Pritikin (pritikin) wrote:
> >> ...
> >>>> - I think we need to bring out more strongly that the state machine
> >>>> needs
> >> to track peer and domain. Because, if there is a failure, the pledge
> >> should, depending on the failure of course, not try the same domain
> >> again, and probably not the same peer either. This isn't coming out today.
> >>>> In fact, this is why I liked the "adjacency table" so much that I
> >>>> presented in
> >> Berlin (and before): Because there you see much clearer that, if
> >> enrolment fails with peer x, you may just move to the next one. As
> >> mentioned it's all there, but to a new reader this won't come out clearly,
> I'm afraid.
> >>>
> >>> Yeah, I can see your point that this is buried in the text of 3.1.1
> >>> where it is
> >> implied that there is a list of "services returned during each query”
> >> and in failure the list processing "picks up where it left off” but thats
> pretty subtle.
> >>
> >> What exactly is the "peer" in the above text? I tend to assume it's the
> proxy.
> >> In that case it seems to me that the discovery process (whether it's
> >> mDNS or
> >> GRASP) will discover all available proxies regardless of domain. And
> >> then try them in some order of preference TBD.
> >
> > "peer" is an entry in the adjacency table. Yes, there may be several on an
> interface, of several different domains. The adjacency table discussion tries
> to capture that.
> 
> Fair enough. But anyway my comment still applies: a node that is joining the
> ACP, or simply updating its ACP adjacencies, will discover all available
> neighbors...

True. But why is that a problem, or what are you suggesting because of this? 
(I think I got lost in the arguments here)
 
> >
> >> Also, all of this needs to work in the absence of an ACP and
> >> therefore of the ACP's adjacency table. That applies to GRASP too,
> >> because in order to perform its various link-local actions, it needs
> >> to know which interfaces it has and which link-local addresses it
> >> has. And it learns of its link-local neighbors as a result of
> >> discovery. So while I fully appreciate the value of the adjacency table, we
> need to be functional without it.
> >
> > Now we're getting into a muddle with ANIMA vs non-ANIMA modes. (And
> you're right - this is important to sort out). Let's see whether we can sort
> that.
> >
> > Up front: This is the ANIMA WG, and we're primarily defining the behaviour
> of an ANIMA node. This is, IMO:
> >
> > - There is an adjacency table, that observes what nodes are seen on each
> ANIMA-capable interface.
> > - This table is fed by discovery (primarily).
> > - Depending on the state of the node, and the state of an adjacent node,
> different things will happen.
> >   (see my presentation on the reference model, last IETF - all
> > described there)
> >
> > For ANIMA, we need to settle on MUST discovery methods.
> > In ANIMA, we will ALWAYS build an ACP to other nodes of the same
> domain.
> >
> > The adjacency table links BRSKI and ACP automatically: Once I discover a
> node which is in the same domain, I attempt to set up an ACP connection
> with that node.
> 
> Sure. And I think I can model that with GRASP - it simply needs an objective
> that includes the domain and node credentials, right?

We need a discovery protocol. 
We should use the same discovery protocol for BRSKI and ACP (and other actions later on, see my message a few mins ago)
GRASP *could* be that protocol, in the way you describe. 
But my understanding was that we had settled on using mDNS for this discovery. 

In the bootstrap calls, this was "decided", see
http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true
Notes from 2016-10-04, bullet 3 (currently, lines 175-178):  
 
<include from etherpad>
3. https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-03#section-3.1.1 does not specify a GRASP mechanism for proxy discovery, should it?

max feels, "no" because defining an insecure mode of GRASP is difficult.

mcr feels, "no" because discovery by multicast UDP but replys are by TCP which means the new node needs to open a TCP port to get a reply back. We just had a long conversation about TCP/UDP etc (re flipping the handshake) and this adds more confusion.

group conclusion: close this. "No". (agreement on the call is noted; with toerless voting for grasp but accepting the group decision)
</include> 

Obviously, we don't have consensus on this in the wider WG yet. We really need to get this consensus to move on. 

(Note that GRASP for discovery in the ACP, and for negotiating between ASAs is generally accepted, I think)

Michael

> >
> > Outside ANIMA, GRASP can be used in many other ways; BRSKI can be
> used to derive LDevIDs and nothing else.
> >
> > Do we agree?
> 
> I think so. But I won't know so until I see what the ACP's API looks like.
> Remember that GRASP needs to create unicast and multicast sockets, so in
> an ACP regime those sockets need to be provided by the ACP.
> 
>    Brian
> 
> > Michael
> >
> >> Rgds
> >>     Brian
> >>
> >