Re: [Ospf-manet] URL for MPR-extension software

Richard Ogier <> Fri, 22 December 2006 00:50 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GxYc9-0003a3-D9; Thu, 21 Dec 2006 19:50:21 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1GxYc8-0003Zx-30 for; Thu, 21 Dec 2006 19:50:20 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1GxYc6-00030D-S7 for; Thu, 21 Dec 2006 19:50:20 -0500
Received: from ([] by with esmtp (Exim 3.36 #1) id 1GxYc2-0004jx-00; Thu, 21 Dec 2006 19:50:14 -0500
Message-ID: <>
Date: Thu, 21 Dec 2006 16:50:08 -0800
From: Richard Ogier <>
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: Emmanuel Baccelli <>
Subject: Re: [Ospf-manet] URL for MPR-extension software
References: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions of OSPFv3 extensions supporting MANET <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

A few more points...

Emmanuel Baccelli wrote:

> Richard,
> Adjacency reduction is indeed an interesting approach that is present 
> in various ways in the three solutions OR, MPR and MDR. The 
> specificity of the MPR solution is that it brings topology reduction 
> too,  in a way compliant with the usual "route on adjacencies only".

The above statement is misleading or incorrect in a number of ways.
OSPF does not "route on adjacencies only".   You know this since
your draft states:

>    Similarly to the broadcast interface, the next hop in the
>    forwarding table may be a neighbor that is not adjacent.  However,
>    when a data packet is further than its first hop, the MPR selection
>    process guarantees that the next hops in the SPT will be over
>    adjacencies.

Even if the rule is "route on adjacencies except for the first hop",
this is not true for OSPF, since an intermediate hop can also be
over a non-adjacent link.  But each hop is at least indirectly
synchronized in OSPF, which is NOT true for your proposal.  This
is why you need something like the concept of "routable" neighbors,
used by the other proposals.

So, you can't claim that your solution is "compliant with the
usual route on adjacencies only" rule, since OSPF has no such
rule.  OSPF does require that each hop, including the first hop,
be indirectly synchronized, and the concept of "routable neighbors"
is used to achieve this in OSPF-MDR.  But your solution does not guarantee
that the first hop is even indirectly synchronized (e.g., following
the recovery of a network partition), although you could add this

Your solution does result in more hops being directly synchronized,
but as a result you lose scalability.


Ospf-manet mailing list