Between schedule transmissions

richard.spencer@bt.com Thu, 24 February 2005 06:01 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 BAA23000; Thu, 24 Feb 2005 01:01:37 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CQz-0005UT-FE; Thu, 24 Feb 2005 01:25:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4BLE-0004aC-0Q; Thu, 24 Feb 2005 00:15:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lKc-0001U9-FY for rtg-bfd@megatron.ietf.org; Tue, 22 Feb 2005 20:28:50 -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 TAA12240 for <rtg-bfd@ietf.org>; Tue, 22 Feb 2005 19:11:25 -0500 (EST)
From: richard.spencer@bt.com
Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3kUL-0007V3-AB for rtg-bfd@ietf.org; Tue, 22 Feb 2005 19:34:49 -0500
Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Wed, 23 Feb 2005 00:10:56 +0000
Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Feb 2005 00:10:56 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Feb 2005 00:10:55 -0000
Message-ID: <B5E87B043D4C514389141E2661D255EC0A8358B8@i2km41-ukdy.domain1.systemhost.net>
Thread-Topic: Between schedule transmissions
thread-index: AcUZO/qtYpqBIDm+QI+EdlioTAabSA==
To: rtg-bfd@ietf.org
X-OriginalArrivalTime: 23 Feb 2005 00:10:56.0458 (UTC) FILETIME=[254ECAA0:01C5193C]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
Content-Transfer-Encoding: quoted-printable
Subject: Between schedule transmissions
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.3 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Content-Transfer-Encoding: quoted-printable

The base draft states that "A single BFD Control packet SHOULD be transmitted between normally scheduled transmissions when the contents of that packet would differ from those in the previously transmitted packet in order to more rapidly communicate a change in state."

In the case of state transitions from 'Down to Up or Init', and from 'Up to Failing' it is obvious that a BFD packet should be sent immediately (rather than waiting for the next scheduled transmission) because the IHY variable changes. However, what about state changes form 'Init to Up' and 'Failing to Down' where the IHY doesn't change? Do these result in BFD packets being sent immediately, or does the system wait until the next scheduled transmission? The answer to this question may be dependant on the bfd.LocalDiag field, the draft states that bfd.LocalDiag MUST be initialised to zero, and describes when it should be changed to reflect failure conditions. However, there is no information (or at least I can't find any) regarding when bfd.LocalDiag should be reset to 0.

The main reason behind asking this question is that following restoration of a unidirectional failure, if a BFD packet is not sent immediately following a state change from Failing to Down, then it would appear to me that it would be possible that a BFD session may never come back up and instead each side would loop through the Failing, Init, Down states. To use an example, lets say that at T=0 seconds, the unidirectional fault (A->B) is repaired, at this point node A is in the Down state and Node B is in the Failing state (to keep things simple, in this example one way delay = 100ms and processing time is not included) -

