The MPLS WG Archive

["Van der Linde, Harmen, ALABS" <hvdl@att.com>]

Bert et al,

Regarding your comments on the LSR MIB:

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

The issues you raise are valid and mostly directed towards
SNMP packet size overhead as a result of the 24-octet indexing
scheme. The problems caused by this overhead is that 
CreateAndGo may not work anymore, in addition to extra
SNMP traffic load. 

When considering this problem, however, I think that you
need consider other factors like usability in production
environments as well.

First off, it is not likely LSPs will be created and deleted 
with a high frequency, certainly not in a provider network. 
As such, additional overhead caused by the 24-octet indexing
scheme is not a major issue (i.e., using CreateAndWait instead
of CreatAndGo). 

The MPLS LSR MIB will most likely primarily being used for MPLS
topology discovery (i.e., LSP path discovery). So, the emphasize
is more on reading the MIB information as opposed to creation
of new MIB information. In some earlier email exchange I read
that a string-based indexing scheme has the benefit of providing
more efficient table read capabilities. This efficiency is very
appealing and beneficial to implement efficient MPLS topology
discovery capabilities.

My concern is that we spend too much time discussion a MIB SMI
optimization (i.e., using a Unsigned32 index) that doesn't have 
substantial value and, in fact, seem to have a negative impact 
on MIB read capabilities. We need to get this MPLS MIB module,
together with the MPLS LDP and MPLS VPN modules, standardized
ASAP. There is a critical need for these MPLS MIB modules for 
management of MPLS-enabled networks, which are currently being
deployed by many service providers.

regards,

Harmen