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

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Fri, 13 Jun 2003 09:07:21 -0400

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:[email-masked]]
> Sent: Thursday, June 12, 2003 10:11 AM
> To: [email-masked]'; 'Choudhury, Sanjaya'; [email-masked]
> 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:[email-masked]]
> Sent: Wednesday, June 11, 2003 10:35 AM
> To: 'Choudhury, Sanjaya'; [email-masked]
> Subject: RE: prequeal to WG lat call om the LSR mib
> module[mplsInSegmentTable]
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf 
> > Of Choudhury, Sanjaya
> > Sent: Tuesday, June 10, 2003 12:06 PM
> > To: [email-masked]'
> > 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:[email-masked]]
> > > 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: [email-masked] [mailto:[email-masked]] 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
> 
>

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 16 Jun 2003 15:25:45 +0200

> the GetNext() works perfectly with the original indexing

With the currently proposed Indexing this seams not be easily possible to 
do anymore (and it has nothing to do with provisioning). Sure you can read 
the full table.

> and indexing does not matter.

Exactly.

Marcus

>> it has little to do with my specific style of implementation

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 16 Jun 2003 14:05:20 -0400

> Sent: Friday, June 13, 2003 9:07 AM
> To: [email-masked]

>      indexing of the mplsInSegmentTable.

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

> the GetNext() works perfectly with the original indexing

	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.

> 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

> > 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
> > > > > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > > > > Wijnen, Bert (Bert)

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 17 Jun 2003 08:36:25 -0400

> With the currently proposed Indexing this seams not be easily 
> possible to do anymore (and it has nothing to do with provisioning). Sure 
> you can read the full table.

	If you still think this is a problem 
you are free to encode the first 4 bytes as an 
ifIndex. However, it has been my experience that 
this is not as useful as you might think. More often
than not insegments of deployments use the per-platform 
label space. This means that it is likely that an 
implementation will accept all labels from the 
per-platform label range on all interfaces
using that label range, thus it is more efficient
to use the ifIndex=0 scheme as is specified in
the older versions of the MIB to handle the majority
of cases.  This amounts to (ifIndex=0, insegmentIndex = *), 
which is in effect the same as just using insegmentIndex
and first looking at the interfaces in that label
range in the InterfaceTable. 

> > and indexing does not matter.

	See above.

	--Tom

> >> the getnext performance of the current mplsXCTable is so slow that 
> >> its practically unreadable in any reasonably sized network.
> >>
> >> 	Mike Shevenell
> >> > From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> >> > Choudhury, Sanjaya
> >> > > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >> > > > Wijnen, Bert (Bert)
> >> 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
> >>
> >>
> 
> 
>