The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

>Perhaps we are forgetting what problem we are trying to solve here? It
>supports a very limited and yet very operationally focused model. By a
>very strange coincidence it is what the operators seem to be asking for.

         This is only what a certain subset of operators are looking for.
The operators who are using the MPLS-TE-MIB which I have spoken to
are very happy with it. I believe this set to be much larger than
the 3 or 4 who seem to want to use Kireeti's MIB to completely manage
their MPLS LSRs.

>Yet strangely enough, for almost all purposes which I would need to run a
>network, the simple and spare kireeti MIB suffices.

         Yet strangely enough, it only suffices for networks which are
comprised of Juniper switches. Funny how that is, since it is
the Juniper proprietary MIB. I am sure that you would have the
same success with vendor X's proprietary MIBs as well.

>Just because I can
>solve some obscure corner case using the generic MIB does not mean I want
>to build a large annoying backend to support solving that corner case.
>Operational reality is that 90% of most MIBS are never used and I do not
>want to hold up my network waiting till all parties are happy with a
>solution.

         I hardly belive that fast-reroute, auto-bandwidth tunnels,
fast-reroute, tunnel path options, ER-LSPs, tunnel interface
statistics, etc.. are obscure problems. These may be obscure vapor
ware in the limited implementation from the vendor which you are
deploying LSRs from, but not in others that I know of.

         --Tom