Subject: Reflections on new state machine

From: "Chris Nogradi" <[email-masked]>
Date: Thu, 24 Mar 2005 11:23:05 -0500

Dave,
 
section 6.7.6 of the new base document (v2) reads:
 
      If received state is AdminDown
          If bfd.SessionState is not Down
              Set bfd.LocalDiag to 3 (Neighbor signaled session down)
              Set bfd.SessionState to Down

      Else
          If bfd.SessionState is AdminDown
              Discard the packet
 
shouldn't the local state remain AdminDown even if the received state is AdminDown?
 
Two other observations:
1. we remain indefinitely in the init state if peer keeps sending down state since packet is not discarded and timer is reset
2. we remain in the up state if the peer keeps sending init state since packet is not discarded and timer is reset
The first seems to be ok but the second does not seem right?
 
Thanks,
 
Chris

---

From: Dave Katz <[email-masked]>
Date: Thu, 24 Mar 2005 10:17:30 -0700

> shouldn't the local state remain AdminDown even if the received state 

Yep, good point.  If both sides are AdminDown they should stay there.  
The intent is that AdminDown is an administrative state and is 
"clamped" there until administrative action is taken to exit it.  I'll 
make this more explicit.

>
> Two other observations:
> 1. we remain indefinitely in the init state if peer keeps sending down 
> state since packet is not discarded and timer is reset

This is true;  this should only happen if there is one-way 
communication.  The net result is that the session doesn't come up, 
which is the intent.  There's no magic about the difference between 
Down and Init operationally.

> 2. we remain in the up state if the peer keeps sending init state 
> since packet is not discarded and timer is reset

This can only happen if the peer is broken, since the peer cannot stay 
in init state indefinitely if properly implemented.  If the peer hears 
you sending Up, he must go Up.  If he's not hearing you, he times out 
and goes Down.  So this scenario can only happen for a Detection Time, 
and only if communications goes one-way during session establishment, 
which is what you'd expect.

--Dave

---

From: Dave Katz <[email-masked]>
Date: Thu, 24 Mar 2005 10:37:53 -0700

Here's what the text in that neighborhood should look like.  Note that 
the transmit interval update is moved before the state machine 
mechanics;  this ensures that a system in AdminDown state still pays 
attention to the receive interval wishes of the remote system.

					...

       Update the Detection Time as described in section 6.7.4.

       Update the transmit interval as described in section 6.7.2.

       Else

           If bfd.SessionState is Down
               If received State is Down
                   Set bfd.SessionState to Init
               Else if received State is Init
                   Set bfd.SessionState to Up

           Else if bfd.SessionState is Init
               If received State is Init or Up
                   Set bfd.SessionState to Up

           Else (bfd.SessionState is Up)
               If received State is Down
                   Set bfd.LocalDiag to 3 (Neighbor signaled session 
down)
                   Set bfd.SessionState to Down

       If the Demand (D) bit is set and bfd.DemandModeDesired is 1,
       and bfd.SessionState is Up, Demand mode is active.

					...

--Dave

---

From: Chris Nogradi <[email-masked]>
Date: Mon, 28 Mar 2005 10:50:52 -0500

Dave,

Section 6.7.3 of the base draft requires a BFD implementation to send a poll 
flag when the required receive interval changes and it is in the up state.  I 
would therefore suppose that in order to enforce that a peer is behaving 
properly, the local BFD session should ensure that it only allows interval 
changes to occur in the up state when the peer is sending a poll flag.  If 
this is a valid assumption, I don't think I am comfortable with the 
relocation of the transmit interval update since it requires updating the 
transmit interval (which should be gated on the existence of the poll bit 
when the session is in the up state) before the current session state is 
evaluated.  In addition to this, I am not sure a session that has been 
administratively disabled should continue to react to received packets.

Thanks,

Chris

---

From: Dave Katz <[email-masked]>
Date: Mon, 28 Mar 2005 10:40:01 -0700

On Mar 28, 2005, at 8:50 AM, Chris Nogradi wrote:

> changes to occur in the up state when the peer is sending a poll flag.

See section 6:

    This section discusses the normative requirements of the protocol in
    order to achieve interoperability.  It is important for implementors
    to enforce only the requirements specified in this section, as
    misguided pedantry has been proven by experience to adversely affect
    interoperability.

In general tests like this are a bad idea.  It is not the job of the 
local peer to enforce sanity in the remote peer; that's the job of the 
remote peer's software engineer.  Further, the protocol has no 
mechanism for "ensuring" anything;  notably there is no mechanism for 
tearing down a session when something "improper" happens, and this is 
purposeful, as it makes the protocol more robust.

If an implementation doesn't do a Poll when changing the timing 
parameters, the worst that will happen is that the session will drop 
anyhow.  It doesn't make the protocol go insane or become inconsistent 
or anything.

The point of the poll/final sequence is to gain confidence that the 
remote system has heard the parameter change before actually changing 
the timing so that the session doesn't drop.  In the case of the 
session not being Up, it makes no difference whether the sender uses 
Poll or not (and the receiver is always required to respond with Final, 
regardless of state.)  An implementation could in fact send packets 
with Poll outside of Up state and nothing bad will happen (in fact, 
this is implicitly allowed by the spec.)

>   If
> evaluated.

Moving that line has no effect on the protocol other than to have the 
timing management apply when in AdminDown.

> In addition to this, I am not sure a session that has been

This was exactly the point of the change.  If I'm telling you I only 
want packets every 10 seconds, you should listen to me even in 
AdminDown.  The two systems are still exchanging packets;  it just 
means that the BFD session is not allowed to come up.

--Dave