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

[Philippe Jacquet <[e-mail]>]

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):

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.

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.


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?) 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

Richard Ogier a écrit :
> Emmanuel,
> 
> Regarding your simulation results, it looks like using
> MPR adjacency reduction does not reduce overhead much,
> and based on the simulation results I presented recently,
> MDR with adjacency reduction has much lower overhead.
> 
> I think you would have to make major changes to your draft
> before it is competitive with MDR.  For example, you will at
> least have to select MPRs (and "path MPRs" for LSAs) to be more
> stable, which has not yet been described in your draft.
> 
> The MDR draft does not need major changes, but I am making
> changes to improve readability, to simplify the BMDR algorithm,
> and other minor changes such as improving min-cost LSAs.
> This does not change the core methods for flooding and adjacency
> reduction, which have been stable for about two years.
> 
> My point was that, since MPR adjacency reduction is not scalable,
> the main contributions of your draft are MPR LSA reduction
> and multicast retransmitted LSAs (the latter of which is not
> new and was considered in version 00 of the MDR draft), and
> that these two contributions do not by themselves constitute
> an OSPF extension, but are techniques that can be applied
> to either ORs or MDRs.
> 
> I mentioned that I will experiment with multicast retransmitted
> LSAs to see if they improve the performance of MDRs in some
> scenarios, and if they do they can be included as an option.
> This would be a minor change to the MDR draft.
> 
> After we have both finalized our drafts, we should continue
> our discussion then, and perform a fair simulation comparison.
> Until then, I suggest we take a break from this discussion.
> 
> Richard
> 
> 
> 
> Emmanuel Baccelli wrote:
> 
>> Dear Richard,
>>
>> We agree that there is no need to argue. The MPR-OSPF is a consistent
>> extension of OSPFv3 that uses flooding reduction, topology reduction and
>> adjacency reduction based on MPR, with a stable specification ready for
>> experimental status.
>>
>> You suggest that you could introduce some changes in MDR, taking
>> advantage of the experimental status. We do not think that it is needed
>> to introduce the major changes you mentionned (such as including MPR
>> topology reduction or multicast) since they are already featured in the
>> MPR-OSPF extension. However, if you think MDR needs major changes, then
>> MDR is not ready for experimental status.
>>
>> Emmanuel
>>
>>
>> _______________________________________________
>> Ospf-manet mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/ospf-manet
>>
> 
> 
> _______________________________________________
> Ospf-manet mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ospf-manet
> 
> 

_______________________________________________
Ospf-manet mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf-manet