[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