Subject: RE: [Adslmib] Profile indexing

From: "Michael Sneed" <[email-masked]>
Date: Wed, 20 Nov 2002 15:17:18 -0500

You have effectively stated the "efficiency" argument for using an integer 
index, and pointed out how this may be more important for the VDSL MIB 
because of the larger number of profile tables.  This was the primary 
argument against using string indices in the past.

I think the most compelling argument FOR the string index, is that anyone 
configuring a device knows the profiles by name, not by index.  And since 
devices may be configured from different applications, eg. from a remote 
high level (network or service) management entity, or via a local CLI that 
may be a minimal local application which is a glorified MIB browser, then 
there is a problem with keeping the name-index mapping consistent across all 
of these applications.  If the mapping is maintained only on the agent, then 
applications must constantly refer to the agent for name or index 
resolution. If the mapping is maintained in multiple applications, then 
there are problems keeping them consistent. If the name IS the index, then 
there is  no such problem.

This affects the impact of the "efficiency" argument.  Eg. if one uses 
integer indices,  for an application to display a line with one of its 
profiles it must GET both the line profile (integer)  and the profile name 
(string). So even though the VARBIND of the profile (integer) is smaller , 
the extra GET is even bigger than the name (string) itself.  If the 
application caches the name-index map there is the danger of inconsistency 
with the device.

I suppose this is primarily an administrative issue.  But it seems like a 
difficult one to manage.

BTW, using a string index also makes reading mib walks a lot easier.

>From: "Bob Ray" <[email-masked]>
>To: "Michael Sneed" <[email-masked]>
>CC: <[email-masked]>
>Subject: RE: [Adslmib] Profile indexing
>Date: Wed, 20 Nov 2002 13:10:55 -0600
>
>
> >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.
>
>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
>
>
>_______________________________________________
>Adslmib mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/adslmib

_________________________________________________________________
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: [email-masked]
Date: Mon, 25 Nov 2002 18:14:01 +0200

Bob,

From our p.o.v.: Keep it as is.

Best regards,
Moti Morgenstern

Senior System Engineer
Inovia Telecoms Ltd.
Member of the ECI Telecom group
30 Hasivim St.
Petach Tikva, Israel 49133
Tel.: +972-3-9266258 Fax: +972-3-9268182
e-mail: [email-masked]

                      "Bob Ray" <rray@                                                                                                 
                      pesa.com>                To:      "Michael Sneed" <[email-masked]>                                        
                      Sent by:                 cc:      <[email-masked]>                                                             
                      adslmib-admin@           Subject: RE: [Adslmib] Profile indexing                                                 
                      ietf.org                                                                                                         

                      25/11/02 18:04                                                                                                   

Are there any opinions from the group on this indexing issue?

Currently, there are three voices/votes:

a) Umberto Bonollo - keep it as is (numeric indices)
b) Mike Sneed - revert to strings
c) Bob Ray - keep it as is

At the IETF meeting, Faye Ly voted to use strings, so
there is a sorta deadlock (2/2).

Randy?  Bert?  Opinions?

Bob Ray

---

From: "Michael Sneed" <[email-masked]>
Date: Mon, 25 Nov 2002 12:04:48 -0500

I am probably beating a dead horse, but what I see is Bob presenting a good 
case for using an integer index on the basis of agent storage requirements.  
I see people agreeing with him.  What I do not see is anyone addressing the 
issue I have raised.

There is another way out of the problems.  Eliminate the profile names from 
the MIB.  Since the consensus is apparently to have the management 
applications translate the name to the integer, why do you need to maintain 
the name at the agent?  It is strictly a user presentation issue, right?  So 
it is just occupying space on the agent, and providing yet another data item 
that can get out of sync.

>From: [email-masked]
>To: "Bob Ray" <[email-masked]>
>CC: [email-masked], [email-masked], [email-masked]
>Date: Mon, 25 Nov 2002 18:14:01 +0200
>
>
>Bob,
>

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail

---

From: "Faye Ly" <[email-masked]>
Date: Mon, 25 Nov 2002 11:04:09 -0800

Mike,

I have a different oponion on the agent implementation of the profile names. 
  There is a danger of supporting profile name in EMS that it can go out of 
sync with the NEs.  This will take a while to sync up all your NEs with your 
EMS wheras profile name in the agent doesn't have this problem.  As for the 
space goes, each NE typically doesn't support more than 4 profiles and 4x32 
is not a big deal with agent's memory (or flash space).  I don't see the 
strong arguement here.

Also don't forget for the agents out there that already support ADSL and 
HDSL MIBs, this is a major head-ache now that profiles are indexed 
differently.

-faye

>From: "Michael Sneed" <[email-masked]>
>To: [email-masked]
>Date: Mon, 25 Nov 2002 12:04:48 -0500
>
>
>  I see people agreeing with him.  What I do not see is anyone addressing 
>the issue I have raised.
>
>the name at the agent?  It is strictly a user presentation issue, right?  
>So it is just occupying space on the agent, and providing yet another data 
>item that can get out of sync.
>
>

