Subject: [Adslmib] Profile indexing

From: "Michael Sneed" <[email-masked]>
Date: Wed, 20 Nov 2002 11:27:20 -0500

During the Atlanta meeting I brought up an inconsistency in they way 
profiles are indexed in RFC 2662 and RFC 3276, and in 
draft-ietf-adslmib-vdsl-06.  Basically, the previous MIBs generated by this 
working group indexed profiles by a name string (SnmpAdminString)), and VDSL 
MIB is indexing them by an integer (Unsigned32).  The indexing issue was 
discussed during the development of both of those MIBs, and in both cases 
the consensus landed on the side of the string index.

If there is not a something different about the VDSL MIB that requires  
changing the indexing for profiles, I think it should remain consistent with 
the other DSL MIBs.

However, the history of this change is at least partially bound up in an 
attempt to eliminate the use of the IMPLIED keyword, which is used in the 
two existing RFCs.    It is recommended that IMPLIED not be used in future 
MIBs.  So, if we return to string indices for profiles in the VDSL MIB they 
really should not be IMPLIED.

So, do we 1) Go back to SnmpAdminString indexing, but eliminate IMPLIED,
2) Change the profile indexing to Unsigned32, as in the current draft, or 3) 
Go back to SnmpAdminString indexing, and retain IMPLIED (which is not 
recommended, but it would be interesting to hear if someone has a strong 
opinion in favor of this option)  ?

I haven't heard any other options.

Regards,

Mike

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus

_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Bob Ray" <[email-masked]>
Date: Wed, 20 Nov 2002 13:10:55 -0600

>changing the indexing for profiles, I think it should remain consistent
with

My opinion is that the indexing should remain as Unsigned32, and here is
why.

At issue is whether vdslLineConfProfileTable should be indexed by

            vdslLineConfProfileIndex               Unsigned32

or by

            vdslLineConfProfileName                SnmpAdminString

In either case, the index of the profile table is also used to index the
remaining profile tables in the MIB:

	vdslLineMCMConfProfileTable
	vdslLineMCMConfProfileTxBandTable
	vdslLineMCMConfProfileRxBandTable
	vdslLineMCMConfProfileTxPSDTable
	vdslLineMCMConfProfileMaxTxPSDTable
	vdslLineMCMConfProfileMaxRxPSDTable
	vdslLineSCMConfProfileTable
	vdslLineSCMConfProfileTxBandTable

Note that these eight tables are line code specific configuration profile
tables.  The ADSL MIB did not have line code specific configuration profiles
(although the document alludes to some work in that direction by the DSL
Forum).

An agent may have many profiles.  Imagine a table of such profiles with
a primary index of type Unsigned32.

   index  name        x    y   z
  +-----+------------+---+---+---+
  |  1  | gold       | 1 | 2 | 3 |
  +-----+------------+---+---+---+
  |  2  | silver     | 1 | 1 | 3 |
  +-----+------------+---+---+---+
  |  3  | bronze     | 1 | 1 | 2 |
  +-----+------------+---+---+---+

As the name is required to be unique (a "candidate key"), the index is
superfluous and the table can be simplified as follows:

   name        x    y   z
  +------------+---+---+---+
  | gold       | 1 | 2 | 3 |
  +------------+---+---+---+
  | silver     | 1 | 1 | 3 |
  +------------+---+---+---+
  | bronze     | 1 | 1 | 2 |
  +------------+---+---+---+

This, I believe, is the crux of the argument to retrace the MIB back to
using SnmpAdminString as the index of the profile table.

However, there are several issues not addressed in the above example but
brought immediately to the fore by the existance of the eight subordinate
tables.  The first of these is profile storage.  With a string index
(IMPLIED
or otherwise), each profile entry in each subordinate table must have as
an attribute of each row with each table the string index associated with
the row.  For a large MCM band table collection (both tx and rx, psd tables
included) for multiple profiles, this can be fairly large.  Imagine a
collection of ten profiles for a MCM modem with 100 band entries per
direction
per profile.  Further, imagine a limit of 30 characters per profile name.
A simple (perhaps tool generated) agent would store the profile name within
each row.

1) Do the math.

Such an implementation might be quite acceptable for a PC-based proxy agent
with dual Pentium Xeon processors and an Oracle database (forgive the name
brands - there is no intention to identify any vendor whatsoever in the
above).  However, a stand alone unit housing an 68HC12B32 controller and
VDSL chipset would have a difficult time supporting even one such profile.

Obviously, one could use a small look-up table to store the profile names
within the agent: when a object identifier arrives, look up the profile
name in the look-up table, retrieving an unsigned integer index to access
some internal representation of the tables sans string index.

But, a curiously cynical programmer might ask, "What have you accomplished?"
Isn't this going full circle?  Rather inefficiently at that.

Examine the processing time required to determine which row in whatever
number of tables one has (perhaps the above "efficient" implementation,
perhaps a somewhat less "efficient" toolset generated implementation) a
received object id is associated with.

Imagine an agent receives an object with a string index.  To determine
which row(s) the string is associated with, the agent must perform a
string comparision with the entries in the table(s).  Imagine an adroit
programmer implements this via a tree structure, arriving at a log(n)
search for a given string.  Imagine, further, that the agent identifies
the object as being in a given band table with 500 rows (5 profiles, 100
entries per profile).  Nine string compares (log(500)) must be done to
determine which row is associated with the object (assuming a simple agent
with a simple implementation).  Compare this with a bounded integer lookup
function.

2) Compare and contrast these approaches in an agent which supports many
such modems and profiles.  Consider two management stations simultaneously
executing getnext walks against the agent.

Yet another consideration should be bandwidth.  Imagine a get request of

       1.3.6.1.4.1.4.1.1.someprofilestringname.1.1
vs.
       1.3.6.1.4.1.4.1.1.n.1.1

[the actual numbers are typed at random by this ranting and arguably
deranged author]

3) Compare and contrast the impact of the two indexing schemes on
network usage.  Consider again two management stations simultaneously
executing getnext walks against the agent.

For these reasons, I support retaining the indexing method of the
current draft (Unsigned32 vs SnmpAdminString).  But, if you've read
this far, you know that. :)

Bob Ray

---

From: "Umberto Bonollo" <[email-masked]>
Date: Thu, 21 Nov 2002 16:59:01 +1100

We'd basically support Bob Ray's retention of the integer indexing.
The average size of PDUs containing string VARBINDS in the index part is
also quite
messy and can exceed default packet sizes...

On the human readable angle,
there's usually a manager application interposed rather than
an SNMP-Walker used by developers,
and SNMP readability won't change much because this VDSL
MIB aimed for readability [there's so many other cryptic ones :-) ].

The pool of current prior-art MIBs is overwhelmingly
weighted towards the integer indexing approach,
correctly in our view.

Umberto Bonollo
NEC Australia ([email-masked])

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Bob Ray
Sent: Thursday, 21 November 2002 6:11
To: Michael Sneed
Cc: [email-masked]
Subject: RE: [Adslmib] Profile indexing

or by

   index  name        x    y   z

   name        x    y   z

1) Do the math.

Bob Ray