Subject: Re: [nmrg] Unable to locate a PC Projector for Saturday's Meeting
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wed, 9 May 2001 10:54:06 +0200

>>>>> Andrea Westerinen writes:

Andrea> My apologies but I have been unable to get a PC-LCD projector
Andrea> for Saturday.  The Cisco office's projector is in use on
Andrea> Saturday, and the hotel charges $550 USD per day!  (Cisco
Andrea> won't ok this charge.)  We will have a projector on Sunday
Andrea> only - compliments of the IM2001 conference.  We will have a
Andrea> flip chart on both days.

Andrea> If anyone has other ideas regarding locating a projector, let
Andrea> me know and I will get the room set up on Saturday to
Andrea> accomodate it.

So unless someone happens to find a projector in his luggage, we will
just do without one on Saturday. I know that Aiko is good at making
drawings on ordinary white boards - so I expect that this will not be
a big problem.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

From: "Andrea Westerinen" <[email-masked]>
To: "Network Management Research Group" <[email-masked]>
Subject: [nmrg] Unable to locate a PC Projector for Saturday's Meeting
Date: Tue, 8 May 2001 10:58:13 -0700
Importance: Normal
Sender: [email-masked]

My apologies but I have been unable to get a PC-LCD projector for Saturday.
The Cisco office's projector is in use on Saturday, and the hotel charges
$550 USD per day!  (Cisco won't ok this charge.)  We will have a projector
on Sunday only - compliments of the IM2001 conference.  We will have a flip
chart on both days.

If anyone has other ideas regarding locating a projector, let me know and I
will get the room set up on Saturday to accomodate it.

Andrea

From: Frank Strauss <[email-masked]>
To: Aiko Pras <[email-masked]>
Cc: Network Management Research Group <[email-masked]>, szabolcs boros <[email-masked]>, Bert Helthuis <[email-masked]>
Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative)
Date: 02 May 2001 14:27:38 +0200
Lines: 58
Sender: [email-masked]

Hi!

>> Aiko, I'd like to let you know in advance of the meeting, what I had
>> in mind some time ago. Here is a part of a mail I've sent some time
>> ago when you first announced your work on the MIB lookup service...
>> 
>> This sounds interesting to me, especially if you would intend to
>> build it on top of (or even integrated with) the libsmi. ;-)

Aiko> Our current prototype is already using libsmi. We have made some stuff
Aiko> as "post-processor" around it (to make things faster). Libsmi does the
Aiko> initial conversion of MIB modules into an intermediate format. From than
Aiko> on the "post processor" uses the intermediate format. 
Aiko> It is nice, however, that you're thinking on this too and I'm looking
Aiko> forward to discuss with you (and others) how we've implemented things. 

What I have in mind, is to keep using the libsmi being the interface
that the management applications use. Just the libsmi input drivers
are extended to support some kind of an `SMI protocol'. 

>> In the early days of the libsmi design I had a similar idea:    
>> 
>> (a) a server that is built on top of the SMI library, that 
>> serves connecting clients that use the server to serve 
>> SMI related requests.
>> 
>> (b) a libsmi input driver that makes the library talks to such a
>> server (or even a list of servers, if the first one doesn't 
>> know the answer) if the configured SMIPATH is configured
>> appropriately.
>> 
>> This rough idea looked very nice to me, but soon a number of 
>> problems became visible and we shelved this plan.

Aiko> I'm interested in the problems you've found. We've identified a couple
Aiko> of problems, but have the impression we know how to deal with them. We
Aiko> could be wrong ;-(

The problems I remember were concerned with 

  - the granularity of SMI lookup requests that would cause really bad
    performance,
  - the memory management; currently libsmi return pointers to structs
    that are allocated once when a module is parsed,
  - the scoping of definitions that could be found on a number of
    servers,
  - the decision which server should be queried for lookups by OID only.

I must admit that I did not spent more detailed thoughts on these
questions, because at the time of disigning the libsmi I was lucky
enough with what we had at that time.

Later I started thinking about the possibility to retrieve and cache
just whole modules from remote servers, but again there are no
detailed plans or implementation efforts yet.

 -frank

From: Frank Strauss <[email-masked]>
To: Aiko Pras <[email-masked]>
Cc: szabolcs boros <[email-masked]>, Bert Helthuis <[email-masked]>, Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] meeting preparation
Date: 02 May 2001 12:14:58 +0200
Lines: 29
Sender: [email-masked]

Hi!

Thanks for the explanations. Just two comments remain:

>> What is the `numeric identity' of a module? The OID of the
>> MODULE-IDENTITY?  What is the purpose of this id?

Aiko> Correct. It is used to detect if a server has already stored
Aiko> this MIB module

I think, the module name is ok to identify a module.
And it works for SMIv1 as well.

