logo       
Google Custom Search
    AddThis Social Bookmark Button

RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble]: msg#00083

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.

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)

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.
  

Thanks,
sanjay                
         
    

> -----Original Message-----
> From: Shevenell, Michael (Mike) [mailto:mshev@xxxxxxxxxxx]
> Sent: Thursday, June 12, 2003 10:11 AM
> To: 'tnadeau@xxxxxxxxx'; 'Choudhury, Sanjaya'; mpls@xxxxxx
> 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@xxxxxxxxx]
> Sent: Wednesday, June 11, 2003 10:35 AM
> To: 'Choudhury, Sanjaya'; mpls@xxxxxx
> Subject: RE: prequeal to WG lat call om the LSR mib
> module[mplsInSegmentTable]
> 
> > -----Original Message-----
> > From: owner-mpls@xxxxxx [mailto:owner-mpls@xxxxxx] On Behalf 
> > Of Choudhury, Sanjaya
> > Sent: Tuesday, June 10, 2003 12:06 PM
> > To: 'mpls@xxxxxx'
> > 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@xxxxxxxxx]
> > > 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@xxxxxx [mailto:owner-mpls@xxxxxx] 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
> 
> 




Try Searching:
servers, voip, java, networking, microsoft ...
<Prev in Thread] Current Thread [Next in Thread>