The MPLS WG Archive

["Choudhury, Sanjaya" <Sanjaya.Choudhury@marconi.com>]

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Thursday, June 19, 2003 11:50 AM
> To: 'MPLS WG'
> Subject: RE: draft-ietf-mpls-lsr-mib-10.txt
> 
> 
> 
> 	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 
> 			}
> 

	I agree that it is a good idea to leave the indexing
	of the mplsInSegmentTable as defined above.


> 	MplsXCTable
> 		INDEX { mplsXCIndex,        -- MplsIndexType
> 			  mplsInterfaceIndex, -- InterfaceIndexOrZero 
> 		 	  mplsInSegmentLabel, -- MplsLabel
> 			  mplsOutSegmentIndex -- MplsIndexType
> 			}
> 
	Since the mplsXCIndex was already an opaque index, personally
	I don't see any problems with this change.

> 	MplsOutSegmentTable
> 		INDEX { mplsOutSegmentIndex -- MplsIndexType
> 			}
> 
	Since the mplsOutSegmentIndex was already an opaque index,
	I don't see any problems in this change. However, I do have
	the following suggestion:

	Seems that the primary reasons for changing the outsegment
	index, was to do with finding the next best label for the 
	output side (search through the input table and then the 
	output table).

	Here again, I will suggest that you consider adding a 
	NextFreeLabelTable (that indicates the next free ingress/
	egress label). This will eliminate the need for the index
	change and allows provisioning applications to determine 
	the next free label in O(1) operations -No MIB walks
	necessary. 

	Thanks,
	sanjay

> 	--tom
>