Autonomic Networking Integrated Model and Approach Chairs: Toerless Eckert & Sheng Jiang IETF102, Montreal, Canada Wednesday (July 18th, 2018) 2.5-hour session: 9:30-12:00, Van Horne, Morning session I ******************************************************************************* 1. WG Dash - by co-chairs ******************************************************************************* 2. WG Document Update (30min) ******************************************************************************* 2a. GRASP Application Program Interface (API) - 10min 9:35 - 9:40, by Bing Liu, draft-ietf-anima-grasp-api No comments. ******************************************************************************* 2b. Autonomic Control Plane - 10min 9:40 - 9:50, by Toerless Eckert, draft-ietf-anima-autonomic-control-plane [Brian Carpenter] regarding domain admission controller, it needs to be clear that it's not sort of a protocol spec; it's something we don't need to describe in detail in the protocol. [Toerless] authors like me prefer to elaborate more than necessary; but maybe really as you said, just the minimum statement [Alex Galis] 1. Network functions have their own control plane, what's the relationship with ACP? 2. ACP allows external operators or a management system to practically configure it, then where are the primitives or the APIs to allow this to happen, and is it a control plane or it's a management plane issue? 3. reachness of network function is not well exploded [Toerless] ANI is for any communication fabric that we need for autonomic agents or for centralized management; it does nothing more than IPv6 reachability btween autonomic agents, service discovery through GRASP and security through certificates, and it's equally to anything centralized in the NOC. ******************************************************************************* 2c. Bootstrapping Remote Secure Key Infrastructures (BRSKI) - 5min 9:50 - 9:55, by Toerless Eckert, draft-ietf-anima-bootstrapping-keyinfra No comments. ******************************************************************************* 2d. Constrained Voucher Artifacts for Bootstrapping Protocols -10 min 9:55 - 10:05, by Peter van der Stok, draft-ietf-anima-constrained-voucher [Toerless] Are there any real relevant functional differences between all these versions? (BRSKI, EST-COAPS, Constrained Voucher, Constrained Join-proxy) [Peter] In principle it's all the same BRSKI(Pledge-Proxy-Registrar-CA-Vouchers in MASA); the only difference is we want to reduce the payload, instead of HTTP we want to use CoAP, and then COSE is there. [Eliot Lear] There is a public key also transmitted as part of the voucher, can you comment on that£¿That might be a difference between the base BRSKI. [Peter] In 6tisch environment, we use certificates, but also possibility to use public keys exchange for the protection. [Brian] The Constraint Join Proxy would not itself be constrained? I assume the Constraint Join Proxy would join the registrar in the same way as the normal proxies. [Peter] Yes. [Brian] How does the pledge discover the Constraint Join Proxy? [Peter] We're still working on that. [Brian] I'd like to know if it's going to use GRASP. [Peter] One concern is to make this Constraint Proxy also stateless. [Brian] We could always talk about a mini version of GRASP for that specific case. [Peter] Always open to know good ideas. ******************************************************************************* 3. Autoconfiguration of NOC services in ACP networks via GRASP 10:05 ¨C 10:15, by Toerless Eckert, draft-eckert-anima-noc-autoconfig & draft-eckert-anima-grasp-dnssd ¨C 10min [Peter] For DNS-SD, do you want to export evertything that is known in GRASP to the DNS later on? [Toerless] At this point in time, it's basically an island, so we've been thinking about keeping very separated. [Laurent Ciavaglia] You propose to have a set of base NOC services to be autonomically discovered, and we connect it with the ANI and underlying infra, is it on purpose that you limit it to this kind of NOC terminology, or we can think about all the services, I'm just thinking about for instance you want to subscribe or to discover some measurement or telemetry services. [Toerless] Here a minimal set that I would love every node that supports the ACP to actually implement it. ******************************************************************************* 4. Bootstrapping Key Infrastructure over EAP & BRSKI over IEEE 802.11 - 15min 10:15 - 10:30, Owen Friel, draft-lear-eap-teap-brski & draft-friel-brski-over-802dot11 [Brian] A lot focus here to proof of ownership in a sense of proving you're joining the network that you're happy to join; the opposite question, whether the network is happy for you to joint it, it should be in your proof of ownership list of things to be solved. [Toerless] In BRSKI, you can only join the network that owns the access. [Owen] The MASA has strong identity knowledge and knows which network operator owns which device and that will be very challenging to build. [Eliot] For Brian's question, what knowledge does the device have out of the box does it know the knowledge of the deployment, the whole point of BRSKI is that it doesn't, it doesn't really know who to join. The additional info either from the manufacture indicating an authorization or from the deployment. ******************************************************************************* 5. Autonomic functions lifecycle management & coordination between autonomic functions & knowledge exchange draft-peloso-anima-autonomic-function, draft-ciavaglia-anima-coordination draft-ciavaglia-anima-coordination, draft-ciavaglia-anima-knowledge - 25min 10:30 - 10:55, by Laurent Ciavaglia [Alex] If lifecycle work is progressing and maturing, it might lead to a slightly different infrastructure which already developed in Anima to be changed. [Laurent] I agree with your comment, but we need to discuss what is the scope of what we want to do, what will be implication for Anima, and then start to work on specifying a bit more on the content, the format etc. [Bing Liu] In general I believe this work(lifecycle) is necessary, because this work could be considered as a kind of meta-ASA, which can intiate ASAs before any ASA could work, otherwise we'll need to fall back to mannual operations. I'd like to see it be progressed, come up with more specific protocol extensions or some node behavior requirements into details. [Sheng] The methodology is resonable to be included in the ASA Guidance draft; but you need go beyond that and maybe lead some new works here with a new draft. [Laurent] There is surely a link with the ASA Guidelines draft. And there should be some standard track aspect in a seperate draft. [Sheng] (Coordination work)So far not convinced, given how complicated to abstract a common command set. I'd really like you take the design of this work into another level, with more detailed designs. [Laurent] We've done some POC(uniself project). It will not come with a univeral solution, but specific solutions to be deployed. [Alex] The work would be added value for orchestrators. ******************************************************************************* 6. The ANIMA domain boundary - 20min 10:55 - 11:15, by Brian Carpenter, draft-carpenter-limited-domains [Toerless] I think what definitely would be very helpful is you know a more complete taxonomy (of different constrains, other than IoT) and also recommendations on how to deal with them. Not sure what the best WG to do it. [Brian] We've got some positive feedback in Intarea, people are intrested in it. But I'm scared of it becoming a topic that's too general. I'd like to see if there is serious focused interest in actually solving it. [Bing] Reading the title "Limited Domains", there are at least two aspects: 1. regarding to human operation, we need to limit the domain for scalability or for security considerations; 2. if we limit some mechanism in a certain domain it implies we can allow heterogeneous mechanisms to run differently each domain. Maybe we need to distinguish different aspects. [Brian] Yeah, but maybe part of the analysis we still have to do here. [Alex] I like the direction. Technology Domains vs. Administrative Domains. Multi-domain orchestration is now the norm in terms of research and development. This could be the source for additional protocols. Another dimension domain is changing. [Brian] Domain boundary and membership will be time varying concepts. [Roland] Do you consider mainly limited domains with respect to connectivity or is it much broader in the sense that you could also use logical associations defining domains on top of a common connectivity substrate. [Brian] Given teh internet is developing, we can assume everything can be virtual. the domains could interpenetrate each other due to virtualization. I think the answer is your yes anything. [Roland] It's quite a broard thing, it's important. But since it's context related it's quite hard to come up with some general recommendations. [Doug] Are you trying to standardize the conceptual notion of a limited domain or you're a list of examples of different kinds of technologies some of these domains can be distributed. [Brian] It could be. I'd like to reduce your question to "is this node within this domain", "is this node an edge of the domain". I know how to turn it into a concrete question to ACP, that's not hard; but if you want to be a more general concept, then it becomes more difficult. ******************************************************************************* 7. Information Distribution in Autonomic Networking - 10min 11:10 - 10:20, by Bing Liu, draft-liu-anima-grasp-distribution [Brian] The proposed GRASP extensions with respect to my prototype GRASP implementation and thought I couldn't really see any fundamental difficulty. The only observation I made is the Un-solicited Sync only works if the ASA at the other end is implemented to listen for the push, it's an extra feature. [???](from Oracle) The extensions look useful, but going for your use case, are you suggesting (3GPP) CT4 consider this is a replacement for what they've specified for SBA? [Bing] The scenarios in the draft not necessarily mean we'll go to 3GPP to let them use it; the bottom line is to give some real example of what kind of scenario might use the advanced features other than the basic GRASP. But the co-author hope the 3GPP can consider existing tools rather than specifying other dedicated protocols. [???] They haven't specified new dedicated protocols, they're using HTTP with JSON. [Laurent] Do you also consider specifying the information semantic? [Bing] For this draft, it is out of scope for semantic part. Maybe it's more proper to discuss semantics in your Knowledge Exchange draft; and also I'd suggest maybe part of the Knowledge Exchange work could be merged to Information Distribution. [Laurent] Telemetry, new monitoring protocols are also about collecting information and exchanging information, do you see any relationship between what is here a bit more specific for Anima. [Bing] As far as I understand, Telemetry is specific to centralized server using Netconf/YANG to collect data; but Information Distribution is more about devices interact with each other. ******************************************************************************* 8. Guidelines for Autonomic Service Agents, Transferring Bulk Data over GRASP - 10min 11:25 - 11:35, by Brian Carpenter, draft-carpenter-anima-asa-guidelines & draft-carpenter-anima-grasp-bulk No comments. ******************************************************************************* 9. Trust networking and procedures for Autonomic Networking - 10min 11:35 - 11:45, by Tae Sang Choi, draft-choi-anima-trust-networking/ [Sheng] Your design target is what we already achieved in Anima; we already have the trust system, the bundary and the way to discover etc. The only thing missing from current Anima to what you described here is only in the data communication policy in data plane to stop the node talk to other nodes out of the network boundary. So I'm getting lost what do you want to standardize here;what the extra goal you want to achieve here. [TaeSang] Beyond BRSKI, considering the communication between the entities. [Toerless] I think you've done some prototype and demostration, so if we have some idea of the practical thing, it would be easier to map it to the Anima case. [TaeSang] We do have POC. The gateway have 3 things: trust management, domain management and IP allocation management. [Toerless] I read the draft, still difficult for me to translate. [Brian] 1. I found your slides are easier to understand than your draft. The draft is unclear about the relationship with ACP and BRSKI. 2. I think what Toerless is asking is I don't understand how your domain gateway can actually authenticate and check addresses, how does it protect itself against spoofed IP addresses, and how does it do this at line speed. You don't need to answer now, but the next version will be very helpful if this is explained much better. [Chong?](TaeSang's colleague from ETRI) We have app-layer use case, IPTV classify to different media, and sharing economy, e.g. sharing car customer is trust fair enough. [Sheng] Is your purpose here to make deployment use case that using Anima components to serve your app level ASA, or you try to define some new Anima components to serve your purpose? [TaeSang] More of the latter. [Sheng] I'm fine with the first one; but for the latter one, I still don't get the point what do you want to do. [TaeSang] It's app layer ASAs, not new to the infrastructure. ******************************************************************************* 10. Summary & ANIMA future activities - 5 min 11:45 - 11:50, by co-chairs WG will be re-chartered before/around IETF103.