Re: Reflections on new state machine

Chris Nogradi <cnogradi@laurelnetworks.com> Mon, 28 March 2005 15:53 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 KAA29843; Mon, 28 Mar 2005 10:53:40 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFwfD-0000Qr-Gj; Mon, 28 Mar 2005 11:00:27 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFwXD-00064s-31; Mon, 28 Mar 2005 10:52:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFwXC-00064g-Ca for rtg-bfd@megatron.ietf.org; Mon, 28 Mar 2005 10:52:10 -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 KAA29660 for <rtg-bfd@ietf.org>; Mon, 28 Mar 2005 10:52:07 -0500 (EST)
Received: from paperclip.laurelnetworks.com ([63.94.127.69] ident=nobody) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFwdi-0000P2-Oc for rtg-bfd@ietf.org; Mon, 28 Mar 2005 10:58:55 -0500
Received: from notepad.laurelnetworks.com (notepad.laurelnetworks.com [63.94.127.20]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id j2SFq6MC005908; Mon, 28 Mar 2005 10:52:06 -0500
Received: from cnogradi-linux.dhcp.pit.laurelnetworks.com (cnogradi-linux.dhcp.pit.laurelnetworks.com [10.0.19.158]) by notepad.laurelnetworks.com (Laurel/Laurel) with ESMTP id j2SFq5Ae010044; Mon, 28 Mar 2005 10:52:06 -0500
From: Chris Nogradi <cnogradi@laurelnetworks.com>
Organization: Laurel Networks
To: Dave Katz <dkatz@juniper.net>
Date: Mon, 28 Mar 2005 10:50:52 -0500
User-Agent: KMail/1.6.2
References: <44467058B41F7E4CB6305769819D5E631DF274@SHERLOCK.pit.laurelnetworks.com> <973a61750f9f4883d5801b722a8d5958@juniper.net>
In-Reply-To: <973a61750f9f4883d5801b722a8d5958@juniper.net>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200503281050.53387.cnogradi@laurelnetworks.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
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: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit

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

On Thursday 24 March 2005 12:37, Dave Katz wrote:
> 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.
>
>        If bfd.SessionState is AdminDown
>            Discard the packet
>
>        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 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