The MPLS WG Archive

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

Comments in-line. 

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Monday, June 16, 2003 2:05 PM
> To: 'Choudhury, Sanjaya'; mpls@UU.NET
> Subject: RE: prequeal to WG lat call om the LSR mib
> module[mplsInSegmentTa ble]
> 
> 
> 
> 
> > -----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.
	
         Here I was just trying find an alternative solution
	   to the proposed index change for the 
	   mplsInSegmentTable.

	   [Note: Here we are talking about case-1 as described above.]

	   o Do you agree that the solution I proposed 
	   provides the users of mplsInSegmentTable
	   with an efficient solution for looking up
	   the next free/best label [O(C)] ?

	   o With the solution proposed in the latest
	   version of LSR-MIB, user for case-1 might 
	   get the similar efficiency (as the one 
	   I proposed); BUT it depends on the vendor
	   implementations. 
	   Unless, everybody implement the mplsInSegmentIndex
	   the same way, user will face the same inefficiencies.

	   o I think the solution I proposed has the
	   following advantages:
		(i) the solution does leaves the index
		as is [ifIndex,label], which is natural
		for the mplsInSegmentTable
		(ii) the solution is implementation 
		independent [does not depend on the way
		a vendor implements the new mplsInSegmentIndex]
	     
> 
> > 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.
> 
	Note that the case-2, is addressing the case 
      where the NMS is trying to display the insegments
      on a *per-interface* basis. 

	  o When NMS is trying to display/query insegments
	    on a per-interface basis, don't you think a 
	    (ifIndex,label) index is perfect ??

	  o The worst case here is for a node that supports
	  only per-platform labels i.e O(n). But this 
	  worst case number is same for both the solutions
	  (proposed in LSR-MIB-v10 and in this e-mail)
	
	  o In distributed cases, it may be O(n) * num-app
	  in the worst case. 

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

   Please note: Case-3 captures the case where the 
   user is NMS is trying to show _ALL_ the insegments.

	o If a table has n rows and one wants to 
	query all the n rows, the cost will be 
	O(n). Correct ?

	o How can I query _ALL_ the n rows from a table
	more efficiently by the choice of indexing??
	[i.e better than O(n)]	
	
  Thanks,
  sanjay
	

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