Subject: When can unschdules packets be sent?

From: Jake Montgomery <[email-masked]>
Date: Tue, 16 Feb 2010 11:00:15 -0500

BFD Folks,

I have been working with draft-ietf-bfd-base-10.txt and have read all 
the recent threads in this group, and I am still a bit confused about 
when it is allowable to send control packets during the interval between 
the normal periodic packets when in asynchronous mode.

The base of my confusion is my perception of a conflict between two 
sections:

(6.8.7 10th paragraph:) "A BFD Control packet *SHOULD be transmitted 
during the interval between periodic Control packet transmissions* when 
the contents of that packet would differ from that in the previously 
transmitted packet (other than the Poll and Final bits) in order to more 
rapidly communicate a change in state."

(6.5 3rd paragraph::) "If periodic BFD Control packets are already being 
sent (the remote system is not in Demand mode), the Poll Sequence MUST 
be performed by setting the Poll (P) bit on those scheduled periodic 
transmissions; *additional packets MUST NOT be sent*."

My confusion is about all the myriad circumstances where there would be 
a packet content change, and a Poll sequence is being initiated for 
whatever reason. For example I wish to change bfd.DesiredMinTXInterval 
(which can be changed at any time 6.8.11). According to 6.8.3 that 
should trigger a Poll Sequence. Now the quandary is, MAY I send a 
control packet immediately, since the contents would be different, as 
described in 6.8.7, or MUST I wait until the next periodic control 
packet because this is a poll sequence and 6.5 comes into play?

This is just one of many scenarios where I am having difficulty 
reconciling those two paragraphs. Any guidance would be appreciated.

Thanks,
    Jake

---

From: Dave Katz <[email-masked]>
Date: Tue, 16 Feb 2010 11:03:09 -0700

Hm, I can see the confusion.

The intent of the verbiage in 6.5 is to make sure that implementations  
don't send periodic Poll packets (since more than one may be sent  
prior to the receipt of Final) in *addition* to the regularly- 
scheduled periodic packets.

6.8.7 says that you should quickly announce a state change;  in the  
case where the state change also happens to carry the P bit, it should  
still be sent immediately.  Any subsequent Polls should piggyback on  
the scheduled control packet transmissions.

--Dave

On Feb 16, 2010, at 9:00 AM, Jake Montgomery wrote:

> BFD Folks,
>
> I have been working with draft-ietf-bfd-base-10.txt and have read  
> all the recent threads in this group, and I am still a bit confused  
> about when it is allowable to send control packets during the  
> interval between the normal periodic packets when in asynchronous  
> mode.
>
> (6.8.7 10th paragraph:) "A BFD Control packet SHOULD be transmitted  
> during the interval between periodic Control packet transmissions  
> when the contents of that packet would differ from that in the  
> previously transmitted packet (other than the Poll and Final bits)  
> in order to more rapidly communicate a change in state."
>
> (6.5 3rd paragraph::) "If periodic BFD Control packets are already  
> being sent (the remote system is not in Demand mode), the Poll  
> Sequence MUST be performed by setting the Poll (P) bit on those  
> scheduled periodic transmissions; additional packets MUST NOT be  
> sent."
>
> My confusion is about all the myriad circumstances where there would  
> be a packet content change, and a Poll sequence is being initiated  
> for whatever reason. For example I wish to change  
> bfd.DesiredMinTXInterval (which can be changed at any time 6.8.11).  
> According to 6.8.3 that should trigger a Poll Sequence. Now the  
> quandary is, MAY I send a control packet immediately, since the  
> contents would be different, as described in 6.8.7, or MUST I wait  
> until the next periodic control packet because this is a poll  
> sequence and 6.5 comes into play?
>

---

From: Jake Montgomery <[email-masked]>
Date: Tue, 16 Feb 2010 14:15:05 -0500

Dave.

Thanks. That was my guess, but I just could not find corroboration in 
reading draft-ietf-bfd-base-10.txt. Since section 6.5 uses the strong 
"MUST NOT", it might benefit from clarification that this refers to 
"additional" poll packets and not necessarily the initial poll packet if 
that packet falls under 6.8.7.  Just a suggestion. For the most part the 
draft is pretty clear and comprehensible.

