[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf Re: TE-MIB readonly or read/write
> > I think we have a clear consensus among those that have recently
> > commented.
> the tyranny of the verbose and stubborn? :-)
> > Define the MIB module completely including configuration/control
> > objects. There are plenty of standard mechanisms by which vendors and
> > users can use less than the full set of capabilities.
> in light of the ccamp mandated separation of measurement and control
> planes, this rush to judgement might take a bit of a pause.
Randy, I was confused by by your comment so I double checked with Scott
Bradner to verify my understanding. I believe that the separation you
point to is part of a three part plane of management and control
functions. There is a desire to standardize two of the three.
1. The first, and lowest layer in this view, is the box to
box control protocol. A request to set up a new path, for
example. Two cooperating devices would use the protocol to
request a new path establishment and probably report certain
conditions to the operational software. Using a routing
analogy, this would be the exchange of LSAs. Clearly there is
benefit to the standardization of such things.
2. The second plane is the 'brains of the operation'. This is
the portion that Scott and others believe is best left
un-standardized. It is at this layer, that the decision about
whether to ask for a new path is made. One vendor may have
better heuristics than another and thus might distinguish
themselves. Interoperability is not compromised in this
regard since the two systems use the layer I described above
to communicate the request for a new path.
3. The third plane, and the one that is the only subject for
the MIB Modules under discussion is the management
plane. This plane has objects for the configuration and
control of the behavior of the system. These controls are
interpreted by the brains with the resulting behavior on the
wire. Also it is at this layer that one would write MIB
objects for usage counters and errors for example.
I believe the "Define the MIB module completely including
configuration/control objects." statement was intended to address only
the third plane. The plane that is historically in the management
domain. People want to be sure that the interfaces to the external world
are standardized, planes one and three, while the middle one is left
open for vendor innovation. This approach could equally be applied to
routing protocols or other areas of technology.
If we are in agreement on these points, then there is no issue unless
do not want configuration and control objects in the MIB Module(s).