Minutes IETF98: anima
minutes-98-anima-02

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.