Re: [Anima] ANIMA state machines, take two
{pushing send on an email in process for some days}
Brian E Carpenter wrote:
> I like this. I have a few comments on some of your open questions:
>> Discovery: mDNS or GRASP?
> I feel very strongly that we need the ANI to be as self-contained as
> possible. Therefore, it must be possible for the ANI to create itself
> without depending on mDNS. Therefore, we must use GRASP discovery (or
> flooding, if we prefer an announcement method) for AN nodes.
I agree that enrolled AN nodes MUST use GRASP for discovery, and I think that
M_FLOOD is the way to create the neighbour table for that.
>> one discovery method for BRSKI and ACP, or several?
> Non-ANI nodes can also use BRSKI. So to say this one more time, since I
> won't be in Seoul: BRSKI proxies MUST be discoverable by both mDNS and
> GRASP.
I am warming to use of M_FLOOD for this, whereby the Join Assistant announces
itself.
>> multicast domain info?
>> packet formats
> For the discovery methods, that is already settled by mDNS and GRASP,
> isn't it? For BRSKI itself and ACP formation, the formats belong in the
> BRSKI and ACP drafts.
Agreed, I don't think that there are any open questions here.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] ANIMA state machines, take two
Michael Behringer (mbehring) wrote: > I had already sent out an early version of the state machines before, > here an update. > To the high level state machine, I added a state "Proxy mode". A node > is in that state when the ACP is up AND it can see a registrar. Other > than that, I think the high level diagram should be ok. Looking for > feedback. I disagree with this state or machine. The proxy process is, as you described, dependant upon having reached the In ACP mode, and having discovered a Registrar. That's true. Assuming IKEv2 (whether keying IPsec, or keying MACSEC [%]) There is some RPL state machine inside the In ACP state as well, but I'm not But, I wouldn't describe it as a seperate state, rather it's an attribute of having reached In ACP mode. I would expect the ACP process, once it has been informed by the RPL daemon that it has found a ground RPL DODAG to join, that it would spawn off the Join Assistant process. The Join Assistant would then open a TCP socket to receive the GRASP reply (binding the socket to the ACP ULA address), and then do a GRASP M_DISCOVERY. Once it gets a response from a Registrar, it would begin listening for New Node discovery messages and relaying. This would be a seperate state machine. Would you like this in the bootstrapping document? > The state machine for the BRSKI pledge (it's a detail on the ANIMA > state machine) still has a lot of open questions. Most are under > discussion. I tried to illustrate where we have open points. You have listed: Discovery: mDNS or GRASP? one discovery method for BRSKI and ACP, or several? multicast domain info? packet formats BRSKI: Feedback to the pledge? (specifically: Reason for rejection / retry?) Let me be more specific, because I think these are not open questions. Discovery of AN peer: - GRASP M_FLOOD (MTI) Discovery of Join Assistant by Pledge: - GRASP M_FLOOD (MUST for JA, SHOULD for Pledge) - mDNS (SHOULD for JA, MAY for Pledge) The "multicast domain info" question is vague to me, but if you mean the multicast scope, it's LL, scope=2. (scope=1 being host) Packet formats are determined by GRASP and mDNS. The feedback to the pledge about rejection would occur inside of EST, and so is about RFC7030, right? [%] - Linux now has a MACSEC implementation I noticed. If supporting MACSEC is interesting to many, then we need a KMP for it, and we need to negotiate it's use via IKEv2. I suggest that a document doing this would not be very long or difficult to pass through the IPsec WG. If supporting MACSEC is not a priority now, then as long as we negotiate the ACP using IKEv2, then we can add it later on rather easily. signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] ANIMA state machines, take two
Michael, I like this. I have a few comments on some of your open questions: > Discovery: >mDNS or GRASP? I feel very strongly that we need the ANI to be as self-contained as possible. Therefore, it must be possible for the ANI to create itself without depending on mDNS. Therefore, we must use GRASP discovery (or flooding, if we prefer an announcement method) for AN nodes. > one discovery method for BRSKI and ACP, or several? Non-ANI nodes can also use BRSKI. So to say this one more time, since I won't be in Seoul: BRSKI proxies MUST be discoverable by both mDNS and GRASP. (One open question in my mind is this: does the pledge know or care whether it is dealing with a proxy or directly with the registrar, if the registrar happens to be on the local link? That does affect some details, at least in the GRASP case.) > multicast domain info? > packet formats For the discovery methods, that is already settled by mDNS and GRASP, isn't it? For BRSKI itself and ACP formation, the formats belong in the BRSKI and ACP drafts. Regards Brian On 11/11/2016 05:04, Michael Behringer (mbehring) wrote: > I had already sent out an early version of the state machines before, here an > update. > > To the high level state machine, I added a state "Proxy mode". A node is in > that state when the ACP is up AND it can see a registrar. Other than that, I > think the high level diagram should be ok. Looking for feedback. > > The state machine for the BRSKI pledge (it's a detail on the ANIMA state > machine) still has a lot of open questions. Most are under discussion. I > tried to illustrate where we have open points. > > I now tried also a state machine for the ACP. I'd appreciate some feedback on > it. > > To me, the big open things are: > - nail down discovery protocol and packet formats for both discoveries (for > bootstrap and ACP). > - decide which (if any) feedback we want to give to the pledge. > > But, I think these diagrams show nicely how all the drafts fit together, > which was the purpose of this exercise. > > Feedback? See you in Seoul! (Will be there from Sunday evening) > Michael > > > > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
