Re: Timer Manipulation

[Vishwas Manral <vishwas.ietf at gmail.com>]

Hi Shahram,

This is the same issue I have raised earlier:
http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00583.html

Like I said it was determined that all similar leaks in the spec will
be fixed later.

Thanks,
Vishwas

On Fri, Aug 14, 2009 at 5:42 PM, Satyam Sinha<satyamsinha at live.com> wrote:
> Hi All,
>
> Do we know what breaks if we allow P=1 and F=1 in same packet ?
>
> Hi Shahram,
>
> A few thoughts here. While running BFD between highly responsive systems
> which are connected with high bandwidth low latency links at even low timers
> like 50ms, a poll mode on the wire looks like one end sending a poll packet
> and the other responding with a final packet. In such a case, if the system
> wants to implement the case that I suggested, should that be disallowed ?
>
> I agree that it does not work in some other cases, including the case that
> you mentioned and so we shouldn't use it there.
>
> This is exactly what the "MAY" allows. There is an implied poll mode that
> works here and if one cares to add a lot of complexity to your
> implementation then that should be optional and not disallowed.
>
> Regards,
>
> Satyam
>
> ________________________________
> From: davari at broadcom.com
> To: satyamsinha at live.com; rtg-bfd at ietf.org
> Date: Fri, 14 Aug 2009 17:00:28 -0700
> Subject: RE: Timer Manipulation
>
> Hi Satyam,
>
> An example is if local systems is in demand mode and a single Poll sequence
> is received from remote system. If the local system changes any value in the
> Final packet, it can't be sure that the remote system has received it.
>
> My be we should allow Poll =1 and F =1 in the same packet !
>
> Regards,
> Shahram
> ________________________________
> From: Satyam Sinha [mailto:satyamsinha at live.com]
> Sent: Friday, August 14, 2009 4:47 PM
> To: Shahram Davari; rtg-bfd at ietf.org
> Subject: RE: Timer Manipulation
>
> Hi Shahram,
>
> Clearly then we can't use the exact semantics that I suggested due to this
> restriction. However, this statement allows an implied poll sequence which
> the systems "MAY" implement.
>
> One example is, if a remote endpoint starts a poll sequence and sends out
> poll packets P1, P2, P3 ... at the same time the parameters change at the
> local endpoint and it sends out new parameters in F1 (Final packet
> responding to P1), F2 for P2 and so on. In such a case, ending of the poll
> sequence (by receiving the first packet with P=0) is indication that the
> parameters were accepted as the remote end as it must have received atleast
> one of these final packets.
>
> However, the same cannot be claimed if you start this process on F2 as the
> same cannot be claimed about the other end accepting these parameters as the
> reset of poll bit could be due to the remote end receiving F1 packet.
>
> Implementations can choose to do this and regardless of the remote end
> implementation this works fine. However, this is not mandatory.
>
> Do you know of any case which may not work if someone implemented this "MAY"
> ?
>
> Regards,
>
> Satyam
>
> ________________________________
> From: davari at broadcom.com
> To: satyamsinha at live.com; rtg-bfd at ietf.org
> Date: Fri, 14 Aug 2009 14:14:28 -0700
> Subject: RE: Timer Manipulation
>
> Hi Satyam,
>
> But section 6.5 says " A BFD Control packet MUST NOT have both the Poll (P)
> and Final (F) bits set.".
>
> Regards,
> Shahram
> ________________________________
> From: Satyam Sinha [mailto:satyamsinha at live.com]
> Sent: Friday, August 14, 2009 1:57 PM
> To: Shahram Davari; rtg-bfd at ietf.org
> Subject: RE: Timer Manipulation
>
> Hi Shahram,
>
> The MAY here means that BFD allows an endpoint to set both (P) and (F) bits
> together in the same packet. The endpoint "MAY" initiate the poll sequence
> even while it is responding to a poll sequence. It is not mandatory for it
> to wait for the poll sequence to complete before initiating it's own poll
> sequence.
>
> In case of change in local parameters while the endpoint is receiving a poll
> sequence, the endpoint could either use new parameters and set both (P) &
> (F) bits or use old parameters with only the (F) bit set and then start a
> poll sequence following the final transmissions. In both cases the endpoint
> has to wait for a Final packet from the other end.
>
> Regards,
>
> Satyam
>
> ________________________________
> From: davari at broadcom.com
> To: rtg-bfd at ietf.org
> Date: Fri, 14 Aug 2009 12:44:24 -0700
> Subject: Timer Manipulation
>
> Hi,
>
> Section 6.8.3 of base draft says :
>
> "If either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval
> is changed, a Poll Sequence MUST be initiated (see section 6.5). If the
> timing is such that a system receiving a Poll Sequence wishes to change the
> parameters described in this paragraph, the new parameter values MAY be
> carried in packets with the Final (F) bit set, even if the Poll Sequence has
> not yet been sent."
>
> It seems that the above mentioned MAY requirement is not a good idea,
> because if a Poll receiver updates any parameter in the Final packet, then
> how can the Poll receiver verify that those Parameters are Received by the
> Poll sender?
>
> Regards,
> Shahram
>
> ________________________________
> Get your vacation photos on your phone! Click here.
> ________________________________
> Get your vacation photos on your phone! Click here.
> ________________________________
> Express your personality in color! Preview and select themes for Hotmail®.
> Try it now.