Re: [Ospf-manet] MPR-OSPF GTNetS simulations report

Richard Ogier <rich.ogier@earthlink.net> Tue, 06 February 2007 18:20 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEUw7-0000D1-RH; Tue, 06 Feb 2007 13:20:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEUw6-0000Cu-El for ospf-manet@ietf.org; Tue, 06 Feb 2007 13:20:58 -0500
Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEUw5-00033L-6D for ospf-manet@ietf.org; Tue, 06 Feb 2007 13:20:58 -0500
Received: from dialup-4.245.102.66.dial1.sanjose1.level3.net ([4.245.102.66]) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1HEUw2-0007TU-00; Tue, 06 Feb 2007 13:20:55 -0500
Message-ID: <45C8C704.8020908@earthlink.net>
Date: Tue, 06 Feb 2007 10:20:52 -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>
Subject: Re: [Ospf-manet] MPR-OSPF GTNetS simulations report
References: <45B5D944.9010303@inria.fr> <45BD37DF.1050005@earthlink.net> <45C38419.7070208@inria.fr>
In-Reply-To: <45C38419.7070208@inria.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc: ospf-manet@ietf.org
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,

As I mentioned, the min-cost LSA algorithm will be modified in the
next draft update, which may affect some of your comments, so I
prefer that you comment on the updated version when it comes out.
(I don't plan any MDR presentation at the Prague meeting, so the
next draft update might not come until after the meeting.)

Also note that the simulation results will not be affected
significantly by modifying the min-cost LSA algorithm, since the
LSU overhead will remain low.  The main issue addressed by the
simulations is the large overhead when MPR adjacency reduction
is used.

I address your comments below.

Philippe Jacquet wrote:

> Dear Richard,
>
> The simulation code about minCost LSA (in ospf6_neighbor.c, in int 
> ospf6_mdr_update_adv_neighbors(struct ospf6_interface *oi)) contains 
> the sequence of instructions:
>
>       // Determine costs to j and k (as would be advertised in LSA)
>       if (onj->state == OSPF6_NEIGHBOR_FULL) costj = 10;
>       else costj = 11;
>       if (onk->state == OSPF6_NEIGHBOR_FULL) costk = 10;
>       else costk = 11;
>
> I understand that it implicitly gives priority to full neighbors. 
> Instead of artificially distorting link cost, could it not be an idea 
> to be more explicit in the draft by using the sentence (page 55-56 in 
> clause 5) b) and c):


I don't agree that this artificially distorts link costs.
I think it is a good idea to give fully synchronized neighbors
a lower cost, simply because they are more likely to provide good
routes.  Actually, I would not fix the cost at 10 or 11, but
would add 1 to the metric of any neighbor that is not Full.
The draft does not specify how to select metrics, so
the implementation is free to do this.

>
> If HCM(j,i) + metric(i,k) < HCM(j,u) + LCM(u,k), or if u does
> not exist and HCM(j,i) + metric(i,k) < HCM(j,k), or if k is a full 
> neighbor, add k to the set of advertised neighbors.


Step 4 already adds all Full neighbors to the set of
advertised neighbors, so your modification has no effect.
(The goal is that if node i advertises Full neighbor k, then
node u should not advertise k if it is not Full.)

>
> But of course it will not be possible to know about the adjacencies 
> between the other nodes (u,k) or (j,u), other than by specific 
> advertizement via a specific TLV in hellos.


That is why it is useful to add 1 to the metric of neighbors
that are not Full.

Actually, the DNL (dependent neighbor list) TLV implies information
about other adjacencies, and the updated min-cost LSA algorithm may
use this information.  However, these details have a small effect
on performance, compared to adjacency reduction.

>
>
> I also have difficulties to see how the option 
> OSPF6_LSA_FULLNESS_MINHOP (LSAFullness=1?) works. It seems that the 
> link cost distortion causes to advertize no more than the full 
> neighbors (like in LSAFullness=0?)


The use of 11 instead of 10 for a link metric would not affect the
number of hops in computed paths, unless the path has at least 10
hops.  (A 10-hop path with all links having metric 11 would have the
same length as an 11-hop path with all links having metric 10.)
Since Full neighbors alone do not provide min-hop paths, some
non-Full neighbors will also have to be advertised.  Maybe I
do not understand your question.  In any case, it might be better
to wait for the updated min-cost LSA algorithm.

Richard

> and not the minCost path as specified in the MDR draft. It seems that 
> OSPF6_LSA_FULLNESS_MINHOP2PATHS (LSAFullness=2) is the right option 
> that provides shortest path. Therefore when you run the code with 
> option LSAFullness=1, one would not get mincost LSA's -- is that 
> correctly understood?


>
> Philippe
>


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