Thanks,
    Jake.

On 2/16/2010 1:03 PM, Dave Katz wrote:
> prior to the receipt of Final) in *addition* to the 
> regularly-scheduled periodic packets.
>
>> when it is allowable to send control packets during the interval 
>> between the normal periodic packets when in asynchronous mode.
>>
>> during the interval between periodic Control packet transmissions* 
>> previously transmitted packet (other than the Poll and Final bits) in 
>> order to more rapidly communicate a change in state."
>>
>> scheduled periodic transmissions; *additional packets MUST NOT be sent*."
>>

---

From: Dave Katz <[email-masked]>
Date: Tue, 16 Feb 2010 18:53:28 -0700

Yep, it could be clearer.  Right now the spec is in Really Really  
Really Last Call This Time For Sure so I'm loathe to make any changes,  
but this can enter the queue for some future revision.

--Dave

On Feb 16, 2010, at 12:15 PM, Jake Montgomery wrote:

> Dave.
>
> Thanks. That was my guess, but I just could not find corroboration  
> in reading draft-ietf-bfd-base-10.txt. Since section 6.5 uses the  
> strong "MUST NOT", it might benefit from clarification that this  
> refers to "additional" poll packets and not necessarily the initial  
> poll packet if that packet falls under 6.8.7.  Just a suggestion.  
> For the most part the draft is pretty clear and comprehensible.
>
> Thanks,
>     Jake.
>
>
>> The intent of the verbiage in 6.5 is to make sure that  
>> implementations don't send periodic Poll packets (since more than  
>> one may be sent prior to the receipt of Final) in *addition* to the  
>> case where the state change also happens to carry the P bit, it  
>> should still be sent immediately.  Any subsequent Polls should  
>> piggyback on the scheduled control packet transmissions.
>>
>> --Dave
>>
>>> all the recent threads in this group, and I am still a bit  
>>> confused about when it is allowable to send control packets during  
>>> the interval between the normal periodic packets when in  
>>> asynchronous mode.
>>>
>>> The base of my confusion is my perception of a conflict between  
>>> two sections:
>>>
>>> (6.8.7 10th paragraph:) "A BFD Control packet SHOULD be  
>>> transmitted during the interval between periodic Control packet  
>>> transmissions when the contents of that packet would differ from  
>>> that in the previously transmitted packet (other than the Poll and  
>>> Final bits) in order to more rapidly communicate a change in state."
>>>
>>> My confusion is about all the myriad circumstances where there  
>>> would be a packet content change, and a Poll sequence is being  
>>> initiated for whatever reason. For example I wish to change  
>>> bfd.DesiredMinTXInterval (which can be changed at any time  
>>> 6.8.11). According to 6.8.3 that should trigger a Poll Sequence.  
>>> Now the quandary is, MAY I send a control packet immediately,  
>>> since the contents would be different, as described in 6.8.7, or  
>>> MUST I wait until the next periodic control packet because this is  
>>> a poll sequence and 6.5 comes into play?
>>>

---

From: Jake Montgomery <[email-masked]>
Date: Thu, 18 Feb 2010 16:23:06 -0500

One small follow up question.

It appears that if bfd.RemoteMinRxInterval is 0 then the local session 
is not supposed "to send any periodic BFD Control packets" (6.8.1).  If 
I understand correctly, the local session can still send immediate 
packets if there is a state change (6.8.7), including those requiring a 
poll sequence be initiated. Thats all well and good if that initial poll 
packet gets received by the remote system, in which case the remote 
session will send an 'F' packet, and we will go on not sending them any 
periodic BFD Control packets. However if that initial poll packet is 
lost, then the remote session will continue sending periodic control 
packets _without_ the Final bit set.  So, unless the local system sends 
additional poll packets, the poll sequence will never complete. This 
means that changes that require a complete poll sequence, such as a 
bfd.DesiredMinTxInterval increase (6.8.3), would never be allowed to 
take effect, even in a system that was up and otherwise functioning 
(except for that one lost packet.)

