There is a case:

One of the tings that we monitor are the power levels for our optical interfaces.
We do this using SNMP OID 1.3.6.1.4.1.2636.3.60.1.2.1.1.6 (jnxDomCurrentLaneRxLaserPower).
This OID returns an integer which represents the receiver laser power on a particular lane of a SFF physcial interface.
The returned value needs to be divided by 100 to get the value in dBm.

This works just fine for optics up to 10G because they have just one single laser.
But 40G and 100G optics are constructed internally using different lasers.
For example a 100G optic internally uses 4 lanes each with it's seperate laser having a bandwidth of 25G. This is how 100G bandwidth is achieved. So there are 4 lasers each with their own power levels.

The problem with LLD discovery here is that the index that is used in the OID isn't at the end, but is on the second to last position.

1 GE optic example:
------------------------

$ snmpwalk -c foobar -v2c r1.brueve 1.3.6.1.2.1.31.1.1.1.1.4935
iso.3.6.1.2.1.31.1.1.1.1.4935 = STRING: "ge-0/1/0"
--> This is a 1 gigabit optic.
$ snmpwalk -c foobar -v2c r1.brueve 1.3.6.1.4.1.2636.3.60.1.2.1.1.6 | grep 4935
iso.3.6.1.4.1.2636.3.60.1.2.1.1.6.4935.0 = INTEGER: -563
--> This means that the optic receives a signal of -5.63dBm

10 GE optic example:
------------------------

$ snmpwalk -c foobar -v2c r1.brueve 1.3.6.1.2.1.31.1.1.1.1.612
iso.3.6.1.2.1.31.1.1.1.1.612 = STRING: "xe-11/0/0"
--> This is a 10 gigabit optic.
$ snmpwalk -c foobar -v2c r1.brueve 1.3.6.1.4.1.2636.3.60.1.2.1.1.6 | grep 612
iso.3.6.1.4.1.2636.3.60.1.2.1.1.6.612.0 = INTEGER: -209
--> This means that the optic receives a signal of -2.09dBm

100 GE optic example:
------------------------

$ snmpwalk -c foobar -v2c r1.brueve 1.3.6.1.2.1.31.1.1.1.1.4671
iso.3.6.1.2.1.31.1.1.1.1.4671 = STRING: "et-8/0/5"
--> This is a 100 gigabit optic.
$ snmpwalk -c foobar -v2c r1.brueve 1.3.6.1.4.1.2636.3.60.1.2.1.1.6 | grep 4671
iso.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671.0 = INTEGER: -230
iso.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671.1 = INTEGER: -146
iso.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671.2 = INTEGER: -209
iso.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671.3 = INTEGER: -265

--> This means that the optic receives a signal of -2.30dBm on Lane 0, -1.46dBm on Lane 1, -2.09dBm on Lane 2 and -2.65dBm on Lane 3.

At the moment the only possibility that we have is to statically define an item for each possible lane:

1.3.6.1.4.1.2636.3.60.1.2.1.1.6.index.0
1.3.6.1.4.1.2636.3.60.1.2.1.1.6.index.1
1.3.6.1.4.1.2636.3.60.1.2.1.1.6.index.2
1.3.6.1.4.1.2636.3.60.1.2.1.1.6.index.3

But since we don't know beforehand if a discovered interface is going to be 1G, 10G, 40G or 100G, this means that for all interfaces with less that 4 lanes we will have unsupported items (because the lanes don't exist).

Is it possible to allow LLD for indexes that are not at the end of the OID? Discover indexes which also have indexes?