Re: Reflections on new state machine
Dave Katz <dkatz@juniper.net> Thu, 24 March 2005 17:19 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 MAA05394; Thu, 24 Mar 2005 12:19:42 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEW5T-0002V4-QQ; Thu, 24 Mar 2005 12:25:40 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVxo-0006rD-23; Thu, 24 Mar 2005 12:17:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVxm-0006r8-F6 for rtg-bfd@megatron.ietf.org; Thu, 24 Mar 2005 12:17:42 -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 MAA05218 for <rtg-bfd@ietf.org>; Thu, 24 Mar 2005 12:17:40 -0500 (EST)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEW3T-0002RZ-Ve for rtg-bfd@ietf.org; Thu, 24 Mar 2005 12:23:37 -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 j2OHHVBm008549; Thu, 24 Mar 2005 09:17:31 -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 j2OHHUe37832; Thu, 24 Mar 2005 09:17:31 -0800 (PST) (envelope-from dkatz@juniper.net)
In-Reply-To: <44467058B41F7E4CB6305769819D5E631DF274@SHERLOCK.pit.laurelnetworks.com>
References: <44467058B41F7E4CB6305769819D5E631DF274@SHERLOCK.pit.laurelnetworks.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <5551a80ad8a4ea77c78036eebf03830a@juniper.net>
Content-Transfer-Encoding: 7bit
From: Dave Katz <dkatz@juniper.net>
Date: Thu, 24 Mar 2005 10:17:30 -0700
To: Chris Nogradi <cnogradi@laurelnetworks.com>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
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: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit
On Mar 24, 2005, at 9:23 AM, Chris Nogradi wrote: > 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? 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
- Reflections on new state machine Chris Nogradi
- Re: Reflections on new state machine Dave Katz
- Re: Reflections on new state machine Dave Katz
- Re: Reflections on new state machine Chris Nogradi
- Re: Reflections on new state machine Dave Katz