---

From: [email-masked]
Date: Mon, 25 Nov 2002 12:03:02 -0800

One vote for using strings:

I appreciate the importance of Bob's comments on the cost of network element resources (size of image, databased, memory, flash), however, it is very unusual to have more than a half dozen service profiles.    Even with advance services (video, voice) around the corner, most access providers follow the "keep it simple" rule, and provide a limited number of choices.    Therefore, I feel that the management of profiles using strings would be an impediment towards product development.

---

From: [email-masked]
Date: Mon, 25 Nov 2002 12:09:29 -0800

Hi all,
Resending... for clarification.

I appreciate the importance of Bob's comments on the cost of network element resources (size of image, database, memory, flash), however, it is very unusual to have more than a half dozen service profiles.    Even with advance services (video, voice) around the corner, most access providers follow the "keep it simple" rule, and provide a limited number of choices.    Therefore, I feel that the management of profiles using strings would NOT be an impediment towards product development.

---

From: [email-masked]
Date: Tue, 26 Nov 2002 09:52:28 +0200

Hi,

Maybe I miss something here but the real problem, as I understand it, is
not the memory resources required for saving strings compared to numeric
indexes.

The real issue is enforcing an upgrade to SNMP version 3. It's clear that
the management of profiles using strings would add a task of upgrading the
agent to SNMPv3. That certainly would be "an impediment towards product
development."

BTW, There's no reason to expect that if the EMS uses numeric indexes then
it can go out of sync with the NEs.  In case the EMS dictates the profile
index (i.e., the unique numeric or textual value) it cannot be changed by
the NE and the type of index doesn't matter. If the NE has also the right
to add/delete or modify the profiles then this may happen regardless of the
profile index type. Why can the EMS/NE change a profile with an index
number 0x4441564500 and it can't perform the same thing if the you
interpret the same value as an index name "DAVE"?

Best regards,
Moti Morgenstern

Senior System Engineer
Inovia Telecoms Ltd.

                      Greg.Bathrick@                                                                                                   
                      nokia.com                To:      <[email-masked]>, <[email-masked]>, <[email-masked]>         
                      Sent by:                 cc:                                                                                     
                      adslmib-admin@           Subject: RE: [Adslmib] Profile indexing                                                 
                      ietf.org                                                                                                         

                      25/11/02 22:09                                                                                                   

Hi all,

I appreciate the importance of Bob's comments on the cost of network
element resources (size of image, database, memory, flash), however, it is
very unusual to have more than a half dozen service profiles.    Even with
advance services (video, voice) around the corner, most access providers
follow the "keep it simple" rule, and provide a limited number of choices.
Therefore, I feel that the management of profiles using strings would NOT
be an impediment towards product development.

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Monday, November 25, 2002 12:03 PM
To: [email-masked]; [email-masked]
Subject: RE: [Adslmib] Profile indexing

I appreciate the importance of Bob's comments on the cost of network
element resources (size of image, databased, memory, flash), however, it is
very unusual to have more than a half dozen service profiles.    Even with
advance services (video, voice) around the corner, most access providers
follow the "keep it simple" rule, and provide a limited number of choices.
Therefore, I feel that the management of profiles using strings would be an
impediment towards product development.

-----Original Message-----
From: ext Michael Sneed [mailto:[email-masked]]
Sent: Monday, November 25, 2002 9:05 AM
To: [email-masked]
Subject: RE: [Adslmib] Profile indexing

issue I have raised.

the name at the agent?  It is strictly a user presentation issue, right?
So
it is just occupying space on the agent, and providing yet another data
item
that can get out of sync.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 26 Nov 2002 11:57:17 +0100

Moti writes:
> The real issue is enforcing an upgrade to SNMP version 3. 

Why is that? using SnmpAdminStrings as index can be used for all
versions of SNMP as far as I know.

> It's clear that the management of profiles using strings would add a 
> task of upgrading the agent to SNMPv3. That certainly would be 
> "an impediment towards product development."
> 
Again, I do not understand why you think that using "strings for indices"
would mandate the use of SNMPv3.

I would also URGE veryone to start using SNMPv3 on new and updated
products. The SNMPv1 and SNMPv2c have been declared Historic
and SNMPv3 is the only version that gives you reasonable security.

Bert

---

From: "Faye Ly" <[email-masked]>
Date: Fri, 29 Nov 2002 16:50:49 -0800

Bert,

Totally agreed and there is no issue supporting SnmpAdminString in SNMPv3.

-faye

>From: "Wijnen, Bert (Bert)" <[email-masked]>
>To: [email-masked], [email-masked]
>CC: [email-masked], [email-masked], [email-masked],   
>[email-masked]
>Date: Tue, 26 Nov 2002 11:57:17 +0100
>
>Moti writes:
> >

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail