[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Research-funding] Re: [nmrg] network management research funding text



Juergen Schoenwaelder wrote:

3.5.2.  Configuration Management

I think there is quite some overlap with aspects already explained in
3.5.1. However, I regard it reasonable to differentiate what the
titles of both subsections denote. (Sorry, I have to concrete suggestion
for a change.)
3.5.1 is a general statement that more work has to be done to manage
networks rather than devices. 3.5.2 is more specific on configuration
management since operators told us that this is the most pressing issue
from their perspective. This section is also more concrete in that it
mentions the need for transaction support across a network of devices.
Does this make sense?
I agree that there are different intentions to be expressed by the
two sections (and by any of the other sections). Just reading the text
from a certain distance (like potential people that are addressed by
this document) lets me think that there are some common arguments.
The same is true for my initial comment on 3.5.4.


3.5.3.  Enhanced Monitoring Capabilities

[...] I have added the sentence:

   This requires adequate and scalable data aggregation techniques.

Does this help?
I'm fine with that.


[...] What about this:

3.5.4.  Autonomous Network Management

   Current approaches to network management do not scale sufficiently,
   so network operators often have difficulty operating their
                                               ^ plural?

   network(s) as successfully and economically as desired.  Hence,
   more work is needed to improve the automation achieved by network
   management systems.  This might involve application of control
   theory, artificial intelligence, expert systems technology, or
   other mechanisms, for example.
Either "or other mechanisms" or "for example", not both, I suggest.

Any other suggestions?
Sounds good to me.


3.5.5. Customer Network Management

An open issue related to network management is helping users and
others to identify and resolve problems in the network. If a user
can't access a web page, it would be useful if the user could find
out, easily, without having to run ping and traceroute, whether the
problem was that the web server was down, that the network was
partitioned due to a link failure, that there was heavy congestion
along the path, that the DNS name couldn't be resolved, that the
firewall prohibited the access, or something else.
I think this paragraph misses a final sentence, just stating what kind
of research is required to address this well described problem.

You basically need a good model of the network and a reasoning engine
to give users explanation. Another approach would be to have specific
automated diagostic tests which can be triggered by customers and which
generate explanations understandable by customers. Sure, such tools
should not reveal any information that is considered a secret by the
network operator. What about adding the following:

   Applied research is needed how to translate data that exists in a
   network or a network management system into terms understandable by
   customers. This also requires to be able to determine which
   customers are affected and how if something breaks. Of course,
   customer network management mechanisms must not reveal any
   internals that are considered to be secrets of organization
                                                     ^the

   operating a network.
Sounds good to me.


Maybe, we should have a subsection to address research not only on what
new ideas should be evolved in the future but also on what we have to
better understand about the past. The plans on NM traffic measurements
we had during recent NMRG meetings belong to this kind of research.
Sorry, again no concrete proposal yet.

Can you please write something up?
Ok. How do you think about this...?


Analysis of Current Network Management Application

In the past much work has been spent on the specification and
implementation of a network management architecture. However, most
administrators use far less components of this architecture than
possible. There are only vague estimations about the reasons for
this reluctance. A better understanding of what is used for which
purpose and what is not for which reasons is highly disirable.
This can be done by an automated analysis of network management
protocol traffic and applications at operators' sites and enhanced
by additional conversations with the operators.




_______________________________________________
Research-funding mailing list
Research-funding@ietf.org
https://www1.ietf.org/mailman/listinfo/research-funding