Skip to main content

Minutes IETF97: anima
minutes-97-anima-00

Meeting Minutes Autonomic Networking Integrated Model and Approach (anima) WG
Date and time 2016-11-18 00:30
Title Minutes IETF97: anima
State Active
Other versions plain text
Last updated 2016-12-13

minutes-97-anima-00
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.