Subject: Question abouth P bit setting

From: Mach Chen <[email-masked]>
Date: Tue, 11 Mar 2014 07:57:47 +0000

Hi BFDers,

Section 6.8.3.  Timer Manipulation (RFC5880), second paragraph states:

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

According to the above statement, does it mean that one system of a BFD session will always send control packet with P bit set when the BFD session becomes UP from DOWN state ? Because during the DOWN->UP period, the bfd.DesiredMinTxInterval and   bfd.RequiredMinRxInterval will be changed.

Thanks,
Mach

---

From: Binny Jeshan <[email-masked]>
Date: Tue, 11 Mar 2014 12:01:59 +0200

Hi Mach,

During this phase the P Bit   must not be set. P Bit has to be set only
when the Timers are Changed from the Configuration "After the First
negotiation was already done and the session was continuing to work". P Bit
is as simple as to tell the peer to either 1) Enter the Re-negotiate phase
again 2) Observe parameter changes (may be auth / other etc)...

In your case, the session when it goes DOWN, it Moves its timers to a "Slow
Interval" which is a standard >= 1 second value. This is known to the peer
that in a DOWN session state the remote would operate in Slower interval
and the peer system need not worry on what exact timer its using because in
DOWN state the Peer is not going to observe for any defects, but just wait
for the next UP packet only.

Is this clear now? Please let us know if any further questions.

Regards,
Binny.

On 11 March 2014 09:57, Mach Chen <[email-masked]> wrote:

> According to the above statement, does it mean that one system of a BFD
> session will always send control packet with P bit set when the BFD session
> becomes UP from DOWN state ? Because during the DOWN->UP period, the
> bfd.DesiredMinTxInterval and   bfd.RequiredMinRxInterval will be changed.
>
> Thanks,
> Mach
>
>

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 11 Mar 2014 14:10:32 -0700

Hello Mach,

> According to the above statement, does it mean that one system of a 
> BFD session will always send control packet with P bit set when the 
> BFD session becomes UP from DOWN state ? Because during the DOWN->UP 
> period, the bfd.DesiredMinTxInterval and   bfd.RequiredMinRxInterval 
> will be changed.

I would think so, exactly based on the text you quote.

What happens if you don't do it?  Let's assume your 
bfd.DesiredMinTxInterval is 1sec for the Down packets, 50msec for 
Init/Up, bfd.RequiredMinRxInterval is already your fast timer 50msec, 
for all packets. Changing bfd.DesiredMinTxInterval to a faster interval 
_and_ sending faster at the same time should not affect the session.

Different story when your bfd.RequiredMinRxInterval also starts as 
1sec. Adjusting the timeout timer based on a new, smaller 
bfd.RequiredMinRxInterval should only happen when the peer has 
acknowledged it is sending faster. Exactly what the Poll sequence is 
for.

So in short: it may work, depending on the details above. But clearly 
expect other systems to use the Poll sequence, i.e. you must be able to 
support receiving the Poll sequence even at that early stage of the 
session.

My $0.02

Regards, Marc

> According to the above statement, does it mean that one system of a 
> BFD session will always send control packet with P bit set when the 
> BFD session becomes UP from DOWN state ? Because during the DOWN->UP 
> period, the bfd.DesiredMinTxInterval and   bfd.RequiredMinRxInterval 
> will be changed.
> 
> Thanks,
> Mach
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 12 Mar 2014 06:26:19 +0000

Hi Binny,

Thanks for the detail explanation, it's clear.

According to your and Marc's response, seems that one system could choose to set the P bit (strictly as RFC5880 says) or clear the P bit (as you said and some implementations do). The key point is that the remote system could properly process the control packet with/without P bit set.

Ask this question, because I saw two implementations that one set the P bit and the other does not.

Best regards,
Mach

From: Binny Jeshan [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 6:02 PM
To: Mach Chen
Cc: [email-masked]
Subject: Re: Question abouth P bit setting

Hi Mach,

During this phase the P Bit   must not be set. P Bit has to be set only when the Timers are Changed from the Configuration "After the First negotiation was already done and the session was continuing to work". P Bit is as simple as to tell the peer to either 1) Enter the Re-negotiate phase again 2) Observe parameter changes (may be auth / other etc)...

In your case, the session when it goes DOWN, it Moves its timers to a "Slow Interval" which is a standard >= 1 second value. This is known to the peer that in a DOWN session state the remote would operate in Slower interval and the peer system need not worry on what exact timer its using because in DOWN state the Peer is not going to observe for any defects, but just wait for the next UP packet only.

Regards,
Binny.

On 11 March 2014 09:57, Mach Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi BFDers,

Thanks,
Mach

---

From: Mach Chen <[email-masked]>
Date: Wed, 12 Mar 2014 06:34:26 +0000

Hi Marc,

Thanks for your prompt reply.

See my response inline...

> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Marc
> Binderberger
> Sent: Wednesday, March 12, 2014 5:11 AM
> To: Mach Chen
> Cc: [email-masked]
> What happens if you don't do it?  Let's assume your bfd.DesiredMinTxInterval is

I think most of the implementations can handle the control packets with P bit set.

