The MPLS WG Archive

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

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
> Of Choudhury, Sanjaya
> Sent: Friday, June 13, 2003 9:07 AM
> To: mpls@UU.NET
> Subject: RE: prequeal to WG lat call om the LSR mib 
> module[mplsInSegmentTa ble]
> 
> 
> Hi! I am open to all changes that will make the MIB 
> efficient for users, but I think it is not a bad 
> idea to examine the alternative solutions. Here 
> are some thoughts:
> 
> Some of the cases, where NMS might use a GetNext()
> on mplsInSegment table:
> -------------------------------------------------
> 
> Case-1:: If the aim of the NMS is to get the next 
> 'best/free' label, to configure the next mplsInSegment,
> then he may encounter a (potential) O(n) search of
> the mplsInSegmentTable.
>     
>      We can resolve this issue, by adding a new table:
>      mplsNextFreeLabelTable [indexed by ifIndex]
> 
> 	  If ifIndex == 0 : the row indicates the 
> 	  next free platform-label-space label
> 
> 	  If ifIndex !=0  : the row indicates the 
> 	  next free interface-label-space label for
> 	  the specified interface.

>      This solution, will address the efficiency
>      issue, without compromising the natural
>      indexing of the mplsInSegmentTable.

	I disagree. It seems that you consider 
the old indexing efficient, which I clearly do not.

> Case-2: If the aim of the NMS is to show/list all 
> the incoming-mpls-segments, on a per-interface basis, 
> the GetNext() works perfectly with the original indexing
> (ifIndex,label)

	Only for a non-distributed implementation.
Please see prior threads as to why this works at
best O(N), and is more likely O(N^2) on distributed
implementations.

> Case-3: If the aim of the NMS is to show ALL the
> incoming segments or access ALL the incoming
> segments, he will need to walk the whole table
> and indexing does not matter.

	Indexing always matters! If I care about this
case and can walk the entire table in 1 hour versus
2-4 minutes, that makes a BIG difference.  The 
compromise that Adrian and I sent out addresses 
all of these concerns AND is efficient.

	--Tom

 
> Thanks,
> sanjay	  	      
> 	 
>     
> 
> > -----Original Message-----
> > From: Shevenell, Michael (Mike) [mailto:mshev@aprisma.com]
> > Sent: Thursday, June 12, 2003 10:11 AM
> > To: 'tnadeau@cisco.com'; 'Choudhury, Sanjaya'; mpls@UU.NET
> > Subject: RE: prequeal to WG lat call om the LSR mib 
> > module[mplsInSegmentTa ble]
> > 
> > 
> > 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
> > 
> > -----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
> > 
> > 
>