NMRG Virtual Meeting April 2020 Tuesday 14-04-2020 14:00-17:00 Paris time Chairs: Laurent Ciavaglia, laurent.ciavaglia@nokia.com ; Jérôme François, jerome.francois@inria.fr Secretaries: Jéferson Campos Nobre, jcnobre@inf.ufrgs.br ; Pedro Martinez-Julia, pedromj@gmail.com Useful links: * Agenda: https://datatracker.ietf.org/doc/agenda-interim-2020-nmrg-03-nmrg-01/ * Materials: https://datatracker.ietf.org/meeting/interim-2020-nmrg-03/session/nmrg * Webex: https://ietf.webex.com/ietf/j.php?MTID=m806e98f7f49bbfd71e4cd23ce3913aa6 * Etherpad: https://etherpad.ietf.org/p/nmrg-virtual-20200414 * Recording: https://www.youtube.com/watch?v=0T2PZ_iVwmM * Attendance: please add your name at the bottom on the Etherpad page (https://etherpad.ietf.org/p/nmrg-virtual-2020414) Agenda: ********************************************************** * 14:00 - 05 min – 1. Meeting logistics and agenda, Chairs Recording: from 00m to 07m 15s Slides (#1 to #6): https://datatracker.ietf.org/meeting/interim-2020-nmrg-03/materials/slides-interim-2020-nmrg-03-sessa-1-10-agenda-and-rg-updates No comments received on the agenda. *************************************************************************************************************************************************** * 14:05 - 15 min - 2. Intelligent Reasoning on External Events for Network Management, draft-pedro-nmrg-intelligent-reasoning, Pedro Martinez-Julia Recording: from 07m 15s to 30m 40s ; Q&A starts at 23m 40s Slides: https://datatracker.ietf.org/meeting/interim-2020-nmrg-03/materials/slides-interim-2020-nmrg-03-sessa-intelligent-reasoning-on-external-events-for-network-management Draft: https://tools.ietf.org/html/draft-pedro-nmrg-intelligent-reasoning Q&A: - Marie-José: You did not mention datasets. What are the data set you are going to use for network management and they should be problem-specific. What do you mean by general reasoning? Machine Learning is not just accumulating learning. You need to know if your data is right or not. Thus, you need annotation from experts, so you need training sets. There is a lot of good stuff, but it is incomplete, too vague. What is the problem you trying to solve? What are the next step for your draft? - Pedro: We are targeting the definition of challenges/gaps for the next stages on the application of AI to the network, mainly the "reasoning" process that is executed after the "learning" process, in order to find new rules to be applied by the learning algorithms. Go beyond ML with reasoning to dynamically adapt the model. Next step: exploit/clarify reasoning (clarify the role of ML in the reasoning part) - Pedro: more in the sense of differentiating the learning phase, the inference from Machine Learning. We want to go to reasoning. After ML finishes, we can take decisions, but how those decisions will be reasoning beyond that output? New rules and condition that a reasoning will produce after ML. Thus, the main step is to explore the reasoning, to clarify such reasoning. Not focus on specific problems, it will be fine to have collaborators. - Laurent: progress to develop a common understanding on ML/MR. May be useful to bring some of your work as inputs to the Research Challenges in AI for Network Management document (). Please remove the confidential tag on the slides, and send a revised version. ******************************************************************************************** * 14:20 - 20 min - 3. Metadata-based Aggregation of Telemetry Flows, Sonia Fernandez Tejeria Recording: from 31m 30s to 48m 40s ; Q&A starts at 44m 50s Slides: https://datatracker.ietf.org/meeting/interim-2020-nmrg-03/materials/slides-interim-2020-nmrg-03-sessa-3-metadata-based-aggregation-of-telemetry-flows Q&A: - Laurent: will the aggregator build the patterns from bottom-up, in an organic way, from the telemetry information? - Sonia: No. You can register all available sources; for example, you have 3 models of sources in your system, the application can choose what information it really needs - Laurent: Several comments in the chat showing interest in this work, so please proceed with providing more materials and documentation. This work could also be of interest to the AI for NM realm or the previous work on Machine Reasoning, for the ontology part. - Pedro: CIM model could be a good way to implement the ontology I was mentioning to in the previous presentation. Few years ago, I worked with CIM, it is quite complete for this task and we can connect these two topics in a single place, i.e. the relation between the AI application and the CIM model for information retrieval, etc. Let's talk about that in the future. Comments from the chat: - Marie-José: What is the difference between CIM and the basic ICN/CCN? - Laurent: I suppose CIM is not "name" based - Marie-José: Context <-> Name - Diego Lopez: CIM is a model for describing data sources, not data itself. It is not about locating contents, but about describing the kind of data you can receive from a particular source - Marie-José: Ok but very related - ICN/CCN also has semantics/ontologies but ok I get it - Diego Lopez: The term "context" here refers to the metadata describing the data flows. I think the people working CIM tried to draw a line between the data and their descriptions. My impression is that ICN/CCN deals with a general problem, while CIM is more focused on measurements, and the reduced scope makes it easier to apply in this environment. Make sure to distinguish the acronym ETSI "CIM" ISG vs. DMTF CIM - Common Information Model - Pedro: CIM is the modeling. Similar to an "XML Schema" but for generalized models. ICN/CCN are protocols. Totally different things. - Benoit Claise: Yes please document it. Even though I would prefer a data model instead of a information model (read UML). data models provide APIs. Anyway DM versus IM is a old debate - Diego Lopez: I know, Benoit. We will document the DM. For the moment we are in the IM phase, analyzing it... ********************************************************************************* * 14:40 - 20 min - 4. Fault Tolerance for Service Function Chains, Milad Ghaznavi Recording: from 49m 55s to 01h 09m 55s ; Q&A starts at 01h 07m 00s Slides: https://datatracker.ietf.org/meeting/interim-2020-nmrg-03/materials/slides-interim-2020-nmrg-03-sessa-fault-tolerance-for-service-function-chains-milad-ghaznavi Q&A: - Jerome: Interesting idea piggybacking of the states, that you intent to put in the NSH. What we can expect in terms of size you need here to piggyback states, for certain service? - Milad: in our system, for NAT, one packet may add info on connection state that is around 40 bytes; stateful load balancers are around the same size 40 to 60 bytes. Lots of middle-boxes / service functions, we expected that it should not go beyond a few dozens bytes. For longer chains or when you have to support more failures. For example, if you want to support 5 failures, so packets need to carry the states form 6 middle-boxes / service functions; for those cases, it could be challenging. Probable there are some limitations, maybe we cannot go beyond some number of failures or beyond some size of service function chains. Comments from the chat: - Laurent: could there be an issue for the in-chain replicas, for instance if there are security or ownership issues between the different SFs, e.g. replicas for SF1 could/shall not be shared with/to SF2... - Milad: that's an interesting question. You are right there is privacy and confidentiality concerns that motivate to approaches to provide trust between different service function or efficient encryption that preserve the confidentiality. This work will also be presented to SFC WG in the future. ********************************************************************************************************* * 15:00 - 15 min - 5. Transport Slice Intent, draft-contreras-nmrg-transport-slice-intent, Luis Contreras Recording: from 01h 11m 00s to 01h 28m 45s ; Q&A starts at 01h 23m 35s Slides: https://datatracker.ietf.org/meeting/interim-2020-nmrg-03/materials/slides-interim-2020-nmrg-03-sessa-5-transport-slice-intent-draft-contreras-nmrg-transport-slice-intent Draft: https://tools.ietf.org/html/draft-contreras-nmrg-transport-slice-intent Q&A: - Olga: in terms of the attributes for the intent at the transport slice layer, do you envisage that the attributes will be delay, jitter, etc. or would the attributes be more higher level, declarative in terms of who needs this kind of slice, e.g. eMBB or for some of the specific 3GPP service types ? - Luis: probably a combination of both of them: some things could be more or less straightforward translated to transport requirements, like throughput, bandwidth or latency, etc. There would be other attributes that are entirely impacting the transport network, for instance as availability or reliability, etc. Thus, it may be necessary for the transport network to create some protecting paths to accomplish a given availability, or if in the slide template declares the need to deploy a service in a given location, indirectly one can infer the need of having more transport capabilities in a specific (geographical) area. In other work (https://tools.ietf.org/html/draft-contreras-teas-slice-nbi, trying to digest how these attributes could impact directly or indirectly in the transport part; so there are interactions in these directions. - Olga: envisage it will be more specific requirements, not high-level requirements (give me slice for this application, and then the transport layer understands the requirements in terms of bandwidth, delay and jitter from high-level abstraction) - Luis: starting point to treat the generic NST or 3GPP NEST, attributes really impacting the transport (like throughput), so no need to infer so much on that. Other attributes could be more generic and required to be translated like reliability or availability. If need to guarantee 99.99%, then need to instantiate different paths in the in the transport part in order to guarantee such level of availability. The generic slice template, then going to higher level like eMBB or else, need something else. - Eric: clarification for the intent in the work going on right now, the transport network does not understand the actual applications that are applying for a transport slice. Thus, the intent will not include any information about exactly what the slice is used for, just what the characterizations are, the attributes to be communicated to the transport. - Luis: Yes. - Qin Wu (via chat): Not clear the difference between attributes defined in GST template and attributes defined in NBI model. - Luis M. Contreras (via chat): please, check draft-contreras-teas-slice-nbi-01 which is an attempt to identify such mapping. - Laurent: it's a new I-D, several interactions, interesting points raised. Continue on the mailing list or future meetings, and develop the work further. ****************************************************************************************************************** * 15:15 - 20 min - 6. Automated Design of Network Services from Network Service Requirements, Navid Nazarzadeoghaz Recording: from 01h 29m 45s to 01h 51m 30s ; Q&A starts at 01h 46m 30s Slides: https://datatracker.ietf.org/meeting/interim-2020-nmrg-03/materials/slides-interim-2020-nmrg-03-sessa-6-automated-design-of-network-services-from-network-service-requirements Q&A: - Qin: How VNF architecture Description is different from NSD? The end goal seems to generate NSD. - Navid: NS is a composition of VNFs ... VNF architecture descriptor is descriptor for that VNF, NSD is a descriptor for the NS that is a higher level, more composite element. VNF arch. descriptor is an extension consisting of information regarding application aspects of that VNF. VNFD from ETSI NFV are just virtualization related. structure of this VNF as virtualized element, components inside, how configured, connected together through virtual links, or external connections; they do not talk about their functionality or APIs which are related to the functionalities. - Jerome: in your approach, is there a way to have requirements that have dependencies, i.e. not all requirements needs to be fulfilled at the same time, there could be combination of requirements or some exceptions or alternative requirement? - Navid: multiple, different types of requirements are captured altogether or are these resolved in ...? - Jérôme: imagine you have some logic between requirements like "or". Usually requirements are conditions that all must be fulfilled. More complex requirements for the services they support. - Navid: the requirements we get, we match them to the ontology, therefore, we start from the higher level requirements, travels down and every time we reach one of those [blocks?] of requirements we try to match them to the ontology; because we rely on the knowledge provided from the ontology. Any requirement that is in contradiction to the ontology, e.g. there is a composition or dependency, that the complete opposite is provided in the ontology, we neglect that requirement and stick to the ontology, because we assume that it may provide us with not fully compatible requirements, when we resolve those requirements when taking knowledge from the ontology. ********************************************************************************************* * 15:35 - 25 min - 7. Intent Classification, draft-li-nmrg-intent-classification, Xueyuan Sun Recording: from 01h 52m 50s to 02h 12m 11s ; Q&A starts at 02h 06m 30s Slides: https://datatracker.ietf.org/meeting/interim-2020-nmrg-03/materials/slides-interim-2020-nmrg-03-sessa-7-intent-classification Draft: https://tools.ietf.org/html/draft-li-nmrg-intent-classification Q&A: - Jerome: as a chair, thank you for your work. On your last slide, regarding process: first, publish the latest version as an -03 individual draft; before asking for adoption, then go for short round of comments on -03 version on the mailing list (2 weeks) to see people are satisfied with how you addressed the comments/questions in the draft. After this check, then we can start the call for adoption. To be sure, before ask for adoption, before entering "official process", people are ok with how you modified the document. Do not forget first to send the revised version. - Olga: in regards to the comment to engage the comments authors, remind that we went through extensive phase of emails and PowerPoints with all the comments and asking the comments authors for the their conclusions and feedback how we want to address the comments, it took probably a month of exchanges and discussions. Ok to do it with v-03, we will repeat the process. Didn't get replied from everybody. - Jerome: in our role of co-chairs, we will also push on the mailing list to get reply on the document in short period of time (2-3 weeks). To support this work, because you made lots of concrete modifications to the document. This way is better than go directly to adoption, to give more chance to have the draft adopted by the group, avoiding misunderstandings on which version of the document we talk about. - Laurent: what we could also, as we already got a first call for adoption for this document in December 2019, is to send an email to the list to clarify what are the conclusion of today's discussion, new baseline with v-03. *************************************************************************************************************************************************** * 16:00 - 15 min - 8. Service Assurance for Intent-based Networking Architecture, draft-claise-opsawg-service-assurance-architecture, Benoit Claise Recording: from 02h 12m 45s to 02h 35m 14s ; Q&A starts at 02h 25m 30s Slides: https://datatracker.ietf.org/meeting/interim-2020-nmrg-03/materials/slides-interim-2020-nmrg-03-sessa-8-service-assurance-for-intent-based-networking-architecture Draft: https://tools.ietf.org/html/draft-claise-opsawg-service-assurance-architecture Q&A: - Luis: Do you expect the IETF to standardize the sub-service assurance? or stay on the overall model. - Benoit: yes and no. Some of them should be standardized. For example, we are all monitoring interface counters, but whatever vendor interface your have, trying to get the health of an interface should be in the standard. the value is higher in the stack. For protocols, IS-IS, or SR, what if you would be thinking directly about the assurance when developing a protocol. I could envision having a couple of sub-service assurance YANG models, interface for some protocols. We have knowledge in IETF and this is not where the value is for the vendors. - Alex: Looking trivial example and YANG module, you expect to maintain all the dependencies as configured information, question regarding the practicality of this, presumably there are lots of dependencies between a lots of objects. How to maintain this, maybe also highly dynamic? - Benoit: Yes, it will a complex graph. different levels: stay at what was configured, e.g. getting the health of the IP connectivity. just trying to get that and seeing where it goes (the paths) or ECMP; ECMP is dynamic. Even just solving the ECMP issue would be great. Yes, there a lot of dynamicity. We have experimenting with code with focus on exactly that. The graph could be as huge as you want, extending in the virtual world, up north. - Toerless: Going to slide 11, interesting question is to run through some examples of workflows to understand what can be produced out of this. The way I imagine this work is through different levels of abstractions what comes from the service configuration orchestrators, more higher level to lower levels (existing YANG based configuration of devices). What would be lovely it to have a way to attach one level to the other through references: when looking at the configuration of a router, I will be able to see which of the services are requiring a particular configuration or vice-versa when do inventory management, at the service level I can see what network components or configurations are there. So, this mutual referencing, not seeing this expressed, ultimately be something what the orchestrator might need to do. - Benoit: what we have is a service model on top of an orchestrator, then we configure a device. Then two options: CLI or YANG. If we have YANG, then start of a solution, because of already have the YANG models for config. and based on that can start to find a mapping. If you start with a CLI, it is harder. There are things we know from the config. of services, things from the network (ISIS). Your service model will not configure ISIS, the IGP is there by default; so need to learn it from the network. Extra things like multicast, we might want to see if a specific service is multicast or not, need to have the operator input to construct the graph the first time you got a new service type. - Toerless: concept of two different levels (ultimately multiple levels): simple case: service level and per device config. forget about CLI, makes is more difficult. device config. is also YANG. purely the abstraction models by which I can say, I'm looking at device level config., but attached to each level of the YANG device config. are pointers pointing back to the service requiring this. - Benoit: this is what we have in slide #7. Top of the assurance graph, is the service ID coming from the orchestrator. Top of the tree comes from the service. This is the link that you need. - Toerless: one of the overheads, e.g. on a router, to see the service dependencies, the router would have to capture the whole tree... - Benoit: No, I mentioned distributed. The router would know about parts of the sub-services (device health, interface health, telemetry health...) not the entire tree. because its YANG, could be a leaf-ref. - Toesless: are these existing YANG structural elements, or requires new structural enhancements to YANG? - Benoit: No, basic YANG. - Laurent: keep good interactions on this document, being mainly progressed in OPSAWG. Expect more feedback and completeness on the concepts. ************************************************************************************************************************************* * 16:15 - 05 min - 9. Intent-Based Networking - Concepts and Definitions, draft-irtf-nmrg-ibn-concepts-definitions, Laurent Ciavaglia Recording: from 02h 36m 00s to 02h 41m 15s Slides: https://datatracker.ietf.org/meeting/interim-2020-nmrg-03/materials/slides-interim-2020-nmrg-03-sessa-9-ibn-concepts-and-definitions Draft: https://tools.ietf.org/html/draft-irtf-nmrg-ibn-concepts-definitions No questions. ***************************************** * 16:20 - 15 min - 10. RG updates, Chairs Recording: from 02h 41m 20s to 03h 11m 05s (end of meeting) Slides (#7 to #16): https://datatracker.ietf.org/meeting/interim-2020-nmrg-03/materials/slides-interim-2020-nmrg-03-sessa-1-10-agenda-and-rg-updates Slide #7: general updates: new charter approved end of March 2020. NMRG GitHub. Slide #8: status on AI for NM: research challenges document initiated (https://docs.google.com/document/d/1dQOzZustI2mkYr_omtiqu3FqUvoqLgaCp7nbRj4ZJyw/edit?usp=sharing). AI for NM research talks series. AI for NM competition. Slides #9-14: status on IBN: progress on work plan/milestones. hackathon project. - Alex: is there someone working on the document for work item #1 right now? - Laurent: there is no I-D on the RG right now, but I am working on this in Nokia. It would be nice to have that in the RG. - Alex: there is a lot of people motivated for that in here. - Luis: I wonder if transport slice can be a use case for this? (RG slide #13) - Laurent: Very good point. The work which you are proposing could be related to that, network slice. Intent instantiations. It could have a draft on this. Slide #15: status on self-management framework: special session on emerging frameworks being proposed. Slide #16: future meetings: - Alex: A little misleading on the slide, NOMS is not canceled, it will be virtually. - Laurent: correct. NOMS is maintained as a virtual conference, only the NMRG session is canceled. ************* Participants (35): 1. Laurent Ciavaglia, Nokia 2. Jérôme François, Inria 3. Börje Ohlman, Ericsson 4. Eric Gray, Ericsson 5. Diego Lopez, Telefonica 6. Sonia Fernandez, Telefon~ica 7. Colin Perkins, University of Glasgow (1st hour only) 8. Jéferson Nobre, UFRGS 9. Benoit Claise, Cisco 10. Olga Havel, Huawei 11. Yuji Tochio, Fujitsu 12. Sun Xueyuan, China Telecom 13. Dhruv Dhody, Huawei-India 14. Hirochika Asai, Preferred Networks / WIDE Project 15. Chi-Jiun Su, Hughes Network Systems 16. Abdelkader Lahmadi, Inria 17. Qin Wu, Huawei 18. Pedro Martinez-Julia, NICT 19. Will Liu, Huawei 20. Navid Nazarzadeoghaz, Concordia University 21. Luis M. Contreras, Telefonica 22. Marie-José Montpetit, Concordia University 23. Kazunori Fujiwara, JPRS 24. Kiran, Futurewei 25. Alexander Clemm, Futurewei 26. Vishnu Ram (Independent consultant) 27. Toerless Eckert, Futurewei 28. Milad Ghaznavi, Waterloo University 29. Xueyuan Sun, China Telecom 30. Sabine Randriamasy, Nokia 31. Chen Li, China Telecom 32. Adriana Olariu, huawei 33. Marco Liebsch, NEC 34. Yoshigumi Atarashi, Alaxala 35. Rafael ?, ?