The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Jun> msg00100



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Tue, 17 Jun 2003 08:36:25 -0400
  • Importance: Normal
  • Organization: Cisco Systems
  • X-MIME-Autoconverted: from quoted-printable to 8bit by cell.onecall.net id h5I3sb807255


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

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

	See above.

	--Tom

 
> Exactly.
> 
> Marcus
> 
> >
> > 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
> >>
> >>
> 
> 
> 
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: brunner@ccrle.nec.de
> 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
> 
> 
> 
> 
>