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...