The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Jun> msg00121



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

draft-ietf-mpls-lsr-mib-10.txt

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Thu, 19 Jun 2003 11:49:45 -0400
  • Importance: Normal
  • Organization: Cisco Systems


	Someone pointed out to me offline
that I had misinterpreted a question posed
the other day. Here is a snipped from the
thread.

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