The MPLS WG Archive

[Curtis Villamizar <curtis@laptoy770.fictitious.org>]

In message <030401c3369d$1c6df740$ed472ca1@amer.cisco.com>, "Thomas D. Nadeau" 
writes:
> 
> > See below.  A new table is proposed to make it efficient to 
> > do an SNMP traceroute using the LSR MIB.  What is needed is a 
> > way to find the index (mplsInSegmentIndex) for a given 
> > interface and label that is determined from the outsegment on 
> > the prior LSR.  The interface MIB on both routers may be 
> > needed to get the ifindex of the other router.
> 
> 	Being one who advocated the original change
> to the indexing, I can live with the addition of a
> mapping table and the indexing currently in v10 of 
> the MIB.
>  
> > Note that even with this change the LSR MIB does not have 
> > enough information by itself to do the traceroute.
> 
> 	Yes, there is a need to use the application-
> specific MIBs to know where to start (i.e.: VPN,
> or FTN).
> 
> 	--Tom


Tom,

I wasn't clear in my second comment.

The LSR MIB is used for RSVP/TE as well as LDP.  For both getting the
ifindex of the next hop interface requires using the interface MIB.

For TE you'd want to trace an LSP from ingress to egress starting with
the outgoing interface, label, and any other information available at
the ingress.  One peice of information that is not available to the
ingress is the ifindex of the next-hop interface (unless the interface
is unnumbered).  The NMS can't get from the ingress any information
the ingress does not have.  It can get the IP address of the next hop
and all next hops from the RRO (via the MIB).  Using the interface
addresses the ifindex can be determined.

If you are tracing a given FEC I think the same is true, the ifindex
is not normally known by the downstream node but the interface IP
address is.  The outsegment ifindex in the LDP MIB is for the current
LSR just as the LSR MIB outsegment ifindex is for the current LSR.
There is no direct way to get the ifindex of the next-hop other than
looking at the mplsLdpPeerTransportAddr and looking that up that
address in the interface MIB on the peer.

I don't percieve this as a serious problem, however it is worth noting
and a possible manageability improvement for either RSVP/TE or LDP
would be to provide the ifindex in the signaling just for management
purposes.  For example, an optional suboject in the RRO could contain
the ifindex of the prior IPv4 or IPv6 address subobject or new
subobjects could be introduced which give both the address and
ifindex.  A similar change could be made to LDP.  The other side
ifindex could then be populated in the LSR MIB if known and the LSR
MIB alone could support a traceroute.

It is also worth noting that it is impossible to trace an LSP
backwards but it could be a worthwhile capability.  For example, if
inseg on a given LSR had a consistent zero traffic and no apparent
purpose it might be worth bein able to trace it back to see if it was
the remnant of a software problem (or errant MIB set if someone were
foolish enough to configure routers with MIB sets :^).

Curtis


[...trimmed...]
> > > > I suggest you keep the index as you now have it and add a table:
> > > > 
> > > >   mplsInSegmentLocate
> > > >     SYNTAX	MplsInSegmentLocate
> > > >     [...]
> > > > 	INDEX { mplsInterfaceLocate,  -- InterfaceIndexOrZero
> > > > 		mplsInSegLabelLocate  -- MplsLabel
> > > > 	        }
> > > >   ::= [...]
> > > > 
> > > >   MplsInSegmentLocate ::= SEQUENCE {
> > > >     mplsInterfaceLocate			InterfaceIndexOrZero,
> > > >     mplsInSegLabelLocate		MplsLabel,
> > > >     mplsInSegmentLocate			MplsIndexType
> > > >   }
> > > > 
> > > > This table would just return the mplsInSegmentIndex.