[A: Down, B: Failing]
T=0:   Connectivity in the direction A->B is restored
T=0.1: B reaches its next scheduled BFD transmission slot and sends a BFD packet to A
T=0.2: A receives the BFD packet from A with IHY set to 0 and changes from Down to Init
[A: Init, B: Failing]
T=0.2: A sends a BFD packet to B straight away
T=0.3: B receives the BFD packet from A with IHY set to 1 and ignores the packet (waits for IHY = 0)
T=0.5: A reaches its next scheduled BFD transmission slot and sends a BFD packet to B
T=0.6: B receives the BFD packet from A with IHY set to 1 and ignores the packet (waits for IHY = 0)
T=1.1: B reaches its next scheduled BFD transmission slot and sends a BFD packet to A
T=1.2: A receives the BFD packet from B with IHY set to 0 and drops the packet (waits for IHY = 1)
T=1.5: A reaches its next scheduled BFD transmission slot and sends a BFD packet to B
T=1.6: B receives the BFD packet from A with IHY set to 1 and ignores the packet (waits for IHY = 0)
T=2.1: B reaches its next scheduled BFD transmission slot and sends a BFD packet to A
T=2.2: A receives the BFD packet from B with IHY set to 0 and drops the packet (waits for IHY = 1)
T=2.5: A reaches its next scheduled BFD transmission slot and sends a BFD packet to B
T=2.6: B receives the BFD packet from A with IHY set to 1 and ignores the packet (waits for IHY = 0)
T=3.1: B reaches its next scheduled BFD transmission slot and sends a BFD packet to A
T=3.2: A receives the BFD packet from B with IHY set to 0, drops the packet, and changes from Init to Failing due to detection timeout
[A: Failing, B: Failing]
T=3.2: A sends a BFD packet to B straight away
T=3.3: B receives the BFD packet from A with IHY set to 0 and changes from Failing to Down
[A: Failing, B: Down]
T=3.5: A reaches its next scheduled BFD transmission slot and sends a BFD packet to B
T=3.6: B receives the BFD packet from A with IHY set to 0 and changes from Down to Init
[A: Failing, B: Init]
T=3.6: B sends a BFD packet to A straight away
T=3.7: A receives the BFD packet from B with IHY set to 1 and ignores the packet (waits for IHY = 0)
T=4.1: B reaches its next scheduled BFD transmission slot and sends a BFD packet to A
T=4.2: A receives the BFD packet from B with IHY set to 1 and ignores the packet (waits for IHY = 0)
T=4.5: A reaches its next scheduled BFD transmission slot and sends a BFD packet to B
T=4.6: B receives the BFD packet from A with IHY set to 0 and drops the packet (waits for IHY = 1)
T=5.1: B reaches its next scheduled BFD transmission slot and sends a BFD packet to A
T=5.2: A receives the BFD packet from B with IHY set to 1 and ignores the packet (waits for IHY = 0)
T=5.5: A reaches its next scheduled BFD transmission slot and sends a BFD packet to B
T=5.6: B receives the BFD packet from A with IHY set to 0 and drops the packet (waits for IHY = 1)
T=6.1: B reaches its next scheduled BFD transmission slot and sends a BFD packet to A
T=6.2: A receives the BFD packet from B with IHY set to 1 and ignores the packet (waits for IHY = 0)
T=6.5: A reaches its next scheduled BFD transmission slot and sends a BFD packet to B
T=6.6: B receives the BFD packet from A with IHY set to 0, drops the packet, and changes from Init to Failing due to detection timeout
[A: Failing, B: Failing]
T=6.6: B sends a BFD packet to A straight away
T=6.7: A receives the BFD packet from B with IHY set to 0 and changes from Failing to Down
[A: Down, B: Failing]

This loop would continue indefinitely, however, the loop would be avoided if a BFD packet was sent immediately following a state transition from Failing to Down, i.e. -

T=3.3: B receives the BFD packet from A with IHY set to 0 and changes from Failing to Down
[A: Failing, B: Down]
T=3.3: B sends a BFD packet to A straight away
T=3.4: A receives the BFD packet from B with IHY set to 0 and changes from Failing to Down
[A: Down, B: Down]
T=3.4: A sends a BFD packet to A straight away
T=3.5: B receives the BFD packet from A with IHY set to 0 and changes from Down to Init
[A: Down, B: Init]
T=3.5: B sends a BFD packet to A straight away
T=3.6: A receives the BFD packet from B with IHY set to 1 and changes from Down to Up
[A: Up, B: Init]
T=3.6: A sends a BFD packet to A straight away
T=3.7: B receives the BFD packet from A with IHY set to 1 and changes from Init to Up
[A: Up, B: Up]

Perhaps I have missed something or there is a mistake in the scenario I describe above. However, if not then it would appear to me that if BFD packets are sent between scheduled transmissions for 'Down to Up or Init', and 'Up to Failing' state transitions, then they must also be sent following a state transition from 'Failing to Down' to avoid a loop occurring. 

Confirmation either way would be greatly appreciated.

Thanks,
Richard