This could be the intention,  that no additional poll packets are sent, 
though it seems problematic to me. If that is not the intention, then 
the local system needs to send multiple poll packets until it receives a 
packet with the Final bit set (or the local Detection time expires 
without any response.) If that is the case, then my question is - what 
is the rate at which additional poll packets should be sent when 
bfd.RemoteMinRxInterval is 0?  (My guess is that the local system just 
keeps sending poll packets at bfd.DesiredMinTxInterval?)

Any guidance would be appreciated,
  Jake.

[... clip]   
>>>> (6.8.7 10th paragraph:) "A BFD Control packet *SHOULD be 
>>>> transmissions* when the contents of that packet would differ from

---

From: Dave Katz <[email-masked]>
Date: Thu, 18 Feb 2010 16:13:08 -0700

In this case, though it is a little confusing, it turns out to be  
pretty much a non-issue, because a system receiving a zero value in  
Min RX Interval ought not ever be in a position to send a poll  
sequence in the first place (or any other kind of poll.)

A zero value is sent in two circumstances--when trying to keep a  
session from coming up (the sender really doesn't care what the  
receiver has to say about *anything*) and in the Multipoint Head role  
in the multipoint spec (soon to be dusted off).  When there are  
potentially a jillion tails, you really don't want them *ever* sending  
*anything* that the head didn't ask for directly.

It would probably disambiguate a bit to say that the state-change  
mechanism doesn't apply if the system is receiving MinRXIvl==0, though  
the spec as is won't hurt much (sending the single Poll on a state  
change in the multipoint scenario is undesirable but not as fatal as  
pumping packets repeatedly.)  Once the dust settles on the last call  
and the RFC gets issued, we could always move forward with an errata  
document as the multipoint stuff progresses.

Thanks for the very close reading and analysis.

--Dave

On Feb 18, 2010, at 2:23 PM, Jake Montgomery wrote:

> It appears that if bfd.RemoteMinRxInterval is 0 then the local  
> session is not supposed "to send any periodic BFD Control  
> packets" (6.8.1).  If I understand correctly, the local session can  
> still send immediate packets if there is a state change (6.8.7),  
> including those requiring a poll sequence be initiated. Thats all  
> well and good if that initial poll packet gets received by the  
> remote system, in which case the remote session will send an 'F'  
> packet, and we will go on not sending them any periodic BFD Control  
> packets. However if that initial poll packet is lost, then the  
> remote session will continue sending periodic control packets  
> _without_ the Final bit set.  So, unless the local system sends  
> This could be the intention,  that no additional poll packets are  
> sent, though it seems problematic to me. If that is not the  
> intention, then the local system needs to send multiple poll packets  
> until it receives a packet with the Final bit set (or the local  
> Detection time expires without any response.) If that is the case,  
> then my question is - what is the rate at which additional poll  
> packets should be sent when bfd.RemoteMinRxInterval is 0?  (My guess  
> is that the local system just keeps sending poll packets at  
> bfd.DesiredMinTxInterval?)
>
>>>> one may be sent prior to the receipt of Final) in *addition* to  
>>>> the regularly-scheduled periodic packets.
>>>>
>>>> 6.8.7 says that you should quickly announce a state change;  in  
>>>> the case where the state change also happens to carry the P bit,  
>>>> it should still be sent immediately.  Any subsequent Polls should  
>>>>> I have been working with draft-ietf-bfd-base-10.txt and have  
>>>>> read all the recent threads in this group, and I am still a bit  
>>>>> confused about when it is allowable to send control packets  
>>>>> during the interval between the normal periodic packets when in  
>>>>> asynchronous mode.
>>>>>
>>>>> that in the previously transmitted packet (other than the Poll  
>>>>> and Final bits) in order to more rapidly communicate a change in  
>>>>> state."
>>>>>
>>>>> (6.5 3rd paragraph::) "If periodic BFD Control packets are  
>>>>> already being sent (the remote system is not in Demand mode),  
>>>>> the Poll Sequence MUST be performed by setting the Poll (P) bit  
>>>>> on those scheduled periodic transmissions; additional packets  
>>>>> MUST NOT be sent."
>>>>>
>>>>> MUST I wait until the next periodic control packet because this  
>>>>> is a poll sequence and 6.5 comes into play?
>>>>>