Re: Reflections on new state machine

Dave Katz <dkatz@juniper.net> Mon, 28 March 2005 17:40 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20736; Mon, 28 Mar 2005 12:40:49 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFyKw-0007ia-AC; Mon, 28 Mar 2005 12:47:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFyDp-0001RJ-9k; Mon, 28 Mar 2005 12:40:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFyDn-0001R8-LD for rtg-bfd@megatron.ietf.org; Mon, 28 Mar 2005 12:40:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20672 for <rtg-bfd@ietf.org>; Mon, 28 Mar 2005 12:40:12 -0500 (EST)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFyKI-0007hU-EN for rtg-bfd@ietf.org; Mon, 28 Mar 2005 12:47:01 -0500
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j2SHe3Bm032430; Mon, 28 Mar 2005 09:40:03 -0800 (PST) (envelope-from dkatz@juniper.net)
Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2SHe2e64194; Mon, 28 Mar 2005 09:40:03 -0800 (PST) (envelope-from dkatz@juniper.net)
In-Reply-To: <200503281050.53387.cnogradi@laurelnetworks.com>
References: <44467058B41F7E4CB6305769819D5E631DF274@SHERLOCK.pit.laurelnetworks.com> <973a61750f9f4883d5801b722a8d5958@juniper.net> <200503281050.53387.cnogradi@laurelnetworks.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <482eb70ff086324a34eb0502c089b66b@juniper.net>
Content-Transfer-Encoding: 7bit
From: Dave Katz <dkatz@juniper.net>
Date: Mon, 28 Mar 2005 10:40:01 -0700
To: Chris Nogradi <cnogradi@laurelnetworks.com>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Cc: rtg-bfd@ietf.org
Subject: Re: Reflections on new state machine
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit

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