Subject: Transition from failing state

From: [email-masked]
Date: Tue, 1 Feb 2005 08:11:38 -0000

Section 6.6.6 of draft-ietf-bfd-base-00.txt states: 

Else if bfd.SessionState is Failing 
  If I Hear You is zero, set bfd.SessionState to Down

However, unless I'm missing something, the draft does not appear to describe what happens if bfd.SessionState is Failing and:

- The sink/destination receives a BFD packet
- The source receives a BFD packet with a nonzero I Hear You

Should the node transition to the init state?

Thanks,
Richard

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Feb 2005 17:57:19 -0500

Richard,

> - The source receives a BFD packet with a nonzero I Hear You

In section 6.1:

   Once a session has been declared down, it cannot come back up until
   the remote end first signals that it is down (by setting its outgoing
   I Hear You field to zero), thus implementing a three-way handshake.

Thus the failing state is meant to wait until the other side has timed out.

We transition to the Failing state upon packet reception like this:

      Else if bfd.SessionState is Up
          If I Hear You is zero
              Set bfd.LocalDiag to 3 (Neighbor signaled session down)
              Set bfd.SessionState to Failing
              Set bfd.RemoteHeard to 0

Or similarly upon a timeout:

   If Demand mode is not active, and a period of time equal to the
   Detection Time passes without receiving a BFD Control packet from the
   remote system, and bfd.SessionState is Init or Up, the session has
   gone down--the local system MUST set bfd.SessionState to Failing,
   bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection
   Time Expired.)  The timeout in Init state is to avoid a potential
   deadlock in which one system is in Failing state and the other is in
   Init state (which could happen if a packet were lost at the right
   time.)

The system will then begin transmitting packets with "I Hear You" of 0,
which will cause the remote system to tear down the connection.

Similarly, when using echo packets:

   BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not
   Up.  BFD Echo packets MUST NOT be transmitted unless the last BFD
   Control packet received from the remote system contains a nonzero
   value in Required Min Echo RX Interval.

Hopefully this helps.

-- 
Jeff Haas 
NextHop Technologies

---

From: Dave Katz <[email-masked]>
Date: Wed, 2 Feb 2005 22:41:05 -0800

On Feb 1, 2005, at 12:11 AM, <[email-masked]> wrote:

> However, unless I'm missing something, the draft does not appear to 
> describe what happens if bfd.SessionState is Failing and:
>

Nope, the whole point of Failing state is to wait there until IHU=0, 
thus ensuring that the other end has killed the session as well.  In 
the pseudocode in the spec, you simply fall through on that test and go 
on with the rest of the process.

--Dave
\

---

From: Dave Katz <[email-masked]>
Date: Wed, 2 Feb 2005 22:56:20 -0800

Looks like this never was replied to, sorry...

On Dec 6, 2004, at 7:00 AM, Chris Nogradi wrote:

> Hello, I have some BFD implementation questions:
>
> 1. Section 6.6.2 specifies in the last paragraph that a '... Control 
> packet
> with the Poll (P) bit clear and the Final (F) bit set...' MUST be sent 
> as a
> result of receiving a packet with the poll bit set.  And later, in 
> section
> 6.6.3, the 3rd paragraph states that if the intervals are changed, 
> '... all
> subsequent transmitted Control packets MUST be sent with the Poll (P) 
> bit set
> until a packet is received with the Final (F) bit set.'  It is not 
> clear to
> me how to implement these seemingly contradictory statements.

Good catch.  The statement that all packets have to be sent with Poll 
should not apply to packets being generated in response to a received 
Poll.  This will be fixed...

>
> 2.  While I am not sure that the document specifically states this, it 
> appears
> to me that the poll and final bits should only be set when in the up 
> state?

Yep.  Originally the P/F bits were only used when Demand Mode was 
active, which can only happen in Up state.  However, we leveraged P/F 
for parameter changes.  This should only apply in Up state.  Will be 
fixed...

--Dave