The MPLS WG Archive

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

All...

As soon as you get to see the MIB module, you can all check
for yourself. Here is why I have a serious concern with using
24-octet index objects. Specifically for the mplsXCTable, where 
3 of such 24-octet objects are used as index.

My comments below are based on a pre-relase version of the doc I got
to see/check, so if things have changed since then, it may not be
100% accurate.

Take the mplsXCTable. It has 3 of these objects as index onjects.

It has 7 columns of which 5 are read-create. The read-create objects
are all pretty small in size. Like 3 integer based that would contain
some 9 octets on the wire together, then an LSPID (4 or 8 octets
on the wire), and another index type, possibly 26 octets on the wire.
So the actual DATA values on the wire to create (or read) such a row
consists of max 43 octets.
 
The OID for the mplsXCEntry is: 1.3.6.1.2.1.10.166.2.1.9.1

So if each of the indices is 24 octets, then it adds 3*25 or 75 octets
to each OID. So the OID for each column is 87 octets.
 
So to transport the 5 objects (containing max 43 octets of real data)
you potentially have to send 435 + 43 or 478 octets.
Add to that the overhead for SNMP header and PDU header data, and
it does not even fit in a 484 SNMP packet anymore and so a 
createAndGo may not be working in some implementations anymore.

When you had 3 Unsigned32 as index. the OID for each column
would have been max 29 octets or so. So the total would have
been 145 + 23 is some 168 or so octets (the data for the 
mplsXCLabelStackIndex would also be reduced from 26 to 6).


Thanks,
Bert