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.
- Question about REAP state transition (draft-ietf-… Alberto García
- Re: Question about REAP state transition (draft-i… Iljitsch van Beijnum
- RE: Question about REAP state transition (draft-i… Alberto García
- Re: Question about REAP state transition (draft-i… Iljitsch van Beijnum
- RE: Question about REAP state transition (draft-i… Alberto García
- Re: Question about REAP state transition (draft-i… Iljitsch van Beijnum
- RE: Question about REAP state transition (draft-i… Alberto García
- Re: Question about REAP state transition (draft-i… Iljitsch van Beijnum