ANIMA IETF-97, Seoul, Korea Chairs: Toerless Eckert & Sheng Jiang Note taker: Bing Liu Anima Session I, Wednesday (November 16th, 2016) 9:30-11:00 Grand Ballroom 3 ********************************************************************************** 1. GRASP update (draft-ietf-anima-grasp-08), by Bing Liu [Sheng]: Did you ever do inter-operation test between the two prototypes? [Bing]: Not yet. [Sheng]: You should do say. That will help a lot to tell whether there are issues. [Sheng]: This document has passed WGLC, but more reviews/comments are still welcomed. WG planning to ship it to IESG in a month time. ********************************************************************************** 2. BRSKI update (draft-ietf-anima-bootstrap-04), by Michael Richardson & Kent Watson [Dean Bogdavic]: for network selection, I want to connect the network with low latency etc., the network would provide the connectivity that I need. [Michael Rechardson]: but at this point, I don't even know who you are; after we agree on your identity, then you could express the desire. Make sense to you? [Dean: yes, thanks.] [Sheng]: I believe that's out of the scope of current charter, but that could be something we work on later. I assume that kind of network selection also could be autonomic. [Michael R.]: Yes, sure. But that's an ASA. [Sheng]: ASA is not in current charter, but could be potential future work. I encourage you guys to bring that in the future. [Dean]: you are ready to connect me to a network, but I don't know whether that network satisfy my service requirements. So based on my desire, what I want to do, you can provisionally connect me and authenticate me. [Michael R.]: assuming I'm your mother...once we figure out we have the parent- child relationship...[Dean: now I'm a teenager]...but first of all you have to be a child, at that point we have the connectivity to you, if you have some additional requirements, maybe through some other management protocol, you can connect another network that already trusted you. [Dean]: so I can roaming to other networks and keep the authentication? [Michael R.]: you now have a credential that "my family" will trust. [Michael Behringer]: about bootstrap document, two things can come back: ownership voucher and auditory token. I'm not clear whether we now make it hard coded for pledge? Say, I'll only accept only one or the other, or do we accept either. [Michael R.]: specific devices are decided by the manufacture how they are going to be operated. [Michael B.]: a vendor can program his devices such that he does require one or the other? [Michael R.]: the vendor has to pick one or the other. The registrar MUST accept either. [Michael B.]: my question is more about the pledge. So it's not a valid scenario that a pledge MAY accept one or the other, it MUST accept either? [Michael R.]: the pledge MUST request A or request B. The pledge is in control of the process. [Sheng]: Can it do both A and B? [Michael R.]: I don't think it can express both. [Dean]: Anima is the better WG for Kent's draft-kwatsen-netconf-voucher, because of the overall context. [Kent]: it doesn't impact Netconf/Restconf protocol, the voucher is the payload. [Sheng]: in that case, I encourage you to bring it back the next meeting, and apply the time slot ealier. Then we can have a proper discussion, and consider that in the re-charter. [Michael R.]: so you are suggesting it to be in the charter, I'm not sure I understand that. What we want to do is basically saying we have a bunch of text gonna to be common with another group. If the Netconf WG didn't exit, then all of Kent's work would be inside BRSKI document already, so in some sense be in charter already. ********************************************************************************** 3. ACP update (draft-ietf-anima-acp-04), by Toerless Eckert joining remotely [Bing]: you mentioned DULL for the ACP discovery, in GRASP-08 there is another instance SONN specifically for ACP discovery. [Toerless]: that is actually what I said in slide 2. SONN is for ACP channel negotiation. [Bing]: but I think the discovery could also be protected by SONN. When we discover the ACP neighbors, we don't need to multicast around the domain. We know which neighbors we want to negotiate the ACP tunnel. [Toerless]: that's not true, because we don't know neighbors, DULL the only thing to do in link-local multicast to figure out what bloody neighbors might be and can talk to, then transferring into either SONN which is TLS, or directly a simpler IPSec to that neighbor. [Michael R.]: 1. only with M_Flood in GRASP, it's both ACP needs and BRSKI needs. We'd like to support with a combination of MAY and SHOULD for mDNS for bootstrapping of other things that may not join the ACP. 2. on the topic of VRFs, I agree creation of separate routing is very, very much platform specific. [Michael B.]: one of the arguments here is that GRASP is in our control, we can decide the behavior of it. [Bing]: in slide 4, GRASP DULL is chosen for not propagating the ACP discovery. In draft-liu-grasp-distribution, we have a mechanism to allow the receiving node not forward the messages, based on the Selective Flooding Criteria. [Toerless]: you're talking about something that the recipient would trust the sender. I think in insecure environment, you can't do it. [Alex Galis]: clarification question: what are the self-configuration aspects of the control plane explicit in this environment as a means to if you want to participate different types of control planes, is differently for different context. Is it something embedded or it needs to be explicit? [Toerless]: the ACP right now provides secure autonomic connectivity between the devices and the NOC. The auto-configuration would come either from either SDN controller or a non fully autonomic network through the ACP, or through the ASAs. ********************************************************************************** 4. Anima Reference Model update (draft-ietf-anima-reference-model-03, not published yet), by Michael Behringer [Bing]: a quick correction: (discovery between the pledge and proxy)the M_Flood should be M_Discovery. [Michael R.]: we want to have M_Flood because we don't want the Proxy-Pledge have to open the TCP ports for the response and get many. That why the answer is M_Flood is here. I also think M_Flood is suitable for ACP formation. [Brian:] I agree with Michael R.. Both M_Discovery and M_Flood are link-local multicast. The advantage of M_Flood is the only person to have the Flood is the proxy, or the ACP reciepient. There is no need for the pledge or the ACP joining devices to broadcast their existence, which is more secure. [Michael R.]: we always have GRASP M_Flood; no M_Flood, no ACP, no autonomics. For proxies, they SHOULD response mDNS. The reason is, other non-Anima devices try to bootstrap, not speak GRASP at all. That's a little bit out of scope, but that's our request, if the protocol re-useable by other things. [Sheng]: for now we agree, M_Flood is everything we start. It starts from M_Flood, to find out whether we have Anima context or not. Right? [Michael R.] Yes. [Toerless]: suggest the bootstrap people read the GRASP DULL text, to see whether bootstrap could reuse the DULL definition to avoid duplicates. [Michael R.]: need time to read it and revise bootstrap accordingly. I'll be happy if there is another document for bootstrap used in non-Anima context. [Sheng]: you can include it in the Anima bootstrap document, maybe in the appendix. [Michael]: that would be fine, if it is in the non-normative appendix. Anima Session II, Friday (November 18th, 2016) 9:30-11:30, Park Ballroom 2 ********************************************************************************** 1. Reference Model(Cont.) - by Michael Behringer [Joel Harlpern]: in terms of "state machine", I think that's a bad representation, very bad, all the rest I like. Once you're in the ACP, you're going to discover objectives, take on roles in various activities; even if one particular objective is mandatory for every ACP participant, it's really just one objective, it is not a different "state" for the Anima device. So, trying to represent proxy mode as if it is a distinct state from in ACP, seems to conflict two different aspects of our work. Some little concern about that. [Michael R.]: step further, be in ACP, the proxy mode is a management function be informed of. It's just another ASA. [Toerles]: how about call it "the state of ANI", the infrastructure includes the proxy, why shouldn't it in the state machine. [Sheng]: actually what you have is the ANI functions in the Anima devices. The state machine is only on ANI functions. [Alex]: i like the "state machine" description. I wonder 3 small issues behind this. 1. There needs to be an opposite bootstrap state; 2.I suspect there devices will sooner of later change the registration, maybe move from one network to another one. (Michael B.: that's in the BRSKI draft, if change domain, MUST set back to factory default); 3.I suspect all the devices would support autonomic functions, that operation is called operational state, or some sort. It is clearly not the representive here directly. [Michael B.]: note taker, pls record:(for the "state machine") 1.we take away the "proxy mode"; 2.we added at the bottom, from here you load the ASAs 3. do the reverse, like, how do you get back to the factory default. [Joel]: response to Toerless' concern. The notion of "state of ANI" is a different thing than the notion of "state of any device" that participate in it. [Brian]: don't lose the point that this is only one state machine, and there are a lot of independent threads going on in an autonomic node. [Michael R.]: we haven't resolved adequately for the "moving from one network to another" case. The problem is what is the "factory reset". In some cases, you want to reset, but remain the identity; in some cases you don't remain the identity. [Sheng]: chair hat on, how much work still needed for BRSKI? There are so many open issues in the slides. [Michael R.]: I think they're all done. (according to recent discussion). [Toerless]: More information for failures is helpful. [Michael R.]: I think you're suggesting that the BRSKI document deal with the kinds of failures that we anticipate. And indicate whether the failures are fatal. [Toerless]: domain had been discussed over years... [Alex]: add another item on the question list: an orchestrator check whether all these are right. [Michael B.]: whether we consider the ACP as an ASA. [Laurent]: don't confuse ASA and ACP. ********************************************************************************** 2. Information Distribution over GRASP (draft-liu-anima-grasp-distribution) - by Bing Liu [M.B.]: I hope we still agree, this (selective flooding) is not for the distribution of intent. [Bing]: This mechanism is general, not necessarily mean Intent. But maybe some intent could also benefit from this. But I don't argue Intent must do this. If the Intent has some requirements of this, it can utilize it. ********************************************************************************** 3. Anima Intent(draft-du-anima-an-intent) - by Zongpeng Du [Michael B.]: "ANI Intent" and "ASA Intent", address the comment? [Zongpeng]: Yes. [Sheng]: 1. we do need abstract information to be distributed over the network; we also need parameters to be distributed. Whether they called Intent, I don't care. 2. SUPA, any progress in SUPA that they develop some general intent for re-use? [Zongpeng]: they are doing some module of impretive intent; for declaritive intent, it is still working on, I'm not sure it's in the charter. [Sheng]: I definitly think we need that, maybe in the next charter we can consider it in Anima. [Laurent]: we (Peloso) made the proposal of ASA life circle, in which there was a manifest, and we proposed formats. [Terry Manderson]: (Responsible AD). Intent, for future discussion. [Alex]: Intent inherited some big problems of policy system. Without solving some of them, it would be very difficult to move forward. E.g., for large number of Intents, hard to maintain the consistance. [Toerless]: ...? [Laurent]: we could to do that, but I don't think it is extremely useful. Intent format and distribution is not the main problem. At last we'll agree how Intent will avoid CLI. [Sheng]: I believe it's too early to discuss the format. ********************************************************************************** 4. Guidelines for Autonomic Service Agents (draft-carpenter-anima-asa-guidelines)- by Sheng Jiang [Brian]: need experts to contribute on the draft. ********************************************************************************** 5. Autonomic Slicing(draft-galis-anima-autonomic-slice-networking) - by Alex Galis [Joel]: one of the challenges with the network slicing is deciding which pieces of the network are participating or supporting the slice. I can't figure out the autonomic devices could decide which pieces participating which slice. [Alex]: in research area, there is some initial experience and prototype to do that. Part of your question is, when you make slice, would you assign resources to it and how you monitor them. [Toerless]: this is the second stage, we're mostly on autonomic devices, for autonomic software...I don't even know single instance autonomicity, slicing is multiple instances. Meeting adjourned. See you in Chicago.