From: Hangbin Liu <ha...@redhat.com> Date: Wed, 16 Nov 2016 14:20:45 +0800
> Hi David, > > On Tue, Nov 08, 2016 at 10:26:25AM +0100, Michal Tesar wrote: >> On Mon, Nov 07, 2016 at 08:13:45PM -0500, David Miller wrote: >> >> > From: Michal Tesar <mte...@redhat.com> >> > Date: Thu, 3 Nov 2016 10:38:34 +0100 >> > >> > > 2. If the received Query is a General Query, the interface timer is >> > > used to schedule a response to the General Query after the >> > > selected delay. Any previously pending response to a General >> > > Query is canceled. >> > > --8<-- >> > > >> > > Currently the timer is rearmed with new random expiration time for >> > > every incoming query regardless of possibly already pending report. >> > > Which is not aligned with the above RFE. >> > >> > I don't read it that way. #2 says if this is a general query then any >> > pending response to a general query is cancelled. And that's >> > effectively what the code is doing right now. >> >> Hi David, >> I think that it is important to notice that the RFC says also >> that only the first matching rule is applied. >> >> " >> When new Query with the Router-Alert option arrives on an >> interface, provided the system has state to report, a delay for a >> response is randomly selected in the range (0, [Max Resp Time]) where >> Max Resp Time is derived from Max Resp Code in the received Query >> message. The following rules are then used to determine if a Report >> needs to be scheduled and the type of Report to schedule. The rules >> are considered in order and only the first matching rule is applied. > > ^^ > > Would you like to reconsider about this? I also agree with Michal that we > need to choose the sooner timer. Or if we receive query very quickly, we > will keep refresh the timer and may never reply the report. I'm still thinking about this, please be patient, I review a hundred patches or more per day so it takes me time to get to tasks that require deep thinking or real consideration on any level.
