Subject: Timer Manipulation

From: "Shahram Davari" <[email-masked]>
Date: Fri, 14 Aug 2009 12:44:24 -0700

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

---

From: Satyam Sinha <[email-masked]>
Date: Fri, 14 Aug 2009 13:57:16 -0700

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: [email-masked]
To: [email-masked]
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!
http://windowsliveformobile.com/en-us/photos/default.aspx?&OCID=0809TL-HM

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 14 Aug 2009 14:14:28 -0700

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:[email-masked]]
Sent: Friday, August 14, 2009 1:57 PM
To: Shahram Davari; [email-masked]
Subject: RE: Timer Manipulation

Hi Shahram,

Regards,

Satyam

________________________________
From: [email-masked]
To: [email-masked]
Date: Fri, 14 Aug 2009 12:44:24 -0700
Subject: Timer Manipulation

Hi,

Regards,
Shahram

________________________________
Get your vacation photos on your phone! Click here.<http://windowsliveformobile.com/en-us/photos/default.aspx?&OCID=0809TL-HM>

---

From: Satyam Sinha <[email-masked]>
Date: Fri, 14 Aug 2009 16:47:11 -0700

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: [email-masked]
To: [email-masked]; [email-masked]
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

To: Shahram Davari; 
[email-masked]

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

Date: Fri, 14 Aug 2009 
12:44:24 -0700

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!
http://windowsliveformobile.com/en-us/photos/default.aspx?&OCID=0809TL-HM

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 14 Aug 2009 16:50:59 -0700

Hi Shahram,

If I understand you right, you are correct. I raised this issue on the
list about what needs to be done when both sides change parameters
symultaneously.

It seems we will put this in a later version of the RFC.

Thanks,
Vishwas

On Fri, Aug 14, 2009 at 2:14 PM, Shahram Davari<[email-masked]> wrote:
> 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
>
> "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,
> how can the Poll receiver verify that those Parameters are Received by the
> Poll sender?
>
> Regards,
> Shahram
>

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 14 Aug 2009 17:00:28 -0700

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

Sent: Friday, August 14, 2009 4:47 PM

Hi Shahram,

Regards,

Satyam

Hi Satyam,

Regards,
Shahram

Hi Shahram,

Regards,

Satyam

Hi,

Regards,
Shahram

---

From: Satyam Sinha <[email-masked]>
Date: Fri, 14 Aug 2009 17:42:41 -0700

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: [email-masked]
To: [email-masked]; [email-masked]
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

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: [email-masked]
To: [email-masked]; [email-masked]
Date: 
Fri, 14 Aug 2009 14:14:28 -0700
Subject: RE: Timer Manipulation

Hi 
Satyam,
 
But 
 
Regards,
Shahram

Hi Shahram,

Regards,

Satyam

Hi,
 
Section 6.8.3 of base 
draft says :
 
"If 
 
It 
 
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®. 
http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_express:082009

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 14 Aug 2009 17:54:22 -0700

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<[email-masked]> wrote:
> 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
>
> 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.
>
> 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.
>
> Try it now.

---

From: Dave Katz <[email-masked]>
Date: Sat, 15 Aug 2009 16:26:48 -0600

On Aug 14, 2009, at 1:44 PM, Shahram Davari wrote:

> "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?

The text does not relieve the sender of the requirement to send a Poll  
Sequence in the other direction (thus the MUST).  It simply means that  
if the local side has just changed its parameters, it may include them  
in the Final packet being sent (so it doesn't have to send the old  
values.)  The local side then must send a Poll with the new values as  
per spec, and wait to change timers or whatever.

--Dave

---

From: Dave Katz <[email-masked]>
Date: Sat, 15 Aug 2009 16:39:59 -0600

I believe the spec is clear--it is a MUST that the end changing  
parameters sends a Poll Sequence (and also a MUST that P and F not be  
set simultaneously.)
It is a MAY that the new parameters are carried in F packets so that  
the old values don't have to be kept around (it doesn't hurt anything.)

Do what it says, and it works.

I don't see that this requires any further text in the spec.

--Dave

On Aug 14, 2009, at 5:50 PM, Vishwas Manral wrote:

>> But section 6.5 says " A BFD Control packet MUST NOT have both the  
>> Poll (P)
>> and Final (F) bits set.".
>>
>> Regards,
>> Shahram
>> bfd.RequiredMinRxInterval

---

From: Dave Katz <[email-masked]>
Date: Sat, 15 Aug 2009 16:40:23 -0600

On Aug 14, 2009, at 6:00 PM, Shahram Davari wrote:

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

No, it just sends its own poll sequence as required by the spec.

--Dave

> 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.
>
> Poll (P) and Final (F) bits set.".
>
> Regards,
> 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: Dave Katz <[email-masked]>
Date: Sat, 15 Aug 2009 16:43:02 -0600

> Do we know what breaks if we allow P=1 and F=1 in same packet ?

This is disallowed because the spec says to send a packet with F=1  
immediately upon receipt of a Poll.  This requirement (trivial to  
implement) bounds the packet transmission rate, and provides  
additional protection against runaway packet transmission in the case  
of a broken implementation.

--Dave