[Ospf-wireless-design] Accelerating convergence when OSPF-MDR is started

Richard Ogier <rich.ogier@earthlink.net> Tue, 01 November 2005 18:48 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX1BO-00059C-2I; Tue, 01 Nov 2005 13:48:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX1BL-00058w-IH for ospf-wireless-design@megatron.ietf.org; Tue, 01 Nov 2005 13:48:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07665 for <ospf-wireless-design@ietf.org>; Tue, 1 Nov 2005 13:48:06 -0500 (EST)
Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX1Pl-00076w-UH for ospf-wireless-design@ietf.org; Tue, 01 Nov 2005 14:03:23 -0500
Received: from dialup-4.243.128.137.dial1.sanfrancisco1.level3.net ([4.243.128.137] helo=earthlink.net) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EX1BE-0005sx-00 for ospf-wireless-design@ietf.org; Tue, 01 Nov 2005 13:48:20 -0500
Message-ID: <4367B870.5050605@earthlink.net>
Date: Tue, 01 Nov 2005 10:48:16 -0800
From: Richard Ogier <rich.ogier@earthlink.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202)
X-Accept-Language: en-us
MIME-Version: 1.0
To: ospf-wireless-design@ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.9 (++)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: 7bit
Cc:
Subject: [Ospf-wireless-design] Accelerating convergence when OSPF-MDR is started
X-BeenThere: ospf-wireless-design@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: OSPF Wireless Design Team <ospf-wireless-design.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf-wireless-design>, <mailto:ospf-wireless-design-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <https://www1.ietf.org/mailman/private/ospf-wireless-design>
List-Post: <mailto:ospf-wireless-design@lists.ietf.org>
List-Help: <mailto:ospf-wireless-design-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf-wireless-design>, <mailto:ospf-wireless-design-request@lists.ietf.org?subject=subscribe>
Sender: ospf-wireless-design-bounces@lists.ietf.org
Errors-To: ospf-wireless-design-bounces@lists.ietf.org

On the OSPF mailing list, Acee wrote the following on 10/26/05 under
the subject "accelerating convergence when ospf starting".

> A better optimization (at the expense of a greater risk that DR churn
> will result) would be to allow the wait-timer interval to be
> configurable to a value
> (hello-interval <= wait-interval <= dead-interval).

I like this for OSPF-MDR and would like to include it in the
next version of the draft.
The current OSPF-MDR draft currently specifies that the Wait Timer
interval is RouterDeadInterval. (A router must wait this interval
before running the MDR selection algorithm.)

In OSPF-MDR, the default for HelloInterval is 2 seconds, and the
default for RouterDeadInterval is 6 seconds, so we are talking
about waiting 2 seconds instead of 6 seconds.  However, some
applications may wish to use a larger HelloInterval.

I know that details such as this are not as important as
achieving consensus on the core approach, but I am also
interested in getting a good OSPF extension designed without
further delays. To this end, I welcome comments
and suggestions for improving the draft.

Now regarding consensus, only one person (Emmanuel) commented
that MPRs (overlapping relays) should still be considered,
offering two possible methods for using MPRs.

(1) Form a CDS by pruning MPRs.
(2) Use MPRs for flooding, with each node forming adjacencies
    with its MPRs.

I think that the simulations of Phil and myself show that (2) is
not a viable solution, partly because it results in too many
adjacencies and too many new adjacencies per second.
Since nobody has disputed these conclusions, it appears that
we have consensus that method (2) can be removed from consideration.

That leaves method (1), which can be implemented by modifying
OSPF-MDR to select MDRs based on MPRs (as I described in a previous
message).  Therefore, I suggest that we agree to use the OSPF-MDR
draft as a starting point for the core approach, and evaluate potential
improvements to the design, including the use of MPRs to select MDRs.

In the interest of avoiding further delays, people should speak up
now if they have a good reason why another existing design is
preferable.  Such a design should be specified with enough detail to
implement in the GTNetS code, so it can be compared with OSPF-MDR.

Richard










_______________________________________________
Ospf-wireless-design mailing list
Ospf-wireless-design@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design