[nmrg] NMRG Virtual Meeting April 2019 - Minutes

["Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Dear all,

Please find below and at: https://etherpad.tools.ietf.org/p/nmrg-virtual-20190425
the minutes of our virtual meeting held on April 25th, 2019.

Link to the slides presented is available in the logistics section of the minutes.

Summary of main inputs and actions:


  1.  Discuss further the next steps for the work from Walter et al. on Intent-based Abstractions for Network Service Specification.
  2.  Use work from Marinos et al. on Towards a reference architecture for intent based networks as basis for IBN reference architectural model document of the RG (as a white paper and/or an I-D).
  3.  Call for reviews on I-Ds:
     *   draft-li-nmrg- intent-classification-00 https://datatracker.ietf.org/doc/draft-li-nmrg-intent-classification/
     *   draft-clemm-nmrg-dist-intent-01 (-02 to be published soon) https://datatracker.ietf.org/doc/draft-clemm-nmrg-dist-intent/
  4.  Start documenting use cases / applications of IBN


We will soon sent a doodle poll for the next meeting in May.

Thanks to all the participants, to Jéferson for helping with the minutes, and looking forward to the next virtual/physical meetings.

Best regards, Laurent.

---
NMRG Virtual Interim Meeting April 2019: 25-04-2019 4pm-6pm CEST

Participants (11):

  *    Laurent Ciavaglia (Nokia), Marinos Charalambides (UCL), Walter Cerroni (UoB), Amina Boubendir (Orange), Arthur Selle Jacobs (UFRGS), Egemen Cetinkaya, Jeferson Nobre (UFRGS), Jérôme François (INRIA), Will Liu (Huawei), Julien Maisonneuve (Nokia), Helen Chen (Jabil?)


Logistics:

  *   Webex: https://ietf.webex.com/ietf/j.php?MTID=m86803140620ac03a9e799f0954a77c5e

  *   Etherpad: https://etherpad.tools.ietf.org/p/nmrg-virtual-201900425

  *   Agenda and slides: https://datatracker.ietf.org/meeting/interim-2019-nmrg-03/session/nmrg


Agenda:

  *   ~05 min. - Introduction

  *   ~45 min. - Status progress on Intent Based Networking topic
·         Intent-based Abstractions for Network Service Specification, Walter Cerroni
·         Towards a reference architecture for intent based networks, Marinos Charalambides
·         Clarifying the Concepts of Intent and Policy, Laurent Ciavaglia (on behlaf of the I-D co-authors, slides prepared by Alex Clemm)
·         Status, discussion, next steps, work plan update

  *   ~10 min. - Status of the WG, next meetings, etc.


Meeting notes:
---
Introduction, Laurent

---
Intent-based Abstractions for Network Service Specification, Walter Cerroni
Q-WC: Can this approach can be considered as what and not how?

Q-Egemen: for peformance aspects: specified or left to the orchestrator? Is there an use case on low latency application and how to decide the decision point to orchestrate?

A-Walter: important question. currently not specificy performance. In the IoT testbed, try to define QoS. Want to avoid going to the level of details of vendor-specific parameters. Considering adding to the specs. Function of the VIM to do the mapping.At the level of the Orchestrator: e2e view, should be able to specify quality levels for different domains.
We been doing some extensions in order to try introduce policies (?), we want to instantiate a service considering threshold for latency, for example. It should not be tech specific in order to achieve that.
The service request by the orchestrator.
If e2e should be 10ms, intermediate domain should not introduce,for example, 5ms.

Q-Marinos: delay constraint. to answer your question: more on the side of the goal than how to achieve it.
See some functions missing, such as how to express constraint in the intent expression.
On the mapping from JSON to domain specific, is the mapping 1-1, is it scalable?
A-Walter: incremental approach. e.g. chain optimizer to select the best domain based on performance wrt. the request.
Marinos: constraints from the intent could be transfered to the e.g. chain optimizer.
Marinos: Some constraint from intent can be available choices in order to verify if the intent can be satisfied.

Q-Laurent: current approach: examples, templates (e.g. similar to slice templates), descriptors, bottom-up approach? Operators service deployment flow?
Q-Laurent: is there templates or something that can be reused?

Q-Laurent: where these NF-topological abstractions fit in the overall "model"? descriptor of the (V/P)NFs and how decided by mapping/embedding function at deployment/run-time?
Laurent: There was several levels of abstractions, topological vs intent, there will be a need for continuum in order to reconcile such levels. How to glue such abstractions? Using declarative approach?  How to perform the mapping considering the differents perspectives?

Q-Laurent: different levels of abstractions: e.g. NF-topological abstraction, ONOS intent...
Q-Laurent (?)
WC: We should try to map the subective point of experience, high level from the user, considering the parameters that should be allowed to provide the level of experience.

Q-Laurent (?) about next steps about this work towards the RG
WC: It is necessary a way to understand the things that can be applied to this approach, in different levels of specification. How to understand the vision to specify in the frameworks currently defined? Another perspective: it is necessary a way to standardize service specification, there is no standard for that.


---
Towards a reference architecture for intent based networks, Marinos Charalambides
Note: share knowlege, common understanding. present past activity/work from ANIMA (intent questions). from IM17-Keynote

For the "reference IBN model": document the challenges and gaps, why/benefits - overall and for the different
functions.

Q-Egemen: differentiate between intent and policy. 2nd Q: conflicts.
A-Marinos: IBN == infrastructure programmability. perfect coder, same with intents: inconsistencies, multiple admins. unavoidable that conflict will come. how to identify conflicts is application domain specific, resolution also domain specific solutions proposed.
Programmable way to configure a network should look for inconsistency. Multiple admin can be able to specify intents. It is unavoidable that conflicts come about, as in policy based management. How to solve such conflicts is application specific. Some methods are priorities, algorithms to reconfigure constraints, etc.

Q-Egemen: ex. of foo-units. if customers ask for more units than the system can provide.
A-Marinos: imortance of feedback, counter-offer. under current conditions, can offer this or this. or prioritize based on revenue/other metrics

Q-Laurent: descriptors: ontologies? functional and operational attributes
Important to consider, work with Walter. Need to cover this challenge.

Q-Walter: multi-operator/domain. business model
A-Marinos:

Q-Laurent: knowledge base? not fully understood the use. "recipes"?
A-Marinos: can have differnt functions to realize parts of an intent, how do you choose?
Q-Laurent: "big" orchestrator function/layer: to be further decomposed?

Q-(?) How do you see the composition logic in the case that is distributed over different domains?


Q-Laurent: You prefer the approach of a logic centralized for the composition?
A-Marinos: The initiation domain should be in charge of this.
Laurent: Domains can be a arbitrary group, different segments of a networks. Intents can be under of responsability of different domains.
Marinos: Intents shoud be exchanged, but it depends on how to break down the intent.

Q-Laurent: You mention knowledge based not sure on how this could be applied.
A-Marinos: This knowledge can be how the intent was used in previous ocasions and how it performed. It could contribute for a more informed form of composition.

Q-Laurent: ?
A- Marinos: Anything below the orchestrator belong to the intent.

Q-Laurent: Next steps?
A-Marinos:  It would be good to have a reference architecture as a RG doc. This could a draft or a white paper.


Status on I-D Clarifying the Concepts of Intent and Policy, Presentation by Laurent

Q-Marinos: What sort of the inputs expected in the terminology?
A-Laurent: Approaches, new areas and necessary concepts. Using a common way to express. Definition are a broader way. Terminology as a working document of the RG.
In general, there is a need to define the important and underlying concepts of IBN, and define precisely the terms.
The terminology itself can be quite small and simple. Concepts definition may require more time, more complex.
Not put as pre-condition to have the terminology complete and definitive to start other works on IBN in the RG.

Q-Julien: Use case document?
A-Laurent: To be discussed in the next meetings. Planned for instance as topic in the agenda for the interim meeting in June.
Usefulness in finding commonalities in the use cases for the applications of IBN  concepts, techniques, generalization. Try to avoid smallest common denominator in the use cases approaches (pitfall).
Also lessons learned, feedback from experience/operation based on use cases.
A-Marinos: Show case of the concepts to be shown on such a system quite useful.

Status, discussion, next steps, work plan update, presented by Laurent
Next meetings list.
Update to the IBN work plan. Good inputs received today, need also comments and reviews on documents, and on the mailing list.

Walter presented current discussion on organization of a f2f interim meeting tentatively in Bologna, in October.
Bologna because team of walter active in this field.
Want to position the meeting as "hands-on" and warm-up to futur RG IETF hackathon participation.
Laurent: Discussion on how to present the future actions of the RG (wiki?), social media...


























*** end of meeting ***