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

From: "Shevenell, Michael (Mike)" <[email-masked]>
Date: Thu, 12 Jun 2003 10:11:02 -0400

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: "Adrian Farrel" <[email-masked]>
Date: Thu, 12 Jun 2003 12:29:04 -0400

Hi Mike,

> unreadable in any reasonably sized network.

Not sure what you're saying here with regard to the getnext performance.

It is of the nature of a complex network (or more precisely, a busy switch) that
it has a lot of cross-connect information. You want to read all of the
information, but there is a lot of information.

It would, presumably, be possible to aggregate the information so that it can be
read in one block not row by row. Is this what you're talking about?

How does this compare with your experience of using MIB modules to manage ATM
equipment?

Adrian

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 13 Jun 2003 11:17:14 -0400

In message <[email-masked]>, "Shev
> 	Aprisma Management Technologies

It may be that the only practical way to use the mplsInSegmentTable is
in network verification tool in which an SNMP trace of a specific LSP
is done.  A reasonable strategy would be to trigger this form of
traceroute (plus MPLS-ping if you wanted to verify forwarding too) any
time a trap indicates the LSP may have rerouted, plus periodically.
This assures that a low background of sanity checking is going on and
that changes are checked promptly.

I'm not sure that dumping the mplsXCTable makes a whole lot of sense
in any practical context except if you are explicitly setting up inseg
and outseg with the MIB which no one seems to be doing.

If changes to the indexing of mplsInSegmentTable make it more
difficult to do this form of traceroute, then we may need to go back
to the Unsigned32 index.

For the traceroute capabiility to work, there has to be a way to take
the outgoing label out of the mplsOutSegmentTopLabel on the previous
LSR and find the MplsInSegmentEntry on the next LSR.  Have we broken
this?  If so that would be a problem.

Curtis

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 16 Jun 2003 13:37:26 -0400

> From: Curtis Villamizar [mailto:[email-masked]] 
> Sent: Friday, June 13, 2003 11:17 AM
> To: Shevenell, Michael (Mike)
> Cc: [email-masked]'; 'Choudhury, Sanjaya'; [email-masked]
> Subject: Re: prequeal to WG lat call om the LSR mib 
> module[mplsInSegmentTa ble] 
> 
> 
> 
> In message 
> <[email-masked]>,
>  "Shev enell, Michael (Mike)" writes:
> > 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
> It may be that the only practical way to use the 
> mplsInSegmentTable is in network verification tool in which 
> an SNMP trace of a specific LSP is done.  A reasonable 
> strategy would be to trigger this form of traceroute (plus 
> MPLS-ping if you wanted to verify forwarding too) any time a 
> trap indicates the LSP may have rerouted, plus periodically. 
> This assures that a low background of sanity checking is 
> going on and that changes are checked promptly.

	Indeed many people are using my implementation 
for just this reason due to the size of the information
contained therein.

> I'm not sure that dumping the mplsXCTable makes a whole lot 
> of sense in any practical context except if you are 
> explicitly setting up inseg and outseg with the MIB which no 
> one seems to be doing.

	The XCtable in a fully populated "P" router gets
quite large. Remember, the TFIB in many cases, is a
direct reflection of the FIB in size.
 
> difficult to do this form of traceroute, then we may need to 
> go back to the Unsigned32 index.

	Changing the index to a string gives you the same
semantics as the Unsigned32, but with possibly (much)
faster performance. BTW, I don't think that Mike was
in favor of returning to the Unsigned32; rather he was
in favor of the new octet string indexing.
 
> For the traceroute capabiility to work, there has to be a way 
> to take the outgoing label out of the mplsOutSegmentTopLabel 
> on the previous LSR and find the MplsInSegmentEntry on the 
> next LSR.  Have we broken this?  If so that would be a problem.

	No, this still works the same way with an octet string.
Remember, an octet string is just a series of bytes. If you
make it 4 bytes, then it behaves the same as the unsigned32
did, if you make it more you have the same interactions.

	--Tom

> > > > > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > > > > Wijnen, Bert (Bert)