Subject: [Tsvwg] TCP and UDP MIB issues

From: Anders Persson <[email-masked]>
Date: Thu, 11 Jan 2007 11:06:34 -0800

Hi Everyone,

During the v6ops meeting at IETF 66 we presented some issues with the 
current TCP and UDP MIBs, however, it was quickly pointed out that the 
TSVWG would be a more appropriate venue. The main issue that we are 
trying to address is how to present associations between system 
processes and TCP/UDP endpoints when there are multiple processes 
associated with one endpoint.

A draft[1] is available that describes the issue and which also contains 
a first attempt at a TCP/UDP extension MIB. It would be highly 
appreciated if members of the TSVWG could help out reviewing this draft.

Thanks,
Anders

[1] http://tools.ietf.org/wg/v6ops/draft-persson-v6ops-mib-issue-01.txt

---

From: Matt Mathis <[email-masked]>
Date: Thu, 11 Jan 2007 14:41:54 -0500 (EST)

Does this conflict with
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-14.txt
(currently between states in IESG review).

The TCP Extended Statistics MIB also AUGMENTS both the tcpConnectionEntry and
tcpListenerEntry.    I am not enough of a mib person to understand how
multiple AUGMENTS clauses might interact.

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------

---

From: <[email-masked]>
Date: Fri, 12 Jan 2007 09:39:58 +0200

> multiple AUGMENTS clauses might interact.

I'm not enough of a MIB person either, but I really wish the existence
of a related v6ops draft had been brought up during WG or at the latest
IETF Last Call.

Lars
-- 
NEW EMAIL: [email-masked]
NEW MOBILE: +358 50 48 24461
NEW JABBER: [email-masked]

---

From: Kristine Adamson <[email-masked]>
Date: Fri, 12 Jan 2007 06:07:43 -0700

I've worked with Matt Mathis a bit on the tsvwg group's TCP Extended 
Statistics MIB because I work on an IBM product's SNMP support.  As far as 
I am aware, you may have more than one "augmenting" table which augments a 
base table.  But an augmenting table can not itself be a base table.  I am 
copying the MIB mailing list for any additional feedback. 

