Re: RE: [802.1] [802.1AB]: Problem with the lldpXdot1RemProtoVlanEntry table inde x

At 08:51 AM 1/20/2005, David B Harrington wrote:
>Hi,
>
>I don't believe the zero usage is the problem, but your mail has been
>sent to the RMONMIB WG and the MIB Doctors of the IETF for
>consideration.
>
>I suspect the lldpRemTimeMark (a TimeFilter) is the problem you are
>experiencing.
>TimeFilters are known to cause infinite loops, depending on how the
>GetNext code has been implemented in the agent and manager.
>I do not know of any definitive text that explains how to avoid this
>problem.

You have identified yet another issue with TimeFilter.
Thanks I guess :-)  The results of the TimeFilter issues
were captured in minutes but not the RFC.  I will work
on this today.

BTW, it's not technically a loop problem.
If implemented to the letter of the current RFC,
there will be a conceptual row for each TimeMark value
in the range (TimeMark .. lastChangeTime).

The actual number is (lastChangeTime - TimeMark + 1) if
TimeMark <= lastChangeTime, or zero otherwise.
Note that every instance of the time-filtered row
(from TimeMark .. lastChangeTime) is exactly the
same and there is absolutely no point in retrieving
more than one of them.

If a manager starts a MIB walk with a TimeMark <
lastChangeTime, and retrieves a counter that keeps
changing (e.g., byte counter for the interface w/ the
SNMP traffic) then the managers timeMark will never reach
the lastChangeTime, and it will appear that the MIB walk
is in an infinite loop.

Andy


>The RMONMIB WG is the correct place to discuss this issue, since they
>control the definition/interpretation of the TimeFilter.
>I believe the RMONMIB WG has chosen to not fix the get-next-forever
>problem, because it would impact the advancement of the RMON2-MIB
>through the IETF standards advancement process.
>
>The RMONMIB WG considered adding an object that helped to characterize
>the "mode" of implementation of an agent, to help solve the problem.
>The RMONMIB WG chose to not add this object to the RMON2-MIB, because
>it didn't actually fix the problem.
>The description may help you to understand the issue and to check the
>implementation you are working with.
>>From the RMONMIB WG archive,
>http://www.ietf.org/mail-archive/web/rmonmib/current/msg00672.html:
>
>------- archive message #672 --------------
>Hi,
>
>The RMONMIB WG decided at the last IETF that the timeFilter
>get-next-forever
>problem should be fixed.  I am proposing the following MIB object,
>which
>should be added to the RMON2-MIB module.  It could either be added to
>the probeConfig group or added to a new group.  The MIN-ACCESS of this
>object would be read-only.
>
>
>timeFilterMode OBJECT-TYPE
>    SYNTAX      INTEGER {
>        stopAfterOne(1),
>        stopAfterAll(2)
>    }
>    MAX-ACCESS  read-write
>    STATUS      current
>    DESCRIPTION
>        "This object controls the way the SNMP agent implements the
>         getnext operation for tables with a TimeFilter index, such
>         as those found in the RMON2-MIB module.
>
>         If this object has the value `stopAfterOne(1)', then a
>GetNext
>         or GetBulk operation will provide one pass through a given
>table,
>         i.e., the agent will continue to the next object or table,
>         instead of incrementing a TimeMark INDEX value, even if
>         there exists higher TimeMark values which are valid for
>         the same conceptual row.
>
>         This mode is not strictly compliant with the TimeFilter
>textual
>         convention definition, because potentially many conceptual
>rows
>         will be skipped instead of returned in a GetNext or GetBulk
>         operation.  Such rows are identical to each other, except for
>         the returned TimeMark INDEX value. This mode is intended only
>         for testing purposes, however it may also be useful if an NMS
>         wishes to utilize the GetBulk PDU. This mode will prevent the
>         GetBulk responses from containing duplicate rows due to the
>         TimeFilter mechanism.
>
>         If this object has the value `stopAfterAll(2)', then a
>getNext
>         or getBulk MIB walk will repeat through the same MIB table
>until
>         the TimeMark for the most-recently changed entry is reached.
>         Note that as long as traffic occurs on the monitored
>interface,
>         it is possible a highest value of the TimeFilter INDEX may
>         never be reached. This mode is strictly compliant with the
>         TimeFilter textual convention definition.  Note that GetBulk
>         PDU responses in this mode will likely contain multiple
>copies
>         of the same MIB instances, differing only in the TimeMark
>INDEX
>         value.
>
>         As an example, consider row 'fooEntry' which was last updated
>         at 'time 1000'. An NMS may use any TimeMark INDEX value in
>the
>         range '0' to '1000', and the current (i.e., time of get
>request)
>         counter values for the 'fooEntry' will be returned by agent.
>         In the 'stopAfterOne' mode, the agent will not increment
>         the fooEntry TimeMark index under any conditions. In the
>         'stopAfterAll' mode, the agent will increment any fooEntry
>         TimeMark INDEX value in the range '0' to '999', up until
>         the TimeMark value of '1000' is reached."
>    DEFVAL { stopAfterAll }
>::= { probeConfig 15 }
>
>_______________________________________________
>RMONMIB mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmonmib
>
>
>
>
>
>----------------------------------------------------------------------
>----------
>
>Prev by Date: [RMONMIB] I-D
>ACTION:draft-ietf-rmonmib-raqmon-pdu-00.txt 
>Next by Date: RE: [RMONMIB] proposal to fix TimeFilter problem 
>Previous by thread: [RMONMIB] I-D
>ACTION:draft-ietf-rmonmib-raqmon-pdu-00.txt 
>Next by thread: RE: [RMONMIB] proposal to fix TimeFilter problem 
>Index(es): 
>Date 
>Thread 
>
>
>
>
>> -----Original Message-----
>> From: IEEE 802.1 [mailto:[email protected]] On Behalf 
>> Of Eelco Chaudron
>> Sent: Thursday, January 20, 2005 2:35 AM
>> To: [email protected]
>> Subject: [802.1] [802.1AB]: Problem with the 
>> lldpXdot1RemProtoVlanEntry table inde x
>> 
>> Hi All,
>> 
>> When implementing the dot1 extension MIB I was running into a 
>> problem with
>> the lldpXdot1RemProtoVlanTable.
>> The table has the following indexes:
>>   - lldpRemTimeMark
>>   - lldpRemLocalPortNum
>>   - lldpRemIndex
>>   - lldpXdot1RemProtoVlanId
>> 
>> The problem lies within the last index, 
>> lldpXdot1RemProtoVlanId. This can
>> have a value of zero, and would be causing an infinite loop 
>> when doing SNMP
>> getnext operations.
>> 
>> To my understanding a SNMP index can never have a value of zero, as
>it
>> indicates to SNMP to get the first value.
>> 
>> How would we hande this? For example not returning entries in the
>> lldpXdot1RemProtoVlanTable wich have a vlanid of zero? Or 
>> report the zero
>> values as 4096?
>> 
>> Regards,
>> 
>> Eelco
>> 
>> IEEE 802.1 list info: 
>> http://www.ieee802.org/1/email-pages/etkg1204.html
>> 
>
>
>
>_______________________________________________
>RMONMIB mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmonmib