The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <0HGD00E04FBXBX@pmismtp05.wcomnet.com>, Len Nieman writes:
> 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.luce
> nt.
> >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. 

We were generating configs for gated, cisco and bay and it was far
preferable to write a backend for three human readable config syntax
than one MIB beside the problems with distributing MIB sets.  I wrote
this sort of code for a provider and the rtconfig tool set is such an
example of a free tool for RPSL to various config syntax (Cisco,
Juniper).

In the router world the config syntax have not been that big and more
than one is undesireable but preferable to MIBs.  If anything I've
seen more interest in the idea of configuring using XML, though no
requests so far, than in configuring with MIBs.

> 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

To be honest with you, I see by your signature that you're with MCI
and there are other people in Worldcom that don't share your opinion
on this.  That is for Worldcom/MCI/UUNET to resolve.  We speak here in
the IETF as individuals and your opinion counts as much as anyone's.

There seems to be two approaches to configuring ATM and FR service.
One is to have an offline NMS set the low level switch mappings.  Many
providers with legacy ATM and FR switches seem to have done this.  The
preference among ISPs using MPLS has been to use dynamic routing and
configure only the MPLS LSP requirements (constraints) at the ingress.
Where we are now is providers want to offer ATM and FR service over
MPLS and there are clearly two groups in many providers that are
starting to do this.  One group wants to set inseg/outseg with the MIB
arguing that it is what they've always done.  The other wants setup on
the ingress and points out that ATM and FR will be a small minority of
traffic and configuring the ingress has proven more reliable.

Maybe you are right.  The IETF can't decide that internal argument for
the providers.  For now the MIB needs to be read-write.  Providers
need to resolve this internally and tell their vendors whether they
need read-write or read-only.  This argument may go on as long as the
cells vs packets argument that raged almost a decade ago.  If it
resolves as many of of think it will, we can go with read-only but at
this point it is not resolved.

Curtis