So, both the tcpEStatsConnectIdTable (from the tsvwg's TCP-ESTATS-MIB) and 
the tcpConnectionInfoTable (from the v6ops' TCP-PROC-MIB) can augment the 
tcpConnectionTable in the TCP-MIB. 

That said, maybe the TCP Creation MIB objects in the TCP-PROC-MIB's 
tcpConnectionInfoTable, could be moved to one of the tables in the 
TCP-ESTATS-MIB.  We will be looking into implementing the TCP-ESTATS-MIB 
in the future in order to support additional information for TCP 
connections.  Since the TCP-ESTATS-MIB is in the final approval stages, 
maybe these MIB objects could be added to one of the TCP-ESTATS-MIB's 
table in the future, as an updated version of the MIB module.   Or, maybe 
they should be added to the TCP-MIB's  tcpConnectionTable? 

Unfortunately, I don't think any IETF group is working on an extended 
statistics MIB module for UDP endpoints.  If we create a MIB table with a 
general name like, udpEndpointInfoTable, then you would expect that any 
other additional management data for UDP endpoints would be added to this 
table.  Instead, maybe it would be better to either add the UDP Creation 
MIB objects to the existing udpEndpointTable in the UDP-MIB, or rename the 
udpEndpointInfoTable to something more specific, like 
udpEndpointCreationTable.
 
Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Phone: (919) 254-7911   T/L 444-7911
Internet e-mail:[email-masked]

---

From: Kristine Adamson <[email-masked]>
Date: Fri, 12 Jan 2007 06:32:10 -0700

Juergen,
   Sorry for the confusion.  The current draft of the TCP-ESTATS-MIB is 
at:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-14.txt

The TCP/UDP Process MIB draft is at:
http://tools.ietf.org/wg/v6ops/draft-persson-v6ops-mib-issue-01.txt 

Kristine Adamson

Juergen Schoenwaelder <[email-masked]> wrote on 01/12/2007 
08:13:50 AM:

> On Fri, Jan 12, 2007 at 06:07:43AM -0700, Kristine Adamson wrote:
> It would help people like me who did not follow any of this work if
> you can provide us the names of the documents in question.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder       {International|Jacobs} University Bremen
> <http://www.eecs.iu-bremen.de/>    P.O. Box 750 561, 28725 Bremen, 
Germany

---

From: Matt Mathis <[email-masked]>
Date: Fri, 12 Jan 2007 10:57:48 -0500 (EST)

If there is not a technical problem with two tables that AUGMENT the same base
table, I strongly advocate advancing the documents separately.   ESTATS mib is
almost ready for the RFC editor queue.  -mib-issue- is not even a WG item yet,
and may or may not converge quickly.   I really don't want to reopen ESTATS
mib for lots of new revisions at this time.

That said, the issues raised in -mib-issue- are real.  We were aware of them
but (mistakenly?) believed that there did not exist a standardizable OS
independent solution.  I would like to see this work proceed, but not at the
cost of stalling ESTATS.

Thanks,
--MM--

---

From: Anders Persson <[email-masked]>
Date: Fri, 12 Jan 2007 10:22:18 -0800

> independent solution.  I would like to see this work proceed, but not at the
I agree that advancing the documents separately is best way moving 
forward. However, maintaining two separate documents might also lead to 
some objects being duplicated (i.e., creation time).

Anders 
>>>> Statistics MIB because I work on an IBM product's SNMP support.  As
>>>>         
>> far as
>>     
>>>> I am aware, you may have more than one "augmenting" table which
>>>>         
>> augments a
>>     
>>>> base table.  But an augmenting table can not itself be a base table. I
>>>>         
>> am
>>     
>>>> So, both the tcpEStatsConnectIdTable (from the tsvwg's TCP-ESTATS-MIB)
>>>>         
>> and
>>     
>>>> the tcpConnectionInfoTable (from the v6ops' TCP-PROC-MIB) can augment
>>>>         
>> the
>>     
>>>> TCP-ESTATS-MIB.  We will be looking into implementing the
>>>>         
>> TCP-ESTATS-MIB
>>     
>>>> connections.  Since the TCP-ESTATS-MIB is in the final approval
>>>>         
>> stages,
>>     
>>>> table in the future, as an updated version of the MIB module.   Or,
>>>>         
>> maybe
>>     
>>>> statistics MIB module for UDP endpoints.  If we create a MIB table
>>>>         
>> with a
>>     
>>>> general name like, udpEndpointInfoTable, then you would expect that
>>>>         
>> any
>>     
>>>> other additional management data for UDP endpoints would be added to
>>>>         
>> this
>>     
>>>> table.  Instead, maybe it would be better to either add the UDP
>>>>         
>> Creation
>>     
>>>> MIB objects to the existing udpEndpointTable in the UDP-MIB, or rename
>>>>         
>> the
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Jan 2007 14:13:50 +0100

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 23 Jan 2007 10:51:41 +0000

Generally, the proposed UDP-Lite MIB follows that for UDP (supporting 
both multicast and unicast). It does differ in the udpliteEndpointTable:

http://tools.ietf.org/wg/tsvwg/draft-renker-tsvwg-udplite-mib-01.txt

If there are implications on the UDP-Lite MIB, we'd be pleased to try to 
understand what these are, and any ideas of what we should do.

Best wishes,

Gorry

---

From: Anders Persson <[email-masked]>
Date: Mon, 29 Jan 2007 11:53:38 -0800

Gorry,

The same general issue does seem to appear within the UDP-Lite MIB, 
which is how to deal with multiple processes using the same UDP-Lite 
endpoint. For example, on a system using sockets, you can have one 
socket being shared between multiple processes if the creator of the 
socket uses fork() to create child processes. However, with the current 
MIB it is only possible to associate one processes with an endpoint.

There are at least four ways this could be addressed:
    (1) Use udpliteEndpointInstance to create multiple entries. 
Unfortunately, this approach
         makes it look like multiple independent endpoints, which might 
be a bit deceiving
    (2) Make udpliteEndpointProcess part of the INDEX
    (3) Create a new Identifier object (like tcpEStatsConnectIdEntry), 
which could then be
         referenced by other tables. For example, we could then have 
udpliteProcessTable
    (4) Create udpliteProcessTable that mirrors the INDEX of 
udpliteEndpointTable, but adds
         udpliteEndpointProcess to the INDEX as well :-(

My personal choice would be (3), as it allows the MIB to be extended in 
the future.

Cheers,
Anders

Gorry Fairhurst wrote:
> If there are implications on the UDP-Lite MIB, we'd be pleased to try 
> to understand what these are, and any ideas of what we should do.
>
> Best wishes,
>
> Gorry
>