The MPLS WG Archive

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

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org] 
> Sent: Friday, June 13, 2003 11:17 AM
> To: Shevenell, Michael (Mike)
> Cc: 'tnadeau@cisco.com'; 'Choudhury, Sanjaya'; mpls@UU.NET
> Subject: Re: prequeal to WG lat call om the LSR mib 
> module[mplsInSegmentTa ble] 
> 
> 
> 
> In message 
> <B73E9D3A15E6D6118DFD00065B3A449A8953DE@amt-exc4.aprisma.com>,
>  "Shev enell, Michael (Mike)" writes:
> > As a provider of management solutions... We'd "prefer"
> > to have a simple solution but we MUST have a working solution. 
> > Although the proposed change makes the instancing a bit 
> more complex, 
> > the getnext performance of the current mplsXCTable is so 
> slow that its 
> > practically unreadable in any reasonably sized network.
> > 
> > 	Mike Shevenell
> > 	Aprisma Management Technologies
> 
> 
> It may be that the only practical way to use the 
> mplsInSegmentTable is in network verification tool in which 
> an SNMP trace of a specific LSP is done.  A reasonable 
> strategy would be to trigger this form of traceroute (plus 
> MPLS-ping if you wanted to verify forwarding too) any time a 
> trap indicates the LSP may have rerouted, plus periodically. 
> This assures that a low background of sanity checking is 
> going on and that changes are checked promptly.

	Indeed many people are using my implementation 
for just this reason due to the size of the information
contained therein.

> I'm not sure that dumping the mplsXCTable makes a whole lot 
> of sense in any practical context except if you are 
> explicitly setting up inseg and outseg with the MIB which no 
> one seems to be doing.

	The XCtable in a fully populated "P" router gets
quite large. Remember, the TFIB in many cases, is a
direct reflection of the FIB in size.
 
> If changes to the indexing of mplsInSegmentTable make it more 
> difficult to do this form of traceroute, then we may need to 
> go back to the Unsigned32 index.

	Changing the index to a string gives you the same
semantics as the Unsigned32, but with possibly (much)
faster performance. BTW, I don't think that Mike was
in favor of returning to the Unsigned32; rather he was
in favor of the new octet string indexing.
 
> 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

> 
> Curtis
> 
> 
> 
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > Sent: Wednesday, June 11, 2003 10:35 AM
> > To: 'Choudhury, Sanjaya'; mpls@UU.NET
> > Subject: RE: prequeal to WG lat call om the LSR mib 
> > module[mplsInSegmentTable]
> > 
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf
> > > Of Choudhury, Sanjaya
> > > Sent: Tuesday, June 10, 2003 12:06 PM
> > > To: 'mpls@UU.NET'
> > > Subject: RE: prequeal to WG lat call om the LSR mib 
> > > module[mplsInSegmentTable]
> > > 
> > > 
> > > Hi! Few comments in-line regarding the indexing of the
> > > mplsInSegmentTable
> > > 
> > > > -----Original Message-----
> > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > > > Sent: Saturday, June 07, 2003 9:13 AM
> > > > To: 'Wijnen, Bert (Bert)'; 'MPLS WG'
> > > > Subject: RE: prequeal to WG lat call om the LSR mib module
> > > > > -----Original Message-----
> > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On 
> Behalf Of 
> > > > > Wijnen, Bert (Bert)
> > > > > Sent: Friday, June 06, 2003 11:14 AM
> > > > > To: MPLS WG
> > > > > Subject: RE: prequeal to WG lat call om the LSR mib module
> > > > > 
> > > >
> > > <snip...>
> > > 
> > > stuff deleted...
> > 
> > 	The problem with designing in the ideal is that
> > real implementations will have issues with it. The
> > IETF generally considers implementation and deployment
> > experience highly over the ideal. I have provided some 
> > real world feedback that indicates that a single Unsigned32 
> > index is insufficient. I also have about 300 customers 
> > that have provided me with the same feedback. I think that
> > it has little to do with my specific style of implementation
> > either (see below).
> > more stuff deleted..
> > 
> > 	--Tom
> > 
> > 
>