ANIMA IETF-98, Chicago, USA Chairs: Toerless Eckert & Sheng Jiang Note taker: Bing Liu, Anil Mehta Anima Session I, Monday (March 27th, 2017) 13:00-15:00, Zurich A ********************************************************************************** 1. WG Bash, by co-chairs [Sheng]: GRASP has already passed WGLC, now in the process for publication. The WG is planning to submit 5 WG documents to IESG before IETF99, then recharter. GRASP Hackathon: (Brian) Python implementation tested on 4 or 5 machines. No need to change the Python code. BRSKI Hackathon: (Max) Focused on the voucher format parsing and signing signatures. [Sheng]: we probably will have another Hackthon in Prague. ********************************************************************************** 2. ANIMA Generic Signaling (Design team) - by Brian Carpenter, draft-ietf-anima-grasp [Dean Bogdavic]: for open issue 63 (Should encryption running without ACP be MUST instead of SHOULD in Section 3.5.1 and Section 3.5.2.1), prefer SHOULD than MUST, for debugging in the open network. [Ran Atkinson]: There is a difference between "MUST use" and "MUST implement". IETF usually makes security "MUST implement", but we don't tell people what they have to use. [Michael Richardson]: Agree with Ran, I don't have a problem of debugging. [Brian]: for CDDL, normative reference, but not an RFC yet. [M.R.]: I heard in CBOR WG, CDDL draft is top priority [Terry]: it's hurt to wait for CDDL becoming normative [Sheng]: if we cannot get the CDDL draft by the time Auth48, is it allowed to add large amount of text? [Terry]: if substantial content is needed, we can do WG consensus again during GRASP Auth48. We can call consensus on a small block of text, it should easy to do. ********************************************************************************** 3. ANIMA Voucher Profile - by Max Pritikin & Kent Watson, draft-ietf-anima-voucher [Peter Van Der Stok]: you are aware of a YANG to CBOR draft? I prefer CBOR, which is tighter. [Kent]: we haven't discussed it, but we wanted JSON for future JWS support. [Sheng]: send an email to Anima WG list for the determination, which were all discussed in BRSKI DT mailing list. [M.R.]: voucher revocation issue [Max]: we can also issue a permanent voucher [Toerless]: what's the best way for security expert review, ask Nancy? [Peter]: prefer PKCS#7, because it is also used in the EST [Sheng]: take the open issues in the mailing list Co-authors believe Voucher draft could be WGLC soon; but BRSKI needs a few weeks for WGLC. ********************************************************************************** 4. Autonomic Control Plane - by Toerless Eckert, draft-ietf-anima-autonomic-control-plane [M.R.]: Is your question that ACP should support CRL, OCSP? [Toerless]: On highest level, I'm wondering if we can allow free choice of CRL or OCSP as well as keeping a consistent security model in ACP. [M.R.]: I don't think either TLS or IPSec as core base protocols make opinions about how to do those things. [M.R.]: I strongly recommend to use CRL. [Peter]: why not write an applicability draft for Anima in ROLL WG, that would be fantastic. The draft describes how to use RPL parameters, security, kind of profile. [Sheng]: ACP has a minimal version of RPL, no parameters? [Toerless]: No, we just pre-specify the parameters. [M.R.]: ROLL WG has a template for RPL. Peter's comment is making an ACP template for RPL as a separated draft. [Sheng]: OSPF-autoconf and ISIS-autoconf also could be candidates of RPL in ACP. [M.R.]: they are default for Ethernet, in RPL, no default [Toerless]: e.g. DC, path optimization Co-authors will try to make it ready for WGLC at the end of April. ********************************************************************************** 5. AN Reference Model - by Michael Behringer (remote), draft-ietf-anima-reference-model [Sheng]: We need reviewers for this draft. Max Pritikin agreed to review this draft. Sheng will work out another reviewer afterwards. It needs reviewers reviewing the draft before WGLC. ********************************************************************************** 6. Prefix Management in Large-scale Network - by Brian Carpenter, draft-ietf-anima-prefix-management [Brian]: For prefix management intent content, using JSON or YANG model? [Bing Liu]: I prefer JSON, it is naturally compatible with CBOR. For YANG, I cannot figure out a reason why we use YANG here. It seems not necessary without Netconf kind of operations. Anima Session II, Friday (March 31st, 2017) 9:00-11:30, Zurich A ********************************************************************************** 1. AN Reference Model (Potential Extension for Next Stage) - by Laurent Ciavaglia [Sheng]: says we are close to finishing phase 1, 5 out of 6 documents are ready to be submitted to IETF for publications, we can use more reviews from the participants. [Michael Behringer]: Agrees on the guidance on ASAs, but will like to see real cases and not made up use-cases, especially for Phase 2. We couldn't successes without real use cases. [Sheng]: Believes we have a few real use-cases already. For our current charter, we did not work on these use-cases. We may work on these use-cases under next charter. [Michael B.]: Standardization of ASAs can come later, but interfaces should be defined with real operational considerations. [Sheng]: needs clarification on the interfaces. [Michael B.]: data model is one, conflict resolution can benefit from a real-live use case. [Laurent]: clarification on what Michael is saying is we need to know the parameters in order to specify the standard. One example is 3GPP. If we want to enable ASA we will have to define data models for example. [Sheng]: Not sure about the specifications and want an specific charter and not open charter like specifying too many data models. [Laurent]: we are not going to exhaustively define data models. For example, in ANIMA ASA registering nodes for ASA is a use-case data model. [Toerless]: One issue is that we have an "all or nothing model" for ASA. We have defined in the past what hosts need to do for example for routing protocols, so can we do that for application layer? [Sheng]: Does not believe we can define the application layer requirements. [Alex Galis]: Regarding the list of deliverables on phase 2, one aspect that is not covered is in ANIMA we are development an autonomic process of structure, but in few years ANIMA may be sandwiched with lower and higher layers, for example, an end-to-end control at application layers and there is an need to define the core dimentional interfaces for ANIMA for example the north bound interfaces. This is mainly because of the multi-technologies and multi- vendors impacting the higher layers, so a definition of the interfaces is needed. For bottom up, the infrastructure is moving to be Software defined and we are having a softnet for networking function management. Therefore, ANIMA will be north of this resource and can use the resource pool to have enhanced power for ANIMA. [Max]: what is software infra? [Alex Galis]: example of soft infrastructure is virtual networks, so management functions are relayed to this software algorithms; second example, trend to group physical resource in a container for a certain life cycle and represent them with the new reference point, slicing is an example of this concept. Third example is the network function being soft now, and a management function is applied on top of these. [Laurent]: requests some discussion on network artificial intelligence as it may be relevant to ANIMA. [Sheng]: We are not sure how the network becoming software based will impact the design of ANIMA and requests all in the working group to review the material and come with comments next meeting. ********************************************************************************** 2. Anima Intent, by Laurent Ciavaglia [Alex Clemm]: conflict detection and resolution is an important part. Is the verification or conflict resolution defined. We may need to have to define such a policy and wording accordingly, for example validation and refinement can be meaning many things. [Michael B.]: needs clarification to the question, and received it from Alex. [Jefferson]: believes IETF does not have place where INTENT is chartered. Should we define the charter with specific word? [Sheng]: generic Intent, the answer is no; Anima specific Intent, yes. [Jefferson]: "management intent" and "ANIMA intent" references are there but not defined. So we should define these terms. [Brian]: take this in the OPS area; [Terry]: well said. [Joel Jaegli]: (OPS AD speaking as an individual). We can have discussion between f2f meetings. [Alex Galis]: Discussion on defining intent is a management issue too, as we should define "minimum" levels of intents, as maintaining these artifacts will be dangerous. A pragmatic minimum level. Should not be more than few hundred by definition. They should also not interfere with each other. [Toerless]: (as an individual) If the intent policy language is a question, we may want to first concentrate on the underlying framework for identifying such language. These questions raised are addressed before in certain parts but language seems to not reflect it. [Kreeti Kompella]: I don't know Intent is, I don't know what policy is. It is too early to decide a minimum set before we define these terms. RFC7575 is an example where the language does not necessarily transfer to an operational action for the machines. So we should define the "Intent of Intent"? [Sheng]: defining "Intent of Intent" is out of scope of our meeting. Defining Intent should not impede the discussions. [Kreeti]: SUPA has similar policies that do not have actual compilable instruction for the machines and hence the effort is not useful. [Terry]: caution to not get stuck in re-defining language. ********************************************************************************** 3. GRASP API - by Brian Carpenter, draft-liu-anima-grasp-api Brian speaks about implementation models for a GRASP core and their interaction with the ASAs. GRASP needs to have a proper data structure set defined for working, which is in the working group discussion, and especially for lower languages. So for GRASP the minimal data structure set is a C based objects. Speaker discussed recent changes. Generally saying that the mapping the data structure set defined in the draft are easy for higher languages such as Ruby, python or Java but not so much C/C++ and hence there is need to have people with C/C++ programming experience in order to define a proper data structure set for the benefit of all types or programmers and languages used to realize a GRASP model. [Terry]: working group documents do not have to go to RFC. [Brian]: we really need lots of feedback on the current GRASP model description. ********************************************************************************** 4. ASA Guidlines, by Brian Carpenter, draft-carpenter-anima-asa-guidelines [Eliot Lear]: Going back to the example of a Light switch as an ASA, needs clarification on how a light controller can be an ASA. Is it the light switching on and off is the function of the ASA and if there is additional latency because of the ASA function. [Brian]: clarifies that such is not the case and no additional latency will be included due to the ASA and the manual control is with the user, ASA will have functionalities such as policies an example is dimming the lights after a certain time. [Bing]: We need another thought in the document to discuss how ASA is configured as a node? This is because if an ASA has to complete some tasks it has to configure the node. [Brian]: There is some language in there already for example "....thread to manage subsidiary non-automatic devices..." however it needs to be included in the code of the ASA. [Laurent]: The south bound interfaces should be specific. [Brian]: it is indeed tough to do so. [Sheng]: believes that a different timeline should be used, where we can post the guidelines to the RFC as there are answers we can get from the working group and publish them, and if there are changes needed we can address them in future discussions. We can move the document to completion faster. ********************************************************************************** 5. Autonomic Slice Networking - by Alex Galis and Bing Liu, draft-galis-anima-autonomic-slice-networking [Sheng]: Network Slicing could be a fundamental magnet between resource management between various network nodes. However he is not sure where the input for the slicing or management policy will come from. Further, for clarification, does this input come from a human operator or a close controlled loop? [Alex]: This is subject of engineering the system. [Joel Harper]: believes that there is no need to do any work on this topic if you just instantiate a separate ASA for each operation we get the same effect. [Alex]: does not believe in a global policy as the individual resources will be better served if they have their own policy. [Toerless]: One cannot build a working model of a network slice from the existing draft. Needs increased definition from the existing definition. One example is the slice can be handled from within the slice or outside the slice as well. [Alex]: slices is a set of a union of resources in a network and a set of network function which can be looked up in one look up at a given time. The main subject is that we have to be able to have automaticity for a given slice on its own. [Bing]: Replying to Joe Harper's comments, the slicing in modern environment is based on virtualization environment, so ANIMA needs to change in order to adjust to this need, or cease to be a relevant protocol. Managing slicing is above just signaling between network resources, it is adding and removing resources from a slice and other such "hard" commands. One example is the allocation of resources for the inter-slice orchestrator where ANIMA can use network slicing as a function. [Sheng]: The physical resource manage in your pic (within the presentation given by speakers illustrating the timing diagrams) is not for a network element but is generic, and the physical resource manager is generic too, so where is the need for network slicing in this example. [Brian]: Re-wording some question, is it true to say that we will be sending a specific query to an network slice than sending generic queries? [Bing]: yes. [Sheng]: so it is okay to say that the "physical resource manager" is responsible to allocate certain resources based on the intent from the ASA? [Bing]: yes. [Sheng]: Question is why slices would interact with each other orchestrator, they are to operate in isolation? [Alex]: slices are represented to outside environment using slice manager, and since there is a number of slices there are a number of managers. The resources need to be released when the life-cycle is complete, the "inter-slices orchestrator" is needed and will help in terms of overall operations. [Sheng]: This is relevant in one single centralized interface, where one entry point seeks outside input, however in such a centralized function there is only one ASA per slice. [Bing]: It is a whole different discussion. [Jefferson]: Is this work belonging to ANIMA? [Bing]: Possibly open to discussions. [Phillip Early]: Do not understand the "inter-slice orchestrator" is used for? As each slice will request resources from the network when the slice is generated, and that it the limit of the orchestration, what is the orchestration needed beyond that? [Alex]: excellent question! When a new slice setup request may the allocation of resources to that slice will affect other existing slices. Similarly when a slice is "switched off" those resources can be resued. Therefore slices are "elastic" so to say, and therefore an "inter-slice orchestrator" is needed. [Tim]: (nokia): explains as the internetworking between slices that can be explained as the role the "inter-slice orchestrator" may play. [Bing]: in future we may define a slice specific ASA for the policy. [Sheng]: The slice element manager function is still not clear. This is because the original work is done when the slice is formed. In certain conditions, it is understanding to have this function as when there is no centralized resource manager, however if the orchestrator is present then a slice element manager should not be needed? [Bing]: It is a case of options. [Alex]: Orchestrator's role can be thought of coordinator not manager. Therefore it can group various management functions to operate on the group as a whole. [Bing]: Should we have a mechanism for the higher tasks such as slide insertion, deletion etc. Meeting adjourned. See you in Prague.