Minutes interim-2019-nmrg-03: Thu 16:00
minutes-interim-2019-nmrg-03-201904251600-00

NMRG Virtual Meeting April 2019
Thursday 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 behalf of the I-D co-authors, slides prepared by Alex Clemm) .
  Status, discussion, next steps, work plan update
~xx min. – Other items/TBD
~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 performance aspects: specified or left to the orchestrator? Is
there a use case on low latency application and how to decide the decision
point to orchestrate?

A-Walter: important question. currently not specific 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 introducing 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 transferred 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 different perspectives?

Q-Laurent: different levels of abstractions: e.g. NF-topological abstraction,
ONOS intent... Q-Laurent (?) WC: We should try to map the subjective 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 knowledge, 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: importance 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 different 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 an arbitrary group, different segments of a networks.
Intents can be under of responsibility of different domains. Marinos: Intents
should 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 occasions
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 future RG
IETF hackathon participation. Laurent: Discussion on how to present the future
actions of the RG (wiki?), social media...