IETF Logo Mail Archive

Re: Question about REAP state transition (draft-ietf-shim6-failure-detection-09)

Iljitsch van Beijnum <iljitsch@muada.com> Thu, 14 February 2008 15:37 UTC

Return-Path: <owner-shim6@psg.com>
X-Original-To: ietfarch-shim6-archive-oY2iet1p@core3.amsl.com
Delivered-To: ietfarch-shim6-archive-oY2iet1p@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1887F28CEE7 for <ietfarch-shim6-archive-oY2iet1p@core3.amsl.com>; Thu, 14 Feb 2008 07:37:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.375
X-Spam-Level:
X-Spam-Status: No, score=-4.375 tagged_above=-999 required=5 tests=[AWL=1.925, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Oa3O2Sx8ptk for <ietfarch-shim6-archive-oY2iet1p@core3.amsl.com>; Thu, 14 Feb 2008 07:37:30 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id CB1F928CEAD for <shim6-archive-oY2iet1p@lists.ietf.org>; Thu, 14 Feb 2008 07:37:30 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from <owner-shim6@psg.com>) id 1JPftk-000G9J-Nl for shim6-data@psg.com; Thu, 14 Feb 2008 15:21:16 +0000
Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <iljitsch@muada.com>) id 1JPftg-000G7W-Ui for shim6@psg.com; Thu, 14 Feb 2008 15:21:15 +0000
Received: from nirrti.it.uc3m.es (nirrti.it.uc3m.es [163.117.139.57]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m1EFKLSo085571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Feb 2008 16:20:21 +0100 (CET) (envelope-from iljitsch@muada.com)
Cc: shim6@psg.com
Message-Id: <4819DD1A-138C-48CC-B7F6-45D54DB2FB4A@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Alberto García <alberto@it.uc3m.es>
In-Reply-To: <006201c86f06$022efd60$7d8b75a3@bombo>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Question about REAP state transition (draft-ietf-shim6-failure-detection-09)
Date: Thu, 14 Feb 2008 16:20:40 +0100
References: <00a901c83cda$348270c0$7d8b75a3@bombo> <F2BAA8B3-38D1-4A8C-BF8E-1B0B149730E4@muada.com> <00e501c84180$0e0e59e0$7d8b75a3@bombo> <CEF283EA-89D2-4D16-B6E8-46C7BF702556@muada.com> <00ba01c867e0$fece0930$7d8b75a3@bombo> <69689EBC-DE88-431F-B67D-86CD90BB0F26@muada.com> <006201c86f06$022efd60$7d8b75a3@bombo>
X-Mailer: Apple Mail (2.919.2)
Sender: owner-shim6@psg.com
Precedence: bulk

On 14 feb 2008, at 13:34, Alberto García wrote:

> Some time after A is not receiving anymore data from B, the Send  
> timer at A
> expires. Then, A moves from Inbound_ok to the Exploring state,

The way I see it, you don't go from Inbound_OK to Exploring. The text  
"received incoming probe since the last transition from Operational to  
Exploring" is consistent with that and not with the situation where  
Inbound_OK -> Exploring is possible.

However, the advantage of allowing Inbound_OK -> Exploring is that  
this can work around the situation where a second failure breaks even  
more a short time after the first failure.

On the other hand, this should be rare and eventually, the protocol  
will converge on what's still working even though selecting a new  
unidirectional address pair that stops working before the address pair  
for the other direction will lead to some extra delays.

Iljitsch

v2.23.0 | Report a Bug | By Email