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

Alberto García <alberto@it.uc3m.es> Tue, 05 February 2008 18:52 UTC

Return-Path: <owner-shim6@psg.com>
X-Original-To: shim6-archive-oY2iet1p@lists.ietf.org
Delivered-To: ietfarch-shim6-archive-oY2iet1p@mail.ietf.org
Received: by mail.ietf.org (Postfix, from userid 51) id 35CA53A7809; Tue, 5 Feb 2008 10:52:51 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by mail.ietf.org (Postfix) with ESMTP id 6CC783A9714 for <shim6-archive-oY2iet1p@lists.ietf.org>; Tue, 5 Feb 2008 02:38:34 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from <owner-shim6@psg.com>) id 1JMKwi-000HgP-I3 for shim6-data@psg.com; Tue, 05 Feb 2008 10:22:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,RCVD_BAD_ID, RDNS_NONE autolearn=no version=3.2.3
Received: from [163.117.176.132] (helo=smtp02.uc3m.es) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <alberto@it.uc3m.es>) id 1JMKwc-000HfS-AU for shim6@psg.com; Tue, 05 Feb 2008 10:22:27 +0000
Received: from bombo (bombo.it.uc3m.es [163.117.139.125])by smtp02.uc3m.es (Postfix) with ESMTP id 51D682F7F6A;Tue, 5 Feb 2008 11:22:22 +0100 (CET)
From: Alberto García <alberto@it.uc3m.es>
To: 'Iljitsch van Beijnum' <iljitsch@muada.com>
Cc: shim6@psg.com
References: <00a901c83cda$348270c0$7d8b75a3@bombo> <F2BAA8B3-38D1-4A8C-BF8E-1B0B149730E4@muada.com> <00e501c84180$0e0e59e0$7d8b75a3@bombo> <CEF283EA-89D2-4D16-B6E8-46C7BF702556@muada.com>
Subject: RE: Question about REAP state transition (draft-ietf-shim6-failure-detection-09)
Date: Tue, 05 Feb 2008 11:22:22 +0100
Message-ID: <00ba01c867e0$fece0930$7d8b75a3@bombo>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <CEF283EA-89D2-4D16-B6E8-46C7BF702556@muada.com>
Thread-Index: AchkAmSRMPaM8dL5TOWyweIzGVXIogD3I6Gg
X-imss-version: 2.049
X-imss-result: Passed
X-imss-scanInfo: M:B L:N SM:2
X-imss-tmaseResult: TT:1 TS:-15.8649 TC:1F TRN:44 TV:5.0.1023(15710.003)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
Sender: owner-shim6@psg.com
Precedence: bulk

Hi,
It is nice to clarify that information related to the received probes should
be included in the probes sent in the InboundOK state.

However, I still think that these information MUST be included also if
available in the Exploring state (and not optionally, in "MAY"-style). 

Otherwise (I copy a part of a previous mail with an example in which the
lack of this information in the probes sent in the Exploring state makes
impossible to recover the communication) "if it is possible that the
exploration process could not find two valid unidirectional paths (on each
direction) even if they exist. Suppose that a node A in Exploring state
receives a Probe Exploring, so it moves to Inbound_OK. For the next Probes
it sends, it includes the information about the valid locators for its
incoming paths (B to A), but it is not able to find a working path from A to
B for some time.
In B, the Retransmission Timer of B expires because a valid path from A to B
was not found, so B starts testing other paths that are not working. Then, A
stops receiving data from B, so the Send timer expires (I don't find any
reason why all the possible paths should be explored in less than Send
Timeout time, so A could not test all possible paths from A to B in this
time). Then, A falls to the Exploring state, and (in the supposition of the
previous paragraph) forgets about the working path from B to A. May be now A
sends a probe to B through a working path. but in B happens the same (it
tries now with different paths from B to A that are no valid, so A tries
another paths from A to B abandoning the good one...). In this case, two
valid unidirectional paths existed, one from A to B, and other from B to A,
but the protocol could not find them, because they not were known at the
same time by both nodes."

Any reason why you consider this information should not be mandated to be
included?

Best regards,
Alberto

|  -----Mensaje original-----
|  De: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
|  Enviado el: jueves, 31 de enero de 2008 13:11
|  Para: Alberto García
|  CC: shim6@psg.com
|  Asunto: Re: Question about REAP state transition
(draft-ietf-shim6-failure-
|  detection-09)
|  
|  Alberto,
|  
|  it's been a long time, so I'm not entirely sure if I missed something
|  else in your message. Please let me know if that's the case. I want to
|  change this text:
|  
|  <t hangText='Precvd'><vspace blankLines='1'/>
|  
|  This is a 4-bit field that indicates the number of received probes
|  included in this probe message. Received probe fields are copies of the
|  same fields received in (recent) earlier probes and may be included or
|  omitted as per any logic employed by the implementation.
|  
|  
|  to:
|  
|  
|  <t hangText='Precvd'><vspace blankLines='1'/>
|  
|  This is a 4-bit field that indicates the number of received probes
|  included in this probe message. Received probe fields are copies of the
|  same fields in earlier received probes that arrived since the last
|  transition from state Operational to state Exploring. When a sender is
|  in state InboundOk it MUST include copies of the fields of at least
|  one the inbound probe. A sender MAY include additional sets of these
|  received probe fields in any state as per any logic employed by the
|  implementation.
|  
|  
|  I think this addresses the problem where two unidirectional paths
|  wouldn't be found.