The MPLS WG Archive

[Len Nieman <Len.Nieman@mci.com>]

Response 'in-line'

>Date: Wed, 11 Jun 2003 22:35 -0400 (EDT)
>From: Curtis Villamizar <curtis@fictitious.org>
>To: "Natale, Robert C (Bob)" <bnatale@lucent.com>
>CC: tnadeau@cisco.com,
>    'MPLS WG' <mpls@UU.NET>
>Sender: owner-mpls@UU.NET
>Reply-to: curtis@fictitious.org
>Subject: Re: prequeal to WG lat call om the LSR mib module
>
>
>In message <305D2EAC01C45448A7F3ECC487666F6C076569D7@md6370exch004u.nse.lucent.
>com>, "Natale, Robert C (Bob)" writes:
>> Hi Tom,
>> 
>> I appreciate your extensive implementation
>> experience and your willingness to share
>> your analysis with the group.  However, I
>> strongly support Adrian's position on the
>> issue of read-write objects in this (and
>> most other) MIB.
>> 
>> The question "Is anyone really using it
>> for provisioning anyway?" appears to be
>> of the chicken/egg quandary type.  Well,
>> now we have a "chicken" (so to speak!)
>> in SNMPv3...let's have it give birth to
>> lots of useful agents and applications.
>> 
>> The concept of producing a separate
>> "Provisioning MIB" has its own merits
>> when one means by that a higher-order
>> MIB that would focus more on logical
>> or service kinds of entities rather
>> than specific transport level atomic
>> objects.  However, such an endeavor
>> should not, IMHO, obviate the need
>> for and value of Set-ability of
>> appropriate objects in lower-order MIBs.
>> 
>> Cheers,
>> 
>> BobN
>
>
>Bob, 
>
>I've been on the provider side of this and quite a long time ago Bay
>networks made every aspect of their provisioning available in the MIB
>and we found that completely *unacceptable* for various technical
>reasons, some of which go away with SNMPv3, others which may not.
>
>Router configurations can be huge and changes need to be atomic.  The
>old way to do this was to do sets, then gets to verify the sets.  This
>was excruciatingly slow and was not atomic.  Bulk sets may go a long
>way toward solving this.  Even so, MIB dumps are barely human
>readable.  There needs to be ways to generate configurations but also
>ways for operators to read and eaily understand the configuration and
>change them if needed.  A read-write MIB is poorly suited for this.
>
>At this point I'm on the provider side of things and I'm not hearing
>anyone that is running a network saying they want to configure their
>network with SNMP.  All our MIBs are read-only and no customer
>considers that a problem.
>
>Given that situation we don't care if the IETF is defining MIBs to be
>read-write or read-only.  We are implementing them read-only, advising
>customers of that and not a single customer is complaining about it.
>If they complain, we'll change but they haven't.
>
>Curtis
>

Curtis,

I'm on the 'transport side', as Adrian put it, and started in Frame
Relay "back when" provisioning Bay BSN's by manually typing in 'set'
commands. Even so, I have to agree with Adrian and Bob on this one.

When all MIBs are only available as read-only, the network management
solutions end up being vendor proprietory. Which means in a large
multivendor network, the network management folks end up 'swivel
chairing' between systems.

This means additional training costs getting people up to speed on each
system, additional development and licensing costs for proprietary APIs
needed to build interfaces from order entry/automatic provisioning
systems, and possibly additional hardware costs for the servers that the
vendors solution has to reside on. 

Most of this can be avoided when MIBs are read-write. Using the MIBs
allows a standard 'front end' to be built for the network managers,
while vendor specific idiosyncrasies are handled in the background by
the system.

Actually, you seem to have provided the 'solution' in your last paragraph.
Let the MIBs be read-write and if a provider wants to disable the write
capability in their implementation, let them as long as they're up front
with their customers about it.

Len Nieman