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

[Richard Ogier <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf-manet