The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

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.

Note that even with this change the LSR MIB does not have enough
information by itself to do the traceroute.

Curtis


In message <02e701c3368d$d23408e0$ed472ca1@amer.cisco.com>, "Thomas D. Nadeau" 
writes:
> 
> 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:curtis@fictitious.org] 
> > Sent: Thursday, June 19, 2003 12:00 PM
> > To: tnadeau@cisco.com
> > Cc: curtis@fictitious.org
> > Subject: Re: draft-ietf-mpls-lsr-mib-10.txt 
> > 
> > 
> > 
> > In message <02cc01c33679$e3834700$ed472ca1@amer.cisco.com>, 
> > "Thomas D. Nadeau" 
> > writes:
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Curtis Villamizar [mailto:curtis@fictitious.org]
> > > > Sent: Wednesday, June 18, 2003 11:05 AM
> > > > To: tnadeau@cisco.com
> > > > Cc: curtis@fictitious.org
> > > > Subject: draft-ietf-mpls-lsr-mib-10.txt
> > > > 
> > > > 
> > > > 
> > > > In message <021c01c3342d$f774b760$6401a8c0@amer.cisco.com>,
> > > > "Thomas D. Nadeau" 
> > > > writes:
> > > > > 
> > > > >  
> > > > > > For the traceroute capabiility to work, there has to 
> > be a way to 
> > > > > > take the outgoing label out of the 
> > mplsOutSegmentTopLabel on the 
> > > > > > previous LSR and find the MplsInSegmentEntry on the 
> > next LSR.  
> > > > > > Have we broken this?  If so that would be a problem.
> > > > > 
> > > > > 	No, this still works the same way with an octet string.
> > > > Remember, an
> > > > > octet string is just a series of bytes. If you make it 4
> > > > bytes, then
> > > > > it behaves the same as the unsigned32 did, if you make 
> > it more you
> > > > > have the same interactions.
> > > > > 
> > > > > 	--Tom
> > > > 
> > > > 
> > > > If I wanted to find a specific interface and label (that I
> > > > got from the outsegment on the prior router) I'd use:
> > > > 
> > > > We don't know the mplsInSegmentIndex.  We just know the
> > > > mplsInSegmentLabel and mplsInSegmentInterface.  It may be a 
> > > > per platform label or per interface label (we don't know)>
> > > > 
> > > > What do we put in a get or getnext to quickly get the
> > > > mplsInSegmentEntry?  Walking the table won't do.
> > > 
> > > 	Reading the original question again, I see that I
> > > missed the question's point in my response. Thanks Curtis.
> > > So to answer the original question, yes, the tracing capability 
> > > is altered and broken by the new indexing, and now I see that we 
> > > may have gone overboard with the octet string as an index in the 
> > > InSegment table. It seems that for only the inSegmentTable, it 
> > > will be useful to use (ifIndex, inSegmentLabel). The big issue
> > > for me personally is to be able to have extended indexing
> > > available for originating segments, which is why I feel
> > > strongly that we still need the octet string index on the
> > > XC and outSegment tables. I have discussed this in private
> > > with the co-authors and a few others and they agree that
> > > the following indexing should now handle all fo the
> > > cases.
> > > 
> > > 	MplsInSegmentTable
> > > 		INDEX { mplsInterfaceIndex, -- InterfaceIndexOrZero
> > > 		        mplsInSegmentLabel  -- MplsLabel 
> > > 			}
> > > 
> > > 	MplsXCTable
> > > 		INDEX { mplsXCIndex,        -- MplsIndexType
> > > 			  mplsInterfaceIndex, -- InterfaceIndexOrZero 
> > > 		 	  mplsInSegmentLabel, -- MplsLabel
> > > 			  mplsOutSegmentIndex -- MplsIndexType
> > > 			}
> > > 
> > > 	MplsOutSegmentTable
> > > 		INDEX { mplsOutSegmentIndex -- MplsIndexType
> > > 			}
> > > 
> > > 	--tom
> > 
> > 
> > Tom,
> > 
> > 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.
> 
> 	I am okay with this, as it keeps things simpler
> from my perspective at least.  Please reply to my posting 
> to the MPLS mailing list and propose that.
> 
> 	--Tom
> 
> > 
> > Curtis