[Ospf-manet] Regarding MPR-OSPF

Richard Ogier <rich.ogier@earthlink.net> Mon, 19 February 2007 17:36 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJCRB-00036r-L9; Mon, 19 Feb 2007 12:36:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJCRA-00036j-J0 for ospf-manet@ietf.org; Mon, 19 Feb 2007 12:36:28 -0500
Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJCR8-0005g7-AL for ospf-manet@ietf.org; Mon, 19 Feb 2007 12:36:28 -0500
Received: from dialup-4.245.103.179.dial1.sanjose1.level3.net ([4.245.103.179]) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1HJCQy-0000ha-00; Mon, 19 Feb 2007 12:36:17 -0500
Message-ID: <45D9E011.1010600@earthlink.net>
Date: Mon, 19 Feb 2007 09:36:17 -0800
From: Richard Ogier <rich.ogier@earthlink.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philippe Jacquet <philippe.jacquet@inria.fr>
References: <45B5D944.9010303@inria.fr> <45BD37DF.1050005@earthlink.net> <45C38419.7070208@inria.fr> <45C8C704.8020908@earthlink.net> <45CC98B1.8060907@inria.fr> <45CCD19B.9070604@earthlink.net> <45D31ECA.50007@inria.fr> <45D4BD6A.3000009@earthlink.net>
In-Reply-To: <45D4BD6A.3000009@earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: ospf-manet@ietf.org
Subject: [Ospf-manet] Regarding MPR-OSPF
X-BeenThere: ospf-manet@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions of OSPFv3 extensions supporting MANET <ospf-manet.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf-manet>, <mailto:ospf-manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf-manet>
List-Post: <mailto:ospf-manet@ietf.org>
List-Help: <mailto:ospf-manet-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf-manet>, <mailto:ospf-manet-request@ietf.org?subject=subscribe>
Errors-To: ospf-manet-bounces@ietf.org

Philippe,

I noticed two possible problems with your GTNetS code for MPR-OSPF.
The first one regards the following code in need_adjacency():

#ifdef OSPF6_MANET_MPR_ADJ_REDUC_OSPF_MPR
        if (on->ospf6_if->synchNode)
          return 1;

        if (ospf6_lookup_relay_selector(on->ospf6_if, on->router_id))
          return 1;
        else
          return 0;
#endif //OSPF6_MANET_MPR_ADJ_REDUC_OSPF_MPR

The above code code says that the router forms an adjacency with
a neighbor only if the router is a synch node or the neighbor
is an MPR selector.  This can cause unidirectional adjacencies,
as explained below.  (A similar problem with the OSPF-MDR code
was discovered and corrected over a year ago.)

Suppose node i forms an adjacency with node j either because
node i is a synch node or node j is an MPR selector.
Suppose that node j later misses a few Hellos from node i,
so that node j changes the state of neighbor i to Down and then
to 2-Way, without sending a Hello that indicates neighbor i is Down
(or perhaps node j sends one such Hello that is not received by i).
Node j does not consider node i adjacent, since j is not a
synch node and i is not an MPR selector. (The need_adjacency()
condition is not symmetric.)

Also suppose that node i never misses any Hellos from node j (or misses
only one Hello from j).  Then node i will still think node j is fully
adjacent, even though node j does not consider node i adjacent.
Thus, a unidirectional adjacency can exist.

Therefore, it is necessary for the need_adjacency condition to be
symmetric. I.e., node i should consider node j adjacent if and only
if node j considers node i adjacent. More specifically, need_adjacency()
should also return true if the neighbor is a synch node or an MPR.
(Notice that the need_adjacency condition is symmetric in RFC 2328.)

The other problem I noticed regards the selection of synch routers.
Your GTNetS code does not agree with your draft.
In your code, only one router in the entire network (area) is
selected as a synch node, i.e., the one with the largest RID.
This does not agree with your draft, which says:

 >   A router decides it is a synch router if and only if:
 >   o  the router is a wireless router that has the highest willingness
 >      in its neighborhood (in case of ties, the router that also has the
 >      greatest ID is elected).


Also, what if the router with the largest (willingness, RID) is not
a MANET router?  And what if you have multiple MANET interfaces,
in addition to non-MANET interfaces?
I think you are safer if you consider only MANET neighbors on a
given interface when deciding whether a router is a synch router
(as in your draft).
I realize that this would result in more adjacencies and more
overhead, but it may also improve robustness.
Also, if you select only a single synch router (as in your code), it is
not clear how to extend this to multiple interfaces or networks that
include non-MANET interfaces.  Please let us know which rule you
plan to use for selecting synch routers.

Richard


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