[Research-funding] Re: [nmrg] network management research funding text
Frank Strauß <strauss@ibr.cs.tu-bs.de> Wed, 16 July 2003 06:52 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17215
for <research-funding-archive@odin.ietf.org>;
Wed, 16 Jul 2003 02:52:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20) id 19cg94-0003yc-BY
for research-funding-archive@odin.ietf.org; Wed, 16 Jul 2003 02:52:15 -0400
Received: (from exim@localhost)
by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G6qAuA015213
for research-funding-archive@odin.ietf.org; Wed, 16 Jul 2003 02:52:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20) id 19cg92-0003x4-Sp
for research-funding-web-archive@optimus.ietf.org;
Wed, 16 Jul 2003 02:52:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17162;
Wed, 16 Jul 2003 02:52:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12)
id 19cg8y-0003fM-00; Wed, 16 Jul 2003 02:52:04 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
by ietf-mx with esmtp (Exim 4.12)
id 19cg8t-0003fJ-00; Wed, 16 Jul 2003 02:51:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19cg8v-0003u0-KS; Wed, 16 Jul 2003 02:52:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20) id 19c1b7-0007xR-Lp
for research-funding@optimus.ietf.org; Mon, 14 Jul 2003 07:34:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10992
for <research-funding@ietf.org>; Mon, 14 Jul 2003 07:34:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12)
id 19c1b7-0005MD-00
for research-funding@ietf.org; Mon, 14 Jul 2003 07:34:25 -0400
Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18])
by ietf-mx with esmtp (Exim 4.12) id 19c1b6-0005M6-00
for research-funding@ietf.org; Mon, 14 Jul 2003 07:34:24 -0400
Received: from ibr.cs.tu-bs.de ([81.160.165.173]) (authenticated bits=0)
by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id
h6EBYKRI007880
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
Mon, 14 Jul 2003 13:34:20 +0200
Message-ID: <3F12952C.50003@ibr.cs.tu-bs.de>
From: =?ISO-8859-15?Q?Frank_Strau=DF?= <strauss@ibr.cs.tu-bs.de>
Organization: IBR, TU Braunschweig, Germany
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.4) Gecko/20030624
X-Accept-Language: de, en-us, en
MIME-Version: 1.0
To: j.schoenwaelder@iu-bremen.de
CC: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de
References: <20030708093936.GA1287@iu-bremen.de>
<3F0C72EF.50805@ibr.cs.tu-bs.de> <20030710083253.GC660@iu-bremen.de>
In-Reply-To: <20030710083253.GC660@iu-bremen.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-IBRFilter-SpamReport: -32.2 () EMAIL_ATTRIBUTION, IN_REP_TO,
QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA
X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Subject: [Research-funding] Re: [nmrg] network management research funding text
Sender: research-funding-admin@ietf.org
Errors-To: research-funding-admin@ietf.org
X-BeenThere: research-funding@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/research-funding>,
<mailto:research-funding-request@ietf.org?subject=unsubscribe>
List-Id: draft-iab-research-funding feedback <research-funding.ietf.org>
List-Post: <mailto:research-funding@ietf.org>
List-Help: <mailto:research-funding-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/research-funding>,
<mailto:research-funding-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/research-funding/>
Date: Mon, 14 Jul 2003 13:34:04 +0200
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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
- [Research-funding] network management research fu… Juergen Schoenwaelder
- [Research-funding] Re: [nmrg] network management … Frank Strauß
- [Research-funding] Re: [nmrg] network management … Juergen Schoenwaelder
- [Research-funding] Re: [nmrg] network management … Juergen Schoenwaelder
- [Research-funding] Re: [nmrg] network management … Frank Strauß
- [Research-funding] Re: [nmrg] network management … Frank Strauß
- [Research-funding] Re: [nmrg] network management … Juergen Schoenwaelder