ANIMA WG Agenda for IETF-106, Singapore Autonomic Networking Integrated Model and Approach Chairs: Toerless Eckert & Sheng Jiang Minutes by: Artur Hecker (Session I), Michael Richardson (Session II) 17:10-18:40 Tuesday Afternoon Session III, Sophia 15:20-16:50 Wednesday Afternoon session II, Hullet ************************************************************************* *****************************Session II********************************** ************************************************************************* Tuesday (November 19th, 2019) 1.5-hour session: 17:10-18:40 Tuesday Afternoon Session III, Sophia ************************************************************************* 1. WG Dash - 5 min 17:10 - 17:15, by co-chairs Chair (Sheng): WG documents state - several key documents still have DISCUSS notes from the IESG, need to finish this to advance the WG ************************************************************************* 2. WG Document Update (25 min) 2a. Autonomic Control Plane - 15min 17:15 - 17:30, by Toerless Eckert, draft-ietf-anima-autonomic-control-plane No questions 2b. GRASP API - 10min 17:30 ¨C 17:40, by Brian Carpenter, draft-ietf-anima-grasp-api No questions ************************************************************************* 3. New Chartering Unscrambling- 10 min 17:40 - 17:50, by co-chairs Ignas/ IESG: the dates are not a problem, just decide what dates you want to have and it can be done Ignas: milestones are at the discretion of the WG Discussions about more documents (non expired docs, etc) MIchael: I suspect there will be no significant changes to the protocol on the wire. No risk in adopting new things. ************************************************************************* 4. Information Distribution in Autonomic Networking - 10 min 17:50 - 18:00, by Artur Hecker, draft-liu-anima-grasp-distribution Laurent: do you mean to limit all info distribution to an event? Artur: no, we only use event notifications for non-instant data distribution, i.e. for PubSub. Laurent: do you mean that it must be done the way you did with GRASP? Artur: well, we suggest a solution based on GRASP because it has some advantages, but it would be good to review and adjust the implementation. Brian: GRASP is indeed quite good at some things, we should use it this way. Ignas (IESG): it's hard to understand why you mix informational GRASP API and other things in this document (also raises a general question for the GRASP API doc presented before). Artur: can only answer for our part - we do specify the "on the wire protocol" extensions to be able to implement a required ANI functionality. Sheng: probably should move the API part to an appendix or take it out completely. Toerless: need to clarify the standard (common) and non-standard ways how to do info distribution. Artur: yes, we actually used GRASP to have a common denominator integrated in ANI per default. Other ways are possible as way, they can even use GRASP to communicate. Artur: authors generally do not claim that this document is ready, but we certainly need this document to become WG document, such that we can get more community comments. Chair: who read the document / who agrees to adopt it as WG doc / who disagrees to adopt it as WG doc? Around 10 hands / similar number to previous question / none Chair: In principle, the WG reach rough consensus to adopt this draft. The chairs will confirm this through adoption call to the list. ************************************************************************* 5. ASA environment & Anima ecosystem - 20 min 18:00 ¨C 18:20, by Brian Carpenter, draft-carpenter-anima-asa-guidelines Michael: we need to ask ourselves "elevator pitch" questions like "What is this ANIMA all about?" Michael (permissionless IPv6 network?) David Dai: two questions 1. can you give some examples for application scenarios? 2. what's the relationship between the AI. Brian: 1. one example scenario is already mentioned, it's the address assignment. 2. AI/ML: still a research topic, not clear how we will do it. It should be there though. Sheng: when we rechartered, we left AI out of scope on purpose. The point is that the ASA AF functionality i.e. the logic, e.g. AI logic, will be independent of the protocols on the wire. Laurent: library of AFs / ASAs / etc. - need to address usage scenarios Laurent: we could see a parallel between an ASA and a network function Toerless: there is a difference from VNF which is a virtual representation of a hardware thing (== no changes in protocols and APIs) to the decomposition approach taken in ANIMA Ignas: happy about the discussion in general. It looks like we look for a problem for an existing solution. We probably need to reach out to the user community and ask them what problems they have. Without having a clear problem space, we are going more into the IRTF view, but this is IETF. Michael: the answer to Ignas' comment is a tangible demo. This should be the next step. We need to get those guys "excited". Ignas: you have your milestones since rechartering. You need to follow and achieve the milestones. Toerless: time is up, we need to concentrate on the draft. Call for adoption will be issued to the list. ************************************************************************* 6. Layer 2 Autonomic Control Planes - 10 min 18:20 - 18:30, by Brian Carpenter, draft-carpenter-anima-l2acp-scenarios Mark Smith: potentially 5000 node subnets in future VLANs Remy Liu: in your mind, what's the limit? Brian: hard to say, but we see at many IETF meetings... Remy: Is the requirement for IPv6 support only Linklocal? Brian: yes, link local Remy: is IP here mandatory or optional? Brian: in principle we could do it directly over L2, yes, but we would not have the APIs. Remy: but normally you mean L2/IPv6/GRASP? Brian: yes. Toerless: if we continue this work, we need to understand that ANIMA already supports management of L2 networks. This should be precised; it's a special case. Ignas: there is a WG working on topology bootstrapping (LSVR) ************************************************************************* 7. Introduce of ETSI ZSM on closed loops - 10 min 18:30 - 18:40, By Laurent Ciavaglia No questions. ************************************************************************* *****************************Session II********************************** ************************************************************************* Wednesday (November 20th, 2019) 1.5-hour session: 15:20-16:50 Tuesday Afternoon session II, Hullet ************************************************************************* 1. WG Dash - 5 min 15:20 - 15:25, by co-chairs MCR says that there is little to say about constrained-voucher. ************************************************************************* 2. WG Document Update (20 min) 2a. Bootstrapping Remote Secure Key Infrastructures (BRSKI) - 10min 15:25 - 15:35, by Michael Richardson, draft-ietf-anima-bootstrapping-keyinfra 2b. Constrained Voucher Artifacts for Bootstrapping Protocols - 10 min 15:35 - 15:45, by Michael Richardson, draft-ietf-anima-constrained-voucher MCR update on document. Sheng asks that no new documents be adopted without finishing current documents. ************************************************************************* 5. (changed order) ACME Integrations with BRSKI - 15 min 16:15 - 16:30, by Owen Friel, draft-friel-acme-integrations Unclear where this document should live. TE: has this document gone to EMU, etc. yet? OF: TEAP requires some tweaks, and this was discussed in EMU. XiaLing(XL): this is about using a public CA? If this is a private CA, do we need the same adjustments? OF: what we see is that most customers with private CA run MSCA, and so you need their custom APIs/SDK. THere are some on-premise CAs that also support ACME, and then you could just use that interface. OF: this document will go to ACME on Friday? TE: is this document ready for adoption in whichever place makes sense? OF: I think we need to figure out where the document goes first, and then get the right views? MCR suggests that this belongs in ACME due to the need to get WGLC review from ACME. ************************************************************************* 3. BRSKI Cloud Registrar - 15 mins 15:45 - 16:00, by Owen Friel / Michael Richardson, draft-friel-anima-brski-cloud TE: what is the difference between a default Cloud Registrar, and a Cloud Registrar? OF: the default is one that is baked into the firmware. XL: how do I understand what the home domain? OF: you plug in a device at your home, and you want the device to register to your head-quarters. Is it possible to have more than one home domain? That's a general BRSKI question? Like if you have different Enclaves? MCR: Yes, that would just be two systems. OF: There are three options on the table, which option should we support? (If we support none, then BRSKI is wrong) TE: They seem to be co-located with MASA? OF: the cloud CA does not have to be with the MASA? MCR: there are three choices, and we probably only need two of them. OF: one issue will be whether the local operator wants to run a CA? ************************************************************************* Interjected: ACP DISCUSS on rfc822Name. Ben presents a mapping of the rfc822Name -> X509 extensions. MCR: this is about getting all this crap in through current CA APIs/processes ************************************************************************* 4. BRSKI-AE Updates - 15 min 16:00 - 16:15, by Steffen Fries, draft-fries-brski-async-enroll started at 16:40pm. No questions. ************************************************************************* 6. Delegated Voucher - 15 min 16:30 - 16:45, by Michael Richardson No questions. ************************************************************************* 7. Summary & ANIMA future activities - 5 min 16:45 - 16:50, by co-chairs