[Ospf-wireless-design] Synchronization requirement for including a neighbor in LSA
Richard Ogier <rich.ogier@earthlink.net> Thu, 31 March 2005 20:18 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 PAA01558; Thu, 31 Mar 2005 15:18:09 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH6ES-0005j8-UE; Thu, 31 Mar 2005 15:25:37 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH67B-0003yh-MG; Thu, 31 Mar 2005 15:18:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH679-0003yb-TY for ospf-wireless-design@megatron.ietf.org; Thu, 31 Mar 2005 15:18:03 -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 PAA01543 for <ospf-wireless-design@ietf.org>; Thu, 31 Mar 2005 15:18:02 -0500 (EST)
Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH6EK-0005j3-9w for ospf-wireless-design@ietf.org; Thu, 31 Mar 2005 15:25:29 -0500
Received: from dialup-4.243.134.28.dial1.sanfrancisco1.level3.net ([4.243.134.28] helo=earthlink.net) by pop-a065c10.pas.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DH672-0002WS-00 for ospf-wireless-design@ietf.org; Thu, 31 Mar 2005 12:17:56 -0800
Message-ID: <424C5AE1.5030109@earthlink.net>
Date: Thu, 31 Mar 2005 12:17:37 -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: 0.1 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Subject: [Ospf-wireless-design] Synchronization requirement for including a neighbor in LSA
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@ietf.org
Errors-To: ospf-wireless-design-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit
All, I want to discuss the definition of a "synchronized" neighbor in Section 5 of my draft, and explain why I think this is a good requirement for a neighbor to be included in the router LSA. This condition is valid for both full-topology and partial-topology LSAs, so the discussion below applies to either case. First, I am assuming that a set of adjacencies has been formed that spans the entire network, so that there exists a (suboptimal) path from each router to every other router via adjacent edges (except temporarily as new adjacencies are formed in response to topology changes). Each router will include, at a minimum, each fully adjacent neighbor in its router LSA. This will provide suboptimal routes to each reachable router. The question is, what other neighbors can be included in the router LSA? Suppose that node i has a non-adjacent, 2-way neighbor j, and that the SPF calculation has calculated a route to node j via a fully adjacent neighbor k. Then node i can route data packets to neighbor j via neighbor k. (Or, neighbor j might not be the final destination, but might be an intermedate node to another destination.) So, instead of using neighbor k as the next hop, why not take a shortcut and forward the data packet directly to neighbor j as the next hop? This is quite reasonable, and is exactly what the synchronized neighbor rule says. Once neighbor j has been declared to be an acceptable next hop (to any destination), it can be included in node i's router LSA. Note that this is a generalization of what is allowed in an OSPF broadcast network, which allows a non-DR/BDR i to use another non-DR/BDR j as a next hop as long as both are fully adjacent to the DR. In a broadcast network, there is no need for node i to include node j in its LSA, since the network LSA originated by the DR already implies this information. But when we generalize to a multihop network, the only way node i can inform other routers that it can forward packets to node j, is to include node j in its router LSA. A possible concern: What if, after declaring node j to be an acceptable next hop, there temporarily does not exist a path of fully adjacent edges to node j, due to topology changes? The above rule does not detect this and does not remove node j as an acceptable next hop (unless node j is no longer reachable). The answer is that the protocol will be robust enough (if designed properly) to maintain sufficient database synchronization even when topology changes cause old adjacencies to fail and require new adjacencies to be formed. The only case where routers may not be acceptably synchronized is when the network partitions, i.e., some destinations become temporarily unreachable. The above rule will detect this, since it requires a neighbor to be reachable via a current path that has already been determined to be acceptable. I plan to implement the above method in the next few weeks, so we will see how it peforms. Richard _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design
- [Ospf-wireless-design] Synchronization requiremen… Richard Ogier
- Re: [Ospf-wireless-design] Synchronization requir… Acee Lindem
- Re: [Ospf-wireless-design] Synchronization requir… Richard Ogier
- Re: [Ospf-wireless-design] Synchronization requir… Richard Ogier
- [Fwd: [Ospf-wireless-design] Synchronization requ… Richard Ogier