Skip to main content

Minutes interim-2020-nmrg-03: Tue 14:00
minutes-interim-2020-nmrg-03-202004141400-00

The information below is for an old version of the document.
Meeting Minutes Network Management (nmrg) RG Snapshot
Date and time 2020-04-14 12:00
Title Minutes interim-2020-nmrg-03: Tue 14:00
State Active
Other versions plain text
Last updated 2020-04-21

minutes-interim-2020-nmrg-03-202004141400-00
NMRG Virtual Meeting April 2020
Tuesday 14-04-2020 14:00-17:00 Paris time

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://ietf.webex.com/ietf/ldr.php?RCID=99f5e46304dee522c2288c1add539db0 *
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. Sabrine Randriamasy, Nokia
31. Chen Li, China Telecom
32. Adriana Olariu, huawei
33. Marco Liebsch, NEC
34. Yoshigumi Atarashi, Alaxala
35. Rafael ?, ?