The MPLS WG Archive

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

> 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




> 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
>