Aiko> Note that multiple top level nodes may be associated with a single MIB
Aiko> module. In case of the if-mib the top-level nodes are:
Aiko> - 1.3.6.1.2.1.2
Aiko> - 1.3.6.1.2.1.31
Aiko> - 1.3.6.1.6.3.1.1.5.3
Aiko> - 1.3.6.1.6.3.1.1.5.4
Aiko> (I'm doing just some cut and paste and haven't realy checked this; I
Aiko> hope I didn't made errors. Is this OK to give you the idea?) 

How does your algorithm dicide to use these four OIDs and not for
example 1.3.6.1.2.1 and 1.3.6.1.6.3.1.1.5 or just 1.3.6.1?

 -frank

Date: Wed, 02 May 2001 12:09:16 +0200
From: Aiko Pras <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] meeting preparation
Sender: [email-masked]

Juergen Schoenwaelder wrote:
> 
> >>>>> Aiko Pras writes:
> 
> >> What is the `numeric identity' of a module? The OID of the
> >> MODULE-IDENTITY?  What is the purpose of this id?
> 
> Aiko> Correct. It is used to detect if a server has already stored
> Aiko> this MIB module
> 
> Which version of "this MIB module"?

The last. That's why it also checks "LastUpdated".
Note that this doesn't realy work for SMIv1 modules.

With IETF MIBs we may also consider the "status" of a MIB module. That
info comes "directly" (well, you all know how easy that is) from the
IETF (we do that in the same way as we maintain
http://www.simpleweb.org/ietf/rfcs/rfcbystatus.html). Thusfar I
considered this as "a local policy", and this info is not being echanged
in the server-server messages.

Bye

Aiko

Date: Wed, 2 May 2001 11:53:46 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] meeting preparation
Sender: [email-masked]

>>>>> Aiko Pras writes:

>> What is the `numeric identity' of a module? The OID of the
>> MODULE-IDENTITY?  What is the purpose of this id?

Aiko> Correct. It is used to detect if a server has already stored
Aiko> this MIB module

Which version of "this MIB module"?

/js

Date: Wed, 02 May 2001 11:38:13 +0200
From: Aiko Pras <[email-masked]>
To: Frank Strauss <[email-masked]>
CC: szabolcs boros <[email-masked]>, Bert Helthuis <[email-masked]>, Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] meeting preparation
Sender: [email-masked]

Hi Frank

Frank Strauss wrote:
> 
> Hi!
> 
> Aiko> 1) A paper written by Szabolcs Boros on this subject. The paper 
> Aiko>    is presented at the High Speed Networking (HSN) workshop at
> Aiko>    Balatonfured (Hungary)
> I took a rough look and have a few questions and comments:
> 
> What is the `numeric identity' of a module? The OID of the
> MODULE-IDENTITY?  What is the purpose of this id?
Correct. It is used to detect if a server has already stored this MIB
module

> What are the `top level node(s) within a module', and what is the
> purpose of this information, e.g. in IF-MIB?
The top level node(s) is (are) used by a server after it gets a request
for some item from a client. Assume the client sends the oid of the item
of which it wants information. The server checks if this oid "fits"
under one of the top-level nodes it knows about. If yes, the server
checks in his database to find the requested item.

Note that multiple top level nodes may be associated with a single MIB
module. In case of the if-mib the top-level nodes are:
- 1.3.6.1.2.1.2
- 1.3.6.1.2.1.31
- 1.3.6.1.6.3.1.1.5.3
- 1.3.6.1.6.3.1.1.5.4
(I'm doing just some cut and paste and haven't realy checked this; I
hope I didn't made errors. Is this OK to give you the idea?) 

> How do you determine the authoritative server of a module?
:-) This is not being solved be some magic algorithm, but is left to the
"owners" of the servers who establish the "friend" relationships.
Determining the authoritive server is therefore a "human policy"
decision. There are some ways you can automate this, however.
It is important, however, to remember that we want a "best effort"
service, and not a 100% guaranteed service.

> XML on page 5: attribute values have be enclosed in double quotes.
> 
> i_have messages are forwarded by servers, right? Is there any hop
> limit? Do you have any assumptions about scalability?
We had a hop limit, but have removed that. There are some simple things,
however, that control how the information within i_have messages are
flooded over all servers. We believe these "simple things" will be
sufficient, since we do not expect an infrastructure with thausands of
servers (I personaaly expect that the number will be less than 100).

> 
>  -frank

Aiko

From: Frank Strauss <[email-masked]>
To: Aiko Pras <[email-masked]>, szabolcs boros <[email-masked]>, Bert Helthuis <[email-masked]>
Cc: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] meeting preparation
Date: 02 May 2001 11:14:57 +0200
Lines: 25
Sender: [email-masked]

Hi!

Aiko> 1) A paper written by Szabolcs Boros on this subject. The paper is
Aiko>    presented at the High Speed Networking (HSN) workshop at
Aiko>    Balatonfured (Hungary)
Aiko>    http://www.simpleweb.org/nm/research/results/publications/boros/DMIBOIS.pdf

I took a rough look and have a few questions and comments:

