Re: Reflections on new state machine

[Dave Katz <[e-mail]>]

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

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

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

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
> administratively disabled should continue to react to received packets.

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