I saw one implementation that expects to receive the control packet with P bit set during the initial phase, this may result in failing to establish the BFD session. 

> 1sec for the Down packets, 50msec for Init/Up, bfd.RequiredMinRxInterval is
> already your fast timer 50msec, for all packets. Changing
> bfd.DesiredMinTxInterval to a faster interval _and_ sending faster at the same
> time should not affect the session.
> 
> Different story when your bfd.RequiredMinRxInterval also starts as 1sec.
> Adjusting the timeout timer based on a new, smaller bfd.RequiredMinRxInterval
> should only happen when the peer has acknowledged it is sending faster. Exactly
> what the Poll sequence is for.
> 
> 
> So in short: it may work, depending on the details above. But clearly expect other
> systems to use the Poll sequence, i.e. you must be able to support receiving the
> Poll sequence even at that early stage of the session.

Yes, agree.

Thanks,
Mach

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 12 Mar 2014 00:07:19 -0700

Hello Mach,

> I saw one implementation that expects to receive the control packet 
> with P bit set during the initial phase, this may result in failing 
> to establish the BFD session. 

                "Be liberal in what you accept, and
                 conservative in what you send"

RFC122, section 1.2.2  :-)

Regards, Marc

P.S.: now don't tell me it was an implementation I was working on ... 
:-)

On Wed, 12 Mar 2014 06:34:26 +0000, Mach Chen wrote:
>> bfd.DesiredMinTxInterval is
> 
> I saw one implementation that expects to receive the control packet 
> with P bit set during the initial phase, this may result in failing 
> to establish the BFD session. 
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 12 Mar 2014 07:47:33 +0000

Hi Marc,

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Wednesday, March 12, 2014 3:07 PM
> To: Mach Chen
> Cc: [email-masked]
> Subject: RE: Question abouth P bit setting
> 
> Hello Mach,
> 
> > with P bit set during the initial phase, this may result in failing to
> > establish the BFD session.
> 

Yes, good point!

> P.S.: now don't tell me it was an implementation I was working on ...

Let's guess :-)

Best regards,
Mach
> > with P bit set during the initial phase, this may result in failing to
> > establish the BFD session.
> >
> >> 1sec for the Down packets, 50msec for Init/Up,
> >> bfd.RequiredMinRxInterval is already your fast timer 50msec, for all
> >> packets. Changing bfd.DesiredMinTxInterval to a faster interval _and_
> >> sending faster at the same time should not affect the session.
> >>
> >> Adjusting the timeout timer based on a new, smaller
> >> expect other systems to use the Poll sequence, i.e. you must be able
> >> to support receiving the Poll sequence even at that early stage of
> >> the session.
> >
> > Yes, agree.
> >
> > Thanks,
> > Mach
> >
> >>
> >>
> >> My $0.02
> >>
> >> Regards, Marc
> >>
> >>
> >>
> >>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Mar 2014 10:19:03 -0400

> Ask this question, because I saw two implementations that one set the P bit and the other does not.

The place this is problematic is that the P-bit expects the F-bit to be
used.  It can't be wholly ignored.  But the procedure also means that if the
F-bit is received, the poll should end.  This isn't a very good fit for the
usual state machine changes because multiple packets may be sent and
received as the state machine transitions.

My recommendation would be that poll sequences (sec. 6.5) should only be
used for parameter changes outside of those part of the state machine
transitioning to the Up state.

A reminder from section 6:
"It is important for implementors to enforce only the requirements specified
in this section, as misguided pedantry has been proven by experience to
affect interoperability adversely."

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 12 Mar 2014 09:55:41 -0700

Hello Jeff,

hmm, I'm a bit lost :-) as I don't see the problem. The Poll sequence - 
sending P, receiving F - seems orthogonal to the state machine for me. 
It's just a synchronization mechanism on top to ensure timers are set 
in the right sequence.

If you mean "stay out of grey zones and don't make assumptions" then I 
agree though :-)  One could always bring the session to Up with slow 
timers, then start P-F to change to fast timers.

Regards, Marc

On Wed, 12 Mar 2014 10:19:03 -0400, Jeffrey Haas wrote:
>> According to your and Marc's response, seems that one system could 
>> choose to set the P bit (strictly as RFC5880 says) or clear the P 
>> bit (as you said and some implementations do). The key point is that 
>> the remote system could properly process the control packet 
>> with/without P bit set.
>>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Mar 2014 13:41:53 -0400

Marc,

> It's just a synchronization mechanism on top to ensure timers are set 

Agreed. It just means that the dance that occurs as the state machine is
being moved becomes more complicated because you have to also worry about p
and f bit state while it's happening.  Just an extra complication.

> timers, then start P-F to change to fast timers.

While certainly possible, I suspect it'd break a lot of people's desired
behaviors for the protocol.  In particular, don't let a state machine
transition happen unless you can accommodate the desired timers.

-- Jeff

---

From: Mach Chen <[email-masked]>
Date: Thu, 13 Mar 2014 02:10:45 +0000

Hi Jeff and Marc,

> 
> While certainly possible, I suspect it'd break a lot of people's desired behaviors
> for the protocol.  In particular, don't let a state machine transition happen unless
> you can accommodate the desired timers.

Agree.

Best regards,
Mach