Subject: [Diffserv] Re: snmpconf FW: November Milestones

From: Randy Bush <[email-masked]>
Date: Sun, 03 Dec 2000 21:21:06 -0800

[ operator hat only ]

we do a LOT of reads, so many that we have to gang boxes to do them, and
write tools to manage the poller array.

if we were to do snmp config, i presume it would be FAR fewer operations
than the polls and other gets.

randy

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Andrew Smith <[email-masked]>
Date: Sun, 03 Dec 2000 21:07:31 -0800

From a thread from the snmpconf WG:
 > Jon wrote:
 >> Configuration is the heart of management. To the extent MIB Documents
 >> are created in each of the different technology areas such as routing or
 >> differentiated services (which is the right place), they should be
 >> designed for full coverage including configuration. There is no excuse
 >> not to.
 >
Randy wrote:
 > i do not intend to discourage those who wish to design for write from doing
 > so.  but i am not sure i see a need to mandate it when doing so would cause
 > complexity or architectural change.  and i believe that, and only that, was
 > the question (in the tewg) that [re]started this rathole.
 >
 > randy

Randy's point is well made - I don't think it is a rathole - and is directly 
relevant to the MIB/PIB/snmpconf/DSMON discussions for diffserv management. In 
the various iterations of the diffserv MIB we have veered between extremes of 
optimise-for-read and optimise-for-configure without, I think, a clear idea of 
why. The -04 version tended towards the former whilst the latest incarnation 
(-06) veers back towards the latter in the interests of consistency with the PIB 
work and the "template" concept for the diffserv policy MIB (snmpconf WG). 
Should we treat these as valid reasons to sacrifice read performance or should 
we find another way to optimise opbjects for configuration e.g. by duplication 
(indexing of same information in multiple ways)? Right now, I believe the -06 
MIB does cause additional complexity for reading.

Andrew

---

From: Jon Saperia <[email-masked]>
Date: Mon, 04 Dec 2000 08:46:21 -0500

> MIB does cause additional complexity for reading.

It is often the case that read only MIB documents are not well designed
in a number of respects. Relevant to this discussion is that the indices
are often created with implementation ease in mind. It is more difficult
to implement a table with multiple indices (regardless of basic
technology) than to use simple integer index values. This is true
whether the objects are read only or read write.  This poor design,
while easy for software engineers, causes unnecessary data collection
overhead since it is more difficult to 'scope' what you want to retrieve
(Randy indirectly alluded to this in a previous post). In some cases,
the design makes it quite difficult not mater how much data you collect
to understand what it means in terms of the configuration.

My view is that the additional complexity for configuration will pay off
in terms of better quality data and less data movement. This is not to
say -06 is just right, there are other who can  better assess that. My
point is that it is worth the work.

/jon

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Dec 2000 11:55:58 -0600

> MIB does cause additional complexity for reading.

Personal opinion: this is a tough call but my computer scientist instincts
are for the consistency argument, i.e. the present approach.

  Brian

---

From: "Andrea Westerinen" <[email-masked]>
Date: Sun, 10 Dec 2000 20:52:06 -0800

Some of the info modeling work may be pertinent here.  Some of the models
separate state and current operational data from configuration information.
The latter is described by Setting classes and collected into Configuration
aggregations.  You can send clearly defined Setting classes and instances to
a device.  You can "apply" these Settings to a device and/or its components.
You can retrieve (read mostly) current state/operational data from other
classes and instances.

Just FYI...

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Jon Saperia
Sent: Monday, December 04, 2000 5:46 AM
To: [email-masked]
Cc: diffserv; Randy Bush
Subject: Re: snmpconf FW: November Milestones

/jon