The MPLS WG Archive

[Dave Cooper <dcooper@gblx.net>]

Our network is another heavy implementor of MPLS w/ both vendors
in the mix and i'll second Ron's comments on what basic functionality
we need NOW rather than waiting for some all-encomapssing all-vendor
satisfying MIB (if that exists). Basic operational checks into 

LSP transitions via counter
LSP last transition
LSP path changes
LSP explicit route 
LSP record route

All of which have to currently be retrieved using less than 
spectacular methods.  A script ssh'ing to the routers
every N minute doesnt cut it.
 
While both implementations tend to do the same 
thing using different methods, i still think a majority of the 
objects in kireeti's mib can be extended across all implementations.

Bottom line... now is better than later as far as an operator's 
concerned.

-dave 


Ron Bonica said :
> >          What I will assure you of is that the Kireeti-MIB is based on the
> > reality of the Juniper implementation. This is not the reality of what the
> > rest of the world uses. Furthermore, it does not necessarily contain the
> > operational reality of MPLS features that other LSR vendors are currently
> > deploying due to its incomplete nature.
> >
> 
> Tom,
> 
> I am an operator with MPLS deployed in my network. For fault management
> purposes, I need to know the following:
> 
> 	-> which LSPs are broken
> 	-> which LSPs are sub-optimally routed
> 	-> which LSPs have reset
> 
> Using Kireeti's MIB, I can answer these questions by polling the following
> items:
> 
> 	-> mplsLspState
> 	-> mplsPathType
> 	-> mplsLspLastPathChange
> 
> This is pretty simple.
> 
> Couldn't this level of abstraction be applied to any MPLS implementation?
> 
> Please re-orient me if I am missing some very fundamental issue.
> 
>                            Ron
>