What is the `numeric identity' of a module? The OID of the
MODULE-IDENTITY?  What is the purpose of this id?

What are the `top level node(s) within a module', and what is the
purpose of this information, e.g. in IF-MIB?

How do you determine the authoritative server of a module?

XML on page 5: attribute values have be enclosed in double quotes.

i_have messages are forwarded by servers, right? Is there any hop
limit? Do you have any assumptions about scalability?

 -frank

Date: Wed, 02 May 2001 11:13:19 +0200
From: Aiko Pras <[email-masked]>
To: Frank Strauss <[email-masked]>
CC: Network Management Research Group <[email-masked]>, szabolcs boros <[email-masked]>, Bert Helthuis <[email-masked]>
Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative)
Sender: [email-masked]

Hi Frank

Frank Strauss wrote:
> Aiko, I'd like to let you know in advance of the meeting, what I had
> in mind some time ago. Here is a part of a mail I've sent some time
> ago when you first announced your work on the MIB lookup service...
> 
>     This sounds interesting to me, especially if you would intend to
>     build it on top of (or even integrated with) the libsmi. ;-)
Our current prototype is already using libsmi. We have made some stuff
as "post-processor" around it (to make things faster). Libsmi does the
initial conversion of MIB modules into an intermediate format. From than
on the "post processor" uses the intermediate format. 
It is nice, however, that you're thinking on this too and I'm looking
forward to discuss with you (and others) how we've implemented things. 

>     In the early days of the libsmi design I had a similar idea:    
> 
>       (a) a server that is built on top of the SMI library, that 
>           serves connecting clients that use the server to serve 
>           SMI related requests.
> 
>       (b) a libsmi input driver that makes the library talks to such a
>           server (or even a list of servers, if the first one doesn't 
>           know the answer) if the configured SMIPATH is configured
>           appropriately.
> 
>     This rough idea looked very nice to me, but soon a number of 
>     problems became visible and we shelved this plan.
I'm interested in the problems you've found. We've identified a couple
of problems, but have the impression we know how to deal with them. We
could be wrong ;-(

>     However, if your work on this topic starts, I would be interested 
>     in it.
> This is still true. I would see some benefit, if your service could be
> applicable by a libsmi input driver. However, it could be hard to 
> align both efforts.
As said before, we already use libsmi. On the other hand, things get
only more more interesting if we have multiple, independent
implementations.

See you in Seattle

Aiko

Date: Wed, 2 May 2001 10:54:51 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] meeting preparation
Sender: [email-masked]

>>>>> Aiko Pras writes:

Aiko> I do not (yet) have an Internet Draft. Depending on the
Aiko> discussion in Seattle, I'm concidering writing one. I propose
Aiko> that interested people read (one of) the following:

Aiko> 1) A paper written by Szabolcs Boros on this subject. The paper
Aiko> is presented at the High Speed Networking (HSN) workshop at
Aiko> Balatonfured (Hungary)
Aiko> http://www.simpleweb.org/nm/research/results/publications/boros/DMIBOIS.pdf

Aiko> 2) A help page on the web, which describes the client-server
Aiko> part of the service.
Aiko> http://www.simpleweb.org/ietf/mibs/oidd/help/ In particular I
Aiko> propose you take a look at the HTTP interface part
Aiko> http://www.simpleweb.org/ietf/mibs/oidd/help/http.html

Thanks. I have linked both documents on the meeting Web page as
reading material.

/js

Date: Wed, 02 May 2001 10:20:52 +0200
From: Aiko Pras <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
CC: Network Management Research Group <[email-masked]>, szabolcs boros <[email-masked]>, Bert Helthuis <[email-masked]>
Subject: Re: [nmrg] meeting preparation
Sender: [email-masked]

Hi all

Juergen Schoenwaelder wrote:
> 
> I would like to ask people who have proposed agenda items to provide
> pointers where people attending the meeting can obtain some background
> information. In general, I prefer to use the Internet-Drafts 
> repository to distribute them, but I understand that sometimes this 
> does not work for several reasons.
> 
> Aiko, can we expect say an ID which describes the MIB Object
> Information Lookup Service before the NMRG meeting? Or which other
> document to you want us to study before the NMRG meeting?

I do not (yet) have an Internet Draft. Depending on the discussion in
Seattle, I'm concidering writing one. I propose that interested people
read (one of) the following:

1) A paper written by Szabolcs Boros on this subject. The paper is
   presented at the High Speed Networking (HSN) workshop at
   Balatonfured (Hungary)
http://www.simpleweb.org/nm/research/results/publications/boros/DMIBOIS.pdf

2) A help page on the web, which describes the client-server part
   of the service.
   http://www.simpleweb.org/ietf/mibs/oidd/help/
   In particular I propose you take a look at the HTTP interface part
   http://www.simpleweb.org/ietf/mibs/oidd/help/http.html

B.t.w. we liked the suggestion of Dave Pperkins and will change the
title of this work into "MIB Item LookUp Service".

See you in Seattle

Aiko