Subject: Re: Fwd: [ipv6mib] So, where were we?

From: Margaret Wasserman <[email-masked]>
Date: Fri, 04 Oct 2002 12:32:48 -0400

Hi All,

There have been some recent discussions with the IPv6 MIB design
team regarding the direction of our work on IPv6 MIBs that I
think would be best discussed on the full IPv6 and MIBs lists.

In particular, we have received input from two areas:

	(1) Folks who would like to see substantial changes
		to the RFC 2096 update (Forwarding Table MIB),
		to make it better reflect the structure of
		forwarding tables on current equipment, be more
		efficient to use, etc.
		
	(2) The authors of a new TCP-related MIB in the transport
		area who would like to see their changes merged
		with the new TCP MIB under development in IPv6.

		This work has been published as:

		draft-ietf-tsvwg-tcp-mib-extension-XX.txt

This whole discussion begs the question of what direction we want
to take with our IP version-independent MIBs, and perhaps raises
a question of how/where this work should be undertaken.

 From my perspective, there are two reasonable choices:

	(1) Update the current IPv4 TCP, UDP, IP and Forwarding
		Table MIBs to be version-independent (i.e. add IPv6).

		In this choice, we would make as few changes
		to those MIBs as possible, in attempt to make
		the implementation of the new version-independent
		MIBs as easy as possible for folks who are
		adding IPv6 to an existing stack.

		This is the work that we originally started in
		the IPv6 WG, based on the fact that the main
		difference in these MIBs would be a transition
		from IPv4 -> IPv4/IPv6, and we have several
		IPv6 WG drafts out that reflect this direction.

	(2) Develop new MIBs for TCP, UDP, IP and Forwarding
		that reflect the state-of-the-art in each area.

		This choice involves more work, and may take
		longer to be adopted, due to larger changes
		from IPv4 to the IPv4/IPv6 versions.

		Also, it is pretty clear to me that the IPv6
		WG is not the right place to develop a new,
		substantially different version of the TCP
		or UDP MIBs.  It is also questionable whether
		a major update to the IP and routing MIBs
		should be done in IPv6, or in a separate
		IPv4/IPv6 MIBs group.

It is possible that we could do a combined version of these
two choices:

	- The IPv6 WG does the minimal updates to make the
		current IPv4 MIBs version-independent.
	- State-of-the-art MIBs are developed in other areas
		and groups, as appropriate.

What do you folks think?

Margaret

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Fri, 04 Oct 2002 13:22:03 -0400

>         and groups, as appropriate.

I agree with this proposal.  The existing work of the IPv6 MIB
Design team should be targeted towards making the minimal updates.

State-of-the-art MIBs should be undertaken by subject matter
experts.

Brian

---

From: Robert Elz <[email-masked]>
Date: Sat, 05 Oct 2002 00:17:14 +0700

Date:        Fri, 04 Oct 2002 12:32:48 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | It is possible that we could do a combined version of these
  | two choices:
  | 
  | 	- The IPv6 WG does the minimal updates to make the
  | 		current IPv4 MIBs version-independent.
  | 	- State-of-the-art MIBs are developed in other areas
  | 		and groups, as appropriate.
  | 
  | What do you folks think?

Yes, that.   We should make sure that there are IPv6 (or better, address
independent) MIBs that at least offer the same functionality as the current
IPv4 MIBs.

At the same time, the NM people, transport NM people, or whoever, can go
on developing their next and greatest MIB, that works better than we
currently have, etc.   Any such MIB should be address independent now
just on general principle.

The only thing to be aware of, is that we (IPv6) must avoid getting upset
if we do lots of work to update some particular MIB, and then just before
we're finished, a new better version emerges from elsewhere (which is
intended to deprecate some current v4 only MIB).  If that happens, we
should just junk whatever we have done, and accept the newer one.   If we
get finished first, then when a newer one emerges, it can just deprecate
our new stuff, as well as the old v4 only stuff.

Note that this "do both" is exactly equivalent, to us, to just doing (1)
from your two reasonable choices, while at the same time not standing in
the way of anyone, from elsewhere, who wants to do (2)  (which is obviously
the better result - but only if it is actually achieved).

kre

---

From: Brian Haberman <[email-masked]>
Date: Fri, 04 Oct 2002 14:04:01 -0400

Robert Elz wrote:
> should just junk whatever we have done, and accept the newer one.

As long as the newer, better version supports IPv6.  We do have the
responsibility of ensuring v6 support in the new MIBs.

As a note, the IPv6 MIB Design Team has been reviewing new MIBs that
come out to make sure they are using the INET Address TC where
appropriate.

Brian

---

From: Rob Austein <[email-masked]>
Date: Fri, 04 Oct 2002 15:04:07 -0400

What KRE said.

---

From: Michael MacFaden <[email-masked]>
Date: Fri, 4 Oct 2002 12:08:15 -0700

>		and groups, as appropriate.

Doing minimal (1) updates make the most sense to me. 

Given the history of the IP-FORWARD-MIB: ipRouteTable, ipForwardTable, 
and the ipCidrRouteTable a minimalist approach might mean we 
have a higher probability that can get this new work to full standard.  

Sadly, only the ipRouteTable is at full standard (std17)
and we've had mostly cidr networks since '97.

I also can't think of a widely deployed device that will provide
the new integrated IPv4/IPv6 mib modules that won't continue to ship the 
existing RFC1213, 1907,2011-13,2096 for backward compatiblity
with existing management applications. 

Regards,
Mike MacFaden

---

From: Robert Elz <[email-masked]>
Date: Sat, 05 Oct 2002 21:14:30 +0700

Date:        Fri, 04 Oct 2002 14:04:01 -0400
    From:        Brian Haberman <[email-masked]>
    Message-ID:  <[email-masked]>

  | As long as the newer, better version supports IPv6.

Of course.

My expectation would be that any new mib, or for that matter, any
new anything (as much as it is relevant) now must support IPv6 to
be accepted.

kre

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Oct 2002 23:48:01 +0200

>>>>> Michael MacFaden writes:

Michael> Given the history of the IP-FORWARD-MIB: ipRouteTable,
Michael> ipForwardTable, and the ipCidrRouteTable a minimalist
Michael> approach might mean we have a higher probability that can get
Michael> this new work to full standard.

The problem with the IP-FORWARD-MIB is that many systems use
forwarding bases which are much richer than what the indexing allows
to report. On such systems, implementing the ipCidrRouteTable (and the
ipRouteTable) means to report only a subset of the real forwarding
information. Hence, management applications which try to interpret
these MIB tables are kind of fooled. This is of course even worse on
systems that only have ipRouteTable support.

If we really care about interoperable management applications, then we
need to spell out very clearly that an IP version independent variant
of the ipCidrRouteTable is only applicable on devices where the
complete forwarding information can be represented in the
ipCidrRouteTable. (And it is my understanding that for example a
recent Linux box would not fit into this category.)

We can try to improve this by adding more stuff into the index.
However, we will end up with something that is getting even harder to
implement correctly. And we all know that retrieving routing tables of
non-trivial size via SNMP is already one of the slowest operations you
can do on some boxes.

So while I in general like incremental approaches, I am not sure this
really works out in the particular case of the IP-FORWARD-MIB.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

---

From: Brian Haberman <[email-masked]>
Date: Tue, 08 Oct 2002 18:57:46 -0400

Juergen,
     So, should we look at trying to simplify the indices for the
tables?  That would seem like the logical thing to me.

Brian

Juergen Schoenwaelder wrote:
> !! This message is brought to you via the `ipv6mib' mailing list.
> !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust
> !! your settings, send a mail message to <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/ipv6mib.